码迷,mamicode.com
首页 > 其他好文 > 详细

产品新人的我,曾在初创公司踩过这些坑

时间:2018-12-26 00:34:11      阅读:167      评论:0      收藏:0      [点我收藏+]

标签:资源   核心   后台   质量   传递   快速迭代   访问   相对   这一   

要踩够多少坑,才能成为一个合格的产品经理——我,是一枚硬件研发转型的产品经理。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+让正确持续发生

产品经理最重要的两个价值点:一是做对,二是做好。而背后的方法和流程、资源是支持这一切发生的元素,最关键的资源是人。

创业公司的早期产品很可能不被市场认可,销量不佳,但是要有一套快速不断迭代,趋近对、趋近好的方法。《精益创业》里面讲述的MVP+快速迭代很适合创业公司。

一个好的产品,不是产品经理一个人能决定的。除了产品层面,公司的层面其实也是需要不断迭代的,快速磨合,让适合的人出现在适合的岗位上,公司本身在人、运转上是要有竞争力的。

公司之间的竞争与战争是很相似的,公司的管理层犹如军队的作战指挥员,不能放上一个没有经验人去指挥,等着他成长,他长大了战也打完了。产品哪一块有问题,回头去看这一块的指挥员,可能会发现这一块的人岗不匹配。

创业公司早期应该格外关注上面两个问题,要想办法去创造一个让正确发生的环境,去产生持续正确,而且速度还要足够快。创业公司的负责人在这个里面的角色非常之重要,通常他是这个环境的缔造者。

 

七、培训:员工成长

初创公司人员相对大公司,团队的知识储量是相对较弱的。另外,通常创业公司人员质量也参差不齐,这是初创公司的风险和人力资源薄弱导致的。在这种小团体内,知识是有局限的,如何高效利用内部和外部的知识,以及补充团队知识的短板,是很重要的。不进步或者说进步太慢,看不到行业的全局会限制初创公司的发展。

一个组织进步获取新知识主要来自三个方面:

  1. 自我学习,例如开展培训、从合作伙伴身上学习;
  2. 吸收新成员,新成员带进来新的知识和经验;
  3. 组织自身经验积累。

培训和总结对于初创公司是一种相对低成本的成长方式,它能扩展成员的知识边界,也会加强成员之间的沟通,为团队带来统一的交流语言。《创业维艰》的作者很看重培训,从我看到的情况,真的很有必要。我觉得这可以作为产品新人找公司时的一个问题,看看面试你的公司是否足够成熟。

 

八、智能硬件:在硬件这条路上一去不复还

智能硬件类创业公司,如果创始团队之前没有硬件开发和生产经验,比较容易放的错误有两个:一是过于乐观估计开发周期,实际周期乘以2乘以3是常见的;二是对产品品质意识不够,对出现的个别问题重视度不够,对生产端重视度不够。硬件产品的质量是要全流程把控的,影响最终效果的因素太多,负责生产和品质的人一定要经验丰富,否足容易迟迟走不上正轨。

目前智能硬件类的产品经理相对比较稀缺,互联网产品经理转型做智能硬件,常见问题是质量不行;传统的硬件产品经理,通常又很不互联网。一个是互联网重塑了产品经理的职责内涵,二是同时有软硬背景的人比较少,有一定工作经验的更少。

做好一个智能硬件产品经理真的有难度,硬件+软件+内容,做好一个领域都够人折腾的,更别说三箭齐发。一些公司会划分软件产品经理和硬件产品经理,然后根据产品形态指定一个为产品总的负责人,也有一些公司会让产品经理同时负责软件和硬件。

起步阶段的创业公司可能会采用第二种,因为早期没人,然后随着产品形态的成熟和产品线的扩充慢慢过渡到第一种方案,当然这个也因公司而异。

不管怎么样,本质都是融合,线上和线下的融合,软件和硬件和融合。到后面,小公司的智能硬件产品经理需要更加全面而又在某一块足够专业,大公司就是分工协作,岗位进一步细分。

 

九、股份与期权:慎重

股份与期权也是到创业公司经常遇到的一个问题。有一情况尽量避免:降薪+股份或期权加入创业公司,这样会导致不合适时你退出损失比较大,因为通常这种股份或期权的兑现是有各种限制的。如果不能避免,最好和公司确定好退出时股份如何处理,是否可以折算或者转让。

另外,创业公司的股份或期权合同可能有一些漏洞,后面容易引起纷争,最好让专业人员审核下内容。之所以写这些,因为这两种情况我都遇到过。

产品新人的我,曾在初创公司踩过这些坑

标签:资源   核心   后台   质量   传递   快速迭代   访问   相对   这一   

原文地址:https://www.cnblogs.com/chuangye95/p/10176988.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!