按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
处都是，就不赘述了。
再谈谈工作了几年，来应聘产品经理的人，几乎都可以算是转行了。做产品的人
有个特点，那就是从做啥的转过来的都有，我身边就很乱：原先是技术人员的，比如
开发工程师、测试工程师、架构师；原先是非技术类的业务人员的，比如市场人员、
产品运营师。这些信息至少会给你信心，不管以前是做什么的，都可以转行做产品经
理。我想这也是和产品经理需要照顾产品的各个方面有关，所以在构建一个产品团队
时，我们也希望招入各种背景的产品人员，这样能让团队在考虑问题的时候思维更加
全面。
几个可能的入行切入点
最后，我尝试给出几个可能的入行切入点。确定自己想干这一行，也知道自己的
位置以后，就剩下怎么向目标前进最省力的问题了。
也许你要失望，因为真的没有捷径，真的没有银弹！对于想转行的人，我的建议
是先在本职工作上找到与产品有关的事情做一些尝试，并且考虑先从产品经理周边的
职位做起。好在产品经理的职责范围什么都涉及，这种事情总是能找到的。
比如你是做开发的，那就经常要参与需求评审，不妨比别人多用点功，每次都预
先了解需求，多多思考，然后在评审会上对需求提出自己的合理建议，时间长了大家
都会觉得你很有想法，做产品也许不错。关于职位，可以从“需求分析师”切入，这
有些像系统分析的工作，比如业务逻辑、流程图，都是你已经很熟悉的，你可以在这
个过程中慢慢培养商业的感觉，重点体会某个产品功能是为了满足商业上的什么需求
而做的。
又如做网站运营的人，有时候会要专门做一些活动的页面，通常是把需求提给用
户体验部门的同事，这样的事情其实就是在做一个小产品了，你可以改变原来用Word
随便写几句要求，甚至口述沟通的方式，而是把这个活动当作一个产品来做，自己练
习写一下BRD7、PRD8，虽然这些文档对于一个小活动作用不大，但这个过程可以帮助
自己在以后碰到更复杂的产品的时候，心里会有点底。所以原来职责偏商业的同学，
可以先做“运营专员”，对已有的产品做一些推广策划类的工作，增强自己对产品的
理解，做一段时间后，相信就能提出自己对产品改进的想法了。
而项目经理也比较好切入，我工作过的团队就有很多同事是从项目经理直接转过
来做产品经理的，因为多数的产品经理也要带项目，所以找个项目经理来也算先得个
便宜，不过也正如第 3。1 节里“产品经理和项目经理”说到的，这种转行有其特定的优
势和劣势。
做过上面的这些事情后，至少面试的时候可以多点谈资。最后给大家介绍一个很
简单的办法——研究几十家公司的产品经理招聘广告。我一直觉得把研究结果做成一
份漂亮的调研报告，而后去应聘产品经理是个很靠谱的事，而且我相信大家多半都很
想读这样的一份报告，可惜还没见过有人这么做。
7 BRD：Bussiness Requirement Document，商业需求文档，书中第 2。4。1 节有详细描述。
8 PRD：Product Requirement Document，产品需求文档，书中第 3。3。1 节有详细描述。
D：My Documentstemp workMy Dropbox2010 成书重要备份分章书稿图片素材汇总可提交的独立文件2…01 生态系统里的云和雨。png
第 2 章
一个需求的奋斗史
在一个生态系统中，水是万物生命之源，而水之源又是天上的云，它们转化为雨，
滴落并滋润大地。
我真正开始做需求相关的事情，是从 2006 年底开始的，直到 2007 年夏末，大半
年的时间过去，总算对需求要做哪些工作有了比较全面的了解。本章将从“需求采集”
开始，一直讲到“确定某个项目的需求范围”为止，从需求被发现到决定实现，这就
是一个需求的奋斗史（见图 2…1）。
图 2…1 “一个需求的奋斗史”缩略图
首先说说“从用户中来到用户中去”，做任何产品都是一个端到端的过程，端即用
户，所以“用户是需求之源”，我们要拥有“以用户为中心的思想”，不断“体会真正
的用户”，于是，本章开始就会和大家“聊聊用户研究”。
然后我带着大家发起“需求采集的大生产运动”，与用户接触的过程就是需求采集
的过程，我们来看看几种常用的需求采集方法，如“数据分析”、“调查问卷”、“用户
访谈”等。并且希望大家意识到“需求采集人人有责”，从而“尽可能多地采集”。
用户说了很多需求，产品经理要“听用户的但不要照着做”，必须“明确我们存在
的价值”是“把用户需求转化为产品需求”，这一过程即需求分析过程。产品经理要通
过“给需求做一次 DNA 检测”，来“确定需求的基本属性”、“分析需求的商业价值”、
“初评需求的实现难度”，从而计算出需求的“性价比”。
资源总是有限的，所以我们只能做那些性价比高的事情，通过残酷的需求筛选，“活
下来的永远是少数”。看看“永远忘不掉的那场战争”，给自己打打气，“别灰心，少做
就是多做”，我们要有意识的“尽可能多地放弃”。
最后，是需求管理的话题。任何东西多了都需要管理，做产品更是“心急吃不了
热豆腐”。这里与大家聊聊“一个需求的生老病死”，“需求管理的附加值”。再次回顾
需求的奋斗史，也回顾我自己“和需求一起奋斗”的第一年。
也许大家已经发现，本章的讨论还仅仅局限于有一堆需求的时候应该“做哪些”、
“做多少”的问题，并没有谈及需求“怎么做”。我会在第 3 章“项目的坎坷一生”里
和大家仔细聊聊项目里的“需求阶段”要做的事情，我将其称为“需求开发”，如产品
需求文档、用例文档应该怎么写。
很多人，包括我，入门的时候都是从写文档做起的，但事后想起，那种“接到一
个任务，然后把它完成”的味道很没有产品经理的感觉 1，所以我在本书第 2 章就会说
明这个任务是怎么一步步明确的。当然，如果你现在已经被这样的任务弄得焦头烂额，
急需一些拿过来就能用的指导，也可以先去本书第 3。3。1 节“真的要写很多文档”，看
看“需求开发”应该怎么做，只是你心里得清楚，其实对于产品经理来说更重要的是
“发现一个问题，然后设法将其转化为一个任务来解决”。
1 我觉得，做产品经理最大的快乐来源于实现自己的想法，而不是执行别人给的任务。
2。1 从用户中来到用户中去
2。2 需求采集的大生产运动
实际工作中，到底采用哪种用户研究方法，往往取决于资源，比如人员数量与能
力、老板给你多少时间、经费。如果资源非常少，我们甚至可能简化出很不正规方法，
比如只是查一些二手资料然后和同事们一起讨论、猜测一下用户是怎么想、怎么做的，
而有了资源以后，我们可能会叫几个用户过来访谈，请咨询公司协助出报告，或者出
差做用户调研等。每个人所处的团队条件不一样，也只能在实践中慢慢总结出适合自
己的方法。
但这些用户研究，或者说需求采集的过程，都会有如下几步：明确目标、选择采
集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
把上一节的图 2…3“用户研究的方法”简化为图 2…4，对应图中四个象限，第 2。2。1
至 2。2。4 节分别通过一种最常见的方法来谈这类方法的特点、如何操作及注意事项。
图 2…4 常用的需求采集方法
最后，提出“需求采集人人有责”的概念，这样，我们才能“尽可能多地采集”。
2。2。1 定性地说：用户访谈
用户访谈通常采用访谈者与被访者一对一聊天的形式，一批次用户访谈的样本比
较少，一般是几个到几十个，但在每个用户身上花的时间比较多，通常为几十分钟到
几个小时，围绕着几个特定的话题，我们问，用户答，用户说，我们听，这是一种典
型的定性研究。用户访谈可以了解用户怎么说，即他们的目标和观点。根据我自己的
经验，用户访谈经常用在新产品方向的预研工作中，或者通过数据分析发现现象以后，
去探索现象背后的原因。
用户访谈的常见问题与对策
用户访谈经常出现如下问题：
第一，“说”和“做”不一致的问题。
用户经常会骗我们，先看一个经典的索尼游戏机的故事。
索尼找了一些用户来，问他们喜欢黄色的还是黑色的游戏机，结果发现说喜欢黄
色的用户比较多。之后，索尼告知用户为了感谢他们的配合，将送他们一台游戏机，
颜色可以任意挑选，而同样一批用户选择黑色的游戏机带回家的更多。很明显，有部
分用户说喜欢黄色却带走了黑色的游戏机。
用户倒不是想故意欺骗我们，而可能是：他们被问了自己也没仔细想过的问题，
又不想回答不知道，就在现场编造了一个看似有理有据的理由，或者他们有讨好访谈
者的心理，会回答他们觉得你希望听到的答案，而不是自己真正的想法 2。
对我们来说，防止被骗的方法恐怕像索尼一样，尽量在用户可以和产品发生交互
的场合下进行，让用户在“说”的同时也“做”，只不过，这样访谈的成本会明显高
于电话访谈或邀请用户来公司的会议室访谈。另外，我们也可以注意区分用户说的事
实与观点，一般来说，诸如“我做了什么，步骤如何，碰到了什么问题”这类事实的
可信度更高一些，而“我觉得、