软件行业从业十年的产品经理的得失杂谈

所谓时间飞逝、日月如梭，暮然回首。猛然发现自己出道伊始也将近十年了。回想此前自己以前担任过的角色，不可谓不繁杂。以前做过翻译员、測试、开发、測试主管、项目经理、产品经理，甚至还做过销售，徒步的大街小巷的去拜訪潜在客户。此间我认为最让自己慨叹的是当年做产品经理的时候的一些得失。所以这里就打算写下来，与同行们共勉。

事实上之前所做的“产品经理”这个角色，我认为是应该打个引號的。由于真正去跑市场、去全世界到处飞、去挖掘需求的是德国那边的一个同事。仅仅是开发团队在珠海这边，而我刚好英语沟通能力还算能够。所以就把我安排到这个所谓的“产品经理”的角色上来了。

所以，假设把客户这个概念给抽象封装一下的话，我们也能够说德国那个同事事实上就是我们这个产品的客户了。

所以说。事实上产品经理这个概念是比較泛的。你能够是一个产品型的产品经理。一个产品的创意的诞生到终于实现推向市场交到客户的手上。整个过程你都必须把控；你也能够是一个市场型的产品经理。针对已经在卖的产品，发掘市场的需求，然后交给开发团队来不断的迭代。等等等等。

技术债务

这可能跟当时我做的这个“产品经理”的特殊性有关系吧，我当时花的绝大部分时间都是在我们的产品backlog和每一个sprint的backlog上面，不断的跟德国那边进行需求的讨论。不停的和团队进行需求的细化。再紧张的去将功能进行优先级排序并和各路人马进行讨论，然后投放到对应的sprint backlog上面去…

在一開始的一两个sprint里面事实上总体状况也都还好，燃尽图也不算太难看。

可是做到后来那条曲线就開始翘得越来越高，远远偏离了理想曲线了。终于不得不由原来计划的7个sprint调整成10个sprint。

后来对这个问题有进行细致的反思，究其原因。我认为有好几个，可是当中最重要的应该就是没有及时的去对”技术债务“进行清理。

事实上这个道理看上去非常easy，基本上跑过敏捷开发的人都知道技术债务给项目所带来的伤害。可是在真正项目開始的时候。我们往往又会由于赶时间而匆忙将新的功能进行实现，而忽略了代码的可扩展性和鲁棒性等。终于这些“技术债务”越累越高，越到后面越发觉尾大难掉。改动一个地方可能都会牵一发而动全身。

这里看上去仅仅是跟程序猿有关系。事实上并不是如此，这个很多其它是跟产品经理的理念有关系。

像我之前，一心仅仅想团队高速的把产品backlog里面的功能高速完毕，而没有花足够的心思去思考产品表层以下的东西，没有去认真去抓实现的质量的问题。假设是将一个产品描写叙述成一个建筑的话，那我认为功能就是客户所示地面以上的这一部分。而质量就是隐藏在地底下的这个地基这一部分。

或许你如今看到的这栋房子外观雄伟功能齐全连厕所都实现了自己主动化，可是一旦碰到大点的风吹雨打。或者说想要加建一两层的话，可能整栋楼立马就坍塌了。

所谓欲速则不达。一个产品经理不应该仅仅是把眼光盯着那份功能列表，还应该多花点时间在解决“技术债务”这些事情上面来。

用户体验

我相信没有哪个产品经理会忽视用户体验的重要性。用户买你的产品/软件的时候，事实上他们真正买的是解决他们的痛点的方案。假设用了你的产品之后，原来的痛点攻克了，但糟糕的使用体验却成为他们的新痛点。那用户的逃离也为时不远了。

依据本人之前做产品经理的经验以及后来在一家创业公司的经历，我发现我们在用户体验方面非常easy犯的错误主要有以下几个：

• 错把自己当用户：这特别easy发生在一个初创企业里面，由于企业自身的经验不足，以及产品经理的过于自负，同一时候也由于创业早期并没有把目标客户过早的关联到项目中来(事实上在Scrum里面是非常强调用户的參与的)，所以一个sprint下来開始demo的时候。往往demo的对象就是项目的同一帮人。而产品经理在考虑下一sprint的用户体验的时候。又往往认为自己能够像周鸿祎一样能瞬间变小白。所以周而复始，几个sprint下来，产品拿出去一试水，发现就是石沉大海，结果就是再也没有结果了。这个错误在敏捷团队里面也能够叫做是“小瀑布”错误，这就是没有让用户过早參与进来的后果。看上去是在跑Scrum，事实上确是将原来的瀑布模式分解成几个小瀑布。然后套用了Scrum的概念，有名而无实。

• 忽视了首次使用体验：其有用户是非常没有耐性的，特别是互联网产品用户。

  你的产品可能功能非常强大，UI呈现也非常惟妙惟肖，但用户却要花大时间，甚至要阅读你几十页的用户使用手冊才干搞清楚怎么使用你的产品来解决他们的痛点，终于发现解决他们痛点的那个功能居然埋藏在三级菜单甚至以下。那你还预期他们会爱上你的产品吗？

要解决这些问题的方法我认为也非常easy：

• 让用户尽早參与进来：比方我们当时在创业公司的做法是。由于我们当时做的是一个适合个人和小企业的私有云产品。所以我们就到附近大学里面找了些学生过来进行试玩以及给他们做demo，然后收集反馈。在他们试玩的过程中要有专人进行跟踪记录，且纪录人不能给对方不论什么提示。当然，最后别忘记了给学生们一些酬劳，我们当时是送学生们100块左右的话费充值卡。
• 竞品研究：除非你在做的这个产品是非常有突破性的。业界还没有同类产品出现，不然你肯定能够在海内外找到一些部分功能相近的产品出来的。

  这里或许你会说抄袭可耻之类的话语。这里我仅仅能低调的说句，你丫少在我面前装圣人。有本事你如今别用QQ别用微信。再来跟老子谈抄袭可耻的问题！这里我们听下传奇人物史玉柱是怎么说的：“抄袭不但要厚脸皮，还要发展和优化。假设你抄后，还超越了对方。别人就不会说你抄了。“ 所以作为产品经理，你常常要做的事情还要是不断的去研究别人的产品。而不是仅仅盯着产品backlog这一亩三分地。而这里说的还不仅仅仅仅是用户体验上面。还包含其它功能点的调整，由于如今信息瞬间万变。

  关于这一点。以下还会有所阐述。

支持销售团队

这里还要由我们当时做的另外一个面向二手房的房源管理系统说起。当前二手房中介用的比較多的房xxx等商用房源管理软件(这里就不点名了)，会把他们的房源数据上传到软件供应商自己的数据中心上面去。

而房源信息事实上一个中介的命脉。所以他们更希望是这个数据中心放在自己公司里面。

所以我们当时做的就是提供一个数据中心server，以及对应的一套房源管理软件。管理软件支持PC端和移动端。

MVP出来后，開始去跑各种二手房中介进行demo以收集进一步信息。问题来了，正如上面所说的，用户是没有耐心的。不管你说的天花乱坠，还是眼见为实。可是将整个server架起来还是须要不少时间的，别人还须要特意给你腾出空间和提供网络接入等，且更尴尬的是。由于这还是非常初期的产品，在你公司里面跑的时候一般非常正常。跑到人家环境里面一跑的时候，不是这出问题就是那出问题。

终于非常多客户都是以有事忙为由。中断了该次演示。

事实上这里全然没有必要在初次demo的时候就把整个环境给架构起来，全然能够在数据控制层以下嫁接一个server模拟器，这样你的数据就不用非要通过网络和数据中心进行交互了(这里涉及到了MVC 分层架构-模型/视图/控制，如有不清楚的请自行百度)。这样做了之后，销售人员去demo的时候仅仅须要给对方看下server的外观，就能够在不接入server的情况下直接在电脑上把软件装上进行演示了。

过程仅仅须要向对方表明真实情况下数据是通过网络存储在数据中心的。仅仅是如今为了方便demo而暂时存在本地而已。

所以这里产品经理要考虑的不仅仅是真实的产品出来的情况。还须要考虑怎样方便销售团队在外进行演示，特别是在产品早期获取用户反馈的时候。

不然你没有足够的用户反馈支撑的话。终于还是走回了闭门造车的老路。

别默认架构师或者项目经理会帮你考虑好销售团队遇到的这些困难，这个产品是你的(事实上在Scrum里面，产品经理的名字叫做Product Owner。也就是产品拥有者)，项目经理和架构师等团队成员仅仅是负责将你交给他们的产品backlog在预期时间内实现出来而已。

竞品分析

上面在谈用户体验的时候有谈到过这一点。一个产品经理要时刻注意着市场的动态，留意着竞争产品的动向。比方我们一開始做的云产品就犯了这种错误，一開始市场上难觅竞争者。战线開始拉得太长，功能不断叠加，产品迟迟没有推出市场。

某一天忽然跳出了个新闻。“百度云1T永久容量 领先进入云空间T时代“，我们的心几本上就已经凉了半截了。

当然。事实上我们当时的产品迟迟没有推出市场的原因错综复杂。可是，毫无疑问，对市场动态和竞品的分析力度和把握的不够是当中一个不可忽视的原因。

所以作为产品经理，要时刻的眼观八路耳听四方，或许竞品新版本号的一个新功能的出现。你就须要立马有针对性的调整自己的产品的实现策略。

要知道。一个产品经理不应仅仅是知道不停的往产品backlog中添加新的功能，更重要的是你要知道不停的为公司添加新的增值。

除了上面说的这几点。事实上我认为以前做产品经理的时候还有非常多地方值得优化的，比方功能点优先级排序的把握(这里特别要提到的事三个木桶原则。详细请查看本人之前翻译的一篇文章《怎样打造一个伟大的产品》)。功能点优化，产品可扩展性的掌控，团队的互动，与项目经理的合作等等，可是限于篇幅和时间，暂时就先说这么多吧，或许今后会另外开篇继续进行阐述。当然。也希望各位看官能在评论中说出你们的观点。

提醒:很多其它文章请关注公众号:techgogogo或官网www.techgogogo.com。当然，也非常欢迎您直接微信(zhubaitian1)勾搭。欢迎转载，转载时敬请保留公众号等信息。