标签：资源 核心 后台 质量 传递 快速迭代 访问 相对 这一
要踩够多少坑，才能成为一个合格的产品经理——我，是一枚硬件研发转型的产品经理。2016年进入一家智能硬件初创公司，至今一年半，没有成功的产品经历，只有踩过的一个又一个的坑。
公司是以技术起家，公司创始人是在学校孵化产品原型，在这一块有技术积累，参加创业大赛拿到风投后，快速推出产品上市。我加入时，公司注册半年，人数30左右，一代产品刚上市。公司除了一个产品总监，没有其它产品人员，产品总监也是研发转型。
坑点：对于产品新人，找个有人能带你的团队，事半功倍。
一定要重视这点，重要的事情放在最前面说。
没做透用户调查，就开始做产品功能，这是我犯过的最痛心的错误。上面也说了公司是技术孵化，第一代产品是创始人扮演产品经理的角色，除了特色功能，产品的功能与市面的产品重合度很高。我进公司的第一个产品是一代的改进版本，一代上市后遇到很多问题，公司准备推出一个迭代版本替代一代产品。
作为一个新人，我很自然理解为改进原有产品问题，提高用户体验。
去看现场使用，电话回访用户使用问题，内部收集问题，再加上自身体验发现问题，前期花了很多时间在搜集问题和改善方案上。随着工作的开展，却发现产品本身的功能和定位存在很大问题，用户没有粘性，用户活跃度低的可怜。可是这个时候产品已经在开发中，而我已经陷在项目开发中，爬都爬不出来。
现在回顾，产品的用户群没有定义清晰，典型的使用场景也没有定义清晰，一代的功能和产品定义本身就有问题，新版本再怎么优化体验其实都是徒然。
前天去面试，面试人让我举例证明自己的需求分析能力，我有点恍惚，证明的没有，失败的惨痛的倒是有一个：用户要找准，核心功能要做透，满足着两个前提再去优化体验和周边。
一些初创公司倒在产品定义上，很多都是犯了这个错误，没有掌握一套有效的方法去迭代。还有就是互联网产品的反馈系统、数据监测、软件更新已经非常成熟的，但是智能硬件产品上还相对不成熟，我所在的公司就对反馈、数据监测，固件更新等重视不够，没有办法形成一套反馈优化迭代的流程，产品出去了不能及时获取到反馈信息，进行快速迭代更新。
很多公司硬件产品卖出去了，也不关心日活跃怎么样，那就更不用说去改善了。
入职2个月时的某一天，正在用墨刀画着原型，有个市场的兄弟反馈产品的App核心功能访问不了。马上找开发的兄弟确认原因，原来是一个开发兄弟自己测试后，直接打包发布到应用市场，而打包用的是测试后台的代码。我只能内心默默说一句：尼玛，这也可以！
发生这件事后我开始意识到公司产品开发流程的缺失带来的问题：公司的现状是完全的原生态，没有流程，没有文档规范，没有审核，但是公司开发人员又在扩张，这样是很容易出质量问题的。拉着产品总监和软件总监，讨论开发流程中的问题，最后结论是后续App打包由软件总监负责，由产品经理确认后发布，并且尽快补充测试人员。
这件事情同时也带来了一点负面影响，软件总监认为我怀疑他个人的把控能力，有抵触情绪，撕了一架。和开发撕，只要是对的，多坚持一点。很多时候，开发一句实现不了，你放弃了就真的没有然后了。上一家公司部门的原则可以借鉴：开发可以说不能做，但是要是其它公司做出来了，这个开发绩效打C。
初创公司没有项目经理是比较常见的事情，所以产品经理通常也要兼任项目经理。作为一个产品新人不知道里面有什么坑，开始的时候觉得挺好的，把以前在HW产品经理、规划、SE和项目经理干的事情都承担了。
然而二个月后，老板整天“这个事情怎么又延迟了”，“这个方案怎么这么难看”，“这些细节怎么都没人处理”；开发的兄弟也不让人省心，Bug一波接一波：“这个功能我们CES前实现不了”，“机器人的音量、语音反馈速度怎样才算OK，产品要给个标准”…
很多初创公司的产品经理做着做着，会觉得自己像一个产品质量管理员。当你把大量的时间花在进度、质量和日常琐事上后，自然没有足够的精力投入到产品设计和优化中。睡觉前想想自己每天处理这些糟心的事情，有点心酸，你知道这样是做不出好产品的，但又只能沿着这条路前进。当你由于进度只能拿出一个糟糕的方案时，你已经慢慢忘记自己是个产品经理了。
坑点：产品与项目职责中有矛盾的地方，产品要把控标准和体验，项目要把控进度和成本，很多时候好的方案和体验都是与时间和成本矛盾的，特别是硬件产品，1个月一个迭代周期很正常。背后的本质是用户视角和开发视角的冲突。
对于经验丰富的产品经理或者周边部门配套完善的公司来说，可能会好点，但是对于初创公司，这真的是一个头疼的问题。
以我的观察来看，将软件产品经理和硬件产品经理分开，由硬件产品经理来负责硬件的项目管理，减轻产品经理在项目开发中的负担，或者单独招聘项目经理，会有帮助。
不管哪种人员配置，建议先把开发流程理顺，分阶段和节点管理项目，这样能更好控制开发进度；将团队成员的职责划分清楚，什么阶段什么事谁主导谁配合规定清楚，可以让项目跑的顺利点；然后采用一套适合公司的任务管理工具，让开发过程可视可跟踪。
入职1个月后被安排负责下一代产品的开发，在开发过程中，我负责的产品由计划的4个月上市，变成6个月，然后变成9个月，最后变成至今未上市。现在反思整个过程，犯了太多错误。
4个月变成6个月，主要是我乐观估计了App的开发周期。前期公司高层不断给压力，要早点出来赶上CES时间，评估是基于原型评估，但是后面细化需求和UI后，开发评估时间不能实现后，CES演示内容删减，产品计划重新梳理，变为6个月。
这个过程中最大的问题是产品这边和开发的沟通问题。早前的需求是通过文档和会议传达，基于原型评估，过程会有很多变动和理解差异，体现出来就是产品不能有效将需求传递给开发，信息不对称，这个过程也是和开发矛盾最多的时候。
这个问题在建立需求评审流程、和建立工单系统后得到改善，在这两个流程开展半年后，和开发之前的沟通问题明显好转，随着不断完善，开发端的沟通逐步正常化。17年公司总结，开发部和产品部都表示认可这套机制，尤其是之前矛盾集中的软件开发。记得在起点学院，一个创业导师讲在公司早期需要明确产品开发流程，现在想起来深表认同。
6个月变成9个月，9个月变成至今，是起始于一个小的变更。这个变更最开始确实很小，需求点是优化产品的硬件外观，把走线隐藏起来。最开始我和开发一起想办法优化走线方案，由于公司Boss比较关注，这个问题也慢慢升级演变，后面变为更换关键零部件来彻底解决，而这个关键零部件公司也打算自己研发。
我们确实也提出了更好的解决方案，而且很快验证了原型，大家也看好这个技术点，也申请了专利。公司预期的开发周期会导致产品延期三个月，Boss决策要等这个问题解决后发布，而且关键零部件自己研发对于公司意义重大。产品也认可这一点，认为无论对于公司还是产品都会提升竞争力。
然而现实情况是这个关键零部件的开发一再延期，由于技术出身而又缺乏经验，公司研发乐观估计了开发周期。
坑点：不成熟的技术方案，在正在开发中的项目应用，要慎重，这种变更带来对项目周期的影响往往被低估。
中间市场一再催促产品上市，我提出采用替代方案，让产品尽快上市，后续自研成功后再替换，这样可以两步走。Boss也直接Pass掉了这个方案，因为这个方案现在代价也很大，人力也不支撑，已经箭在弦上不得不发，这个部件必须研发成功。
坑点：Plan B要有，而且在变更一开始就要有。木已成舟后，执行Plan B的成本会增加，甚至变得没有可行性。
这直接导致了产品至今还没有上市，更重要的问题的是：们之前规划的特色产品功能，随着竞争对手产品的发布，顿时变得尴尬起来。回首这一切，深感痛心。
坑点：不要低估项目延期带来的影响，永远都不要忘记还有竞争对手。
如果当初更加坚持，不是因为Boss决策就遵从，而是更加坚持去深究合理性，结果会不会不一样，还是没有摆脱唯上的心理，默认了“老板是不会错的”。Boss一个想法，一纸令下，改变了一个产品的命运，这也是创业公司最容易遇到的问题之一。
我比较深的体会是产品越没有自己的意见和调查结果时，越容易被Boss主导，Boss也越容易拍脑袋下决定，一不小心就拍到屁股上。这个过程中，Boss和产品就像博弈的双方，产品没有充足的理由时会沦为结果的执行者。
产品经理最重要的两个价值点：一是做对，二是做好。而背后的方法和流程、资源是支持这一切发生的元素，最关键的资源是人。
创业公司的早期产品很可能不被市场认可，销量不佳，但是要有一套快速不断迭代，趋近对、趋近好的方法。《精益创业》里面讲述的MVP+快速迭代很适合创业公司。
一个好的产品，不是产品经理一个人能决定的。除了产品层面，公司的层面其实也是需要不断迭代的，快速磨合，让适合的人出现在适合的岗位上，公司本身在人、运转上是要有竞争力的。
公司之间的竞争与战争是很相似的，公司的管理层犹如军队的作战指挥员，不能放上一个没有经验人去指挥，等着他成长，他长大了战也打完了。产品哪一块有问题，回头去看这一块的指挥员，可能会发现这一块的人岗不匹配。
创业公司早期应该格外关注上面两个问题，要想办法去创造一个让正确发生的环境，去产生持续正确，而且速度还要足够快。创业公司的负责人在这个里面的角色非常之重要，通常他是这个环境的缔造者。
初创公司人员相对大公司，团队的知识储量是相对较弱的。另外，通常创业公司人员质量也参差不齐，这是初创公司的风险和人力资源薄弱导致的。在这种小团体内，知识是有局限的，如何高效利用内部和外部的知识，以及补充团队知识的短板，是很重要的。不进步或者说进步太慢，看不到行业的全局会限制初创公司的发展。
一个组织进步获取新知识主要来自三个方面：
培训和总结对于初创公司是一种相对低成本的成长方式，它能扩展成员的知识边界，也会加强成员之间的沟通，为团队带来统一的交流语言。《创业维艰》的作者很看重培训，从我看到的情况，真的很有必要。我觉得这可以作为产品新人找公司时的一个问题，看看面试你的公司是否足够成熟。
智能硬件类创业公司，如果创始团队之前没有硬件开发和生产经验，比较容易放的错误有两个：一是过于乐观估计开发周期，实际周期乘以2乘以3是常见的；二是对产品品质意识不够，对出现的个别问题重视度不够，对生产端重视度不够。硬件产品的质量是要全流程把控的，影响最终效果的因素太多，负责生产和品质的人一定要经验丰富，否足容易迟迟走不上正轨。
目前智能硬件类的产品经理相对比较稀缺，互联网产品经理转型做智能硬件，常见问题是质量不行；传统的硬件产品经理，通常又很不互联网。一个是互联网重塑了产品经理的职责内涵，二是同时有软硬背景的人比较少，有一定工作经验的更少。
做好一个智能硬件产品经理真的有难度，硬件+软件+内容，做好一个领域都够人折腾的，更别说三箭齐发。一些公司会划分软件产品经理和硬件产品经理，然后根据产品形态指定一个为产品总的负责人，也有一些公司会让产品经理同时负责软件和硬件。
起步阶段的创业公司可能会采用第二种，因为早期没人，然后随着产品形态的成熟和产品线的扩充慢慢过渡到第一种方案，当然这个也因公司而异。
不管怎么样，本质都是融合，线上和线下的融合，软件和硬件和融合。到后面，小公司的智能硬件产品经理需要更加全面而又在某一块足够专业，大公司就是分工协作，岗位进一步细分。
股份与期权也是到创业公司经常遇到的一个问题。有一情况尽量避免：降薪+股份或期权加入创业公司，这样会导致不合适时你退出损失比较大，因为通常这种股份或期权的兑现是有各种限制的。如果不能避免，最好和公司确定好退出时股份如何处理，是否可以折算或者转让。
另外，创业公司的股份或期权合同可能有一些漏洞，后面容易引起纷争，最好让专业人员审核下内容。之所以写这些，因为这两种情况我都遇到过。
标签：资源 核心 后台 质量 传递 快速迭代 访问 相对 这一
原文地址：https://www.cnblogs.com/chuangye95/p/10176988.html
