理清需求
当了十几年的敏捷团队的产品经理，我觉得这些年积累最多的经验就是把握客户需求。产品经理作为和客户接触最紧密的人，对客户需求最了解，在敏捷迭代开始之前，就要先将客户的需求整理出来。然而，不是每个客户都会交给你一份整理好的需求文档，也许客户的需求只是一个idea，具体需要什么自己也没想好。这时，如果产品经理拿着这个idea去给开发交代任务，我敢肯定会被凑回来的。
那么，该怎么做呢？重要的两点：沟通和整理。首先，尽量多的和客户沟通，搜集各个渠道客户的需求信息，并理清需求优先级和价值，记录下来。使用一款好的工具有事半功倍的作用，我推荐使用脑图的方式记录需求，MindManager和Xmind都还不错，我一直在使用华为软件开发云的scrum流程中的“项目规划”，这个服务在脑图的基础上为产品需求分了层次，更有助于整理。
我经历过的故事
讲个我们团队一个web平台的研发案例吧，有一家规模比较大的家居公司，由于销售量下滑，想把主战场转战到线上，老板找到我们说“给我做一个卖家居的网站吧”，其它的就没了，不是老板对网站没要求，而是他还没想出来。
我带着公司几个人去家居店里转了一圈，记录了一下销售的产品和品牌，和店员咨询了一下店里的活动，就回公司开始整理需求了，下图是我整理出来的产品backlog，我在开发云平台上直接把工作项导出excel，发给了客户。客户很快就有反馈了，说增加一个“样品特卖”的功能，将实体店里摆放超过三个月的产品定期更新到网上，低价处理。
此外，预约到店的客户要给折扣优惠。客户在我的分类筛选上也给了详细的建议，按照家居风格，家居实材，房间类型等。
总之，客户根据我的初稿，有了真正的需求。
拆分需求
敏捷开发过程中,通过进行Story拆分,将客户的需求对接给开发人员，帮助开发人员发现问题，识别交付风险，这就要求Story必需要是验收的。
对于一个pizza开发团队（7到8人），一个迭代我们建议完成5-10个story，所以story的大小应该符合这个团队速率。
拆分前应考虑的点：
1．Story之间的依赖，一个story的完成是否依赖另一个；
2． 从简单到复杂，不要追求一次把事情做完，用贝塔版响应客户需求
3.先使能功能，再完善性能
拆分后应考虑的点：
1.优先级，哪个story先交付会提高客户认同感或降低开发风险——提高它的优先级
2.拆丢了，哪个客户关注的点没有story对应——增加
3.拆多了，哪个story客户不关心，没有交付价值——删除
澄清需求
Story拆分之后，最重要的是让开发人员充分的理解需求。在迭代开始前的计划会议上，对需求讲解之后，一般会让开发人员进行反串讲，这样一个回合之后，基本不会上有理解的偏差，工作量也直接评估出来了。
以上只是浅谈了产品经理的一些工作内容，对于新手产品经理，由于缺乏经验，迷茫和困惑是不可避免的，但只要端正从客户角度出发，对开发团队负责的态度，不怕苦不怕累，离成功只是时间的问题。
