一文读懂硬件最小化可行产品中的那些坑

　　在上一篇文章我对＂产品系统设计＂的思考中我提到最小化可行产品（MVP），有个朋友看完留言，让我可以试一试讲清楚＂MVP有哪些坑？＂回想起来，这几年我一直从事硬件产品开发相关的产品管理工作，有面向企业的，也有直接面向消费者的，有的产品历时一年多，短的可能几个月。在这方面踩过的坑确实比较多，倒是有一些惨痛的经历可以说一说。
　　一
　　我记得几年前朋友介绍加入一家创业公司，不到十个人。团队创始人都是技术出身，在行业内也都算小有名望，做的是一款面向公安、交管使用的硬件设备，客户群以集成商为主。
　　当时那款产品业界能做出来的厂家也不多，国内大概五六家，如果在一个合适的时间能够推出性价比不错的硬件产品，以当地城市每年10000台进行估算，只要能够占据1/4的市场容量，那公司的销售额和利润都会取得一个不错的结果。
　　为了走一个差异化的道路，我们当时选择了一款非市场主流的sony芯片，这款芯片比主流的便宜，但性能表现不错。于是我们在憧憬中快马加鞭，几个人5+2，白加黑地投入到产品开发中。
　　几个月后，当我们满怀信心地把产品交付出来后，市场给了我们狠狠的一击。
　　我们和当地一个比较有代表性的集成商合作，给了他们一个非常有诱惑力的市场价格，但最关键的图像清晰度指标（特别是晚上）却无法满足最终用户的要求。虽然集成商肯定我们的技术能力，但经过几次试验和对比测试后，最终却不得不更换了其他厂家的设备。
　　最小化可行产品（MVP），指的是快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以满足产品部署的要求并能够检验有关客户与产品交互的关键假设。该概念由埃里克·莱斯在其著作《精益创业》中提出，用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出你产品最终想要的效果，然后通过迭代来完善细节。
　　很不幸，我们当时的做法，几乎犯了所有的错。
　　首先，手头上确实有一个值得解决的问题（集成商之前用的产品价格高也有一些问题），但最核心的是对于＂符合产品预期功能＂这一点走在了错误的道路上。产品对应的解决方案，并不能满足最终用户的要求。所以在这个阶段，需要问自己三个问题：
　　你的解决方案是否是客户想要的？（必要性）
　　他们是否愿意为你的解决方案掏钱？如果不愿意，那么谁来买单？（发展性）
　　你的解决方案是否能够真正解决问题？（可行性）
　　Ash Maurya在他的《精益创业实战》中，给我们提供了另外一种方法——精益画布，一款制作迅速、内容紧凑、方便携带的工具，基本上可以解决前期的一些问题。如下所示：
　　其次，我们当时是有机会在半路调整方向的。
　　开发进行了两个月左右，产品第一版（我们自己定义为MVP）出来后，在测试的过程中发现了夜晚清晰度问题（相比业界最较好的两家公司产品）。
　　这个时间点，本来应该是我们拿着原型去客户处进行假设验证的绝佳时机，如果此时有几个客户的真实反馈数据，我们可能会推翻之前的假设，这会决定我们下一轮的行动方向。
　　但我们当时的做法没有遵循这个原则，我们反而花了大量的时间去选择周边配套的补光设备，企图通过算法优化、补光增强来达到效果，这再次让我们在错误的方向上越行越远。
　　虽然我们带着强烈的信念，但硬件产品的字典中没有＂信念＂二字，一切都必须通过科学方法的验证。
　　二
　　从上面的例子可以看出，做产品过程中，我们无法完全避免犯局部的错误，但是若能从一开始就愿意并尝试去探索甚至同时测试多种模式，总能增加找到更好方案的几率。
　　这里面＂探索＂是关键，抛开那些极为困难的技术问题，其实只要有足够的时间、资金和人力，做出个产品应该不是什么难事。怕只怕做出的东西根本没人想要。
　　Steven Gary Blank博士在他的《四步创业法》中提到，＂客户探索＂是用事实去检验设想，而检验假设都必须走出舒适的办公环境，去到客户中间，虚心了解他们的需求。这个过程的目标不是说服潜在的客户接纳你的想法和假设，而是设法了解客户的真实意见，他们在使用类似产品过程中的痛点，然后如实地记录下来即可。
　　三
　　2015年的时候，我负责公司的一款物联网产品开发管理工作。那时候我已经读了一些精益管理的文章和书籍，总想着通过快速迭代来打造一款有价值的产品，所以我制定了比较激进的产品发布策略。
　　我把过程分为三个阶段，第一步是快速出一个原型机，第二步是增加我计划中的几个功能模块，第三步是完善并兼容几个物联网平台。
　　但是，第一阶段就遇到了一些问题，我当时和开发人员一起选的MCU到程序设计时发现32KB的FLASH不太够用了（可以满足基本的功能），一旦程序满负荷运转，内存就比较吃紧。
　　当时的情况一是有项目在等着用这款产品，二是考虑沉没成本，我们决定牺牲掉一部分功能来达到产品上线的目标。
　　这个案例也比较有代表性。
　　首先，肯定是前期的需求工作没有做完整，产品的使用场景并没有明确到极值。此款物联网设备既可以单独使用，也可以组成集群，在集群工作环境中，当设备容量达到一定规模时其程序处理复杂度上升较多，导致MCU的FLASH即将到达极限。
　　其次，最小化可行产品（MVP），有两个形容词，其一是＂最小化＂，另外一个关键词是＂可行＂。而我犯了一个典型错误，将重点放在了＂最小化＂出产品，而忽视了＂可行性＂的部分。
　　举一个例子：一款硬件产品，其MCU支持串口、网络、USB等，如果没有强制要求，可以先用最简单的串口实现通讯，形成一个最小化可行产品去验证数据传输以及功能，验证了可行性后可以再慢慢完善底层网络协议、USB驱动等。
　　四
　　做硬件产品开发，要求短时间内囊括需求、设计、测试、生产等步骤， 迭代不如软件那么容易，所以硬件产品如果出了问题往往比较麻烦，改进的周期会比较长，这容易导致产品无法按时上市或者不得不忍受一些缺陷。
　　以上两款硬件产品都有各自的问题，在复盘过程中，除了上面提到的外，还有一些需要注意的点。
　　典型问题一：硬件产品基本上遵循摩尔定律。
　　当价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。所以在设计方案的时候，需要对行业及产品的发展方向有一个预估，涉及核心芯片的选型留一些余量。
　　典型问题二：不要期待一次就把产品做到完美，但关键步骤不能少。
　　硬件产品一般建议走一轮样机评审和测试，样机评审的主要目是验证一下设计的指标，同时在此阶段尽早进行单元测试，看看关键性能指标是否满足市场及客户需求。
　　典型问题三：不要纠结于沉没成本。
　　很多时候，我们已经投入这么多人力、物力和资金，因为不甘于这个投入，限制了我们做出下一步有效的决策，从而在错误的道路上越走越远。最好的做法，仍然是以绝对的事实为基础，充分调研和沟通，一旦发现设计指标无法满足最终市场的要求，尽快调整方案或方向。
　　典型问题四：迭代的方向没有遵循一致性。
　　常见的一种情况是，迭代过程中设计的两代产品，其结构、构思完全不一样，根本没有传承性，这相当于把所有的过程再来一遍。比较好的做法是，技术选型、硬件框架、结构设计尽量模块化和标准化，在此基础上的芯片升级、功能升级、程序代码就可以复用，以减少重复劳动。
　　典型问题五：为了追求快速，所选器件来自非正规渠道。
　　经常有一些做法，从正规渠道购买某个器件周期太长，所以选择从淘宝、阿里巴巴购买一些器件。
　　这种方式存在几个风险，其一是器件可能是高仿，批次存在不一致性，你验证的结论就存在不确定性；其二是存在不稳定性，这台可以，下一台就不行，导致投入过多精力去解决器件本身的问题；其三从知识版权来考虑，也应该购买正规的器件和物料。
　　目前，硬件物料有很多渠道和代理，前期成本可以稍微放松一些，除了原厂沟通外通过这些渠道和代理，一般也能找到合适的供货方式。
　　五
　　当然，最小可行性产品（MVP）也有其局限性，比如在一些创新性产品中，其应用就受到一些限制。
　　类似于苹果iPhone，其技术标准、工艺标准都是非常高的，和普通的原型机比较丑有天壤之别，而且直接引领市场。即使如小米手机、锤子手机，其迭代的也多是软件系统（小米的MIUI是每周迭代，锤子Smartisan OS其迭代周期也比较快）。
　　在乔克·布苏蒂尔的《产品经理方法论》这本书中有一个例子也说明了这个问题。
　　美国鞋类品牌REEBOK构思了一款新型的篮球鞋，做市场调研的时候反响平平，差点停止了新鞋的开发，但当一款早期＂试验款＂运动鞋真正穿上时，篮球队员们觉得鞋不但合脚且非常酷，最关键的是他们更自信而不必担心会受伤。这款泵鞋后来取得了可观的市场份额。
　　所以，看看你自己的产品领域，不用拘泥于惟一定式，MVP也只是为我们提供了一种思路和方式。
　　参考：
　　《精益创业》，埃里克·莱斯，中信出版社
　　《精益创业实战》，Ash Maurya，图灵文化发展有限公司
　　《四步创业法》，Steven Gary Blank，华中科技大学出版社
　　《产品经理方法论》，乔克·布苏蒂尔，中信出版社