是谁？每次K歌都对着点歌面板评头论足。是谁？逛超市时总在想“这个商品能解决什么需求？”是谁？会给自己的个人发展做战略规划。是谁？一定要在自己的婚礼中讲一个PPT。是谁？会拿用户调研的方法与亲朋好友交流。是谁？装修房子的时候抢着当项目经理。是谁？看电视广告总想在几十秒中提炼出三大卖点。是谁？会给自己的孩子设计各种“功能点”。是谁？访问任何网站都能一下子挑出好几个Bug。……

这个人就是产品经理。2006年底，我开始做产品经理，逐渐体会到这种做事方法与思路真的很好用，已经忍不住用它来解决任何问题，并且想告诉每一个人，尝试着用产品经理的视角看世界吧，你可以看得更清楚，走得更顺利。

苏杰编著的《人人都是产品经理》适合刚入门的产品经理、产品规划师、需求分析师，以及对做产品感兴趣的学生，用户体验、市场运营、技术部门的朋友们，特别是互联网、软件行业。

苏杰编著的《人人都是产品经理》为《人人都是产品经理》的升级版，是写给“1到3岁的产品经理”的书，适合刚入门的产品经理、产品规划师、需求分析师，以及对做产品感兴趣的学生，用户体验、市场运营、技术部门的朋友们，特别是互联网、软件行业。作为一名“4岁的产品经理”，作者讲述了过去3年的经历与体会，与前辈们的书不同，本书就像你走到作者身边，说“嗨，哥们！晚上有空吃个饭吗，随便聊聊做产品的事吧”，然后作者说“好啊”。

书名叫“人人都是产品经理”，是因为作者觉得过去几年在做产品的过程中学到的思维方法与做事方式对自己很有帮助，而每个人也无时无刻在思考着同样的问题：“我们为了什么，在做什么事，解决什么人的什么问题？何时，和谁一起做？需要什么能力？”这些正对应了《人人都是产品经理》要说的几大话题：用户、需求、项目、团队、战略、修养。

写在正文之前

 为什么会有这本书

 本书的产品定位

 本书的风格与特色

 本书的目录与内容

 我与本书的局限性

第1章 写给-1到3岁的产品经理

 1.1 为什么要做产品经理

 1.2 我们到底是不是产品经理

 1.3 我真的想做，怎么入行

 1.4 一个产品经理的-1到3岁

第2章 一个需求的奋斗史

 2.1 从用户中来到用户中去

2.1.1 用户是需求之源

2.1.2 你真的了解用户吗

 2.2 需求采集的大生产运动

2.2.1 定性地说：用户访谈

2.2.2 定量地说：调查问卷

2.2.3 定性地做：可用性测试

2.2.4 定量地做：数据分析

2.2.5 需求采集人人有责

 2.3 听用户的但不要照着做

2.3.1 明确我们存在的价值

2.3.2 给需求做一次DNA检测

 2.4 活下来的永远是少数

2.4.1 永远忘不掉的那场战争

2.4.2 别灰心，少做就是多做

 2.5 心急吃不了热豆腐

第3章 项目的坎坷一生

 3.1 从产品到项目

 3.2 一切从Kick Off开始

 3.3 关键的青春期，又见需求

3.3.1 真的要写很多文档

3.3.2 需求活在项目中

 3.4 成长，一步一个脚印

 3.5 山寨级项目管理

3.5.1 文档只是手段

3.5.2 流程也是手段

3.5.3 敏捷更是手段

 3.6 物竞天择适者生存

3.6.1 亲历过的特色项目

3.6.2 一路坎坷，你我同行

第4章 我的产品，我的团队

 4.1 大产品，大设计，大团队

4.1.1 产品之大

4.1.2 设计之大

4.1.3 团队之大

 4.2 游走于商业与技术之间

4.2.1 心思缜密的规划师

4.2.2 激情四射的设计师

4.2.3 “阴险狡诈”的运营师

 4.3 商业团队，冲锋陷阵

4.3.1 好产品还需市场化

4.3.2 我们还能做什么

 4.4 技术团队，坚强后盾

 4.5 容易被遗忘的角落

 4.6 大家好才是真的好

4.6.1 所谓团队文化

4.6.2 虚无的无授权领导

第5章 别让灵魂跟不上脚步

 5.1 触及产品的灵魂

 5.2 可行性分析三步曲

5.2.1 我们在哪儿

5.2.2 我们去哪儿

5.2.3 我们怎么去

 5.3 做吧，准备出发

5.3.1 敢问路在何方

5.3.2 低头走路，抬头看天

 5.4 KPI，KPI，KPI

 5.5 本书的源头活水

第6章 产品经理的自我修养

 6.1 爱生活，才会爱产品

 6.2 有理想，就不会变咸鱼

 6.3 会思考，活到老学到老

 6.4 能沟通，在什么山头唱什么歌

 6.5 产品经理主义

附录：它山之石 可以攻玉

 别人眼中的产品经理

 各种有用的信息

3.5.3 敏捷更是手段

2007年夏天，网店版在很长一段时间内保持一周发布两次的快节奏，最近两年，很多产品也都保持着平均一两周发布一次的频率。这么快的速度，是为了迅速响应市场与用户，这个特点和互联网、软件项目的其他特性杂糅在一起，必然要有相应的方法论支撑，所以，从2008年起，作为项目经理的我开始学习体会“敏捷方法”。

从书本到实践

在互联网和软件领域中，项目管理理论的发展，和任何知识一样，开始很混乱，每个项目自有一套，每个项目经理自有一套。后来人们非常想定出一个统一的、简单的流程，以减少人为影响，所以软件工程里的瀑布模型等出现了；再后来发现瀑布模型有其局限性，于是提出了敏捷方法。

经典的软件工程方法旨在定义一套完备的过程规范，使软件开发的运作就像是机器设备的运转，人在其中则是可更换的零件，不论是谁参与其中，机器都能运转良好。这意味着：开发进度的可预见性，流程方法的固化与可复用，人力成本的节省，人员的流动不会对软件开发构成影响等。这样的做法对于公司而言，是具有很大吸引力的。其背后所隐含的观点则是：软件从业者无须是具备非凡智力的高级人才，人是一种可以被任意替代的资源，并且软件的需求从项目开始的时候就是确定的，而且不会改变。这显然是不符合事实的。

所以在瞬息万变的互联网、软件行业，大家渐渐体会到敏捷的优势。我们参考了几种经典的敏捷模式，按照产品、团队的需要定制了属于自己的敏捷方法，特点如下：

有计划，更要“拥抱变化”。

随着时间变化，必然有新的信息出现，特别是市场环境、用户情况等瞬息万变的互联网业界，所以死守着的项目计划不调整是没有逻辑的做法。并且，项目估计的不确定性是会累积的，80％×80％×……以后，能确定的就更少了，所以开始订的项目计划，在一个月后很可能已经面目全非，强行遵守是没有意义的，而应该不断地修正，当然，在一开始的计划中间就应该留有一些弹性。

迭代周期内尽量不加任务。

敏捷再灵活，也不能容忍毫无控制的变化，“迭代”权衡了变化的成本和不变的成本，这是一个将“大项目长期不变”细化为“当前迭代不变，下次迭代待定”的做法。此外，如果某次迭代内的任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。我们可以把每个迭代看做一个小的瀑布模型，其实Royce前辈早在1970年提出瀑布模型时也谈到过迭代的思想，不过经常被后人忽略。所以说敏捷其实并没有排斥经典的项目管理方法，只是各种方法都应该用在最适合的场景，瀑布模型对于需求固定的项目还是不错的，比如它在管理一个工厂时就非常有效。

集中工作，小步快跑。

项目干系人都在一个区域办公，或者在一间会议室里办公，这样可充分利用白板和墙壁。相应地就要求团队较小，一般小于十几人，太多了可分割为多个团队。同时，项目有较短的迭代周期，通常是2-4周，我们推崇每日“站立晨会”，会长小于20分钟，每个人只能说3个问题：昨天做了什么？今天要做什么？碰到什么问题，打算如何解决，需要什么帮助？集中工作也是为了倡导较少的文档，更多的口头沟通，其实这点对团队成员要求很高，特别是对国内的技术人员。

集中办公、团队较小、文档较少等特点让很多创业团队看似敏捷，但其实他们徒有其表，并没有领会精髓，存在很多隐患，往往项目前期很快，发现问题的时候已经晚了……

持续细化需求，强调测试。

需求唯一不变的特征就是“不断变化”，项目与产品都要小步快跑，用不着在需求阶段纠缠。有些需求在开始的时候是提不出来的，或者说没法细化的，所以试图一次性完成需求分析的工作会存在“过度需求”的问题，是浪费时间的行为，到后来多半还是要改。

我们在开发和测试过程中完善需求，而且特别看重测试驱动项目，更早的测试，重度的测试。这需要有很强很严谨的测试人员，TC编写、TC评审，甚至测试执行的过程可以用来补充和细化需求，比如业务逻辑里的一些限制条件、异常流程等，往往都是测试人员提出来的。

不断发布，尽早交付。

让需求方不断地、尽早地看到结果，并给予反馈，当然需求方代表要有话语权，不然半途杀出个老板说三道四是令人极其郁闷的。这点也要求需求方充分投入，包括集中办公、参与验收测试等。我们的“冒烟测试”、“每日构建”就符合“尽早交付”的概念，可以让需求方尽早看到最新的产品。不断地发布也是为了把大问题分而治之，先解决最核心的，风险最大的部分。我们会先完成最重要的功能，所以说敏捷的里程碑是功能驱动的。

说到这里，我提一下，我们公司的项目发布时间通常是周二和周四晚上。这是因为周一大家刚回来工作，状态不佳；周五又归心似箭，并且发布后有问题的话第二天没人上班，不适合；安排在周三的话就会有连续两天发布，时间周转不过来，而且可能在精力体力上吃不消。所以公司渐渐形成了每周二、周四为发布日的惯例，如果需要额外的发布，则要特别提出申请，毕竟很多部门要相互配合。当然如果每周只有一次发布的话，周三也是个合适的选择。

以上各点之间也存在着千丝万缕的联系，比如说固定的迭代周期可以保证不断地发布，较轻量级的文档降低了持续细化需求的成本等。项目中的敏捷沟通

“无论最终发现什么，我们必须理解并完全相信：每个人在其当时所处情况下，在其能力范围中，做了最大的努力。”

这是敏捷里让人很温暖的一句话，让我们互相理解，又能激发团队力量。在此基础上，更顺畅的沟通成为可能。接下来说说我亲历的团队在真实的项目中是如何沟通的，不妨起个名字叫做“敏捷沟通”。

我们的每个项目，项目经理都会建立一个即时通信的IM群，我们用的是阿里旺旺；一个临时的邮件列表，把项目干系人全部加入。IM用于实时沟通，比如发了重要邮件要大家赶紧收、文档有重要更新、测试环境正在构建暂时没法访问等，都可以在群里吼。旺旺有群公告，我们会贴上项目各种文档、资料的Wiki地址，以及一些测试环境的地址等公共信息。项目相关的第一封邮件，会把大家的E-mail收集齐，在此邮件最后说明“本项目干系人以此封邮件为准，大家的项目邮件可以直接回复全部并修改邮件名称和正文”，我们可以通过此邮件建立项目的邮件列表。当然，之后有人员变化也可以随时增删。

我们坚持着经典的每日站立晨会，对于典型周期为2-4周的项目，控制粒度到“天”很有必要，“项目看板…视情况而定，举例如下。

P167-169

是谁？每次K歌都对着点歌面板评头论足。

是谁？逛超市时总在想“这个商品能解决什么需求？”

是谁？会给自己的个人发展做战略规划。

是谁？一定要在自己的婚礼中讲一个PPT。

是谁？会拿用户调研的方法与亲朋好友交流。

是谁？装修房子的时候抢着当项目经理。

是谁？看电视广告总想在几十秒中提炼出三大卖点。

是谁？会给自己的孩子设计各种“功能点”。

是谁？访问任何网站都能一下子挑出好几个Bug。

……

这个人就是产品经理。2006年底，我开始做产品经理，逐渐体会到这种做事方法与思路真的很好用，已经忍不住用它来解决任何问题，并且想告诉每一个人，尝试着用产品经理的视角看世界吧，你可以看得更清楚，走得更顺利。

SNS里的抢车位游戏，曾经很流行，也许你考虑的问题是：应该怎样玩才能赚更多的钱？怎样最快地买到想要的车？怎么玩最爽？……而产品经理的视角则是：为什么每个人是4个车位？如果车位多了会怎么样？不同档次的车为什么停车费是一样的？如果高档车停车费高了，会有什么优缺点？

原来，这些都是和商业目标有关的，车位多了，停车费高了，对好友数量的需求就会降低，这意味着用户互动的减少，与商业目标矛盾；而反过来，如果简单粗暴地试图增加互动，用户又会不高兴，也不行。

后来，“偷菜”比较火，可惜我没玩过，玩过的可以试着用这种思路想一下，一定能发现一片从未到达的“世外桃源”。而这本书的写作过程，我也用上了做产品的套路，遵循了互联网产品设计的五个层次--战略、范围、结构、框架、表现。就算这本书的实体，也到处有着思考的痕迹，比如勒口，你发现了没有？可以剪下来当书签，上面的一段话又是书名的真谛：

不是每个人都能以产品经理为业，但在我看来，产品经理是一类人，他的做事思路与方法可以解决很多实际的生活问题。只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态去跟踪、维护这个产物，那么，你就是产品经理。至少，你已经是自己的产品经理，这才是“人人都是产品经理”的真谛。

记得上一次写致谢是在研究生的毕业论文里，用的是学长的“模板”，我以为会成为终身的遗憾。没想到4年后，有机会原创了。

首先，重点感谢一些“没有他们就没有这本书”的人。

感谢父母。说点实在的，我自问不是不食烟火的纯理想主义者，衣食无忧很重要。这两年我在想，要不是他们送了我一套房子，那我可能也会像《蜗居》里的人们那样，被生活所累而根本没时间思考。

感谢公司。阿里巴巴宽松的文化、分享的氛围是这本书诞生的土壤。不得不再提起我的几位主管，这本书的第一个1000字，其实就是我2007年7月的一份周报，当时我绝对没有主动写作的意识，完全是他们要求的。几年来，在他们的帮助和鼓励下，工作上的体会成为这本书源源不断的素材。到了最后，甚至在我提出了利用工作时间来做本书运营的想法时，他们也表示理解……

感谢博文视点的周筠老师。早在两年前就发现了我，可算是我的贵人。她介绍了很多前辈给我认识，也为我这本不成熟的书付出了很多精力，到了最后阶段，甚至亲自动手帮我修改很多生涩的文字。

接下来，要感谢很多“没有他们这本书就会失色不少”的人。

感谢呆过的几个团队。这些同事都是最棒的兄弟姐妹。2009年6月，写书前跟腱断裂的意外，他们扛住了我丢下的工作，并且不断地给我打气，虽然方式有些特别，比如说K歌的时候点郑智化的《水手》给我唱。

感谢编辑夏青。这是我的第一本书，也是她从头到尾做的第一本书。在我正式写作的大半年里，两个新人都没太有底气，可以算是互相鼓劲，努力总算有了回报。

感谢出版社其他朋友。他们一直以来的关注和最后一起的冲刺，让这本书顺利产出。

感谢小敏。是2009年初的一次聚会，她促使我把出书从想法正式提上日程。我的个人名片、本书的部分插图都出自她手。

感谢Park。这本书和我的博客是分不开的，是一个产品的两种表现形式。博客从注册域名、虚拟主机到上线后的各次调整间，我问了Park很多很傻的技术问题，他都瞬间帮我解决了。

感谢审稿人。是他们无私地贡献出自己的时间，让我这个后辈意识到自己在哪些方面能力不足，并且帮我明确了前进的方向。

最后，感谢所有交流过的同行、前辈、新人。名字我没法一一列出，他们可能都没意识到自己对这本书有多大帮助，随便举几个例子：

推荐序充分体现了互联网的力量。没有常见的长篇大论式的名人推荐，而是每个人贡献一句话，某位应届生的话、某位产品设计师的话、马云的话，放在一起共同组成了本书特别的推荐序。

封面设计的初稿在博客上发出，短短几个小时内就有几十位专业的产品经理、设计师为它提出了修改的意见和建议，避免了我把不合适的封面展现在最终的读者面前。

和朋友们谈起这本书要充分利用互联网运营，很快就自发形成了虚拟的运营团队，很多都是资深的互联网运营人员。

写到这里，我还是不敢确定，我居然写了一本关于产品经理的书？在这条路上，我还是一个新人，是大家，让我愈发地坚定了自己的宣言--

一个成长中的产品经理，期待和同学们一起，用好产品改变世界。

我对这书特别有兴趣，因为阿里在未来几年内需要大大培养优秀的产品经理！希望你能把这作为辅导教材。

——马云 阿里巴巴集团CEO

产品经理的核心，是将自己视作产品的Owner。这本书正是苏杰这几年始终以Owner的角度观察、思考、分析、总结工作与生活所得。这种态度，结合在优秀互联网公司的亲身实践，让他本人从一名刚毕业的学生迅速成长为优秀的产品经理。读《人人都是产品经理》，这种成长的共鸣会让你轻松理解产品经理的相关知识；而我更相信，你会受其启发自创武功，从而成为优秀的产品经理。

——叶伟 前盛大文学CTO

这是一本基于实战的书，将现实生活与实际案例结合到一起娓娓道来，用一个个活脱的生活场景对比一个个的产品案例，亲切且印象深刻。希望所有的产品设计同行们都读一读这本书，也希望大家在读完这本书之后可以时时关注生活中的产品设计，并将其运用在实际工作中。

——白鸦 guang.com创始人 前支付宝产品设计师

贴近工作和生活，以需求为中心的书，产品经理必读！

——李力 搜狐无线事业部产品经理

一本真正的互联网产品经理实战手册，内容都是来自实践的总结与分享。无论你是不是产品经理，只要你在互联网行业，都值得一读，因为“人人都是产品经理”。

——李春秋 腾讯广告平台与产品部产品经理