怎样才能做出一款合适的产品？
有个朋友在后台留言，让我写一写“产品系统设计”相关的内容，这个话题我也确实一直在思考。不过仍有点犹豫，因为我自己也没有完全想清楚，所以一直也没有动笔。但心里一旦长了草，就难免有点牵肠挂肚，拖着也没有减轻我的焦虑，所以结合这一两年踩过的坑，试着记录一下相关的思考。
我理解的“产品系统设计”应该包括产品的多个周期管理，以及在每个阶段应重点考虑的事情。
一
首先当然是产品必须要有用户需求，以及用户真正的需求是什么。用户需求最有代表性的一个例子是“赛格威”，这款产品拥有优秀的工程学设计以及漂亮的外观设计，但产品的商业计划是基于一系列不确定性的假设，以及过大地估计了目标市场的规模。
所以，在开始昂贵的产品开发之前，我们最需要做的事情就是确认用户需求并检查你对市场和产品的假设以减少风险。作为产品经理，首先要质疑一个新产品的基本观点，并通过一系列工具将需求工作落到实处，认真评估用户是否有足够的动力去真正使用该产品。
需求往往是隐藏的，自带含混性，我们往往意识不到。如何深刻地理解人们真正想要解决的问题并知道为什么，是这个部分最重要的事情。此部分可参考的书是清华大学出版社出版的《探索需求-设计前的质量》，其核心内容就是探讨如何降低需求的含混性。另外，可以通过一些问题来设问自己。
它是普遍性的吗？具体是哪些人有这样的难题，会影响很多人吗？
它是亟待解决的吗？人们希望马上解决这一难题，还是可以等等看？
它有替代解决办法吗？
它是有价值的吗？这个难题究竟让人们有多头疼，他们愿意花钱解决它吗？
它有利可图吗？我们解决该难题的成本比难题本身的价值多还是少？
失败案例：2015年我刚接手一款产品时就犯了一个典型错误，当时公司计划推出一款新的硬件产品，我们就想当然地假设我们能获得多少市场份额，对自己的技术也有信心，投入人财物后，产品是做出来了，但一直没有销量。原因有几个方面，一是市场容量有限；二是产品使用低频；三是客户接受度偏向于进口产品，扭转这个认知需要耗费过多的资源；四是客户可以选择其他方式间接代替产品；这些原因叠加起来，公司市场部就没有意愿和动力去推广，产品就变成了鸡肋。
二
初步确定产品在市场中的定位和需求后，接下来我的经验是快速做出一个产品原型。
目前流行的做法是创建一个最小可行产品（Minimum Viable Product，简称MVP），用于早期市场投放，测试产品是否有效地解决某一市场难题。但在实际执行中，我发现这一方法时常被误用。比如：因为进度控制或者技术未突破，最小可行产品有缺陷，又或者需求存在含混，导致最小可行产品并没有验证真正的问题，而是变成了公司内部不得不定期升级的产物。
埃里克·莱斯在《精益创业》中提到，尽管设计到最简，一个真正的最简可行产品也必须是商业上可行的，而不是一个半吊子的废物。人们应当对该产品十分满意，愿意出钱购买。如果我们的最小化可行产品变成了销售产品而并没有满足客户的需求，导致客户抱怨或退换货，这就给后续带来了无穷尽的麻烦。很多产品一旦涉及到成本，如果失败一次，再进行第二次迭代便面临诸多困难。所以，在最小可行产品之前用更简单的原型来测试产品的各方面是一个好办法。
谷歌眼镜的原型设计是一个绝佳的例子。来自谷歌X的汤姆·齐，仅仅花了几分钟就用建模的电线和几团用来增加重量的橡皮泥创建了最初的原型。通过这个快速的可用性测试，他得知了这个装置不会伤到耳朵的最大重量。他也得知，鼻梁可以舒适地承受的重量比耳朵大一些。这就是谷歌眼镜在鼻梁处设计稍重的原因。
另外，谷歌眼镜的手势交互细节，也是通过快速的原型测试，验证了若要感觉舒适，手势的交互需要出现在视野里，双手不能高过心脏，因为那样坚持几分钟，乳酸就会开始增多，你的胳膊会迅速地变得疲劳和酸痛。
三
接下来需要做的是结合需求探索、原型设计及验证，对产品进行快速迭代。此部分我们目前采用的是IPD开发流程，目前国内做得比较好的公司是华为。在这个阶段，核心是“系统思考”，钱学森对“系统”的定义为：
极其复杂的研究对象称为系统，即相互作用和相互依赖的若干组成部分结合成的具有特定功能的有机整体，而且这个系统又是它所从属的更大系统的组成部分。
系统中，需要综合把各个环节考虑到，需求、规格、项目计划与执行等。另外，需要考虑系统构件、系统分解结构和系统架构。用两张图来体现，大概是这个样子。
案例：结合我自己的经验来说，在此阶段，我重点考虑的事情主要是输入、输出。谁来提供输入、输入的标准是什么，团队输出什么、输出要达到什么样的指标，我们的“相关利益者”，他们的预期是什么等。
典型问题：
综合设计及成本控制，指的是在设计前需要有一个整体的系统设计方案。以一款硬件为例，需要考虑整个供应链的情况，我们之前自己设计的感觉很好，但供应商加工完则问题一大堆，有可能是工艺水平达不到，有可能是精度控制不达标，所以在前期就需要综合考虑产品的定位和供应商的加工水平，以整体成本来衡量，也许我们降低了采购成本，但如果后期的制造成本、维护成本大幅提升，这就不是一个好的系统设计。
需求变更管理，产品设计过程中，可能因为前期遗漏或者论证不充分，导致需求需要变更，这也是开发过程中经常遇到的问题。此时，一是需要去验证需求变化的背后深层次原因，谋定而后动，可以用“5问法”去追究根本原因，找到用户背后真正的动机；二是一旦确定更改，则拥抱变化，用最快的速度来实现并验证。
创造场景和用户形象，指的是你需要深入了解你的用户，与他们产生同理心，知道他们在何种情境中使用产品。这个问题的答案来自外部，我们需要去体验客户的真正使用场景，和他们对话和交谈，继续了解他们日常生活、习惯和所处环境：他们往往在何时何地遇到这个难题。这些可以为我们产品的交互以及使用场景提供可供参考的框架。
此阶段的要求其实和需求阶段类似，给前期设计预留出足够多的思考和讨论时间，不在含混的地方贸然下结论，可以通过组内充分论证、单元测试等方法降低后期的风险，也即是说：需要更多的前期努力，而不仅仅是努力，因为越是到项目后期，改变的成本都是指数级增长。
四
在产品设计过程中，还有一个经常会犯的错误是堆叠功能。越是到产品开发的后期，领导的一句“我认为……”、开发人员的奇思妙想或者来自竞争对手的新功能上线，这些内部或外部信息时刻冲击着产品经理脆弱的神经。于是不自觉地新增功能模块，并自以为代表了客户。
对产品经理而言，负责一个产品的策略意味着你必须做出选择，试图面面俱到则会导致毫无重点，试图取悦每一位用户最终导致平庸。
解决这个问题的途径也是“系统思考”，产品提供的是价值而非功能。我们需要考虑的是如何让产品已有的功能客户用起来最舒服，即使复杂但仍然容易使用。
五
实际产品开发过程中，还有一些典型的问题。比如：
产品还没完全准备好，到底要不要发布？
我想这个问题是仁者见仁智者见智。苹果在2012年9月iOS 6发布时，苹果从应用商店中移除了谷歌地图，用的是苹果自己的地图，但事实证明这是一次灾难级别的发布，苹果地图并没有完全准备好；但也有一个反面案例，华为当年在做程控交换机时问题比较多，但当时程控交换机的市场还是空白，所以华为硬着头皮发布了品质并不完整的产品。
如何提前布局好产品的“最后一公里”？
物流行业和交通出行行业，都有所谓的“最后一公里”一说。产品也有其自身的最后一公里。比如我之前有一篇文章写的是“多抓鱼”，如果你卖书，他们提前打通了顺丰，会安排顺丰上门提货，这种速度和体验对用户来说是非常友好的。
产品的生命周期如何管理？
产品的生命周期管理，可以简单地理解为产品路线图计划。这对于团队协调和沟通比较有用，就如一个GPS引导你开车时避开拥堵一样，如果有中期、长期的产品规划，开发团队在讨论当前的设计方案时，同时也需要考虑到后续产品的升级以及扩展，比如系统架构是否能支撑、技术的延用性等。
六
尝试在一篇文章中把“产品系统设计”说清楚是不现实的，在这个过程中，还有若干的阶段和细节，每一点拿出来说，都可以写上2000字。比如遇到技术难题无法攻克怎么办，产品延期被领导和客户催怎么办，发布后出问题怎么补救，都是相关的内容。这些以后再慢慢补充吧。
参考书目
《探索需求-设计前的质量》，杰拉尔德·温伯格&唐纳德·高斯
《精益创业》，埃里克·莱斯
《产品经理方法论》，乔克·布苏蒂尔
《格鲁夫给经理人的第一课》，安迪·格鲁夫
《设计心理学》，唐诺德·诺曼
《IPD流程管理》，网络资料
《邱岳的产品手记》，极客时间专栏（重点推荐）