| 在产品的调研的过程中，用户的需求往往被隐埋的很深。因为用户并不懂得表达出其需求，或者说，用户自己阐述的概念并不能表达出其所期待的解决方案。
由用户口中给出的解决方案与其真实需求相去甚远，因此在任何产品开发的过程中，都应该注重对用户的需求管理。
我们能从用户口中听到各种各样“奇妙的想法”，有的复杂有的简练。但是无一例外的，用户不会给你一个清晰、有条理的需求线索，因此在解决用户需求的前提下，你所需要的就是对用户的需求进行探索。
需求探索
确认价值
什么是「需求」？简单来说：
1.需求=问题
2.满足用户的需求=解决问题=产品
「问题」一般藏得深，用户难以表达出来，甚至他们自己也不知道想要什么。举个例子，用户说「饿了」，往深挖掘：如果问题是「活不下去」，塞给馒头即可；如果问题是「想吃好的」，馒头就不管用了。有意思的是，用户往往直接提出经过自己思考后、理想化的解决方案（比如，更快的马），这个时候已经离问题十万八千里了。
产品经理要做的，就是揪出用户的问题所在。
用户想要一对翅膀？噢不，其实他只是想快点从上海赶回汉口。
若问题大众化，或者惹毛了愿意付费的高端 / 小众用户，或者我们的产品方案能更完美地解决问题，这便是价值所在。为了确认价值，几件事情必须完成：
- 产品定义
- 目标用户
- 核心人群的属性（性别、年龄段等固定不变的）和偏好（小清新、喜欢旅行等阶段性的）
- 用户场景
- 人物角色。把目标用户拆开，进行细分，绘制典型用户
- 用户场景。这些典型用户在什么情况下用该产品的哪个点
- 产品特色
收集、整理和掌握足够有用的信息，才适合做上述判断。多和团队成员聊聊，想必是极好的。
上面的话题网上俯拾皆是，不管是产品相关还是用户体验相关（的博客还是书）都在聊这些东西。强调之多，可见之重要。对于大公司来说，每个环节都必不可少；并非为了应付团队成员的质疑，这是大公司以「规避风险」为原则的生存守则。
确定范围
项目层面
首先是时间范围。确认期望上线时间，可能有时政因素、竞争对手因素的考虑。（还可能包括下线时间，比如某活动，某版本。）
其次是项目范围。从框架（比如跨系统流程图）开始评估，一步步细化到预期解决方案。确认一定要做什么，一定不做什么。
最后，最重要的是，确认优先级。为了在保证确认时不会跑题，以及尽量避免争执，可以从这三点出发：
1.产品定义。引用「基本产品」的概念，即这个最小化的产品必须满足，不满足就等于没做这个产品，不满足就会死
2.人物角色。优先满足哪个类型的用户
3.产品原则。定义产品的方向。资源（人力和时间）有限；在解决方案既定的情况下，优先满足运营计划、功能实现还是用户体验
前两个在上一步已经讨论过，所以只用把产品原则讨论清晰即可。噗，冥冥中还有一个：关键绩效指标（KPI）。
部门分工
“谁”在哪个“时间点”向“谁”交付“什么”。
团队协作的效率就指望这4个要素了。对于大项目来说，有两个图很好使：
- 甘特图。跟踪项目进度的利器
- 跨系统流程图。理清部门关系最方便不过
解决方案
主要包括：
- 产品经理。功能方案，即产品功能规格文档，或者称产品需求文档（PRD）
- 项目经理。技术方案，不仅包括开发，还有测试方案
- 交互设计师。体验方案，即交互稿
这些同学在产出方案之余，还有各自的职责。嗯，产品经理需要协调资源、控制需求和进度，项目经理需要和数据库管理员确认细节，测试经理需要在系统压力和安全上分析考虑，交互设计师需要协调整体视觉样式，等等。
团队沟通
邮件
坚持按要点（1、2、3）撰写邮件，不仅方便对方阅览，更有助于自己整理思路。要点根据重要紧急程度依次展开。需要后续跟进的部分，确认部门分工四要素，缺一不可。邮件发送给项目成员（比如前端开发），抄送给项目相关成员（比如主管）。
邮件的行文：对事、语言精炼、有进展。
重要的事情务必口头沟通确认。
会议
会议总是不讨人喜欢。故此，不论是会议组织者还是参与者，为了自己宝贵的时间，都有必要维护会议的高效性。根据项目阶段，粗浅地分为两类。
1、头脑风暴类
- 阶段：项目前期
- 目的：发散思维
- 要素：主题、思路、成果
2、议题类
- 阶段：项目中期和后期
- 目的：达成一致
- 要素：目的、问题、结论
功能与商业
确定需求（的价值、范围）后，便着手思考解决方案。很多方案是对产品功能的添删和改善，比如上传图片：
1.「上传图片」按钮。但一次只能上传1张图片
2.添加「批量上传」按钮，一次最多可以上传25张图片
3.删除「上传图片」按钮，更新「批量上传」按钮为「上传」，一次可以上传30张图片
4.优化视觉，突出「上传按钮」
5.优化方式，允许用于拖动图片到网页即可上传。同时将上限提高到50张
然而，功能通常滞后，而且容易被竞争对手模仿。功能上的改进对专业的竞争对手来说几近透明，还记得脸谱用更改颜色来验证校内网「反应速度」的例子吧（别在意是否真实）。反之亦然，自己的产品也可以跟风很酷的功能。问题在于，这些功能的初衷是什么呢？
iPad 用户场景：商务应用
功能一定对应某个的需求；而需求并非孤立存在，必然融合到使用场景中。用户作为社会人，进入场景时也必然带着情绪（与感情）。用户场景可以看成对用户情感的细化与细分。以评价为例，我作为消费者，当然是商品评价越客观、越有用越好；自己购物评价不评价则不太在意（至少不强烈）。做评价的产品，我会解决下面两个问题：
一、将现有的客观且有用的评价提炼出来
1.对商品的评价无非是偏好还是偏好，中评的价值不如好评和差评
2.有用=丰富=形容词≠泛泛而谈（比如「很好」这种词）
3.提炼，即一瞟页面就能看出，扫都不用扫
二、鼓励用户产生客观且有用的评价
1.人都是自利的，目的是利用产品将自利转化为同时利他。这句话比较绕，反过来说即将利他转化为自利。比如，小朋友帮助老奶奶过马路，得到老奶奶的表扬，可以有材料写作文，增强了自我肯定
2.可以评价某一条评价，并结合网站会员体系，积分信誉神马的
功能可以克隆，需求可以模仿，场景可以堆资源去覆盖，但情感只能亲自体会。一款没有情感灌注的产品，是没有灵魂的
3 ，也不可能做到极致。
一旦关注用户的情感，产品功能便顺其自然；有时甚至微不足道。
商业化的产品离不开商业意识。在《产品经理修炼之道》的座谈会上，印象最深的莫过于这样一句话，大致是：「产品经理能不仅仅通过功能和技术解决问题，而要跳出来，不能只做技术范围内技术不做的事。」
至于张小龙说「微信是一种生活方式」我倒不以为然。
首先，「生活方式」难以定义，至少比「噱头」难。其次，这句话用任何其它大型互联网产品代替「微信」都比微信更合适。
个比方：QQ 是一种生活方式（有事儿您Q我），百度是一种生活方式（有问题，百度一下），淘宝是一种生活方式（淘不出手心），微博是一种生活方式（随时随地分享身边的新鲜事儿）……不过这也没什么好叨的，毕竟微信取得了市场占有率的成功，还不如讨论「同样是腾讯的产品，为什么微信成功了，腾讯微博却没有？」
|
