关于本书

《成为产品经理：求职篇——知乎刘飞作品》/ 知乎「一小时」系列

出品人 周源

策划编辑 阳子

设计 刘奕含

封面图提供 李智

星际矿工（ZERO INBOT）系列形象有资深设计师李智设计 版权所有

联系我们 publish@zhihu.com

本电子书版权为北京智者天下科技有限公司所有，未经书面授权，不得在任何地区以任何方式反编译或节录本书内容。

ZHI-BN:8-0058-0000161214-1

DNA-BN：ECFD-N00007384-20160322

最后修订：2016 年 12 月 14 日

出版：浙江出版集团数字传媒有限公司

浙江 杭州 体育场路 347 号

互联网出版许可证：新出网证（浙）字 10 号

电子邮箱： cb@bookdna.cn

网址： www.bookdna.cn  

本书电子版如有错讹，祈识者指正，以便新版修订。

Zhejiang Publishing United Group Media CO., LTD, 2013

No.347 Tiyuchang Road, Hangzhou 310006 P.R.C.

service@bookdna.net

www.bookdna.net

「一小时」电子书出版序

知乎创始人 周源

感谢你阅读知乎推出的「一小时」系列电子书。

「一小时」系列是什么？

这是一系列短小精炼的电子书。我们邀请了知乎各专业领域的知友在书中分享他们的知识、经验和见解。如果你足够认真，便可以在一个小时内读完一本书。

这里既有日常经济分析，也有人文历史，既有职场经验，也有生活中的科学。这些作者，都是我们精心为你寻找，在各个领域拥有独到见解的专业人士。而我们出版的每一本书，都会解释一个问题，分享一种思路，展开一个视角。

地铁上，入睡前，在这些细碎的时间里，挤出一小时的时间，静下心，读下去。

你很忙，但知识不慌张。

愿你从「一小时」开始，对这个世界，又多了一分认识。

求职前：认识产品经理

产品经理为什么这么火

产品经理大概从十年前就开始出现在各种新闻里。后来很多名人都被称为产品经理，比如马化腾、周鸿祎，加上那本《人人都是产品经理》引发的热潮，着实火了一把。不过在五六年前，只是少数人有当产品经理的机会，那时候产品经理门槛并不低，也只在大公司设立，动辄要求是 985、211 高校的学生，或者计算机专业毕业。

不过随着创业潮来临，就在五年前，「江湖」上涌现了一大批产品经理。连很多不在互联网的明星，像汪峰、徐峥也都在说自己是产品经理，真的是给这个职业的火热又浇了一勺油。

产品经理为什么火，其实是有好几个层面的。

首先，在行业外，这是个神秘而伟大的存在，就跟过去造飞机、造飞船的工程师或者股市火热时的分析师、操盘手一样。虽然现在我们看这些工程师和分析师已经习以为常，但产品经理刚刚出现时，并不像现在这么常见。他们以某些奇思妙想改变世界，本身就很符合流行故事的套路，因此很快人尽皆知。

其次，凡是有志于进入互联网行业的非技术和设计专业的应届生都觉得这是个很好的起步选择，因为不用写代码、不用做设计。我见过很多同学，的确是一心想加入互联网，挑来挑去认为产品经理这个岗位门槛最低，但并没有关注自己究竟是不是适合做产品的工作。

最后，产品经理的薪资水涨船高，不仅是应届生，还有许多非产品岗的程序员、设计师也想转岗，希望能获得更好的工作条件。

那么，产品经理是否真的是大家以为的那样呢？

并不是。

第一，在大家想象中，产品经理的工作是充满创造性的、趣味性的，这就是很大的误解。就像大家只看到歌星在舞台上光鲜亮丽，但关注不到他们在台下的艰辛。我们平时看到好产品，会关注产品经理在其中的奇思妙想、有趣的创新，但这只是产品经理工作的一小部分而已。真正产品经理工作是什么样的，我会在下文中讲解。

第二，大家想象中产品经理的角色是管理者，因为名字中有「经理」这个称呼。这也是误解。在开始几年里，产品经历往往是不管人的，即使之后会带团队，也只会带其他的产品经理。这个「经理」，不是指管人，而是指管产品。

第三，大家想象中产品经理的工作是门槛很低的、不需要条件的，也是误解。产品经理所需要的技能和素质，的确在目前的高校教育中没有对应专业，但岗位要求的分析能力、沟通能力、对用户的感知和对设计的理解，都不是很轻易就能具备的，尤其对很多应届生来说。

所以，总的来说，产品经理这么火，表面上是互联网热潮和创业热潮的来临，但本质上，很大程度来源于大家对产品经理的误解。

我做过一张对比图，供参考：

入行后才懂的那些定律

有些关于产品经理的说法，入行前我是并不在意的，等真正入行后，才发现真的是行业定律。一共七条，供参考。

1．产品经理不是经理。

刚入行的时候觉得自己高高在上，或者至少觉得自己很有分量。相信大多数产品经理都是这么感觉，甚至很多同学会觉得自己就是预备 CEO 了。

实际上呢……有首歌叫作《产品经理是条狗》，百度就能搜到。

要真把自己当成经理，工作上绝对会步步维艰，什么都推动不了。因为刚毕业就是刚毕业，懂的东西就是很少，能把手头的事做好就不错了，不要想着凭「经理」这个虚衔压别人。

2．不管设计得再怎么样完美，需求总会改的。

以前还特别奇怪，产品经理设计产品的时候考虑周全点儿不就行了，干吗非得改需求。入行后经过了很多次惨痛的教训，终于发现，需求总是会改的。

改需求不代表产品经理不认真、太随意，也不是老板或者高层总喜欢拍脑门想点子，而是有很多现实原因。

可以列举一些：

·市场情况变化。比如因为某些事件，用户需求发生变动；竞争对手有了新动作，必须有应对措施。

·运营策略变化。比如公司的运营手段不同了，导致产品上的支撑方法也要不同。

·研发阶段暴露出了问题。一些底层逻辑在产品设计之时很难发现问题，但研发中暴露了，因而产品方案要改为更适配的。

·时效性变化。比如由于开发周期过长，时效性下降，所以也没必要用原来的复杂方案。

·临时需求插入。比如因各种因素影响，导致有更重要的需求紧急加入，这时必然要修整原来的方案或者延后开发。

虽然产品经理确实会在设计上出现纰漏，但更多情况下，产品经理只是背锅侠而已。

3．用户很傻，而且会越来越傻。

这里说的「傻」不是 low，也不是笨，而是用户不会愿意在使用产品的时候还思考。

我在入行前觉得说用户傻的人才傻，现在都什么年代了，大家的知识量以及对新事物的接受程度都大不一样，不知道的、不会用的去网上搜一搜或者跟朋友问一问不就好了？

几年前很出名的书《Don't Make Me Think》说的理念我也不太明白，就让用户想一想怎么了。

后来发现事情不是这样的。

一些特别小的问题，例如用户体验上一个极小的漏洞，都会带来灾难性后果。即便出错的可能性仅为 1%，但如果面对的是几十万的总用户量，就会影响到上万人。让一个用户多思考一分钟，那对于几十万用户，在你的平台上就会浪费几十万分钟。

有朋友在产品上开发过一个功能，是邀请有奖。用户 A 发二维码给用户 B，用户 B 扫码下载，注册成功后去输入邀请码，两个人都有奖励。但中间环节出了问题——90% 的被邀请用户都意识不到要在设置里输入邀请码。

邀请机制在各种 app 里都有，理所当然地认为大家都很熟悉了，而且在用户 A 发给用户 B 的使用说明里也都都明确写清，但现实来看，大部分用户不会主动去找。

最后怎么办呢？把用户当成小白，设计中用户 B 扫码后先填自己的手机号，才能下载。这样记录下用户 B 的手机号，也就知道他是用户 A 邀请的了。后面就不需要用户 B 再输入邀请码。

从产品设计上来说，这是很小的改动，但让用户省去了很多麻烦。后来的数据显示，这个功能的使用率上升了好几倍。

防呆、把用户当成傻子，是产品设计的基本思路。并不是说用户真傻，而是他们越来越懒，并且希望找到最不需要动脑的产品。

这也是为什么 T2 发布会上老罗主打的远程协助功能引起大家共鸣。这个技术难吗？不难。这个功能之前没有吗？有啊。但是发布会里演示的效果就是操作简便，老人用起来不费力，这也是产品的竞争力。

说到用户越来越傻，其实大家都是有体会的。各种设计都在让大家少动脑、少动手，过去的电脑要经过专业培训才能用，现在的智能手机 3 岁小孩都可以快速上手。

4．要把用户体验做好，并不简单。

看起来越简单、越自然的操作，就越需要更纠结、更慎重的考虑。

比如很多人想过聊天时会标注消息已被对方读到的功能后，就觉得自己想得比微信远了。大家都倾向于认为自己想到了别人没想到的，就是自己有理；而自己觉得应该没有，别人有了，也是自己有理。其实微信做这个是有自己的考虑的，他们的产品经理也不傻。张小龙曾经说过这么一段话：

「如果我们针对一部分人的需求去满足，你可能获取了这部分用户，但是得罪了另外一部分用户。有人就挺不喜欢把我的已读状态暴露给别人，你想这样的话，如果你的上级找你，你看了然后你又不回，就很麻烦。

我们要给人撒谎的机会，我们说人性是什么？给他撒谎的机会，说我没有看到。你看短信不太准确，我们经常会说，你那个短信丢了，我们没有看到。如果我们把人都像机器一样约束起来不一定是好事。

我们为什么不做已送达的状态？因为我们觉得未来的系统是绝对可靠的，我们有这个信心，肯定会送达，除非他关机了，我们不会再专门做一个是不是已送达，只有不自信的系统才会做这样一个状态。而且你每发一个消息还有个已送达或者发送中，那很丑陋的，多了一个东西在那里。所以这也是一种态度。对于这种用户要什么就给什么，其实这是考验产品经理水准的东西，因为我满足需求很容易，但是你怎么找到理由拒绝它，或者说找到什么方式实现它这个非常难。」

从此之后，我对很多产品有了敬畏之心，不是想当然地跟大家扯皮：「这个 app 做得好垃圾，你看这里 ×××，你看那里 ×××。」

做产品经理时间越久，就越发现自己的无知。比如很简单的「可用性」三个字，就有「尼尔森十大原则」。这里不再展开去讲了。

5．产品设计，尤其是交互和 UI，（大部分情况下）在一个产品中起到的作用只占10%。

「亮眼的产品交互和 UI，怎么可能起不到主要作用？」我曾经也是这样想。后来发现，如果功能不好用，再顺畅的交互、再华丽的 UI，都没意义。

比如聊微信，你发现数据丢了、记录没了，你是不会再用的；比如逛淘宝，你搞了半天都找不到想买的东西，你也不会再用。

再比如 12306，交互一塌糊涂（当然改版后略有好转），验证码烂到爆，更没什么视觉效果可言，但大家不得不用，因为能买票，买到票就行了。

你会发现几乎没有人单纯为了交互和 UI 去使用什么产品。从这方面考虑，互联网公司的成功之路上，产品设计相对于运营、推广、内容、资源，都是微不足道的。

你会因为滴滴打车那几个弹窗舒服、按钮合适就用吗？当然不是。用是因为补贴多、因为运营机制健全（有雄厚的推广资金和良好的服务）。

你会因为微信比别的社交 app 简单、色调明朗就用吗？当然不是。用是因为这已经是每个人的社交必备品（有海量的用户基础）。

你会因为支付宝的交互优秀、视觉突出就用吗？当然不是。用是因为安全和方便（有极佳的安全技术支撑和广泛的线下合作）。

看到这里有人可能会问，「那为什么好产品的设计和交互都很不错呢？」只是因为他们花得起钱雇高阶的设计师而已。

6．产品经理要多看书、多学习。

在入行前别人告诉我多看书多学习时，我不认可，我觉得产品经理应该多体验、多实践。

我当时的思考是：

·互联网是千变万化的，产品经理又是很新的职业，过去的书和知识不能提供帮助；

·产品经理需要的都是软实力，比如逻辑判断、沟通能力、审美和创新能力；

·产品经理并不需要太多技能和成体系的方法，尤其是工具、流程和制度，没有通用的；

·只要够聪明，在摸爬滚打中同样能快速成长。

真的摸爬滚打一段时间后，再开始看书、虚心跟厉害的人学习，才意识到自己犯了很大的错误。

（1）关于成长

够聪明的确能快速成长，但是产品经理的工作周期很长——不像工程师或者设计师，做的成果很快就能得到检验。

产品设计或者项目跟进的工作，可不像写代码一样，调试时就会报错，甚至还会告诉你怎么改。产品设计和项目跟进的结果，很有可能需要长达数月甚至半年的检验。而且你很可能不能发现原因，也不知道好的怎么保持、不好的怎么改正。

因此自己摸爬滚打的成本很高（这还需要学习能力足够强）。

所以明明通过别的途径能少走弯路，却偏偏要靠自己撞墙来学习，这是不合理的。

（2）关于技能和方法

确实没有通用的技能、工具和制度，比如有的团队喜欢 Axure，有的就喜欢 Keynote。有的喜欢把文档按照交互逻辑整理，有的喜欢按照功能逻辑整理。大公司讲究格式和流程，小团队追求效率。

但这些区别其实是浅层次的。深层次的概念和方法论，不仅是通用的，而且是必备的。

例如用户体验中的可用性原则、用户体验的五大要素、图片排列方式、注册登录方法……这些海量的知识，如果不去有针对性地学习，很可能需要自己折腾几个月才搞明白一个地方要怎么做。但如果事先学习，就能很快明白。

前人的经验在这个方面显得特别重要。

（3）关于软实力

逻辑能力、沟通能力等等，都是产品经理要具备的，需要系统地去学习。

可以去阅读一些能应用于日常生活中的逻辑科普书籍，这类书籍里也有很多讲社交和沟通的。其他的能力比如管理能力、组织协调能力，可以去看看成熟大企业总结出的方法论的。

这些仅靠个人领悟，不知道多久才能悟到书里能达到的水平。

（4）关于变化

虽然互联网发展非常迅猛，很多人的知识量有点跟不上节奏，但大多数解决问题的方法其实并未发生改变。我在《简易读书指南》一章中提到了关于读书的建议，你会发现其实十几年前的书，现在看来都完全不过时。

7．程序员总是会讨厌产品经理。

不管怎么讨好程序员，他们总会讨厌你的，不用太担心是不是自己做得太差。协作中尽量公正就好啦。具体原因？还用说吗。参见第一条。

产品经理需要具备的素质

差的产品经理千变万化，好的产品经理也不都是一个模子。

用户体验方向的产品经理，对细节的偏执是第一重要的素质，但这对高级产品经理或者产品负责人来说就不算太重要。做策略和规划的产品经理当然要区别于做执行的产品经理，我们听说过马化腾、雷军直接给产品团队提细节上的建议的故事，但这些故事只是反映他们关注产品细节，而不是说他们的工作就是这个。对某些产品经理来说，从细节中抽身出来反而是他们所必需的。

好的产品经理应该具备哪些素质，我认为可以从充分条件和必要条件两方面来说说。

充分条件

1．出色的逻辑分析能力

有的产品经理确实不太在乎逻辑、不太在意推理，更关注感性上的顿悟和创意，这不妨碍他们成为优秀的产品经理。不过说实话这跟时运有关——大多数产品经理遇到的状况是，他们的工作内容失去逻辑也就没了意义。

我所见的大部分产品经理，都偏重「落实」和「执行」环节。说不好听一点，就是需求经理或者文档经理。要把需求和文档梳理清楚，必然都是逻辑完善、内容翔实。不要指望用精彩的创意打动开发人员，他们只在乎你考虑是否周全。

拥有严密的思维方式和靠谱的分析能力，未必能让你成为大神，但成为一个好的产品经理绰绰有余了。

2．对用户、市场和行业特别熟悉

有很多行业内的人，虽然转岗成了互联网产品经理，但其实做的仍然是类似过去的事。因为这些岗位都关注同样的用户、同样的问题，转岗后也就能做出同样的决策。只要对用户和市场足够熟悉，都不用做调研和访谈，就需求和功能做出正确的判断。这样的人也能成为优秀的产品经理。

或者另外一种，对人性理解得非常透，所以能做社交或者游戏，对媒体特别熟悉所以能做内容产品，对安全有深入的了解所以能做支付产品。他们优势不在于会写好的文档、会做出好的设计，而在于他们的工作不可替代性强，很难找到他们这样的人。

3．出色的统筹资源的能力

有的人未必能自己写好文档、自己成为行业专家，但是他可以很好地统筹能写文档、能成为专家的人。他擅长的是利用外在的资源来达成目的，这样的能力在某些公司和团队中至关重要。

我们经常谈到产品经理应该有沟通能力，这句话并不清晰。如果仅仅是「让沟通的双方很开心」或者「油嘴滑舌」并没有意义，好的沟通能力是要真正调动资源、实现目的。通过沟通、维护协作、协调流程，让开发人员高效实现产品、让产品稳步合理地迭代、让团队成员各司其职，这都是此类产品经理的价值。

要成为这样的角色很多时候要靠管理职能，不过产品经理有的没有真正的管理权限，他们也能把无授权管理做得特别漂亮。

必要条件

4．自我管理能力

自我管理指的是能够安排好自己的任务、规划好自己的工作、利用好自己的时间。产品经理的工作内容不固定，实际的工作边界也不清晰。所以做好自我管理并不是简单的事。

缺乏自我管理的产品经理，只能成为最底层的执行者，因为他们没有办法去思考和优化自己的工作，只能听命于别人，最终也就只能在基层工作，写写文档、出出主意。

5．学习能力

学习能力对产品经理尤其重要。一方面，产品经理面临的问题随时都在发生变化，昨天是怎样解决用户的一个特殊需求，今天可能是怎样让产品上线延迟的风险降到最低，处理不同问题所需的知识显然不同，很多要从原本陌生的知识领域获取。另一方面，互联网和产品也是日新月异地在变化，旧的知识和经验难以支撑太长时间，需要随时更新。

这里说的不只是要学习，而且是要掌握独立学习、解决当前问题的能力。许多产品经理都习惯做伸手党直接向别人要解决方案，或者期望哪本书、哪个培训就能让自己立刻变得优秀、一蹴而就，这样并非是学习能力，是偷懒而已。

6．责任心

具备比较强的责任心，表现为：随时在线，下班后或者假期中也愿意解决问题，用户的反馈悉心回答，陪开发的同事们加班……说白了，更强的责任心意味着把更多时间精力投入到工作上。许多人并不愿意这么做，认为收获和付出不成正比。

我倒认为不是不成正比，而是付出和收益会有时间差。有责任心的付出，在一定时间后会让你更了解用户、更得到同事和领导的信任、更熟悉公司的工作流程，也就成为更好的产品经理。

7．对产品有一定追求

有一定追求的产品经理往往不会总逞口舌之快，说自己的理想和远大志向。还有一些产品经理则认为产品的工作无非就是按部就班实现功能、完成任务，并没有对产品的未来寄予多少期待。相比于「改变世界」或者「就是赚份工资」，我觉得介于两者之间的「把事情做成、让用户更满意、为社会创造价值」会是更好的心态。

大家由于所处环境不同、状况不同，具备的素质也就不同，不过作为好的产品经理，我觉得一般都是充分条件（1—3）里的某一项或多项与必要条件（4—7）里大部分项的组合。

对产品经理未来的思考

人人都是产品经理的时代结束了，职业产品经理的时代开始了。

大家可以回忆下程序员刚出现时，每个码农都称得上是「全栈工程师」吧。当时很多项目的开发流程并不标准，对品质的要求也不太高，除了巨头企业，并不会分工太细。

但现在，即便是一个小创业团队，也至少会分清服务端工程师、iOS 工程师、安卓工程师和 Web 工程师，不会轻易招一个安卓工程师来写后台，也不会找个前端工程师做手机端。而且对专业性方面的要求更高了——不仅需要实现功能，还要保证代码不冗余；不光让代码简洁，还得有极强的扩展性。

总结来说有两点：对领域的细分更多；对专业的要求更高。我认为这也正发生在「产品经理」身上。

1．互联网产品的类别越来越多、差别越来越大。

最早的互联网产品巨头清一色的是门户网站。再后来，BAT 三分天下，开始走不一样的路。时至今日，全国有几千万个互联网项目在折腾，每个市场几乎都有互联网产品在觊觎。

最早的产品形态也很趋同，网站的形式简单、软件的形式也很简单，后台产品更不用说了，就那么几家。移动互联网出现后，产品之间越来越不一样。比如布局的方式，就有宫格、列表、边栏、标签等各种各样的。

再比如，线上社交的产品和涉及线下服务的产品，其逻辑也全然不同。

另外，由于业务需要，例如后台产品，规模稍大些的公司都不会用第三方。后台产品经理的需求也是节节攀升。更不用说其他比如 CRM、客服等内部使用的产品，自己招募团队完成，应该会成为常态。

互联网发展到今天，每天都有新产品新花样出现，每时每刻都有新产品在挑战旧霸主。

从这个角度说，产品经理真的不仅仅是「想个主意」这么简单。

2．用户的需求越来越杂、产品的复杂度越来越高。

随互联网发展，不仅是用互联网产品的用户多了，他们的需求也变多了。原本可能只是满足基本需求（能完成任务、做成这件事），现在还会追求附加价值，比如是不是用着顺心、用着舒服、用这个产品的时候又快又好。

从诺基亚到苹果，飞跃的既是产品的复杂度，也是用户的需求。大家不只满足于「能够打电话」「能够看照片」和「能够上网」，而是要「很爽地打电话」「很爽地看照片」和「很爽地上网」。进一步说，大家还需要苹果手机本身给自己带来的光环加成。

要解决这些问题，可不是工程师够多就行了。会需要更多优秀的产品经理、更专业的产品经理，去满足大家日益增长的需求。

试想下 10 年前我们使用互联网产品的心态，往往都是费尽心思一定要搞定，出了问题甚至会查攻略、给朋友打电话、向客服求助。现在呢？注册的时候多一个步骤，你就滚犊子吧。

这些也给产品经理提出了更高的要求：要懂各种知识，要理解各种用户，要完成更难的工作。有个很简单的例子：很多老板觉得做产品经理很简单，自己去兼任，结果出来的产品往往惨不忍睹。

3．产品经理将随互联网渗透进各行各业。

互联网在过去可以称得上是特有的「行业」，就跟旅游业、出版业、房地产业一样，同是一种「行业」。但未来互联网肯定会渗透进各行各业的，未必是所谓「互联网+」的形式，人们看待互联网，不会把它当成是特殊的领域，而是会当成「谁都用得上」的工具。

现在渗透的层面都还比较浅，但也有了雏形。只要是有点规模的公司、企业、单位，都在做自己的 app，不管功能体验如何，这些 app 都是产品经理做出来的。未来它们会起到更大的作用，道理很简单：过去很多信息的记录、传递、处理，都是落后的。互联网就是解决这个问题的。

比如我认识一个传统行业的朋友。他告诉我现在他们的记录和通信方式特别落后，平时工作每个人都要拿厚厚的本子，整理信息的时间就花去工作时间的大半。文件需要一些领导签字的时候更是无比麻烦，需要挨个去找，费时费力。这样的流程，未来必然会被手机工具取代（在线记录、电子签名）。

就跟个人电脑普及之前，大家用的还都是手写表格、手写文档，觉得电脑是个新奇玩意儿一样。未来互联网工具普及之后，任何人都会习惯性地利用手机去解决生活工作中的大部分问题。

而解决问题的产品、工具，都是要由产品经理去做的。

上面说的三方面，其实就是在表达「移动互联网并没有成熟」「产品经理并不只是做创新」和「产品显然并没有在同质化」。

综上所述，我觉得职业产品经理的时代刚刚到来。

未来，产品经理可能会细分到「技术型产品经理」「运营型产品经理」「体验型产品经理」，或者按领域区分为「社交产品专家」「后台产品专家」「电商产品专家」等等。

产品经理也会有更成熟的培养体系和成长体系出现，在高校里产品设计、项目管理这样的课程会越来越多、且更加专业。

整个行业，也会出现公认的教学著作和指导思想，产品方面的知识不再是零散的、虚无的或者有些模棱两可的（看看张小龙被解读成了什么样子吧），而是逻辑自洽、经过实践检验的、屡试不爽的。

那时候，可能就不会有人对产品经理有这么深的误解了吧。至少不会觉得产品经理就是每天在想 idea 的人吧？

求职中：知彼知己

应届生能不能直接做产品经理

关于这个问题，我有三点看法。

1．大部分应届生做需求或者文档产品经理是合适的，但做产品负责人或者模块负责人就不合适了。

许多人反对应届生做产品经理，实际上是反对他们在不恰当的岗位。有的应届生对产品经理的认知有比较大的偏差，认为产品经理就是把控产品、设计功能，忽视了很多其他的必备能力和经验。

《纸牌屋》里一句话说得好，要想掌舵，得先知道怎么划船。

要是根本不知道一个功能在具体实现上到底要经历多少头脑风暴、小组讨论、跟老板和 leader 的争论，要经历多少方案改动、文档整理、版本规划和上线后的反复跟踪优化，要经历多少跟技术、业务或者运营同事的交手，只能做出「一个功能看起来不错，用户估计是喜欢的」这样的判断，那是做不出好的功能的。

我的确见过一些应届生，由于没有拿到大公司的 offer，就到小团队里做产品了。小团队一般没有太多产品经理，所以往往这种情况下，应届生就会要自己主导产品，或者主导一个模块。对应届生来说，这是极危险的路径，就像完全不熟悉航海的情况下、一天水手都没当过的时候，就开始掌舵了。

大公司的应届生较少存在这样的问题。许多刚入门的应届生需要先来一段为期几周甚至几个月的培训，熟悉工作流程，学习工作技能，然后会分到一些细碎的需求跟进，过上个一两年接手完整的功能模块，就可以游刃有余了。

其实最关键的还是，不同产品经理的工作性质差别很大——很多公司 CEO 自称是产品经理，负责整条产品线的是产品经理，做功能模块的是产品经理，在写文档、画原型的也是产品经理，这些都不能一概论之。应届生还是应该从底层做起。

2．产品经理不是看有没有基础技能，而是看有没有基本素质。

做产品经理的人都有一些类似的素质，这些素质有的是天生的，有的是后天可以习得的。说起来比较务虚的「产品感」、「用户感」，都没法从几本书里、几个教程里快速掌握。

应届生经常会犯的一大错误就是，误以为产品经理是技术工种，以为 Axure 和会聊天之于产品经理，就是 Python 和算法之于程序员那么重要。

画原型、写文档、使用工具或者沟通能力强，这些都只是术的层面。就好像掌握了语法，背熟很多词汇，也是写不出莎士比亚剧本一样，产品经理不是这么简单的。

过去大家都说，遇到看了两本书（《人人都是产品经理》《结网》）就应聘的应届生，一般不敢要。现在是，遇到刷了刷知乎就应聘的应届生不敢要了（并不是说看这两本书或者刷知乎不好，而是以看过这两本书和刷过知乎作为自己应聘的筹码、懂产品的理由，这样不好，非常不好）。

3．应届生不直接做产品经理，在别的岗位上提高的仍然只是协同能力。

还有一个误解是：我现在没有产品感、搞不懂产品，那我先做两年技术/运营/业务，是不是就能做产品了？

当然不是。

这还是说到所谓的素质。如果具有产品感，有逻辑分析和沟通能力，那么先做一些别的岗位，可能会对技术/运营/业务方面的背景有更深的理解，这样再做产品经理，能够更好地跟同事们协作并且理解他们的场景，会有更强的竞争力。

如果从来都不具备这些，硬着头皮做了几年工程师或者业务员，再考虑转行产品经理，反而更不靠谱。反正我是不太理解为什么埋头写两年安卓或者 Python 就能成为一个好产品经理这种奇怪的逻辑。

产品经理是没有前置专业或者前置岗位的，因此不存在在别的岗位修炼几年就顺理成章成为产品经理这样的事。传说中程序员转产品的案例多，那是因为那个年代就没有几个产品经理。

最后，建议要找产品经理工作的应届生都考虑下自己的状况。有没有耐心先做几年需求产品经理，面临枯燥复杂的文档撰写和用户分析？应聘前是不是只刷了刷知乎、学了点工具就觉得可以了？是不是一时心动想要做产品，逃避其他看起来更难找的工作？自己的经历、性格和能力，是不是能够做好一个产品经理？有没有考虑过未来自己的职业生涯？

如果这些问题答案都搞清楚了，作为应届生你适不适合做产品经理也就清楚了。

给要做产品经理的应届生的建议

1．确保从第一次见「产品经理」这个词，到你决定应聘的这段时间，你获取关于互联网和产品经理的途径不仅仅是知乎和微博，你知道的产品经理不只是乔布斯和张小龙，你见过的好产品不只有微信和支付宝。

不是沟通能力、不是分析能力。大部分应届生应聘暴露出的软肋其实是对产品经理的理解缺失。

2．「产品经理改变世界」这句话写全了应该是「一小撮产品经理改变世界，大部分产品经理改变一丁点世界」。这句话的重点不在世界上，而在改变上。一个人在生活或工作中的影响力（不是创造力），是成为产品经理的基础。

在想出一个惊天动地的 idea 之前，先想想，你在学校里、在社团里、在实验室里、在班级里，曾经起到过什么作用没有？

你下铺的班长抱怨说每次班会人都不齐，你出过主意吗？你在各种演讲、分享和讨论会中，经常主动发言吗？你在社团、协会和比赛里，是主要负责人或者核心角色吗？

如果都没有的话，你连身边的人都影响不了，又哪来的勇气说自己的 idea 可以改变世界？

3．自我判断。

面试的时候，面试官知道大家并没有产品基础，通常会观察面试者过去的经历和特点。单纯给面试官们表达自己对产品的理解对他们来说就是班门弄斧，毫无意义。

观察能力未必要体现在自己注意到了哪个微小的交互动画，也许是体现在总能搞明白别人的需求，在跟老师同学的交流中总可以知彼知己。

沟通能力未必要体现在自己能滔滔不绝、面试时口若悬河，也许是体现在你曾经带着学弟做过科研项目、还让舍友心甘情愿每次帮你带饭。

逻辑推理能力未必要体现在读了多少本数理化的书，也许是体现在你讲话已经习惯区分层次、列清条目，并且有着层层递进的关系。

最重要的是，不要误以为做一个很好的用户就是一个很好的产品经理，想办法写很多竞品报告或者产品体验报告，以对几个 app 的粗糙理解作为自己的加分筹码。真正的产品经理写出来的，是从设计者的角度看本质，我见过的大部分应届生写的，仍然只是用户说明书而已。

4．搞清楚产品经理究竟是什么，再搞清楚自己究竟行不行，接下来就是搞清楚，自己到底想不想。

「在职业规划时，偶然发现了产品经理这个岗位，有种突然找到了人生意义的感觉！」

「看过一些产品经理的介绍之后，认为这就是我想做的职业。」

「现在互联网特别火，产品经理门槛也不高，我觉得可以试一试。」

这不是我编的，这都是一些同学跟我的真实聊天记录。

不要只看到光鲜的地方，或者自以为看到了光鲜的地方。先别看最牛的产品经理都在干吗。先看看最惨的产品经理都在做什么。

他们可能在日复一日写无穷无尽的文档、在日复一日跟技术扯没完没了的皮、在日复一日当老板的传话筒并没有机会做自己的设计。

在遇到做第一个像样的功能的机会之前，也许要先写 100 篇无聊透顶的文档、跟技术吵 50 次架、梳理 30 个错综复杂又没什么乐趣的产品逻辑。

对于大部分产品经理来说，新的产品，可能几个月甚至几年里，都没有多少用户，你根本没法从中得到成就感；成熟的产品，可能几个月甚至几年里，都不会把重要的功能交给你（甚至给你过目），你只能打打下手。

你能忍受这些吗？

你对产品的所谓「热爱」是不是只是找工作的筹码，你看中的是不是只是赶快进到一个大家都看好的行业里做一个看起来有趣且有范儿的职业？

5．在简历和面试中，应该给别人展示的是，你最真实的学生生涯中、最接近产品经理的一面。

这一面，越有差异化、越具有不可替代性，就越靠谱。很好的判断方法是，看你作为筹码的这些，别人是不是也容易做到。

你可以组织学校的晚会、可以在实验室做项目、可以本科时候就发表论文，甚至是在学校里开小卖部，这些都是具有不可替代性的，别人未必做得到。

但你的简历上如果是「重度 app 使用者，装了 400 个」「读过《人人都是产品经理》」「对产品很感兴趣」或者「会用 Axure」，那真的没什么价值——你说的这些，谁又不行呢？

6．尽量别以自己的个人经验选公司和产品。有的公司名气大，产品经理未必靠谱；有的产品你虽然喜欢，但公司可能快不行了。

不挑公司和产品，尽量挑人。这个团队是不是有足够优秀的产品经理？这是对于没有经验的新人来说，最重要的判断标准。

要是很难知道对方团队有没有足够优秀的产品经理，那就看对方是不是有够多的产品经理。只要够多，那有靠谱产品经理的机会也就大了。

这样来看，要是自己很难做出好的判断，那 BAT 就是至少不会出错的选择。

7．最后，不要随便加入创业团队，成为他们唯一的产品经理。

给应届生的面试建议

应届生往往对产品经理的面试有很大的疑惑，不知该怎么做，也不知道面试官考察哪些方面。对于这些，我有以下几点建议。

第一，关于简历。

应届生准备简历往往都习惯罗列所有的过往经历，把有关的、无关的信息都放在上面。我觉得这样是很糟糕的。从产品经理的角度看，面试本身也是要关注面试官的需求的。

招聘你的公司、面试你的面试官，他们最希望了解你的，就是你能不能胜任他们在招聘的岗位。而是否能够胜任，从那些无关信息里是推断不出的。

每个岗位都有自己的 JD（Job Description），详细描述了这个岗位的需求，因此简历应该从这个角度出发去写。再华丽、再有意思、再耀眼的简历，都不如一个与 JD 契合得天衣无缝的简历来得有效。这就跟一个视觉很酷炫但没有解决用户需求的产品，不如虽然粗糙但用户爱用的产品一个道理。

那么最正确的做法是什么呢？

（1）阅读清楚对方的要求。

对方是更看重你熟悉互联网、熟悉其他产品吗？还是更看重你是不是技术出身、计算机专业？对方更看重你擅长功能吗？还是更看重你的项目规划、管理能力？虽然岗位名字都是产品经理，做的事情却未必都是相同的。搞清楚到底需要的是什么。

（2）梳理自己的经历，找出对应经历，一个一个进行处理。

不要看到对方说「需要沟通能力」就在简历上写「具备沟通能力」，对方说「熟练使用 Axure」就在简历上写「会 Axure」，这都没有价值。如果大家都这么写简历，那简历还有什么意义？简历最重要的点在于，要证明这一点，所以经历才是真正的证明。

经历未必就是直接相关的，可能是从侧面的证明。大部分应届生是没有办法体验到产品经理工作的，所以很多应届生就觉得自己的那些经历跟产品既然无关，就都没有意义了。尤其是跟互联网离得比较远的专业。事实是，即使是焊接专业，也完全有可以写的内容，比如是不是在某些项目组里曾经做过领导？是不是自己组织过班级的重要活动？是不是在游戏公会里担任重要角色？它们都可以从侧面证明你具备一定的组织协调能力。

（3）描述经历。

对经历的处理不要夸张或者瞎写，找出其中最有价值的点。每段经历，都要写清楚背景、做的具体内容，以及结果，这样会更有说服力，同时也能让面试官判断出你真正的能力。

第二，关于面试的准备。

根据我的经验，面试一般会问这么几类内容：

（1）自我介绍；

（2）过去主要的经历；

（3）某些具体的问题（考察逻辑能力、分析能力）；

（4）某些知识性的问题（考察对行业或产品的了解）。

在这几类内容里，第（3）类是难以抱佛脚准备好的。或者说即便用了「歪门邪道」的办法暂时逃过面试官一劫，也没有意义——找工作毕竟是选择自己最合适的，不要伪装成自己成为不了的。

对于前两类内容，就是要把简历里的方方面面烂熟于心，要考虑到面试官会问的任何问题，并且给出有说服力的答案。既然是自己之前的经历，就好好回忆下，整理清楚，避免出现「你说的这个，时间太久了我记不清」或者「你问得太细了我也不太知道」这样的回答。

对于第（4）类则需要多花点时间，多看看自己喜欢的行业知识，多读几本书。不一定什么都知道（这也不太可能），但对自己感兴趣的行业、觉得有趣的产品还是要有些深入的体验，让面试官知道你是有想法，而且胸中还是有点东西的。

第三，面试的过程。

·群面

群面中，一般是大家吵成一片，或者在不断重复同样的话。有的群面攻略说，一定要突出自己，要争抢着说话、表现自己的热情，我觉得没什么道理。

我曾经参加过群面，我的策略是，按兵不动，好好观察。看看大家讨论的主线是什么，每个人的观点是什么，有什么漏洞和问题。等到下半场的时候，找时间发言，然后一条一条罗列出自己的观点：「这位同学说的 ××× 我认为不可取，原因是……」「这位同学刚刚提到了×××，我觉得是……」这样会给面试官留下深刻的印象，看起来你的思考层面是在他们之上的。

总之，保证自己群面时候的逻辑性、条理性，比保证发言的次数和长度重要多了。

·一对一面试

1. 保持自信，气势上不要太弱。虽然对方已经毕业多年，但可能从业也没多久，未必就是特别专业的老师。你越没底气，就会显得自己越没有能力。

2. 任何问题的回答，最好清晰具体。我很崩溃的几次面试，基本都是答非所问，虽然看起来好像是在认真回答。我问：「你有没有比较喜欢的 app？能否列出几个喜欢它的地方？」答曰：「其实我对很多 app 都很有兴趣，不过呢，最近工作实在太忙，所以也没有时间去体验。我一般对设计漂亮的产品感兴趣。也不一定，有时候吧……」自始至终没有说一个具体的 app。这样的问答就是极其糟糕的。

任何问题的回答，能分条的就分条，能讲述清楚逻辑的就讲清逻辑。有时候问题可能会比较复杂，如果不能答得准确，也可以尽量尝试描述自己的分析思路。面试官不一定想要一个完全正确的答案，他有时候只是想看你分析问题的方法和思路。我校招时曾经遇到的问题是：「我们晚上想叫外卖，但是经常叫的那家店不送了，怎么办？」这就是个很开放的问题。

千万千万不要说谎。我面过一些同学，说的是一个样子，等我通过朋友打听到，却又是一个样子。这样对自己的求职是致命的。

第四，offer 的选择。

如果拿到了很多 offer，该怎么选择呢？

应届生角度来说，让我排序的话应该是这样：

（1）导师是否资深、团队是否优秀；

（2）行业是否喜欢；

（3）是不是处于上升的行业，或属于在蓬勃发展的项目；

（4）薪资待遇是否满意。

道理很简单，对于一个人（尤其是应届生）的成长来说，有良好的学习途径以及个人兴趣，是至关重要的。薪资待遇在成长之后自然会有更大增幅。

以上就是对于应届生面试产品岗位的一些建议。

给找不到产品工作的同学的建议

我遇见过很多应届生，都有这个疑问：为什么我找个产品助理的工作都这么难？

他们的逻辑是：

・我不太懂互联网，但想去互联网从业（潜台词：听说这个行业赚钱多）；

・我不适合做别的岗位（潜台词：我什么都不会，但好像做产品经理也没啥要求）；

・我不当产品经理啊，我只是做个助理（潜台词：我让步了啊）；

・但他们都不要我，说还是更需要有经验的（潜台词：他们好像有偏见，只要有经验的）。

然后推导出结论：

作为应届生，估计很难找到产品岗位吧。

有这种想法的同学，心里想的都是自己的状况和遭遇，提出的问题里都是「我」「我」「我」。但偏偏没考虑到一个简单的问题：自己能给「对方」带来什么？自己值那份工资吗？

再回头看那几点。

1．不太懂互联网？只是觉得互联网真棒？这种说法根本打动不了人。你表达出来对互联网的热情并不能证明什么，不知道为什么很多同学都把这个当作应聘的筹码。我还对当省长有兴趣呢，兴趣够大了就让我当吗？

现在又不是信息闭塞的年代，至少基础知识在网上没有找不到的。多了解互联网，多掌握些知识，这才是筹码。

2．你不会别的，就让对方收留你，这是什么奇怪逻辑。

你应该做的，是向对方证明：我就是做产品经理的料。我有逻辑能力，我对产品很有感觉，我能跟人很好沟通等等。产品经理需要的能力，可以买几本书多翻一翻，在网上多查些资料。我把「证明」加粗是想强调，不要空口说自己牛，而是用一些事情证明。

作为应届生，就算没有很直接的证明，但从小到大很多经历都可以拿来用。（怎么拿来用，在前文「简历」和「面试」里已有提及）

当然啦，如果你证明不了，有可能你确实不适合做产品经理，那就得另做打算了。

3．在你看来，从经理到助理是忍痛后的让步。但对招聘你的团队来说，「不能做事」就是「不能做事」，你做经理产生的价值是 0，做助理同样是 0，甚至你做助理的助理也是 0，这跟岗位没有关系。

那如何证明你是可以做事的呢？

除了上文提到的描述自己经历，最有效的方法，就是去猜想对方需要的人是什么样的人，去证明你可以或者有潜力成为这样的人。

比如，锤子科技之前在面试中最看重的，就是对目前的系统提的功能建议。你如果能提出好的建议，那加入团队后，也应该能继续提出好的建议。

比如，有的团队更看重协作能力，那你的计算机专业学历、做过兼职销售或者策划组织过活动的经验，就都可以拿出来讲。

如果你分析后发现，你很难成为对方团队需要的人，那不是对方苛刻或者你不够好，纯粹是不合适罢了。产品经理并非是普适的岗位。

只要让对方觉得「哦，面前这个人，来到我们团队能创造价值」，那他们就会认真考虑你。

如果只是表达出「我特别喜欢互联网，我很想到贵团队学习做产品，让我干什么都行，拖地都行！」那他们就会觉得这人可能只会拖地，还想让别人花钱养着他、教他做产品？要他何用？

大公司 or 小公司

很多应届生在求职时对去大公司还是小公司颇有些犹豫，不太清楚到底大公司好还是小公司好。我在这里提供一些可参考的信息。

1．在工作流程方面，大公司讲规矩，小公司看效果。

大公司是讲规矩的，流程出了纰漏，问题很严重，整个机器就运转不起来。

以淘宝举例，你是做商品展示的，却偏要对支付环节指手画脚；再或者你是做用户研究的，却偏把交互也帮忙做出来了。萝卜不在自己的坑里，结果就是会乱套。

人越多的团队、部门越多的公司，越容易因为这个扯皮。

而小公司更看重效果，你愿意多做些，那就多做些。惹人不高兴了，我开掉不高兴的人就是，你把事赶快做好最重要。

我见过很多技术人员强行参与产品设计，很多产品人员强行参与运营决策，甚至有前端产品经理兼做 HRD 的团队。只要这事儿做出来了、有效果了，那就是大家认可的。

虽然这么操作不可持续，但资源紧缺、时间紧张的情况下，效果一定是最优先的。这是小团队动作快的原因，同时也是小团队问题暴露得多的原因。

2．大公司看的是经验、资历，小公司更看重是不是聪明、执行力强不强。

大公司用人会考虑到很多因素，某个部门的领导一定程度上会有公关或者给部门做品牌的作用，除了本身能在产品经理方面创造的价值，还要考虑是不是能很好地成长、适配未来的岗位，在这个公司有健康的工作状态，甚至对公司够不够忠心。

小公司则会为了尽快得到收益，只看重这个产品经理立刻能产出什么。是不是能画图？你上！是不是可以写文档？你上！是不是可以跟项目？你上！这时不会太在意刚才提到的那些，也不在意具体的方式合不合理，流程正确不正确。

所以这里多说一句，小公司的成长其实建立在近饱和的工作状态下，同时做的事情可能很杂、很乱，有时还很匪夷所思。对于内心强大并有充足学习能力的人来说，这是极好的成长途径，但对于尚未有概念的产品新人来说，每天专注在工作量繁重的细枝末节上，未必有精力很好地总结、很好地成长。

3．在策略方面，大小公司都是老板定，小公司里产品经理是有机会参与的。

所谓的点子或者主意，肯定都是由老板来出。策略级别的事情是永远不会交给普通产品经理的，至少也需要是产品合伙人。

小公司里，发声会更容易，更能够「上达天命」，也就更有在老板面前表现、被老板器重的机会。大不了有想法了在公司门口堵老板。你到阿里堵一下马云试试？

4．大公司和小公司的产品设计流程，都会存在不合理的地方。

大公司出现不合理的状况，原因一般是中间信息传达步骤过于冗长、沟通烦琐、各方推卸责任。尤其在产品设计上，如果是通过一些文档、格式化的信息来传递想法，必然会有错漏，不如一个人能从头到尾跟进下去。

小公司的产品设计出现不合理，就是老生常谈的问题了——拍脑门太多。小公司的老板会比较闲，有精力参与细节，经常爱想（能表现自己聪明才智）点子。同时，因为用户研究这部分工作的缺失，产品经理没有能力和资源来做更多验证，只能硬着头皮做。

减少抱怨。糟心事总是会遇到的，好的产品经理在哪都能游刃有余，而糟糕的产品经理只会吐槽自己生不逢时。

5．不管大公司还是小公司，都会接触到很多杂七杂八的事。

在接触到大公司之前，我以为只有小团队的产品经理才需要三头六臂、会三十六变。后来发现就产品经理这个岗位的特殊性而言，真的是什么都得会做。

大公司里流程健全、机制复杂，很多事情都得需要去推进。有时候给别人讲方案得做好几天 PPT，请设计师同事帮忙作图，资源调配不平衡得去别的部门求帮助，甚至运营团队不给力也得自己去发传单……这些倒真的不分公司大小。

大公司的环境相对有优势，起码杂七杂八的事情，都还是跟产品强相关。小公司里甚至会有搬桌子、买器材这样的事，还有要自己去搞招聘、组织团队活动的。在大公司，至少行政、人力和后勤的工作是不用操心了。

6．大公司和小公司做产品是不是靠谱，在于是不是存在很有经验的人。

有人说大公司制度全、做事专业，有人说小公司成长快、见识广，有人说大公司牛人多、学习机会多，有人说小公司接触面大、参与感强……我倒觉得判断时没必要想太多，就看一件事：这个地方牛人多不多、你能不能跟他学。

你认可的牛人，也会是你想成为的榜样，跟他学习，不就是往你期待的方向发展吗？

过去专业的、优秀的产品经理都是在大公司，这几年已经逐渐开始外流。有的小团队虽然资源不全，但有专业的人在，做事至少能保证是用正经的方法来做的，不是瞎搞的。

最怕的就是，你原本是到一个团队锻炼的，但老板也不懂产品，让你自己控局，美其名曰更好的成长机会，但其实每一步都没人懂该怎么做，然后每一步都是大家扯皮，结局还是老板说了算。你成了炮灰。

7．大公司的产品经理是被塑造的，而小公司是可以自塑的。

换句话说：大公司的产品经理必须要填已经挖好的坑，而小公司的产品经理，要自己挖想填的坑。

大公司里，岗位编制都特别清晰细致，你作为某个角色进去，那很可能就会一直在这个岗位上做下去了，即便是部门换岗，肯定也是雷同的角色。而小公司的优势是，有试错的机会，感觉目前的定位不合适，完全可以试着做点别的事情。

我见到很多朋友在创业期间发现了自己最合理的定位，之后的事业就一帆风顺。但在大公司，这样试错的成本就成倍地增加，公司才不管怎么帮你找到自己的定位，公司只关心你现在能不能值你的工资。

入职后：产品新手指南

简易入门指南

1．锻炼对自己产品的理解

初学者可能刚入门就会被琳琅满目的原型工具和一堆堆的案例绑架，满脑子想的是别人花俏的功能和亮瞎自己眼睛的方案，但唯独对自己产品不了解，脑子里全是别人的东西。

这样的 PM 平时跟别人的对话一般是：

A（老板）：你觉得这里放四个标签页合理不合理？
P（PM）：当然合理，美团啊、点评啊、微信啊都这么做的。这是天下大势。
A：那我们页面上功能排版这样靠谱不？
P：没问题。现在这样的排版方式是最常见的，交互方式也保证是最流行的。唯一色调设计手法是国际上流行的设计理念 Minimal。
A：额，那我们这几个功能是必需的吗？
P：这几个功能竞品都有了，我们没有的话不好吧？
A：......

对自己产品的理解又分为多个方面：

对公司定位的理解，跟老板和投资方有关；

对用户定位的理解，跟公司的定位和市场的状况有关；

对产品定位的理解，跟用户的定位和推出产品的初衷有关；

对公司研发能力的理解，包括设计能力、开发能力和运营能力；

对其他部门状况的理解，包括各部门在做的事情、大家进行的状态；

……

总之，你做出的每个判断必须基于对产品多方面的理解，而不是对竞品的理解、对市场的理解这些零散的因素。

只有这样，当设计师做出你不满意的稿子时你可以说「你的这个风格可能适合年轻人，但我们的目标用户是商务人士」，而不是说「你这个不够大气，没有 feel」；当你要求工程师改一个看起来不重要的 Bug 时可以说「后续运营部门有好几次大型活动，到时流量会瞬间暴涨，你这个 Bug 会放大 10 倍，所以很危险」，而不是说「重要不重要不是你工程师定的，是产品经理定的，你改就行啦」；当你跟老板讨论要不要加一个功能时可以说「我觉得我们这样的功能是一个重要的补充，跟下个版本要做的事情不谋而合」，而不是「竞品做了咱们不能落下啊，管它有没有用」。

具体怎么去锻炼，其实是件费力又费脑的事情。你要不断地去跟老板沟通、跟同事们沟通，去跟用户聊，去做调研，同时做大量的思考和总结，你要形成自己的一本词典，记录产品相关的各种信息，每当需要查询就能随时翻阅。

这本词典可以记在心里，也可以整理成笔记。别人看来，它可能无关紧要，也不是那种张口「人机交互的趋势」闭口「立体化设计语言」这些可以用来装逼的术语。但没有这本词典，你每走一步都是一个坑，等走远了回来想填的时候，已经晚了。

2．提高分析和判断能力

如果说对产品理解是第一步，那第二步就是怎样基于你的理解做出靠谱的判断。

说来也怪，很多 PM 除了参考别人以外，就是做用户调研，或者唯老板是从。但很多事情简单得要命，只要有生活常识、有基础的推理能力，明明是可以更靠谱的。

举例子来说，当初 MIUI 做安卓本地化的时候，日历里加入阴历是作为主打特色之一，也广受好评。在做 T1 的日历的时候，我们也在考虑这个问题：到底加不加阴历？

加的话，整个界面非常满，显得丑陋；不加的话，需要看阴历的用户又会不爽。

这是常见的一个日历界面：

对于重调研的 PM 来说，就做个调查问卷，规模越大越好，看哪边的用户多；对用户定位是偏高端用户或者说发烧友的 PM 来说，可能就做个开关选项，需要用就打开，不用就关了。

但实际上完全可以往前推理一步：用户到底为什么需要阴历？

大概场景就几个：春节前后用；阴历的节假日用；自己和亲友生日用。这基本囊括了所有用户的需求。

那就简单了，我们能不能就在春节和节假日的时候显示阴历？对于生日的话，我们可以提供设置项，在用户和亲友每年生日那天显示阴历。

这是 T1 的日历界面：

这样既在很大程度上防止了界面始终显示阴历的尴尬，又满足了大部分用户对阴历的需求。这种方案凭常识很快就能推断出来吧？也不用复杂的问卷调查吧？也不用复杂的产品设计吧？

你可能说，这就是个抖机灵的需求分析，况且是个小功能。我再举个例子。

我们在嘟嘟美甲讨论最基本的功能和界面时，并没有参考的市面流行的 O2O 工具，看它们都有什么功能、都有哪几个标签页、都是如何排版。我们先做了一次用户分析。

用户分析没有靠问卷来做。因为在问卷里问「你是哪类用户」「你平时做美甲会更看重什么？」，她们很难答清楚。如果你给的是具体的选项，又会有诱导回答的可能，最后的结论往往不能说明问题。

我们的分析路径是这样的。先从常识判断，美甲用户使用我们的产品有哪几种场景：

·已经有想做的样式的用；

·想来做美甲但不确定样式的用户；

·不确定做不做只随便来看看的用户。

对于上述用户，需求肯定是不同的。

·看你这有没有想做的那个样式或者类似的样式。

·看你这有没有好看的样式。

·看你这有没有什么足够吸引她做美甲的地方。

对于这三种需求，我们要提供的功能又是不同的。

·根据用户的样式提供定制服务；搜索和筛选功能。

·精品/热门推荐；搜索和筛选功能。

·专题；精品/热门推荐。

所以，在用户第一次看到我们产品的时候，我们需要提供的功能就一目了然了：专题、推荐、搜索/筛选和定制。

然后我们的进一步判断是，产品刚上线，第 3 种用户肯定最多，第 2 种用户会逐渐多起来，而第 1 种用户会是高端、深度的用户，出现得更晚。这样对功能的主次也都分得清了。

最后初版的产品，我们决定把主要精力放在推荐和专题上，搜索功能是第二版上线的功能，而定制将是更未来版本的功能。而界面的布局和排版，也都因为功能主次分明，心里有数了。

从最终结果上来看，做出来的界面似乎大同小异。但从研发角度来说，每个功能都会耗费精力，从用户角度来说，不合适的功能会影响体验。如果是拍脑袋想的，一点小差别、一些可有可无的功能都会成为南辕北辙的错误决定。

你看，上面的分析都是依靠常识判断的。你说「我不是女人哪懂美甲咋回事」，但你总逛过淘宝用过京东吧？购物时用户的思路还是可以想象得出来吧？当你有了初步判断之后，用户调研的意义就体现出来了：它是作为验证的手段。但它不能作为需求的来源。

总结起来，产品经理在做任何决定时，都要做到三个字：

讲道理。

那怎样培养这种能力呢？也不难。就是在日常生活中多问为什么。

这个小区的停车场入口需要绕三个圈，为什么这么设计？这个优衣库进门一眼看到的全都是内衣裤，这么摆放是什么道理？楼下咖啡店平时顾客也不多，但居然撑了五年还没关门，他们的收支能够平衡吗？

很多道理是相通的，每天都在想明白一些事情，那真遇到棘手的产品问题，你肯定想得比别人远，也比别人靠谱。

3．确保良好的沟通和表达能力

如果能够对产品有充分的理解、对各种问题有了清晰有据的判断，下一步就是把这些自己的理解和判断跟同事们做充分的交流和沟通。

其实说来也不会很难，也就是注意沟通的技巧。一方面是有情商，怎样让没有实权的你在推进大家完成任务、在协调大家的工作时不那么令人讨厌；另一方面是要让每次沟通都有效率，不耽误时间。

对于前者，我的建议是：

（1）始终清楚自己是产品经理，但不是经理，不要盛气凌人。

（2）用有理有据的事实来说服别人，而不是用「老板的决定」「反正跟你没关系」这种说法。

（3）别人遇到困难不要说「我不管，这是你的事儿」，主动去理解他的困难，并且尽力帮忙解决，解决不了的一起想备选方案。

（4）产品项目组中的任何同事之间有了矛盾，要主动去协调，别在旁边看热闹。

（5）随时让每个产品线上的同事了解全局的进展，让大家产生主人意识。

（6）整理好用户的反馈后可以周知同事，让大家产生成就感，觉得自己做的事有价值

对于后者，我的建议有：

（1）每次讨论问题，不管是一对一聊，还是开会，都明确这次的目的，有腹稿。

（2）描述问题清晰，想好了再说，同时不要偏题。

（3）每个问题都形成结论，不要讨论来讨论去，只是感觉很充实，没有结论都是瞎扯。

（4）不要把任何事情都交给别人决定，自己时刻准备提出更多方案和建议。

（5）每次讨论的过程和结论都有记录，可以随时查阅。

交际能力学习最快的方法其实不是从书本上背诵，也不是记下我说的这些要点，而是找一个你觉得交往起来特别舒服又很优秀的人，学习他身上的优点。

4．对产品的责任心

责任心似乎是最容易能有的，但却是我直到现在面对很多优秀的 PM 都自愧不如的。

我特别喜欢一句话：「产品经理最重要的能力就是让正确的事情相继发生」。

你做到我说的 1~3 了，但那只是做「正确的事情」，是不是能让它们相继发生，却要考验你的责任心。

在午夜工程师为项目上线加班时，你是在楼下电影院里吃爆米花，还是在旁边默默陪他？在设计师跟老板因为方案闹僵了的时候，你是等着他们握手言和，还是主动找老板或者设计师聊一聊赶快把项目推进下去？在运营的同事为了某个紧急活动给你提出不太实际的功能需求时，你是一句「做不完」就打发走，还是认真跟他讨论下有没有什么别的方法能凑合着用？

是的，严格来说，你跟公司是劳动契约，你不能被强制加班；你的岗位是产品，不该去帮别人想解决方案；你也不是老板，公司的各种坑也不必由你来填。

但一个优秀的产品经理，是要对任何与产品相关的事务负责的。任何阻碍产品正常上线的事情都应该由你解决，任何能对产品产生帮助的事情都应该给予关心。

在这方面如何抉择，就决定了你作为产品经理是平庸还是优异。

5．关于工具的使用

工具放到最后说，是因为实际意义上的产品经理，并不必掌握太多原型工具、交互绘制工具甚至绘图工具。

不管是什么样的工具，都是为人和当前做的事情服务的。还是刚才那句话，你为什么要用它？它对你现在做的事情有帮助吗？

很多初创团队刚刚起步，就开始搭建各种大规模的 Feature/Bug 的记录和处理平台，都在用特别复杂的需求文档描述规则，都把脑图、Axure 作为必备的工具。没有提高效率，反而造成了很多问题。

就跟 MBA 不适合创业者一样，复杂的流程会严重拖累中小公司的运作。我平时就用 Keynote、Sketch 这样的工具，完全能覆盖 90%的需求设计工作；产品研发的需求记录和处理就用 Trello 或者风车，操作简单，易用。

更多关于工具的使用，请看本书末尾的《简易工具指南》。

记住一条就可以了：只要觉得目前手头的工具好用、高效，那就没必要换成高大上的。除了装逼，没有别的意义。

6．尽力涉猎广泛

曾有一个朋友问我，他经常会与设计师有争论，他总觉得排版上有问题，但却说不出哪有问题，该怎么办。我说：「很简单，如果你直觉上觉得有问题，那可能真的犯了一些基本错误，那你多去学习些排版上的知识，多去了解下常见的排版规则，那之后遇到争论肯定就有底气了呗。」

作为产品经理，懂一些其他岗位的基本知识是很有用处的。这样既能保证良好的沟通，也能让你在考虑需求、设计方案时心中有数。这是一个好的补充，当然没有也无所谓。

去看看他们都在看什么书，找些基础的看一下；也可以到知乎多看看相关文章。这样别人就不会在背后说，「这小子就会每天瞎想些点子、画点不靠谱的原型、做点不接底气的方案。」

简易创业产品经理指南

为什么单独把创业产品经理的指南单独拿出来说呢？因为创业中的产品经理，要掌握的技能区别很大。以下是只针对创业中产品经理的建议。

1．严格把控需求，拒绝墙头草。

需求简直是创业团队，尤其是早期创业团队，最要命的东西。

老板对业务干预度高，销售觉得产品不作为，技术觉得产品节奏太快——绝对是每个创业团队的经典面貌。所以把控需求是当下最重要的事情。把控需求不是说「推掉所有比较难的需求」，也不是「接受所有重要的需求」，你先要花大量的时间，搞清楚几件事：

·每个需求的来源，背后的逻辑是什么（不管是老板还是其他部门）；

·所有需求中，哪些是最重要的；

·每个需求的实现方案，到底有哪些；

·根据目前的需求重要程度和实现困难程度，下一步到底该做什么。

对于需求的重要程度，一定要从需求方的角度考虑问题，作为产品经理，不要偏袒技术，觉得难就不管了。比如运营那边急需一个后台可以封禁关键词的功能，的确很难，但如果你没做，可能产品第二天就被勒令下架，可能公司要被调查，这件事的严峻程度就不用多说了。同时，对于同样的需求，并非只有一个解决方案的。比如，要做一个后台统计用户数据，这个功能的做法有很多种，可能是这样：

可能是这样：

还可能是这样：

呈现的方式不同，复杂程度也会不同。简单的用户统计数据是一个方案，在用户统计数据上加入趋势图是一个方案，在用户统计数据上加入各种筛选条件又是一个方案。并非是有了需求，就有了功能。功能是需要根据当下的状况设计的。

好了，下面教给你一个特别简单的方法，注意，干货预警。

想象你现在是嘟嘟美甲的产品负责人，你打开需求列表，发现需求有以下这些（当然这是虚构的，真实情况下数量可能是 3-4 倍）。来自老板：

·实时记录美甲师 GPS。

·首页有点杂乱，不够简洁。

来自运营：

·要统计用户对每个 banner 的点击率。

·秒杀功能。（运营总监：「下周就要做活动，通知发出去了，必须做。」）

·需要提供给用户在线改单的功能（比如换样式，补差价）。

·提供私人订制的功能（包括用户上传图片、美甲师提供参考价、双方确认等步骤）。

来自产品：

·用户下单时，支付失败后需要重新下单，不能继续支付，要改正这个问题。

·下单步骤要跳转太多页面，应该集中在一页输入信息。

·根据关键词筛选样式的功能。

好了，首先，我们把标题简化成几个字，然后把重要程度标记下（按照 P1、P2、P3 来），顺便也把重要的原因写清楚。

·记录 GPS：P1（记录 GPS 是为了防刷单，不然公司损失巨大）

·首页简洁：P3（……）

·banner 点击率：P2（对运营安排活动有重要作用）

·秒杀功能：P1（通知已经给用户了，必须做）

·在线改单：P2（现在是人工后台改单，运营人员特别不方便，消耗大量人力成本）

·私人订制：P3（订制用户较少，不着急）

·可继续支付：P1（体验巨差，无法忍受）

·简化下单步骤：P2（大大提升体验，但目前可以接受）

·筛选：P3（目前的分类功能比较完善，筛选是补充）

我们用图表表示：

下一步就是直接开发吗？当然不是。根据目前的需求和预想的功能，跟开发团队讨论执行的难度。同样，实现难度也做一次标记（按照 D1、D2、D3，D1 是最容易实现）。

·记录 GPS：D2（记录 GPS 比较麻烦，服务器有负担）

·首页简洁：D3（排班布局会耗费大量时间）

·Banner 点击率：D1（注入 log，很简单）

·秒杀功能：D3（逻辑特别复杂）

·在线改单：D2（功能交互比较复杂）

·私人订制：D3（同样是功能交互复杂）

·可继续支付：D1（页面改动少，主要是调试接口）

·简化下单步骤：D2（还是功能交互比较复杂）

·筛选：D3（后台逻辑需要做大的改动，数据处理也很麻烦）

OK，是不是现在也要做个表格？不着急。现在是特别关键的一步：跟需求来源方核对需求。其中最重要的是跟需求方确认当前的需求，有没有其他方案能够实现。讨论的结果（可能）如下：

·老板对于实时记录 GPS 的需求，可以改为每 15 分钟记录一次。

·秒杀功能可以分为两个版本，简单的是后台直接修改价格，秒杀的量够了后再修改回来，这样客户端不需要做改动，称作简单秒杀；复杂版本是后台可以控制秒杀款的起止时间和价格，称作复杂秒杀。

那刚才的列表就变成了：

·记录 GPS：D1

·首页简洁：D3

·Banner 点击率：D1

·简单秒杀：D1

·复杂秒杀：D3

·在线改单：D2

·私人订制：D3

·可继续支付：D1

·简化下单步骤：D2

·筛选：D3

 制作图表为：

下面，我们把 P 序列和 D 序列做成矩阵图。

这样，你就知道该做哪一步了。一般来说，推动开发的顺序是这样的：

2．捋顺产品思路，拒绝不合理需求在早期创业过程中，捋顺产品思路是产品经理当仁不让的事情，尤其是老板不懂产品的情况下。

很多朋友问我，总觉得老板拍脑袋定的方法不对，但我也说不出来哪有问题，这该咋办？

这其实还是产品设计的思路上的问题，以及你自身的经验所限。有一本书特别重要，建议每个产品经理都每天默诵：《用户体验的要素》。

其实道理特别特别简单，你看我画的这张图（下图）就明白了。

自下向上设计的思路是所有产品设计中最重要的。

举个很简单的例子，让我们一起来设计一款产品。我们做一个讲故事、说体验的「说乎」（暂定名）。我是这么描述它的市场定位的：

目前知乎的主要定位是分享干货、解决具体问题，但其实很多人写的东西是故事和体验。所以应该有这样一个区别于知乎严肃、严谨、严格的定位，氛围轻松愉快、讲各自在某个主题下的体验的平台。

这样的产品定位，用一句话就是：

讲故事、说体验、写段子的问答社区（或者内容分享社区），模（shan）仿（zhai）知乎。

第二层，我们要探讨做成这样一个社区，要满足怎样的需求，需要什么样的功能。核心的需求，对于读者来说，就是获得乐趣或者实际经验；对于写作者来说，是成就感、个性品牌输出以及更实际的收益。基于这样的需求，我们进一步推导出功能设置。

·读者：发现（热门、精选、搜索、自定义关注、个性化推荐、收藏等）；阅读；评价（喜欢、感谢、评论）。

·写作者：写作（发现问题、编辑写作、邀请）；积分或者奖励机制；个人页面（介绍、历史回答时间线、更多展示）；专栏；IP 输出（电子书、剧本、出版物等）。

考虑到这里，作为生产内容的牛×产品，其实我们还能想象到有一批潜在用户，就是 IP 接收方。我们也把这个列上：

IP 接收方：获取 IP 内容（故事、段子、剧本等）。

现在跟知乎有点不同了，是吧？我们再往上一个层次是结构层，要考虑基本的交互逻辑了。既然整个产品的逻辑都是围绕着内容，那我们就以「文章」作为核心点，去展开具体的逻辑。

下图是对「写作者」来说，到达文章的页面路径。

下面是对于读者和 IP 接受者来说，到达文章的页面路径：

这两个图只是简单的例子，具体肯定会复杂十倍，就不赘述了。

再到「视觉层」和「框架层」，这往往是大家特别熟悉的，什么页面动画、什么布局排版、什么视觉设计，每个人都能说出一堆自己喜欢的 app。但创业公司中，老板和产品经理常常忽视下面的三层(结构层、功能层、战略层)。没有基础，上层建筑怎么可能稳固呢？好了，现在假设这五个层次的内容都丰富完善，这个产品大致是这样的：

未来，每一个需求，不管是谁提过来的，都可以从这里面找到它的位置。

如果它是悬空的，也就是说没有底层的支持的，或者是没有这个需求，或者是并不符合我们产品的定义，那这件事就是错的，这个需求就是不对的。不管这个需求看起来多高科技、多酷炫。

比如，这时候老板来跟你说，「哎，我觉得咱们这上面可以加个卖书的功能。你看我想的有没有道理，第一，这些用户都是爱读东西的，那肯定爱读书；第二，我们可以提供给书点赞给书评论的功能，还能让大 V 们去写书评，让大家讨论起来；第三，这个功能是可以直接变现的。」

乍一听你会有些懵——「好像很有道理」。尤其如果这个老板能言善辩，会集中某个点把你说得心悦诚服，根本找不出漏洞。但作为产品经理，你首先要从产品角度考虑问题。

这时候，你就掏出这张大表来，说：「卖书跟我们产品目前的设计有什么关系啊？从根本上说，这不符合我们的产品定义，也不是我们的目标人群，爱看答案的确实爱看书，但未必买书吧？而且买书为什么不在京东淘宝买？非要在我们这买？我们是比他们便宜，还是比他们质量好，还是比他们送得快呢？」

「另外，核对下目前我们做的用户需求，没有一条是能够用卖书来满足的，也就是说，即便我们确定要做这样的产品，也是要重新规划用户需求，我们可以说是完全开辟了一个新产品线。」

「所以从整个逻辑上，你说的即使都对，我们也是在做一个新产品了，反正现有的产品里，是不能随便做的。」

如果这个老板逻辑清楚，他应该会很快明白你的道理。

再举个真实的例子。

有个朋友的旅游项目，是卖境外游路线的 app，主页就是各种境外游的展示页。但他们老板觉得，活跃度不够，想了想，决定在第二页做电商，用卖签证业务、卖随身 Wi-Fi 来吸引用户。现在他们又在考虑通过有趣而且精美的攻略和游记，吸引用户。

你能看得出问题了吗？

看似这些功能都是面向同样的用户，境外游游客当然既需要买路线、要办签证、要买随身 Wi-Fi，还要看攻略游记作为参考，但这根本是三种需求！

简单用图表表示，大概如下图。

有的创业者会天真地以为，平台圈起用户来，总是有利可图的，不用太在意是什么需求。

可是通过卖随身 Wi-Fi 圈起来的用户，也许大量都是自由行、从来不购买路线的，那这些用户怎么可能引导到你的主要产品上呢？

再比如我阅读一次游记就感觉像出了趟国，我看完也就看完了，我为什么要去买你的路线？

3．成本最低的方式给用户解决问题，拒绝不切实际

这段是承接上一段的。

做任何产品的初衷都是给用户解决问题，如果你把用户当傻×，想通过投机取巧的办法成功，那你早晚也会傻×。

说两个例子就明白了。

（1）用砸钱的办法让用户去用并不需要的产品。

如果没有体会，你可以中午或晚上吃饭时间到望京 SOHO 和麒麟社之间，或者到中关村创业大街附近转一转。你拿了很多传单和礼品，你下载了很多 app、关注了很多公众号，然后告诉我，有几个是你真正需要的。

烧钱总会带来用户，但有多少用户是不烧钱了之后还会留下的？

（2）企图用高频需求拉动低频需求，用刚需拉动非刚需。

就像刚才境外游的那个例子。你可以用很多办法做好一个功能，比如你成为随身 Wi-Fi 的全国第一，然后呢？你这边如果路线做得不好，那仍然没有人会在你这里买路线。

用做另一个功能、满足另一个需求的方法去拉动核心功能、满足核心需求，就相当于是做了个产品 B，在上面挂了产品 A 的广告。

所以在初创期，每个人都心思活络，每个人都天马行空的时候，一定要时刻谨记用户的需求是什么。做产品不是件有趣、好玩、瞎折腾的事儿，它是需要你冷静下来思考，并且一切为用户着想的事儿。

另外一点，成本低的意思是，没必要一下吃成胖子。

比如做境外游，那就把路线这点做得特别好，页面可以很简陋，但好用，支付不出问题、流程完整。相比杂糅了很多社交功能、游记功能、画面也酷炫但是用户连在线支付都很难顺利完成的产品，要靠谱多了。

最后一句，对任何功能都足够慎重，对所有用户都心存敬畏。

4．尽力做好团队润滑剂，拒绝无尽的争执

创业期间，不同的需求方和承接需求方都难免会有各种争执，但不要让它无休止下去。

不管是跟别人的争执，还是参与了别人的争执，记住 6 点。

（1）任何时候，注意讲话的语气，并且建议其他人注意讲话的语气。

（2）就事论事，不要人身攻击。

（3）就事论事，不要提及之前的琐事（「你就是不做我的需求，××，上个月那个就死活不给我做」）。

（4）尽快找到解决办法，不要僵住。

（5）有大家认同的解决办法之后，必须遵从。

（6）有必要的话，多安抚从局势上来说比较吃亏的一方。

总之，千万不要跟老板一摊手：他们谁都说不过谁，我也不知道咋办。

而是当老板过问的时候，你有自信地说：「刚才有问题来着，不过已经给解决了。」

简易需求获取指南

产品经理工作中，很重要的一步就是需求的获取，这是产品工作的开始。因此，我想简单跟大家说说需求获取的一些方法。

产品经理获取需求有很多步骤，在我看来可以这么描述：

获取信息→整理统计→分析总结→功能设计→实景验证。

1．获取足够全的信息。

途径极多，比较常见的就有：

（1）公开信息。包括新闻（百度新闻、科技媒体、微信搜索）、大众评论（微博、微信、知乎）、相关领域的网站和论坛、各种互联网分析网站（比如艾瑞咨询、企鹅智酷等）。

（2）用户调查。在线问卷（问卷星等）、线下问卷，还可以委托代理公司等。

（3）用户访谈，找到较高质量的目标用户进行跟踪访谈。高质量的定义一般是指在领域内资深，对产品体验要求高，有话语权，以及擅于表达。

（4）行业专家、同类产品从业者访谈。可以获得更容易执行、更真实以及更深入的一些信息。

通过这些途径，要获取的信息大概是：

（1）市场规模、市场特点。

（2）竞品状况、用户使用情况。

（3）目标用户特征。

（4）用户目前满足同类需求的方式。

（5）用户期望其他哪些方式满足需求。

按道理说，这些都是基本常识性的东西。但很多有创业点子的朋友来问我的时候，我都特别懵。

「你说的这个两年前就有了啊。」

「你这个市场有多大根本没有调查过吧。」

「你觉得用户真的有这种使用习惯吗？」

这样的话我不知说了多少遍了。

即便是所有信息都尽量获取全了，也只是完成需求分析的第一步。后面的几步，真正做的人、做好的人，会越来越少。

2．整理数据、总结信息，并得出分析。

整理和总结实际并不是特别棘手，稍有统计知识或者做过调研，这些都不用多说。

我想提到的是，在每一步统计和总结中，一定要做到两点：有逻辑；避免陷阱

朋友为二次元项目做调研，发现垂直领域女性用户比例是 95%，是问卷得来的板上钉钉的。但做调研的过程中他们发现，男生很少愿意填问卷，所以真实比例肯定是比这个小的。

同时，由于种种目的，问卷填写者不会填写自己的真实意图，访谈者也可能不会告知真实的想法。

另外，在访谈中，很多用户们会提到自己的想法和灵机一动的点子，要发现背后的需求，要做沉淀，而不是把这些东西当成真正的需求。

比如用户说一直想有人给他做饭，你不要就觉得需求是「找人做饭」，应该记下来的需求点是：平时忙没时间做饭，又不想出去吃觉得不干净。这样抽象出来的核心就是：方便、快捷、卫生。

如果只是找个人做饭，结果预约步骤麻烦、上门服务又不够干净，即使再便宜也没用，因为这不是他的需求点。

3．将需求转为功能设计。

我们在做产品设计时会觉得这一步很简单。用户饿就给饭吃，用户渴就给水喝，这么简单的事情，为什么还要单独拿出来说？

还是刚才的例子，上门做饭，方便要方便到什么程度？干净要干净到什么程度？OK，方便和干净的程度你大致有体会了，预约流程和上门服务的规范具体要做成什么样能满足呢？

微信当初的语音对讲功能满足的就是移动设备上的方便、快捷沟通的需求，但在大部分产品设计者的心里，IM 的王道还是怎么把文字和表情做到极致。

很多经典案例或者优秀产品设计总结，都会把「另辟蹊径」「卓尔不群」「意料之外」「上帝之手」来作为形容，然而实际上这些优异的产品设计都是基于用户已有的需求。跟我一起念：用、户、已、有、的、需、求！

我们之前也购物，所以我们也用淘宝。我们之前也读报看杂志，所以我们也用知乎日报和一刻。我们之前也到处贴广告发通知，所以我们也用 58 同城。

需求必须是一以贯之的，你做一个天气 app 是为了解决用户快速获取天气信息的需求，可能还有得到更多环境信息、获得更好的视觉体验的附加需求。但如果还要做社交、做智能硬件，这就离原来的需求差好几个次元了。

当然，最牛的产品经理也不能保证自己设计的功能就真正符合用户需求，这时就需要下一步了。

4．快速验证，在用户使用过程中修正需求。

一个产品真正能不能火，因素实在太多。没人能确保自己的产品一做出来就能让用户觉得厉害，更多的情况是，在不温不火中慢慢发现需求的偏差，慢慢做好更重要的功能，慢慢成了真正受欢迎的产品。

模仿 Twitter 的产品当年很多，新浪跟大家做的方式不一样，跟 Twitter 也不一样。它敏锐地把控到了娱乐、文化这些方向在国内的趋势，所以能做成做大。

做团购的产品当年也很多，美团对用户端率先上了全额无条件退款的功能，对商家端率先提供了半自动结账的功能，很快就势如破竹。

这些都并不是因为谁是天才，或者巧合，就是因为对运营过程中发现的需求把控做得出色。小米一直提的互联网思维不就是讲这个吗。

作为总结，就一句话：

任何需求的分析和总结，要有逻辑、避开陷阱；任何需求的修正，要投入市场、观察用户。这样就能做出符合用户真正需求的产品了。

另外，在分析需求时，可以再参照这么 4 个建议。

（1）需求多看几个角度。

同样的行为，或者说出同样的话，其背后的需求可能完全不一样。

比如，同样是找你帮忙给他答案点赞的，看似都是「需要点赞」的需求，但背后可能是：

·我这篇是软文，需要传播。

·我希望这篇能够帮到更多人。

·我这篇赞数太少了，有点丢人。

再类比一件事，大家就更清楚了。当女朋友跟你发火、赌气，她的需求每次都是千变万化的。有时候需要你给她买个包，有时候需要你带她出去耍，有时候需要你跟她说清楚昨晚到底在哪。

（2）需求多分几个层次。

不一样的产品经理，看问题的深度或者高度是不同的。越深入某个行业、越懂得某个技巧，就能看到更多的东西。

比如，一个人说她要减肥，她的需求就是减肥是吧？这是最表层的。我们分几层看，是这样：

直到人性需求，这次的需求分析才能算到底了。我们了解人性需求有什么意义呢？

比如有人说要减肥，我们就认为只要能减肥就好了，提供了特别有效的一种减肥操，但是这个操做起来很难看。如果你意识不到，其实来减肥的人都是对自己形象有要求的人，那就不会知道，这样的方式满足了表面需求，但破坏了底层需求。

再举个例子：

对于很懒的人，或者宅男宅女，他们的需要，也可以在很多环节优化。我们能够从人性需求上判断出这些人是怎么样的人。

（3）需求多跟用户聊。

定量的调研有各种各样的问题和缺陷，也并不适合创业公司、产品新人去用，这种方法会受执行者的水平所限，且要效果好必然成本高。

我更建议新人多跟用户聊。这个聊不是很随意地说「哎呀我们要做个×××」。他们说，「哎呀你这个×××真好，我们肯定用。」用户访谈是有很多讲究的，这里不展开说，就提一个点。

在访谈时，一定要多问为什么，发掘每一个话题背后的逻辑。

「你想要减肥，为什么？」

「因为我胖。」

「所以胖如何影响到了你的生活呢？」

「找不到女朋友。」

「那你觉得胖在你找不到女朋友的原因中占多大的比重？」

……

在访谈中，有很多内容关乎访谈者的生活方式和个人情况，这要求我们，在问的时候循序渐进，并且一定要处好关系，确保他们说的是真实的情况。

（4）需求多去试验、体会。

作为产品设计者，一定要去需求所在的环境和情景中体验。如果是做减肥的产品，那你了解胖子的需求，最好的方法就是变成一个胖子。

当然减肥是一个例子，很多产品里，是完全可以先变成自己想象中的用户的，不停地去体会需求，看自己在这样的场景下会想到什么、做什么、需要什么。

乔布斯说过，「你不把产品给用户，用户就不知道自己需要什么」。但要真的抛开所有用户调研和访谈来做产品，只有两种情况：①你对用户需求足够了解，完全清楚；②你对自己预测、感知和设计的能力极其自信。乔布斯能做到这两点的，但我目测到的大部分产品经理，第一点都很难达到，更不用说第二点了。

所以当很难通过用户访谈获得真实有效的信息时，就自己先变成用户吧。

简易工具指南

产品经理在工作中要掌握一些工具的使用，这里做简单的推荐。

一、协作工具

总结下目前我们产品部门会用到的工具。

1．需求管理：伙伴云表格

在锤子科技时，我们做需求管理用的主要是 Excel 和 Google Docs，后来在别的团队还用过 Excel+SVN 的方式，都不太理想。

实际上从需求管理的角度来看，我们最需要的是：

·能够详细记录需求的不同属性（大部分协作工具做不到）。

·能够快捷指定负责人、状态、优先级等可选项（大部分协作工具做不到）。

·能够对一个需求进行评论和操作的记录（Excel 做不到）。

·能够同步共享给所有人，并有不同的操作权限（Excel 做不到）

后来我发现了伙伴云表格，感觉解决得特别棒。他们的创始人是 Discuz!之前的合伙人之一，还是挺感慨——技术真的在解放生产力。

2．任务协作：Tita/Teambition/Worktile

任务协作方面我觉得可以见仁见智，不同的工具有不同的特点。

这几款工具我在不同的团队都用过，具体是根据当时的情况来决定的。

建议都试用一下，再决定团队到底适合哪个。

不管怎样，如果团队在三个人或以上了，一定要有一个任务协作工具。

二、个人工具

1．格式化书写：Markdown 

我在每个团队几乎都能见到喜欢 Markdown 的产品经理，当然一般都是程序员转职的。

如果习惯了这种写文档的方法，至少可以在以下方面效率提高十倍：

·产品需求文档

·个人想法

·邮件

·会议记录

·读书笔记

往大了说，产品经理做的任何产品和功能，其实就是为了提高效率、解决问题，而在互联网行业更擅长的就是通过标准、流程化的方法解决问题。Markdown 就是这样的一套解决方法，完美地搞定了书写的格式问题。

推荐的工具有：

（1）Mac 上的：Mou 。

（2）内置了 Markdown 的 Evernote 中国版：为知笔记。

（3）需要配合 Evernote 用的：马克飞象 。

2．可视化描述：餐巾纸的背面/视觉会议

我们团队目前在开会的时候，已经很习惯用图、表、线条等元素来描述情况了。

产品经理在讨论时，如果不能够有逻辑地把问题条分缕析搞明白，那很可能会跑题、会纠结在没有意义的事情上，导致最后得出来不真实、不合理的结论。

3．整理记录：笔记本&笔+Evernote

永远不要空手讨论问题！永远不要空手聊天！永远不要空手学习！

带上本子和笔，主要是起两点作用：

（1）把问题和相关的元素列清楚。

（2）把结论和相关的过程记录清楚。

如果只凭脑子记住，事后再回忆往往都是会错漏的。

对了，如果不喜欢公司提供的本子和笔，记得买好些的，不要省钱。

完成了记录后，整理的工作就交给云笔记做吧。大家习惯的应该还是 Evernote。

把目录列得有条理一些，等你用到的时候，会感谢自己的。

4．原型和交互：Sketch/Keynote/PowerPoint/墨刀

Sketch 应该是目前 Mac 上公认制作 UI 最好用的工具了。产品经理也完全可以用这个画交互。

另外，也不要小看 Keynote 和 PowerPoint。许多专业工具能达到的交互和 UI 效果，它们也完全能够做到。

墨刀适合做可演示模型。

5．免费图标/图片：Iconfinder/Pixabay

做原型和交互的时候可以参考。

说句题外话，我很建议大家不要用线框图来讨论方案，最好是用高仿的原型图来讨论。因为很多情况下，产品的交互、视觉层面会对功能产生影响，单纯看线框图是完全没有感知的。

《启示录》在第 21 章「产品验证」里也提到，尽量用高仿真的原型甚至可用的版本来作为产品描述，而不是线框图或者文档。

简易读书指南

产品经理应当看很多书，因为产品经理需要获取很多各方面的知识。

我在读很多书时看到例子老旧，就有点嫌弃。估计大家都有这种感受。书的出版周期很长，所以时效性难免差一些，尤其是例子。

在读了很多关于互联网、创业和产品的书之后，我深刻感觉到，除了例子很老，绝大多数的方法论、道理和逻辑，都不会过时。

我翻了很多已经出版三五年，甚至七八年的书，发现现在遇到的问题居然都能得到解答。Web 时代的很多分析，用在移动互联网只是在实现层面有差别，在底层逻辑上完全一致。

有三本书，对我的产品经理生涯来说意义重大。

1．道

《必然》

很多人都说，凯文·凯利被过度神化了。我是同意的，他的确不是神，也不是那种不出世的天才预言家。其实他只是个敏锐的观察者，他看得到的我们都能看得到，他能分析的我们也可以分析。当你看到了、分析了，也就会有很多结论、能做很多预测了。

不过大家看问题的角度往往都过于局限、过于死板。在新事物出现时，大家还是在用生物本能去思考事物，不是从更高层次去考虑问题。

很简单的例子，互联网大潮来临时，无数创作者觉得末日来临，所有人也都狂欢起来，什么免费时代来了、版权的黑暗时代来了、以后就是共产主义了。但过了很多年，版权没有消失，反而更宝贵了。未来，版权会以什么形态变化、免费的潮流会怎么样……这些都会基于互联网信息传播特性而缓慢发生的，不是谁说什么就是什么。

只是去判断「这是对的」「这是错的」，而不是去观察环境发生的变化，是低阶产品经理的思维方式。

这是读《必然》的方式。

你要看，明明是同样的问题、同样的现象，为什么凯文·凯利要这么说，而我之前会那么想。准确地把握重点、梳理体系、大胆论断，是产品经理的基本功之一。

同时，要去想，他说的这个，对应到我的认知中，会是怎么样的。

另外，像《大教堂与集市》《稀缺》《失控》，都可以作为参考。

切记：观点未必全收，思考方式都可以反复借鉴。

2．术

《用户体验要素》

不夸张地说，我从没有见过像五层模型这么深入人心的产品设计法则。在各种产品分析文章中，已经作为标配出现了。虽然这本书问世已经整整 14 年，但直到现在的移动互联网时代都不过时。

其实道理很简单，就是拆分设计的层次，一方面要区分层次和保证逻辑的通顺性，另一方面根据不同层次的特点去设计。怎样把平时产品设计的核心思想抽象出来，是我们在看这种书的时候要思考的问题。

平时总是跟程序员吵架，问题出现在哪？怎么解决的？这样的解决方法是不是最好的？解决方法如果可行，那能不能总结出方法论来作为指导？这种方法论又能不能制定成跟程序员沟通的流程去遵守？这是合格的产品经理要做到的。一味地只是解决眼下，只能算助理的水平。

能从日常生活里抽象出问题，并想到解决方案，为现实生活和工作提供帮助，也就是所谓的产品经理思维吧。

《影响力》《参与感》《引爆点》《疯传》等，都是这类型的书。

3．器

《启示录》

虽然有很多产品经理的书了，但我还是觉得这本是唯一可以称得上是「专为产品经理定制的百科全书」。

书的字数不多，却面面俱到。作为 2008 年的书，同样能指导现在的很多创业者。

比如很多朋友会问我的问题：「外包团队靠谱吗？有什么问题？」

书里提到（作者把外包称为定制）：

「长久以来，开发定制软件困难重重……虽然需求存在，但客户通常不知道自己想要什么……等到交付软件时，客户往往发现到手的软件和想象中的相差十万八千里，于是又要求开发人员修改，如此恶性循环，客户屡屡失望而归。

定制软件的客户认为自己了解自己的需求，所以不需要什么产品经理，他们也不需要用户体验设计师……客户不理解什么是用户体验，以及对成本过于敏感（让开发人员设计产品可以节约成本）。

换句话说，这就是现在到处问「开发个 app 到底多少钱？」「我让外包做的产品怎么不满意呢？」的土老板们遇到的问题。

他们既不理解为什么需要产品经理和设计师（不就是放几个按钮、画几个图标吗？），也不理解为什么外包团队总是做不满意（告诉他们大概的样子，实现不就行了吗？）。

我再摘录几段话。

「许多产品团队没有意识到，或者很晚才意识到要转变工作重心。更糟糕的是，产品经理还时不时冒出新点子；公司高管认为产品文档还可以继续修改，导致开发要求大幅变更，严重影响开发团队工作。结果不是发布日期一推再推，就是某些功能被迫取消，或者产品质量下滑。」

这段话说的就是「产品经理不仅要想点子，还要保证产品的实现」。

「在我看来，每当团队内出现严重的意见分歧时，并非是大家对事实的认定有争议，而是对目标和目标的优先级有不同的理解。」

这是「有争执时讲道理都可以解决问题，除非大家价值判断不同」。

「我无法想象不深入理解用户需求，特别是在禁止与用户面对面交流的情况下，产品经理怎样打造出让用户满意的产品。」

这是「任何事情都看用户的需求，做判断，而不是主观上做太多自以为是的设计」。

「目前流行的研发模式通常是这样的：创业者想到一个好点子，得到启动资金后，马上招聘程序员开发产品。由于创始人最清楚要做什么，因此，他通常会扮演产品经理和产品设计师的角色。开发团队则按照他的想法实现产品。这些创业公司一般在『秘密状态』下运行，很少与用户互动。另外，由于产品需求和创意往往边做边变化，开发进度相对较慢。」

这里面同时提到了创业中「创始人会兼任产品经理」「创业过程中太过频繁改动需求」和「创业者过于关注自己的点子的保密性」的问题。难以想象，2008 年美国就流行的事情，在如今的中关村和望京 SOHO 重新上演。

我看书的时候边看边拍大腿，因为说得太有道理了。

这样的书该怎么读呢？

1．首先，下载一个 Evernote，或者用在线版。

2．建立合理的目录。

3．在书里看到任何有价值的内容，摘抄、做笔记、整理。不要拖到周末不要拖到晚上，就是在看到的时刻（下图以《必然》举例）。

4．每周做一次整理。最好再到知乎或者人人都是产品经理社区等地方，写写东西。

读了这三本书只能算初阶，学会怎么读这三本书才算中阶，能把学到的知识运用到现实工作中，就是高阶了。

作者说

我是刘飞，知乎 ID 也是刘飞。四年互联网产品经验，先后就职于锤子科技、嘟嘟美甲和点我达。

我开始跟大家分享自己的产品心得纯属巧合，创业期间接触到许多新事物，应接不暇，因此经常做复盘和总结，顺手贴到知乎上没想到引起了很多朋友的共鸣。在知乎上，跟我咨询、寻求帮助最多的，是大学生和初学者，我也深知在他们的境遇下，对产品经理的许多困惑，于是经常会整理分享一些通识性的、基础性的产品经理概念，以及求职心得。不知不觉已可整理成书，希望能够帮助更多人。

另外，如果有需要进阶的知识和方法论，可以购买我的新书《从点子到产品》。如果有书中仍未解答的问题，欢迎到知乎来与我交流，我的知乎主页是：

https://www2.zhihu.com/people/laufei