作为产品经理，不应只知道往产品backlog增加新功能

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

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

所以，如果把客户这个概念给抽象封装一下的话，我们也可以说德国那个同事其实就是我们这个产品的客户了。所以说，其实产品经理这个概念是比较泛 的。你可以是一个产品型的产品经理，一个产品的创意的诞生到最终实现推向市场交到客户的手上，整个过程你都必须把控；你也可以是一个市场型的产品经理，针 对已经在卖的产品，发掘市场的需求，然后交给开发团队来不断的迭代等等。

技术债务

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

在一开始的一两个 sprint 里面其实整体状况也都还好，燃尽图也不算太难看。但是做到后来那条曲线就开始翘得越来越高，远远偏离了理想曲线了。最终不得不由原来计划的 7 个 sprint 调整成 10 个 sprint。

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

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

这里看上去只是跟程序员有关系，事实上并非如此，这个更多是跟产品经理的理念有关系。像我之前，一心只想团队快速的把产品 backlog 里面的功能快速完成，而没有花足够的心思去思考产品表层下面的东西，没有去认真去抓实现的质量的问题。如果是将一个产品描述成一个建筑的话，那我觉得功能 就是客户所看到的地面以上的这一部分，而质量就是隐藏在地底下的这个地基这一部分。也许你现在看到的这栋房子外观宏伟功能齐全连厕所都实现了自动化，但是 一旦碰到大点的风吹雨打，或者说想要加建一两层的话，可能整栋楼立刻就坍塌了。

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

用户体验

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

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

错把自己当用户：这特别容易发生在一个初创企业里面，因为企业自身的经验不足，以及产品经理的过于自负，同 时也由于创业早期并没有把目标客户过早的关联到项目中来（其实在 Scrum 里面是很强调用户的参与的)），所以一个 sprint 下来开始 demo 的时候，往往 demo 的对象就是项目的同一帮人。而产品经理在考虑下一 sprint 的用户体验的时候，又往往觉得自己能够像周鸿t一样能瞬间变小白。所以周而复始，几个 sprint 下来，产品拿出去一试水，发现就是石沉大海，结果就是再也没有结果了。

这个错误在敏捷团队里面也可以叫做是“小瀑布”错误，这就是没有让用户过早参与进来的后果。看上去是在跑 Scrum，事实上确是将原来的瀑布模式分解成几个小瀑布，然后套用了 Scrum 的概念，有名而无实。

忽视了首次使用体验：其实用户是很没有耐性的，特别是互联网产品用户。你的产品可能功能很强大，UI 呈现也很惟妙惟肖，但用户却要花大时间，甚至要阅读你几十页的用户使用手册才能搞清楚怎么使用你的产品来解决他们的痛点，最终发现解决他们痛点的那个功能 竟然埋藏在三级菜单甚至以下，那你还预期他们会爱上你的产品吗？

要解决这些问题的方法我认为也很简单：

让用户尽早参与进来：比如我们当时在创业公司的做法是，因为我们当时做的是一个适合个人和小企业的私有云产 品，所以我们就到附近大学里面找了些学生过来进行试玩以及给他们做 demo，然后收集反馈。在他们试玩的过程中要有专人进行跟踪记录，且纪录人不能给对方任何提示。当然，最后别忘记了给学生们一些报酬，我们当时是送学生 们 100 块左右的话费充值卡。

竞品研究：除非你在做的这个产品是非常有突破性的，业界还没有同类产品出现，不然你肯定可以在海内外找到一 些部分功能相近的产品出来的。这里也许你会说抄袭可耻之类的话语，我们听下传奇人物史玉柱是怎么说的：“抄袭不但要厚脸皮，还要发展和优化。如果你抄后， 还超越了对方，别人就不会说你抄了。“ 所以作为产品经理，你经常要做的事情还要是不断的去研究别人的产品，而不是只盯着产品 backlog 这一亩三分地，而这里说的还不仅仅只是用户体验上面，还包括其他功能点的调整，因为现在信息瞬间万变。关于这一点，下面还会有所阐述。

支持销售团队

这里还要由我们当时做的另外一个面向二手房的房源管理系统说起。当前二手房中介用的比较多的房 xxx 等商用房源管理软件，会把他们的房源数据上传到软件供应商自己的数据中心上面去。而房源信息其实一个中介的命脉，所以他们更希望是这个数据中心放在自己公 司里面。所以我们当时做的就是提供一个数据中心服务器，以及相应的一套房源管理软件，管理软件支持 PC 端和移动端。

MVP 出来后，开始去跑各种二手房中介进行 demo 以收集进一步信息。问题来了，正如上面所说的，用户是没有耐心的，无论你说的天花乱坠，还是眼见为实。但是将整个服务器架起来还是需要不少时间的，别人还 需要特意给你腾出空间和提供网络接入等，且更尴尬的是，因为这还是很初期的产品，在你公司里面跑的时候一般很正常，跑到人家环境里面一跑的时候，不是这出 问题就是那出问题。最终很多客户都是以有事忙为由，中断了该次演示。

其实这里完全没有必要在初次 demo 的时候就把整个环境给架构起来，完全可以在数据控制层下面嫁接一个服务器模拟器，这样你的数据就不用非要通过网络和数据中心进行交互了。这样做了之后，销 售人员去 demo 的时候只需要给对方看下服务器的外观，就可以在不接入服务器的情况下直接在电脑上把软件装上进行演示了。过程只需要向对方表明真实情况下数据是通过网络存 储在数据中心的，只是现在为了方便 demo 而临时存在本地而已。

所以这里产品经理要考虑的不仅仅是真实的产品出来的情况，还需要考虑如何方便销售团队在外进行演示，特别是在产品早期获取用户反馈的时候。不然你没有足够的用户反馈支撑的话，最终还是走回了闭门造车的老路。

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

竞品分析

上面在谈用户体验的时候有谈到过这一点，一个产品经理要时刻注意着市场的动态，留意着竞争产品的动向。比如我们一开始做的云产品就犯了这样的错 误，一开始市场上难觅竞争者，战线开始拉得太长，功能不断叠加，产品迟迟没有推出市场。某一天忽然跳出了个新闻，“百度云 1T 永久容量，率先进入云空间T时代”，我们的心几本上就已经凉了半截了。

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

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