您的位置：
作为产品经理，不应只知道往产品backlog增加新功能
作者：佚名
　　摘要： 要知道，一个产品经理不应只是知道不停的往产品backlog中增加新的功能，更重要的是你要知道不停的为公司增加新的增值。
　　所谓时间飞逝、日月如梭，暮然回首，猛然发现自己出道伊始也将近十年了。回顾此前自己曾经担任过的角色，不可谓不繁杂。曾经做过翻译员、测试、开发、测试主管、项目经理、产品经理，甚至还做过销售，徒步的大街小巷的去拜访潜在客户。此间我觉得最让自己慨叹的是当年做产品经理的时候的一些得失。所以这里就打算写下来，与同行们共勉。
　　其实之前所做的“产品经理”这个角色，我认为是应该打个引号的。因为真正去跑市场、去全世界到处飞、去挖掘需求的是德国那边的一个同事，只是开发团队在珠海这边，而我刚好英语沟通能力还算可以，所以就把我安排到这个所谓的“产品经理”的角色上来了。
　　所以，如果把客户这个概念给抽象封装一下的话，我们也可以说德国那个同事其实就是我们这个产品的客户了。所以说，其实产品经理这个概念是比较泛的。你可以是一个产品型的产品经理，一个产品的创意的诞生到最终实现推向市场交到客户的手上，整个过程你都必须把控;你也可以是一个市场型的产品经理，针对已经在卖的产品，发掘市场的需求，然后交给开发团队来不断的迭代等等。
　　技术债务
　　这可能跟当时我做的这个“产品经理”的特殊性有关系吧，我当时花的绝大部分时间都是在我们的产品backlog和每个sprint的backlog上面，不断的跟德国那边进行需求的讨论，不停的和团队进行需求的细化，再紧张的去将功能进行优先级排序并和各路人马进行讨论，然后投放到相应的sprint
backlog上面去...
　　在一开始的一两个sprint里面其实整体状况也都还好，燃尽图也不算太难看。但是做到后来那条曲线就开始翘得越来越高，远远偏离了理想曲线了。最终不得不由原来计划的7个sprint调整成10个sprint。
　　后来对这个问题有进行仔细的反思，究其原因，我觉得有好几个，但是其中最重要的应该就是没有及时的去对”技术债务“进行清理。
　　其实这个道理看上去很简单，基本上跑过敏捷开发的人都知道技术债务给项目所带来的伤害。但是在真正项目开始的时候，我们往往又会因为赶时间而匆忙将新的功能进行实现，而忽略了代码的可扩展性和鲁棒性等，最终这些“技术债务”越累越高，越到后面越发觉尾大难掉，修改一个地方可能都会牵一发而动全身。
　　这里看上去只是跟程序员有关系，事实上并非如此，这个更多是跟产品经理的理念有关系。像我之前，一心只想团队快速的把产品backlog里面的功能快速完成，而没有花足够的心思去思考产品表层下面的东西，没有去认真去抓实现的质量的问题。如果是将一个产品描述成一个建筑的话，那我觉得功能就是客户所看到的地面以上的这一部分，而质量就是隐藏在地底下的这个地基这一部分。也许你现在看到的这栋房子外观宏伟功能齐全连厕所都实现了自动化，但是一旦碰到大点的风吹雨打，或者说想要加建一两层的话，可能整栋楼立刻就坍塌了。
　　所谓欲速则不达，一个产品经理不应该只是把眼光盯着那份功能列表，还应该多花点时间在解决“技术债务”这些事情上面来。
　　用户体验
　　我相信没有哪个产品经理会忽视用户体验的重要性。用户买你的产品/软件的时候，其实他们真正买的是解决他们的痛点的方案。如果用了你的产品之后，原来的痛点解决了，但糟糕的使用体验却成为他们的新痛点，那用户的逃离也为时不远了。
　　根据本人之前做产品经理的经验以及后来在一家创业公司的经历，我发现我们在用户体验方面很容易犯的错误主要有以下几个：
　　错把自己当用户：这特别容易发生在一个初创企业里面，因为企业自身的经验不足，以及产品经理的过于自负，同时也由于创业早期并没有把目标客户过早的关联到项目中来(其实在Scrum里面是很强调用户的参与的))，所以一个sprint下来开始demo的时候，往往demo的对象就是项目的同一帮人。而产品经理在考虑下一sprint的用户体验的时候，又往往觉得自己能够像周鸿祎一样能瞬间变小白。所以周而复始，几个sprint下来，产品拿出去一试水，发现就是石沉大海，结果就是再也没有结果了。
　　这个错误在敏捷团队里面也可以叫做是“小瀑布”错误，这就是没有让用户过早参与进来的后果。看上去是在跑Scrum，事实上确是将原来的瀑布模式分解成几个小瀑布，然后套用了Scrum的概念，有名而无实。
　　忽视了首次使用体验：其实用户是很没有耐性的，特别是互联网产品用户。你的产品可能功能很强大，UI呈现也很惟妙惟肖，但用户却要花大时间，甚至要阅读你几十页的用户使用手册才能搞清楚怎么使用你的产品来解决他们的痛点，最终发现解决他们痛点的那个功能竟然埋藏在三级菜单甚至以下，那你还预期他们会爱上你的产品吗?
　　要解决这些问题的方法我认为也很简单：
　　让用户尽早参与进来：比如我们当时在创业公司的做法是，因为我们当时做的是一个适合个人和小企业的私有云产品，所以我们就到附近大学里面找了些学生过来进行试玩以及给他们做demo，然后收集反馈。在他们试玩的过程中要有专人进行跟踪记录，且纪录人不能给对方任何提示。当然，最后别忘记了给学生们一些报酬，我们当时是送学生们100块左右的话费充值卡。
　　竞品研究：除非你在做的这个产品是非常有突破性的，业界还没有同类产品出现，不然你肯定可以在海内外找到一些部分功能相近的产品出来的。这里也许你会说抄袭可耻之类的话语，我们听下传奇人物史玉柱是怎么说的：“抄袭不但要厚脸皮，还要发展和优化。如果你抄后，还超越了对方，别人就不会说你抄了。“
所以作为产品经理，你经常要做的事情还要是不断的去研究别人的产品，而不是只盯着产品backlog这一亩三分地，而这里说的还不仅仅只是用户体验上面，还包括其他功能点的调整，因为现在信息瞬间万变。关于这一点，下面还会有所阐述。
　　支持销售团队
　　这里还要由我们当时做的另外一个面向二手房的房源管理系统说起。当前二手房中介用的比较多的房xxx等商用房源管理软件，会把他们的房源数据上传到软件供应商自己的数据中心上面去。而房源信息其实一个中介的命脉，所以他们更希望是这个数据中心放在自己公司里面。所以我们当时做的就是提供一个数据中心服务器，以及相应的一套房源管理软件，管理软件支持PC端和移动端。
　　MVP出来后，开始去跑各种二手房中介进行demo以收集进一步信息。问题来了，正如上面所说的，用户是没有耐心的，无论你说的天花乱坠，还是眼见为实。但是将整个服务器架起来还是需要不少时间的，别人还需要特意给你腾出空间和提供网络接入等，且更尴尬的是，因为这还是很初期的产品，在你公司里面跑的时候一般很正常，跑到人家环境里面一跑的时候，不是这出问题就是那出问题。最终很多客户都是以有事忙为由，中断了该次演示。
　　其实这里完全没有必要在初次demo的时候就把整个环境给架构起来，完全可以在数据控制层下面嫁接一个服务器模拟器，这样你的数据就不用非要通过网络和数据中心进行交互了。这样做了之后，销售人员去demo的时候只需要给对方看下服务器的外观，就可以在不接入服务器的情况下直接在电脑上把软件装上进行演示了。过程只需要向对方表明真实情况下数据是通过网络存储在数据中心的，只是现在为了方便demo而临时存在本地而已。
　　所以这里产品经理要考虑的不仅仅是真实的产品出来的情况，还需要考虑如何方便销售团队在外进行演示，特别是在产品早期获取用户反馈的时候。不然你没有足够的用户反馈支撑的话，最终还是走回了闭门造车的老路。
　　别默认架构师或者项目经理会帮你考虑好销售团队遇到的这些困难，这个产品是你的(其实在Scrum里面，产品经理的名字叫做Product
Owner，也就是产品拥有者)，项目经理和架构师等团队成员只是负责将你交给他们的产品backlog在预期时间内实现出来而已。
　　竞品分析
　　上面在谈用户体验的时候有谈到过这一点，一个产品经理要时刻注意着市场的动态，留意着竞争产品的动向。比如我们一开始做的云产品就犯了这样的错误，一开始市场上难觅竞争者，战线开始拉得太长，功能不断叠加，产品迟迟没有推出市场。某一天忽然跳出了个新闻，“百度云1T永久容量，率先进入云空间T时代”，我们的心几本上就已经凉了半截了。
　　当然，事实上我们当时的产品迟迟没有推出市场的原因错综复杂，但是，毫无疑问，对市场动态和竞品的分析力度和把握的不够是其中一个不可忽视的原因。
　　所以作为产品经理，要时刻的眼观八路耳听四方，也许竞品新版本的一个新功能的出现，你就需要立刻有针对性的调整自己的产品的实现策略。
　　要知道，一个产品经理不应只是知道不停的往产品backlog中增加新的功能，更重要的是你要知道不停的为公司增加新的增值。
　　除了上面说的这几点，其实我觉得以前做产品经理的时候还有很多地方值得优化的，比如功能点优先级排序的把握，功能点优化，产品可扩展性的掌控，团队的互动，与项目经理的合作等等，但是限于篇幅和时间，暂时就先说这么多吧，也许今后会另外开篇继续进行阐述。当然，也希望各位看官能在评论中说出你们的观点。
(转载请保留)
您刚刚看过
互联网的一些事，已超50万小伙伴关注！他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)如何编写product backlog_百度知道
如何编写product backlog
我有更好的答案
&。Importance(重要性)：产品负责人评出一个数值来衡量&故事&的重要性;。&故事&包括如下字段Product Backlog 是Scrum的核心。它就是一个需求、或故事、或特性等做成的列表，按照重要性的级别进行排序;Backlog 条目&故事&quot。一般2~10个字。比如。比如，先这样做;查看个人交易明细&quot：ID：统一标示符，自增字段：简短的、描述性的故事名称。它必须要含义明确，并用客户术语描述出来。我们称作&故事&(Story)，有时也称作&quot，数值越大，重要性越高。Initial estimate(初始估算);理想的人天(man-day)&故事&quot，需要几天才能给出一个经过测试验证，可以交付的完整的实现呢？如果答案是&quot，在完全没有打扰的情况下工作、解释说明、其他资料的引用等等，简短意赅;的含义：完成&quot。这个估算值不需要保证绝对无误，也不可能绝对的无误，而是要保证相对的正确性(即，两个点的故事所花费的实践应该是四个点的故事所花费的时间的一半)How to Demo(如何做演示即，手顺)：简述这个故事应该如何在Sprint演示上进行示范;重复。Name(名称);所需的工作量。最小单位&故事点&3个人大概4天&;，一般大致相当于一个&quot。防止&quot，那么初始估算的值是12个故事点;。附：【故事点】，就是把人锁到一个屋子里，有吃有喝，再那么做，然后做什么，最后就得到该得到的效果。Notes(注解)：相关信息。通常Product Backlog这个文档应该归产品负责人所有。里面包含客户想要的东西;故事&quot，这样产品负责人和开发人员才能通过字面意思明白&quot，其实就是一个简单的测试规范
为您推荐：
其他类似问题
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。【图文】第2.3.4章-编写产品backlog和制定Sprint计划_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
第2.3.4章-编写产品backlog和制定Sprint计划
&&硝烟中的scrum学习资料
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢51CTO旗下网站
作为产品经理，不应只知道往产品backlog增加新功能
　　所谓时间飞逝、日月如梭，暮然回首，猛然发现自己出道伊始也将近十年了。回顾此前自己曾经担任过的角色，不可谓不繁杂。曾经做过翻译员、测试、 开发、测试主管、项目经理、产品经理，甚至还做过销售，徒步的大街小巷的去拜访潜在客户。
作者：来源：天地会珠海分舵| 16:45
所谓时间飞逝、日月如梭，暮然回首，猛然发现自己出道伊始也将近十年了。回顾此前自己曾经担任过的角色，不可谓不繁杂。曾经做过翻译员、测试、 开发、测试主管、项目经理、产品经理，甚至还做过销售，徒步的大街小巷的去拜访潜在客户。此间我觉得最让自己慨叹的是当年做产品经理的时候的一些得失。所 以这里就打算写下来，与同行们共勉。
其实之前所做的&产品经理&这个角色，我认为是应该打个引号的。因为真正去跑市场、去全世界到处飞、去挖掘需求的是德国那边的一个同事，只是开发团队在珠海这边，而我刚好英语沟通能力还算可以，所以就把我安排到这个所谓的&产品经理&的角色上来了。
所以，如果把客户这个概念给抽象封装一下的话，我们也可以说德国那个同事其实就是我们这个产品的客户了。所以说，其实产品经理这个概念是比较泛 的。你可以是一个产品型的产品经理，一个产品的创意的诞生到最终实现推向市场交到客户的手上，整个过程你都必须把控；你也可以是一个市场型的产品经理，针 对已经在卖的产品，发掘市场的需求，然后交给开发团队来不断的迭代等等。
这可能跟当时我做的这个&产品经理&的特殊性有关系吧，我当时花的绝大部分时间都是在我们的产品 backlog 和每个 sprint 的
上面，不断的跟德国那边进行需求的讨论，不停的和团队进行需求的细化，再紧张的去将功能进行优先级排序并和各路人马进行讨论，然后投放到相应的
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时代&，我们的心几本上就已经凉了半截了。
当然，事实上我们当时的产品迟迟没有推出市场的原因错综复杂，但是，毫无疑问，对市场动态和竞品的分析力度和把握的不够是其中一个不可忽视的原因。
所以作为产品经理，要时刻的眼观八路耳听四方，也许竞品新版本的一个新功能的出现，你就需要立刻有针对性的调整自己的产品的实现策略。
要知道，一个产品经理不应只是知道不停的往产品 backlog 中增加新的功能，更重要的是你要知道不停的为公司增加新的增值。
除了上面说的这几点，其实我觉得以前做产品经理的时候还有很多地方值得优化的，比如功能点优先级排序的把握，功能点优化，产品可扩展性的掌控， 团队的互动，与项目经理的合作等等，但是限于篇幅和时间，暂时就先说这么多吧，也许今后会另外开篇继续进行阐述。当然，也希望各位看官能在评论中说出你们 的观点。
&【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条头条头条头条
24H热文一周话题本月最赞
讲师：108828人学习过
讲师：90589人学习过
讲师：15449人学习过
精选博文论坛热帖下载排行
本书分为4个部分共24章，以插件开发为中心，围绕插件开发主要介绍SWT/JFace的应用、插件扩展点的实现，以及GEF、EMF和RCP的相关知识。本书...
订阅51CTO邮刊