需求探索

确认价值

    什么是「需求」？简单来说：

需求=问题

满足用户的需求=解决问题=产品

    「问题」一般藏得深，用户难以表达出来，甚至他们自己也不知道想要什么。举个例子，用户说「饿了」，往深挖掘：如果问题是「活不下去」，塞给馒头即可；如果问题是「想吃好的」，馒头就不管用了。有意思的是，用户往往直接提出经过自己思考后、理想化的解决方案(比如，更快的马)，这个时候已经离问题十万八千里了。

    产品经理要做的，就是揪出用户的问题所在。用户想要一对翅膀？噢不，其实他只是想快点从上海赶回汉口。

    若问题大众化，或者惹毛了愿意付费的高端 / 小众用户，或者我们的产品方案能更完美地解决问题，这便是价值所在。为了确认价值，几件事情必须完成：

产品定义

一句话描述用来解决谁的什么问题

目标用户

核心人群的属性(性别、年龄段等固定不变的)和偏好(小清新、喜欢旅行等阶段性的)

用户场景

人物角色。把目标用户拆开，进行细分，绘制典型用户

用户场景。这些典型用户在什么情况下用该产品的哪个点

产品特色

最吸引人的3个特质

竞品分析

评价指标

靠什么指标来判断上线的产品好还是不好

指标预期值

    收集、整理和掌握足够有用的信息，才适合做上述判断。多和团队成员聊聊，想必是极好的。

    上面的话题网上俯拾皆是，不管是产品相关还是用户体验相关(的博客还是书)都在聊这些东西。强调之多，可见之重要。对于大公司来说，每个环节都必不可少；并非为了应付团队成员的质疑，这是大公司以「规避风险」为原则的生存守则。

确定范围

项目层面

    首先是时间范围。确认期望上线时间，可能有时政因素、竞争对手因素的考虑。(还可能包括下线时间，比如某活动，某版本。)

    其次是项目范围。从框架(比如跨系统流程图)开始评估，一步步细化到预期解决方案。确认一定要做什么，一定不做什么。

    最后，最重要的是，确认优先级。为了在保证确认时不会跑题，以及尽量避免争执，可以从这三点出发：

产品定义。引用「基本产品」的概念，即这个最小化的产品必须满足，不满足就等于没做这个产品，不满足就会死

人物角色。优先满足哪个类型的用户

产品原则。定义产品的方向。资源(人力和时间)有限；在解决方案既定的情况下，优先满足运营计划、功能实现还是用户体验

    前两个在上一步已经讨论过，所以只用把产品原则讨论清晰即可。噗，冥冥中还有一个：关键绩效指标(KPI)。

部门分工

    谁在哪个时间点向谁交付什么。

    团队协作的效率就指望这4个要素了。对于大项目来说，有两个图很好使：

甘特图。跟踪项目进度的利器

跨系统流程图。理清部门关系最方便不过

解决方案

    主要包括：

产品经理。功能方案，即产品功能规格文档，或者称产品需求文档(PRD)

项目经理。技术方案，不仅包括开发，还有测试方案

交互设计师。体验方案，即交互稿

    这些同学在产出方案之余，还有各自的职责。嗯，产品经理需要协调资源、控制需求和进度，项目经理需要和数据库管理员确认细节，测试经理需要在系统压力和安全上分析考虑，交互设计师需要协调整体视觉样式，等等。

团队沟通

邮件

    坚持按要点(1、2、3)撰写邮件，不仅方便对方阅览，更有助于自己整理思路。要点根据重要紧急程度依次展开。需要后续跟进的部分，确认部门分工四要素，缺一不可。邮件发送给项目成员(比如前端开发)，抄送给项目相关成员(比如主管)。

    邮件的行文：对事、语言精炼、有进展。

    重要的事情务必口头沟通确认。

会议

    会议总是不讨人喜欢。故此，不论是会议组织者还是参与者，为了自己宝贵的时间，都有必要维护会议的高效性。根据项目阶段，粗浅地分为两类。

头脑风暴类

阶段：项目前期

目的：发散思维

要素：主题、思路、成果

议题类

阶段：项目中期和后期

目的：达成一致

要素：目的、问题、结论

    参考资料

莱恩 《给产品经理的建议》(英文) http://feltpresence.com/articles/14-advice-for-product-managers

知乎 《怎样判断用户需要(Need)和用户想要(Want)什么？》 http://www.zhihu.com/question/19574413

小轰 《关注问题，而不是解决方案》 http://cuikai-wh.com/blog/2105

小轰 《产品原则，还是用户习惯？》 http://cuikai-wh.com/blog/2276

知乎 《如何高效地管理邮件？》 http://www.zhihu.com/question/19600890

纯银 《谈开会》 http://firecacada.blog.163.com/blog/static/70743762012031102447600/

    扩展阅读

打不死的小强 《真假需求》 http://xiaoqiang.me/?p=3416

随线放矢 《关于产品管理》(英文) http://www.randomwire.com/product-management-manifesto

优涩控 《解决方案，而不是功能》 http://www.userkon.com/tolyer/about_solution_no_features.html

设计团队博客 《以故事为中的设计：武装你的大脑，像用户一样思考》(英文) http://www.designstaff.org/articles/story-centered-design-2012-03-22.html

费杰 《由产品经理找人难想到的》 http://www.kuliqiang.com/?p=3791

产品启迪 《我是产品经理》(英文) http://mindtheproduct.com/2011/10/i-am-a-product-manager/

白鸦 《关于要不要做调研》 http://uicom.net/blog/?p=912

互联网的那点事 《为何产品升级后越来越烂》 http://www.alibuybuy.com/posts/67025.html

建议继续学习：

1. 不懂技术的人不要对懂技术的人说这很容易实现    (阅读：4431)
2. 关于架构的一句话，还有一个实例    (阅读：3592)
3. 用Unix的设计思想来应对多变的需求    (阅读：3609)
4. 需求评审与讨论问题的基本方式    (阅读：2982)
5. 百度PM万维雅：需求把握和正确决策    (阅读：2707)
6. 如何准确看清用户需求？    (阅读：2570)
7. 用户的地图需求分析    (阅读：2407)
8. 如何媒体正确的看待：产品需求文档和产品需求    (阅读：2258)
9. 姐要的视频广告    (阅读：2256)
10. 分析用户需求：在场景中寻找“痛点”    (阅读：2072)