人人都是产品经理-第4部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 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。
对我们来说，防止被骗的方法恐怕像索尼一样，尽量在用户可以和产品发生交互
的场合下进行，让用户在“说”的同时也“做”，只不过，这样访谈的成本会明显高
于电话访谈或邀请用户来公司的会议室访谈。另外，我们也可以注意区分用户说的事
实与观点，一般来说，诸如“我做了什么，步骤如何，碰到了什么问题”这类事实的
可信度更高一些，而“我觉得、我认为”这类的观点，则需要带着大大的问号去听。
第二，样本少，以偏概全的问题。
选择样本的时候需要多加注意，尽量做到随机，举几个常见的“不随机”的例子。
比如为了成本考虑，我们上门访谈的时候只找了本市的用户，这样很可能得出一
些与地域有关的错误推论；又如电话访谈时，为了提高联系成功率，我们优先拨打留
了手机的用户，而留手机很可能代表这批用户忠诚度已经比较高；再如邀约用户来公
司访谈，“愿意来的用户”，就已经和全体用户有差异了……
对于这个问题，我常用的几个对策如下。首先，我们应该尽量识别出各种可能引
起偏差的因素，并在访谈的报告里标明，让读者了解。然后，为了用尽可能少的样本
得到尽可能正确的结论，我会以增量的方式做访谈。举个例子，我会先访谈 5 个用户，
得出基本结论，然后再访谈 5 个，观察结论是否有改变，如果有改变，就继续加大样
本量，或者思考问题是否合适？样本集是否合适？如果没有改变，就停止继续访谈，
节省成本。
样本的选取，其实属于概率与数理统计的范畴，想深入的同学可以自行研究。
第三，用户过于强势，把我们往沟里带。
我在 2006 年底做网店�
