大把大把的产品像是柴火，把产品经理这个角色烧得火热。
满大街都是想做产品经理的人、觉得自己适合做产品经理的人、以及已经做了产品经理又觉得现在随便哪个阿猫阿狗都要做产品经理的人。其间种种党争热闹之后，还是做一个安静学习的美男（女）子吧。
（以下是个人学习心路历程，一家之言，不当之处，多多指正。）
1. 产品经理好做吗
来跟“PM”的项目经理做对比看看。
对于项目管理而言，周期短、环境或风险等不可控因素影响相对更大，对进度、成本、质量等项目执行要素的要求最高。
产品管理与之差异明显，首先，产品的战线更长：产品的生命周期远长于一般项目；但更重要的区别是，项目交付成果的定义一般在客户（甲方）手中，而产品的定义在产品提供者（乙方）手中，——也就是说，甲方定义了的交付成果，只要执行到位即可交差，但由乙方定义的产品，如果没有跟客户／甲方的需求对接，人家可以不买不看嗤之以鼻啊。
所以产品经理的角色，是要打通从需求到功能再到实现的通道，并且向外延伸到用户的心坎儿里。
那么尝试总结一下产品经理最重要的职责：
1）正确的需求：与客户的对接。
2）恰当的定义：把需求用功能描述的语言讲清楚，类似用例，但粒度可能更灵活。
3）合理的执行：分得清轻重缓急，而且是能够给开发人员送报纸的好汪汪。
4）Last not the least：最少偏差的信息传达。
要实现优秀的理解能力、思考能力、沟通能力、组织能力与执行力于一身，难啊。
2. 产品定义先上手
感谢CCTV，感谢Baidu，感谢爱唠嗑的PM们，感谢爹妈给的肠胃，学习、消化并吸收，然后纸上谈兵产品定义的过程如下：
（1）唠嗑，哦不，沟通需求。
沟通的方式可以有很多种，调查问卷啦、SNS啦、数据分析啦等等。
最直接的方式还是找人聊天（题外话，据说Snapchat的CEO鼓励所有员工找公司以外的人吃饭聊天，给予报销额度，并认为从中受益颇多），人是感性动物，用户也是人，不是吗？不是吗？！
如果要进一步细分，用户更像是女人，会说“你哪儿错了？你哪儿都没错！你怎么可能有错！”的女人，所以直接沟通能够获得的信息量比机械式的信息采集要多得多。
输出结果：会议纪要、沟通纪要。
（2）需求整理
很多UGC中几乎没有把这个步骤单列出来的。但我觉得，需求整理、反馈、再整理的过程更加重要。
对应一整套产品的需求，至少应该是分层次的。比如，用户的本质需求是什么，表象需求是什么，其它附属需求（够装之类）又是什么，大需求分解成为小需求又是什么。也应该是分类的，比如，有些需求是个性化的，可能某些客户有某一类需求，但更多客户认为没有必要、甚至无法理解；甚至有些需求的输入本身就可能是错误的。
如果有一个好的需求整理框架，应对新的需求输入也许能够更加从容。这个需求整理框架即应该跟产品架构具有直观的对应关系。
输出结果：用户分析、需求架构图。
（3）功能列举
上来就画架构图似乎有些困难，更不用说原型之类的高大上了。
所以从我这样的零基础菜鸟看，根据需求一条条写功能似乎是最容易上手的事情。
有了功能，再反推架构，就显得顺理成章了。
所以，这一步实际上是进行产品梳理的中间环节，辅助需求与产品之间的对接。
输出结果：功能列表。
（4）产品架构
这一步与第二步的需求整理有着直接的互动：合理的产品架构能够帮助我们更好地管理碎片化的需求。
目前我看到的大多数产品架构是通过脑图展现的，可以使用的工具很多，像xmind、mindmanager。但考虑到完整的产品架构中涉及的要素比较多，各要素的反馈修改更多，至少包括功能、信息、甚至需求与页面、交互，我觉得也许使用excel是一种更好的方式来搭产品的架子，未来有时间打算试一下。
输出结果：产品架构图、信息架构图，如果业务复杂，最好把用户流程图也画清楚。
（5）原型设计
这大概应该是产品经理的主业：通过手绘原型、灰模原型、交互原型来作出产品的雏形。
输出结果：PRD文档、用例文档。
首期先到这里，去实践看看。
参考网站：人人都是产品经理、PM唐杰博客、百度文库。
