产品复盘为何这款产品会做失败

　　本文是作者根据自己开发的产品的一次复盘，从九个方面来分析了他失败的原因，一起来看看
　　进入主旨之前呢，笔者先大体介绍下目前所在公司业务，笔者目前所处的是一家物联网公司，公司的业务是基于IOT应用，为中小企业提供SAAS服务。
　　我司硬件产品作为底层设备，作为物联网的基础设施，主要起到一个数据采集作用，平台依据这些数据，进行精细化运营，向B端提供有价值的服务，这也就构成了我司的商业模式，目前在业内也算是获得了一些认可，深耕物联网领域，取得了些小小成绩。
　　公司没有自研硬件研发团队，硬件产品的来源主要是外部成熟硬件产品，我司直接开发协议接入和ODM设计。笔者负责其中一条产品线的硬件产品引入和新产品定制工作。
　　和互联网敏捷开发思路不同，互联网讲究小步快跑，快速尝试，增量迭代，相比硬件开发成本而言，其试错成本较低。
　　硬件产品开发是一项重视前期整体规划，前期人力资源和现金投入都比较大，算是重资产运作模式，大家可以抽空了解下腾讯和华为的研发投入占比，就可以看出这其中的差距了。
　　在目前这个分工明确的大环境下，越来越多的公司专注于精细化运营，专攻某一领域，整合供应链资源完成新产品开发，如OV之流，这也是为什么深圳号称电子之都，哪怕房价再高，中小企业也愿意扎根于此拼搏一番了，核心优势在于其整体的产业链非常完整。
　　言归正传，硬件产品从一个想法到形成最终的产品落地，量产上线，中间环节很多，前期需要协调内部的资源进行研发，保障进度，后期更多的是涉及到多家供应商的协同，每款核心物料更是需要准备应急方案，预防胜于检查（往往成就你的也许就是PLANB），这样方能最终确保将一款产品成功按时上线并面向市场销售，正所谓好事多磨。
　　目前手头正在负责两款新产品的产品开发管理工作，之前定的其中一款新产品由A供应商负责开发，另外一款找B供应商负责开发。奈何，哪怕是前期进行了充足的技术调研工作，也没料到，其中A供应商做到一半，因技术瓶颈，无法做下去。无奈之下，我们不得不把鸡蛋放在一个篮子里，代价便是我们变得更被动了。
　　受到重任的供应商也是忙的飞起，加之他们手头还有其它的CASE，这个开发任务又是中途插进来，导致两个项目整体进度均受到了不同的影响。
　　后面我们也只好权衡之后，对重点项目进行资源倾斜，另外一个暂且就当后娘养的吧。
　　前段时间和市场同事撕逼，大意是责怪我们耗时两年竟然没有把一款如此简单的产品做出来，失去了现有客户对我们的信赖，以至于丧失了大量的机会成本，产品迟迟不能按计划上市，一再delay，部分预约客户更是已经直接放弃采购计划，转向友商的怀抱。
　　能理解市场同事的焦躁，身上背着沉重的KPI，被客户刁难，末了，还得被自家兄弟拖后腿，确实不容易。只能说需要相互理解了，在较为苛刻的范围内完成新产品开发对我们而言也是一项挑战，毕竟巧妇难为无米之炊。
　　好了，接下来就花点笔墨复盘下笔者是如何做出这款失败产品的过程，说是心路历程也不为过了，短短几个月，心情像坐过山车一样，经历了喜悦、纠结、愤怒、麻木当然，自身也还是存在许多不足的，还没办法保持人格上的独立。
　　16年6月入职这家公司，当时公司2月份已完成内部立项，当时听同事介绍说决定开发这块产品时，整个行业还未有同类产品【等到我们开发出来，市场上已经充斥了同类产品，时间窗口真的很重要】，我们算是第一个吃螃蟹的了，而且客户也确实有这个真实诉求。
　　经历了一番需求调研与分析，于是便着手开干了，首先完成新产品开发供应商选择并同步完成初步的技术评估，双方在4月份，愉快的签订了正式合同，也承诺了订单，算是给供应商吃了颗定心丸。按照以往的销售预测，我们计划8月份，正好是销售的旺季，产品必须达到可以出货的标准，正式上线开卖。
　　奈何现实很骨感，实际上到17年的4月份时间节点，才开始试产，软件方面也是在17年8月份才算达到一个较为稳定的状态，其中还有几个重要缺陷未修复。
　　后来我们内部觉得该供应商一代产品开发效率和效果实在是太差，之前谈好的二期迭代开发也决定不找他们合作，结果供应商不顾合同约束，也以近乎无赖的方式结束了和我们的合作。
　　其后果就是自9月以后，再未提供正常的维护，供应商也在17年的年末宣告破产。
　　我司在18年下决心下线了该款产品，我们采购过此款设备的客户停止继续使用，后续的采购计划泡汤，这款产品最终以三败俱伤的结局落幕。
　　对于这个产品开发失败的案列，感触很深，一直没机会做一次系统性的复盘。
　　昨天去产线跟进新产品小批量试产，在组装的时刻，供应商才发现一个即有可能严重影响进度的主观失误：供应商PCB修改之后直接投产制板，未和结构做匹配，最后在组装环节才发现PCBA和结构不匹配。
　　这里也可以看出：内部评审环节的重要性，可以将一些主观风险扼杀在萌芽中。
　　此时距离我们的合同约定的批量交付节点不足22天，扣除掉节假日和休息，时日所剩无几，哪怕是再赶工，delay也已是板上定钉的事实了。
　　借着这个契机，我开始着手整理去年经历的项目失败的原因，思考整个过程中，究竟是哪些环节最可能出现问题，哪里最容易导致项目delay不受控制。
　　所谓以史为镜，可以知兴替，一番复盘下来，简直是问题不要太多，这里也主要对重点问题进行叙述，以期带给读者些体会，若是能做到他山之石，可以攻玉，那也是极好的。
　　失败原因
　　失败原因之一：前期技术验证不够严谨，未全面验证产品可能会使用的应用场景
　　该项目是为了解决物流冷链环节的温湿度监控，在前期的技术验证阶段，只验证了几个常见场景，缺乏几个较为极端当时较为少用的场景的验证。
　　大家不要忽视这点，这对技术方案的选型相当重要，后面也将会讲到，考虑到整个产品的生命周期，对产品的应用思考是需要具备前瞻性的。
　　失败原因之二：对供应商技术实力预估不足，无法攻关核心技术
　　在硬件研发过程中，久久无法攻克核心技术，在技术存在瓶颈时，考虑到之前的投入，也未果断的调整方向。
　　项目过程中，选用无线方案时，供应商考虑到其技术储备，选择了他们擅长的GFSK无线方案。结果在常规应用场景上也无法满足，后面反复验证，均认为是天线匹配存在问题，后面光是拉着天线供应商进行天线匹配这块就耗了2个多月，其结果也自然是凉凉了。
　　当时我们建议修正方案，采用其其它技术方案。但供应商考虑到交货的时间节点临近，和已经成型的PCB方案在前期投入了巨大的精力，供应商不能下决心去推翻之前的方案，加之新方案的技术攻关耗时不可控，就被否决了。
　　当时我们也没有正确的认清形势，未坚决的止损，还抱着一丝幻想，专业的事情交给专业的人做，也许他们能攻克呢？
　　事实证明被打脸了，项目后期，核心人员几乎全部离职，然后供应商对我们隐瞒相关情况，到实在保不住，到了关键的里程碑节点，才跟我们坦白，希望时间能放缓点。
　　国内做项目就这样，合同没有想象中那么具备约束力，大家都是钻空子的高手，另一反面，买卖不在仁义在，这里也注定了这个项目的悲剧吧！
　　失败原因之三：开发人员超卖严重，无法做到allin
　　合作的供应商有自己的项目正在跟进，他们前期对于项目过于乐观，一般是白天干他们的项目，晚上通宵做我们的项目，这是后面从离职人员了解到的。
　　当时确实还被他们的敬业精神所感动，以为他们是全身心的ALLIN，其实前期根本没花太多的精力在项目上，之前也算是对他们充分授权和信任，结果还是被他们CEO忽悠了，说专门成立了一个项目小组负责我司项目，全力推进落地，事实上却是行的挂羊头，卖狗肉之举。
　　后期觉察到了，而最佳介入时期却是已经过期了，经过几次严厉的交涉之后，才稍微上点心。但事实证明通宵工作的效率很低，没有成果输出，后面我们直接驻场，坚持联合办公，效率才有所提升。
　　失败原因之四：供应商缺乏必要的开发流程和项目管理思维。
　　新产品开发过程中，涉及到跨职能和跨组织沟通，流程和信息的及时同步非常重要。在合作过程中，往往我们主动跟进，供应商也无法及时的同步相关信息，更别说要求供应商自身具备较强的自驱力了。
　　整个开发配合过程中存在严重的沟通不畅问题，双方所在立场不同，往往造成鸡同鸭讲的困惑，沟通成本很高、效率很低，再加上前期其无主要责任人负责相关管理，开发内部互相推诿，造成开发的低效和交付不及时。
　　失败原因之五：设计和生产脱节，未考虑可制造性
　　在整个设计过程中，在方案的选择上未考虑可制造性，这对后面的售后和量产造成了很大的困扰，最终是整个生产成本和售后成本大幅上升。
　　在组装线上，由于结构设计部合理性，SOP较为繁杂，人工投入很大，日产率低。
　　再一个就是有款产品考虑到其防水性能，上下底盖采用超声波封盖工艺，其试产过程中，不良率很高。
　　在后期的售后维护中，对于因质量问题造成的返修，基本都是通过换新来处理，因为超声波封盖，拆了再盖上去的成本也不低了，处理起来也较为麻烦。
　　失败原因之六：核心物料把控不严，产品出现严重的质量问题
　　最终产品上线销售之后，可以说最大的坑出现了，因为涉及到客户的用户体验和利益，因为这款产品续航造成的客诉居高不下，严重影响到公司品牌和商誉。
　　后面核查到因供应商物料把控不严，电池出现了严重的质量问题，这对于我们这行而言，可以说是极大的打击了，也是这个项目被判为失败的主要原因之一。
　　当然这也和我们电池定制化有关，考虑到应用场景的特殊性，我们没有选择市面上成熟的电池方案，订制的低温电池，可靠性测试还不够，最终埋下了这个祸根。
　　失败原因之七：新产品开发未从公司层面名正言顺的统筹
　　整个项目涉及到多方合作，当然板子也不能全部打在供应商身上，后面几个原因，要从自己身上找下了。
　　整个新产品的开发还是挂在二级部门身上的，没有形成跨职能的项目管理委员会，公司层面没有进行充分的授权，这样对于资源的调动形成了一些阻力。
　　一是责权不匹配，二是对于不相关的干系人，容易有事不关己高高挂起的心态，做事情的时候容易畏首畏尾，对于资源的争取就无法显得那么名正言顺了，这算是职能型组织架构的先天不足，属于公司治理层面上的一个缺陷罢了。
　　失败原因之八：无商务主导权
　　在项目开发中，没有一定的财权，缺乏商务主导的授权，便无法及时有效对供应商进行约束。
　　缺乏必要的激励和惩罚机制，未形成对供应商的考核，也易形成部门和合作方之间的相互推诿，造成内耗，降低开发效率。
　　所谓当断不断，反受其乱，如果在项目前期，主导人员有较大的自主权，这样也不至于造成项目的一再delay，后面反复在思考，要是以合同约定时间算，如果合作方未在约定时间完成项目，我们及时止损，是否现在又会是另外一个局面呢？
　　失败原因之九：需求规划过于大而全，忽视了小而美
　　在需求规划中，内部其实也是缺乏必要的敏捷开发思路的。
　　项目管理的思维也是随着项目的逐渐纵向推进中才体会到其的重要性，需求把控这块未结合迭代做到合理的规划，仍是选择的传统的瀑布型开发模式。
　　后面也是被迫的将项目分成了二期完成，但是抢占市场的时间窗机会却是失去了。
　　整个项目过程中唯一称得上亮点的地方也许便是ID设计，没操太大的心，这里也不得不赞一下他们的工业设计团队。
　　但是对于B端的客户和用户来讲，性能才是王道，花架子带来的价值更多的是锦上添花，在同质化竞争日益严重的时候，产品满足硬指标的同时，如具备差异化的竞争优势，脱颖而出可能更为容易。
　　后面也了解到供应商CEO是个连续创业者【几乎没成功过】，心里不免有些凉凉的味道，创业不易，做产品也不容易，且行且珍惜。
　　踩了这么多坑，当然也需要总结些经验教训了，要不然可不就白费了这段经历，以下是笔者觉得在后续项目管理中需要注意的，当然仁者见仁，智者见智了，仅供参考。
　　总结教训
　　在项目管理中：应严格把控进度和里程碑节点，须有定期的阶段性汇报和风险分析，指导决策。
　　项目在立项前期：应该从公司层面统筹安排，形成合力，降低阻力。
　　前期的需求调研：可行性报告及供应商选择须有慎重。
　　项目执行过程中：需和合作方就项目实现最大程度的可视化，保证信息的同步。
　　结合产品开发失败的主要原因分析，以上便是笔者对去年经历项目的整体复盘了，时间拖的有点久，去年9月份close掉的项目，今天才算是正儿八经的仔细捋了一遍，希望能对你有所帮助。
　　作为一枚硬件产品狗，感觉从事物联网的产品经理和互联网PM人员不在一个数量级上，希望多认识些同道中人，大家一起交流成长。