详情
本书系统地介绍产品经理所需要的知识。全书共16章，主要内容包括产品基本概念、产品工具的使用方法、用户的研究方法、需求的分析方法、产品的设计方法、项目的管理方法、行业和商业的分析方法、产品知识的学习方法、产品经理求职面试方法，以及职场经验。本书结合配套的案例展开讨论，不仅有助于读者对整个产品经理知识体系有更加清晰、直观的认识，还有助于读者搭建完整的知识框架，掌握产品经理工作流程中的各种技能，不断在职业生涯中成长。
书名：产品经理方法论——构建完整的产品知识体系
ISBN：978-7-115-57114-4
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 赵丹阳
责任编辑 谢晓芳
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书系统地介绍了产品经理需要掌握的知识，包括产品的基本概念、撰写产品文档的方法、绘制流程图的方法、绘制产品原型图的方法、研究和分析用户的方法、管理需求的方法、设计产品的方法、分析数据的方法、理解技术的思路、管理项目的方法、产品设计实践、产品学习方法等。
本书适合产品经理或想要成为产品经理的读者阅读。
记得上小学学习数学时，我就特别爱背公式，我认为很多题目考查的其实是同一个原理或同一个公式的应用。到了期末复习的时候，老师会帮助我们总结一整套公式，以及各种题型的解法。这不仅是方法论，还是对知识体系的梳理。
本书介绍了产品经理应该掌握的大量工具、方法。本书的作者曾经是我的同事，他是一名学习能力超强并且非常愿意思考的产品经理。几年前他就独立运营了一个微信公众号，专门记录他在产品方面的想法，以及各种思维模型、方法，并且他一直坚持做了下来，这非常难得。
他多次修改本书的书稿，持续打磨了一年多，就是为了让刚入行或者准备转行做产品经理的读者能够快速积累相关知识和方法，少走弯路。
产品经理这个职业需要一套完备的知识体系，产品经理不仅要重视对经验的总结传承，还要像本书作者这样，不断地优化，形成一整套实战性非常强的知识体系。
一个人的成长并不是一蹴而就的，我们从小学到大学学习的文化知识一直处于螺旋式上升的态势，难度逐渐增加。随着知识面逐渐拓宽，我们遇到的问题逐渐变多、变难。然而，这一切都囊括在一个知识体系里，谁能够更好地把知识串起来，把所有的知识形成图谱，谁就能更好地应用这些知识，并能够在学习和工作中取得好的成绩。
我们要更新观念——产品经理并不是一个技能型的岗位，并没有一个技能可以让你在学完之后就终生受益，其实产品经理的工作更像一台大型计算机的运转，这台机器要有非常严谨、可靠的体系结构，一个体系的力量远比任何一个元素的力量要大。不管是在大公司中参加系统化培训，还是在小公司中历练，它们都只是成为产品经理的环境与手段，关键是我们最终可以达到什么样的状态，形成什么样的知识体系。
在工作中经常会出现突然有了想法的时刻，而这种时刻似乎总会在不经意间出现。因为我们在不断地学习，不断地实践，不断地完善自己的知识体系，所以更应该把新的想法、新的工作感悟更新到属于自己的成长宝典中。
成长宝典可以公开，如通过分享给朋友，获得多维的观点，让自己成长得更快。“得到”App就公开了生产内容的白皮书，这本白皮书现在成为行业的重要参考。“得到”团队公开了非常详细的执行方法，每一个人都可以查看在生产内容时可能遇到的各种问题和解决方案。他们不担心这些工作经验被窃取，因为他们知道只获得了一些知识是没有用的，关键是要能够将其内化到自己的知识体系中，持续优化自己的成长宝典。同样，希望你能和周围的朋友共读本书，从而成长得更快。
知识体系也可以称为知识结构。合理的知识结构既有精深的专业知识，又有广博的知识面，还要有对众多知识的高度概括，具有可快速复制的特性。
现在很多产品经理的知识结构是偏理工科的，他们对计算机软件的操作很熟悉，但缺少要用软件做什么的想法，以及洞察用户需求、规划产品、创造商业价值的能力。所以本书呈现了完整的知识体系，就好像一张知识图谱、一本成长指南。合理的知识结构是担任产品经理的必要条件，是人才成长的基础，也是培养更多优秀的产品经理的有效工具。
产品经理在实际工作中应该有一个基础的知识体系，在此基础上可以任意发挥，不至于完全依靠某一个人的背景知识。产品是否能够成为“爆款”不应该取决于某个人的灵感乍现，好的产品是团队协同的结果，是应用方法论的结果。
产品经理是团队的一部分，协同力就是团队战斗力的影响因素之一。如果团队成员有共同的产品理念，共同的工作方法和流程，大家就比较容易齐心协力，融合成一个强大的整体。
总而言之，知识体系并不是什么神秘的东西，产品经理的整个工作过程都可以用本书的内容去解释。如果我们能持续不断地完善自己的知识体系，就能获取更多信息、更多灵感。这个过程能让我们的知识体系更加完备。
何文彬，《商业产品经理：腾讯教我的产品工作思维》的作者
刚开始做产品经理时，我连最基本的独立访客（Unique Visitor，UV）、日活跃用户（Daily Active User，DAU）等名词都不知道，很长一段时间内我对产品经理所需要的知识、技能等的认识都处于混乱和模糊的状态，甚至不知道自己处于职业生涯的哪个阶段。那时候，求知若渴的我一边怀着极大的热情在公司做产品项目，一边利用业余时间在“人人都是产品经理”等网站上阅读各种文章，通过理论联系实践，花了大概一年的时间，才勉强搭建了非常粗轮廓的知识体系，才了解了产品经理的工作内容。
读完本书，在感叹内容齐全的同时，我也羡慕“产品新人”能直接阅读和借鉴书中的知识体系。本书可以在一定程度上让读者绕开我曾经走过的弯路，为产品知识体系的搭建和职业道路上的进阶节省更多的时间。
产品经理这个职业最初诞生于市场，高校并没有开设相关的专业和课程。如今虽然其价值不断地被市场认可和强化，产品经理已经成为不可缺少的一种职业，但是整个行业对产品经理所需要的知识、技能等还没有统一的标准和规范。大部分读者可能遇到过我曾经作为产品新人时遇到的问题。对于刚进入一个行业的新人来说，如果没有一个完整的知识体系来指导他的学习和成长，那么他在职业初期一定是迷茫的，他的成长一定是缓慢的。
同时，整个行业对产品经理知识体系的非标准化，导致“人人都是产品经理”这个口号一度成为行业内的笑谈。当初说这句话的人原意并非如此，但是在信息碎片化的时代，这句话的真实含义确实被严重地扭曲了。2020年6月，腾讯公司内部对产品经理这一职位进行了规范界定，将一定级别以下的产品经理改名为产品策划人员或者产品运营人员。早期大量涌入的那些不具备上升实力的产品经理被淘汰了，所谓的“人人都是产品经理”的时代结束了，整个行业逐渐恢复理性。在未来，产品经理一定会有严格的职业准入门槛、完整的知识体系、明确的技能要求，以及成熟的能力模型，而本书让我看到了这样的未来。
行业内的前辈先后写了不少产品类的图书，却一直没有一本按照流程详细介绍产品经理知识体系的书。看完本书，我的内心是激动的，这不就是曾经作为新人的我非常想看到的书吗？我坚定地相信，本书一定能帮助到需要了解、搭建和完善自己产品知识体系的读者。
我关注作者的公众号两年多，看过他的很多文章，它们可谓“篇篇原创”，写得很有深度。他邀请我写推荐序时，我又惊又喜。很荣幸受邀提前拜读了本书，即使我已经入行好几年，也依然能从本书中获得大量启发，同时对我自身的知识体系做了一次完美的迭代更新。因此我强烈推荐本书，相信你在阅读本书之后，一定会有所收获、有所成长。
詹涵，“人人都是产品经理”专栏作家
说来挺有趣，我当初选择成为一名产品经理最直接的原因竟然是一个比喻。在《乔布斯传》里，乔布斯把产品经理比喻成一个交响乐团的指挥家，他指挥着乐团成员演奏动人的作品。
从那个时候起，“指挥家”的形象就在我的心中埋下了种子，我希望自己大学毕业后能成为一名产品经理，设计出优秀的产品来改变世界。时至今日，虽然我当初的想法稚嫩，但是它点燃了自己产品经理职业生涯的火种，这粒种子值得长久地守护。
工作后不久，基于平时对产品工作的思考和总结，我开始写一些文章，并将其发表在“人人都是产品经理”网站以及自己的微信公众号上，至今已经有了几十万次的阅读量。一些读者留言，希望我可以写一本书来系统地介绍产品经理的基础知识体系和能力模型等相关内容。受到读者的认可是一件让我很开心的事情。其实我一直有写书的想法，通过图书传播经验，从而影响一些人，是一件很令人兴奋的事情。
于是，2020年年初，我便开始投入本书的写作。这既是对自己产品经理工作和学习的一个总结，也是给那些对我寄予厚望的读者的一个交代。
写书就像做产品，读者就是用户，只有书的内容满足用户的需求，才能彰显其价值。在写作初期，我一直在想，处于职业成长阶段的产品经理到底想要阅读一本什么样的书，这也是我在构建本书的内容框架时思考最多的问题。结合自己的工作经历，我发现大多数产品经理在职业成长过程中存在以下3个方面的学习需求。
所以，本书的内容结构就是围绕着满足以上3个方面的需求来设计的。本书共16章。主要内容如下。
第1章首先介绍了用户、需求和产品这几个概念，然后讲述产品经理的角色定位、好产品的定义，以及产品经理的知识体系。
第2章主要介绍了如何撰写产品文档，展示了可以直接在工作中使用的文档模板。
第3章主要介绍了产品流程图的定义、作用和画法，并结合实际案例讲述了如何画好一般流程图和泳道流程图。
第4章不仅介绍了如何画好产品原型图，还讲述了常用的原型设计工具，并对产品原型设计经验进行了总结。
第5章介绍了业务架构图、功能架构图、信息架构图、混合架构图的画法。
第6章以用户研究与分析为核心，介绍了进行问卷调研与用户访谈以及构建用户画像的方法。
第7章以需求管理为核心，介绍了如何挖掘用户的真实需求，如何评估需求的价值、评估需求的优先级、管理需求、拆解需求，并详细说明了需求研发过程中和上线后产品经理应该做的事项。
第8章讨论了产品设计模型库的概念，完整性、高内聚低耦合等设计原则，以及交互设计定律和产品分析方法。
第9章总结了数据分析的方法，并讨论了常用数据指标、维度、漏斗模型、AARRR模型、RARRA模型、埋点技术与无埋点技术。
第10章介绍了产品、业务、技术三者的关系，讲解了产品思维和技术思维的差异，讨论了产品经理如何学习基本的技术知识并培养技术思维，如何更好地与技术人员进行沟通和协作。
第11章讲解了产品经理需要具备项目管理能力的原因，对瀑布模型和敏捷模型进行了说明，并对如何创建完整的需求、如何设计完整的项目流、基于TAPD的项目管理工具，以及管理跨部门协作的项目的方法进行了详细介绍。
第12章主要介绍了如何做好行业分析和商业分析。
第13章讲述了账号体系、CRM系统、权限体系、会员体系的产品设计思路，同时介绍了支付体系。
第14章主要介绍了产品经理工作中一些好的学习方法，以及一些职业进阶方法，帮助读者在更加有效地学习新知识的同时，更快地取得进步。
第15章主要介绍了产品经理的职业成长路径，同时对如何转行做产品经理，以及产品经理面试求职等问题进行了解答，还说明了产品经理的专业化和职业化要求，并提出了结构洞的产品职业进阶概念，最后介绍了从产品经理到产品总监的管理瓶颈。
第16章主要介绍了产品之外的一些方法和理论，包括如何理解学习和成长过程中的秩序和混乱，如何学习一个新领域的知识，如何克服VUCA时代的知识焦虑，如何甄别优秀的图书和课程，还介绍了以积极乐观的心态面对日常工作的方法。
在写作本书的初期，我一直有两种心态，对这两种心态的选择决定了本书会以一个怎样的内容框架来呈现。一种是“工人心态”，即以工人的心态写本书，就好像车间里的师傅传授一些个人的经验和方法给徒弟一样。在这种心态下，怎么做比为什么这样做更重要，只需拼凑平时工作过程中零碎的思考分析和经验总结，输出内容，并稍加分类以构成目录，即可成书。以这种心态写书，无须总结全面的知识体系，以及具体的产品知识和技能学习的方法论，这样做对我来说自然是轻松的。
但我内心更喜欢另一种心态——“学者心态”，即以学者的心态来完成这本书。工人心态更注重“1+1=2”的使用，注重对零散的经验和方法的总结，而学者心态更注重“1+1=2”的证明，注重整个知识体系的完整性。要构建从概念到基础、从基础到中阶、从中阶到高阶，以及职业和成长这样的结构，写作自然是不易的，但我始终觉得，无论是对自己还是对读者来说，用这样的心态写作都是更有价值的。
1927年，美国宝洁公司设置了产品经理（product manager）的职业，这标志着产品经理诞生于商业和市场，整个知识和技能体系都在行业、商业和市场的驱动下发展。就像电子商务一样，它最初诞生于商业和市场，但后期在高校中开设了电子商务专业，并向社会输出电子商务专业的人才。
因此，我始终对未来抱有一种不成熟的期待，假如产品经理所需要的整个知识体系最终形成一门学科——“产品学”，能像“电子商务”一样作为高校的一门主修或选修课程，那么这门课程一定需要教科书，到那时候，产品、需求、用户这些概念就不能只停留在大家都明白即可的基础上了，一定需要严谨地定义和规范地使用。同时，大量严格定义的产品概念、完整的产品理论、科学的用户研究方法、严谨的需求分析方法、系统的产品设计方法，以及完整的产品经理工作技能模型会出现在教科书上。这是一个诞生于商业和市场并在组织分工过程中形成的泛化的知识体系，该知识体系逐渐学术化，最终专业化。
也许读者在阅读本书时也会有两种心态：一种是“工人心态”，只关心经验、技巧和方法的习得，不关心这些知识内在的机制，对这些知识的要求是实用就行；另一种是“学者心态”，抱着求知、解惑、追智的心态来阅读本书，以塑造自己的产品知识体系为目的。
我更希望读者以学者心态来阅读本书，以学者心态来学习产品知识，从短期来看，这在实用性层面也许没有明显的优势，但是这种在学习过程中体现出的溯源精神、求知精神、追智精神一定会潜移默化地影响我们的学习心态、学习方法以及学习习惯，也必将在职业成长这个长期的过程中体现出它的价值。
同时，我希望未来的“产品学”能和项目管理学、市场营销学、软件工程学等学科一样，成为一种工具，培养学生的专业知识，并帮助学生形成这门学科的知识体系所带来的思维方式。学习产品学的读者大学毕业后并非要做产品经理，但是他们一定很懂产品，具备用户视角、产品思维以及商业格局；学习软件工程学的读者大学毕业后不一定要做程序员，但是软件工程方面的知识与设计思想注定会影响他们的思维方式，让他们对这个世界的认识更加多维。
产品经理是一个有趣的职业，从中可以学到多样的知识，并培养自己多元的能力。产品之路是一条充满创造和创新的道路，是一条需要不断地学习才能走下去的道路。希望正在读这本书的产品经理和想成为产品经理的读者重视产品思维和产品观，以学者心态作为学习和成长的武器，让优秀成为一种常态。本书难免疏漏之处，还望各位读者雅正。
首先要感谢我的家人一直以来对我的支持和鼓励，让我有条件、有信心专注于自己想做的事情，让我无论是在工作还是在生活中，遇到再大的困难和挫折，都能从容勇敢地去面对。
其次，写书的过程是费时且费心的。一方面，要在一个宏大的知识体系中搭建一个完整的结构，需要不断地学习、研究，谨慎求证，这个过程要感谢任明、王玉成、孟天林和“大梨”等行业前辈的帮助与指导。另一方面，要进行多次的修改和校对，不断地让一本书的内容结构和语言描述趋于完美，这个过程要感谢人民邮电出版社的各位编辑。
另外，还要感谢在工作中帮助过我的领导、同事，在梳理整个产品经理的知识体系的过程中，他们分享的很多方法、观点以及经验在很大程度上帮助我丰富了本书的内容，完善了本书的结构。
本书由异步社区出品，社区（https://www.epubit.com/）为您提供后续服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，单击“提交勘误”，输入勘误信息，单击“提交”按钮即可，如下图所示。本书的作者和编辑会对您提交的勘误信息进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区投稿（直接访问www.epubit.com/contribute即可）。
如果您所在的学校、培训机构或企业想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接通过邮件发送给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社几十年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的Logo。异步图书的出版领域包括软件开发、大数据、人工智能、测试、前端、网络技术等。
异步社区
微信服务号
如果把产品经理所需要的知识体系称作一门学科，可以叫作“产品学”，那么用户、需求和产品这3个概念是构建整个学科的元概念。所谓元概念，就是起到支撑整个学科知识体系作用的基本概念。若干个元概念就可以衍生出整个知识体系，两者的关系就好像“加减乘除”之于数学，“元素”之于化学，“力”之于经典物理学等。元概念如此重要，那么对于整个产品知识体系而言，用户、需求和产品这3个概念是怎么定义的呢？
在图1-1所示的用户-需求-产品关系模型中，3个元概念之间的关系被清晰地展示了出来，用户产生需求，产品基于需求被设计出来，从而服务于用户。需求决定了产品从哪里来，而用户决定了产品到哪里去。
用户-需求-产品关系模型清楚地定义了3个基本概念之间的关系，但并没有定义元概念本身。用户、需求和产品这些基本概念在百度百科、维基百科中有明确的定义，但这些定义都是基于特定的学科或者行业的，例如用户的定义基于互联网行业和IT行业，需求的定义基于经济学，产品的定义则基于经济学和营销学。
显然，这些基于特定的学科和行业所下的定义都不适用于产品知识体系。因为各行业对这3个概念的定义是相互独立的，只为自己特定的知识体系服务。而产品知识体系里的用户、需求和产品紧密关联，不能独立存在。当我们提到用户的时候，这个用户一定是基于一个产品，是属于某个产品的用户，这个产品可以是有形的，也可以是无形的，可以是已经设计完成的，也可以是在规划之中的。同理，当我们提到需求的时候，这个需求一定是基于用户的，是属于某一个用户或某一群用户的。当我们提到产品的时候，这个产品一定是基于用户需求设计出来的。
▲图1-1 用户-需求-产品关系模型
用户-需求-产品关系模型之所以不能给出3个元概念的明确定义，是因为它们之间是相互关联且依赖的，不能用用户来定义需求，又用需求来定义产品，最后再用产品来定义用户，这会陷入典型的“循环论证”，是无意义且无效的。
为了打破用户-需求-产品关系模型中的循环论证，我们在关系模型中引入“人/群体”这个概念。“人/群体”这个概念已在自然科学和社会科学中明确定义。这里的“人/群体”是一个集合名词，人/群体产生各种需求，根据不同的需求设计出不同的产品并服务用户，而用户就是群体中直接使用或潜在使用产品的人/群体。
在图1-2所示的新关系模型中，首先，由“人/群体”定义需求这个概念，需求是人/群体在生理或者心理上产生的某种需要和诉求。然后，用需求定义产品，产品是满足人/群体在生理或心理上的某种需要和诉求而被设计出来并服务用户的实体或虚拟物品。狭义的产品包括我们使用的计算机、手机、App、保险等，广义的产品还包括组织、地点、思想等。最后，用产品定义使用产品的用户，用户是群体中直接使用或潜在使用产品的人/群体。
▲图1-2 人/群体-用户-需求-产品关系模型
综上所述，在用户-需求-产品关系模型中，引入“人/群体”这个基本概念，能使得每个概念的定义都遵循一个完整的逻辑关系。至此，整个“产品学”知识体系下的3个元概念就被清晰地定义出来了。
在社会生活中，我们每个人都被赋予了多种多样的角色，这些定义好的角色指导着我们的行为，规范着我们的生活和工作。在社会上，我们可能是医生、教师、工人或学生等角色；在家里，我们可能是子女、配偶、父母等角色；在公司中，我们可能是员工、领导等角色。
但即使拥有同样的角色，每个人也会对自己有不同的角色定位。同一个角色在每个人心中的定位不同，就必然导致不同个体在具体实践活动中的动机和目的不同。
产品经理这个职业也是如此。从不同的视角来看，产品经理这个角色有不同的定位，如图1-3所示。下面分别从产品视角、职业视角、自我视角3个方面来分析总结产品经理的角色定位。
▲图1-3 产品经理的角色定位
从产品视角来看，产品经理首先是一个用户研究员，他不仅要懂用户，要理解用户，要会做用户调研和访谈，还要会构建用户画像。其次，他是一个需求分析师，要能挖掘用户的真实需求，能对用户的需求进行价值判断。最后，他是一个产品设计师，要会画原型图、会写文档，会进行产品设计的评审和交付。
从职业视角来看，产品经理首先是一个需求管理者，内外部所有的需求都会汇集到产品经理这里，他需要对各种需求进行真伪鉴别、价值评估、优先级排序、评审、研发、上线等管理工作。其次，他是一个产品管理者，负责多个产品线，或者一个产品的多个版本的规划。最后，他是一个项目管理者，从需求分析到产品设计，再到产品研发和交付上线，这个过程中的所有活动过程称为项目，产品经理要负责整个过程中的需求分析、方案评审、研发追踪、上线验收等一系列事项。
从自我视角来看，产品经理或者是一个产品工作者，负责分析用户需求，然后把有价值的需求设计成产品；或者是一个产品缔造者，与完成本职工作相比，还融入了一些自我价值实现的需求。乔布斯把产品经理比喻成一个交响乐团的指挥家，指挥着乐团的成员，为观众演奏动人的作品，这也是把产品经理定位成一个缔造者。还有一些产品经理把自己定位成用产品改变世界的人。
以上从3种不同的视角来看产品经理这个角色的定位。对比这3种定位，从长远来看，真正能拉开人与人之间的差距的，其实是自我视角的定位差异。一个定位自己是一个园丁的老师与一个定位自己是一个教育工作者的老师相比，他们的教学任务和本职工作是一样的，但是前者一定会给予学生更多的关心和关爱。同样，一个定位自己是乐团指挥家、用产品改变世界的人的产品经理，一定会在产品上投入更多的热情。而这些热情随着时间的积累必然会潜移默化地对其职业成长和发展产生积极的影响。
希望产品经理能对自己的职业角色有更高的定位，而不是仅定位自己是一个听需求、画原型、设计功能、推动产品上线的产品经理。希望大家能找准自己内心的高价值的产品经理角色定位并将其作为原动力，在漫长的职业生涯里，驱动自己进阶和成长。
到底什么样的产品才算是一个好产品？站在不同的视角和维度看，人们会有多种理解。有的人认为，满足用户需求，让用户觉得有用的产品就是好产品；有的人认为，用户体验好，实际使用感受超出预期的产品就是好产品；有的人认为，能给公司带来利润，具备持续发展能力的产品才是好产品。
总结下来，3个基本要素决定了一个产品是否会被视为一个好产品，如图1-4所示。这3个基本要素分别是有用、好用、有价值，下文将对这3个基本要素做详细介绍。
▲图1-4 好产品的3个基本要素
有用这个要素规定了产品一定是基于真实需求被设计出来的，能满足用户的需求，是用户需要的。
好用这个要素在有用的基础上，更加强调用户体验。好用的产品不仅能满足用户的实际需求，还能给用户带来超乎预期的使用体验。如果说一个产品做到60分是及格，可以满足用户的基本需求，那么把产品做到80分，甚至100分，就是在“好用”这个层面上努力了。
这里的价值，并非指的是产品的“使用价值”，因为“使用价值”已经包含在“有用”这个要素中了。这里的价值强调的是产品的商业价值。
对于一个好产品加一个坏的商业模式和一个好的商业模式加一个坏产品，你会选择哪个？
想必大多数人会选择后者。显然，我们都认同一个好的商业模式比一个好产品更重要。产品再怎么有用、好用，如果没有一个好的商业模式支撑，基本不可能成功。
而好的商业模式不仅强调产品的有用和好用，还会在此基础上考量产品本身满足的是否是刚性需求、是否是高频需求、是否是大众需求、具备多大的市场，以及产品的渠道通路、竞争格局、商业变现、商业增值等一系列其他要素。
所以，上文中“好产品和坏的商业模式”中的“好产品”只能称为狭义的“好产品”，而广义的“好产品”的定义本身就包含了商业模式的范畴。一般我们称赞一个好产品，会形容其“物美价廉”，“物美”就突出了产品的“好用”和“有用”，而“价廉”则需要一系列的商业闭环（例如生产销售闭环、成本利润闭环、运营营销闭环，增长增值闭环）的支撑。所以，“价廉”实际上强调的是产品背后的商业逻辑闭环。
这个世界上除少数类似于阳光和空气这样的自然物品（事实上，阳光和空气并不属于“产品”，虽然阳光和空气满足了人类的生理需求，但是从这种生理需求到阳光和空气之间并不存在一个人为的设计，在经济学中，它们也不被定义为商品）外，大多数为满足人们某种需求而被设计出来的产品遵守一个基本的逻辑，那就是“商业逻辑”。
为什么说商业需求文档（Business Requirement Document，BRD）是三大文档（商业需求文档、管理需求文档、产品需求文档）之首？因为一款产品在设计初期，最重要的就是要让它符合基本的商业逻辑。一些产品即使具有有用、好用的特征，但是投入产出比太高，也不具备商业上的可行性，例如乔布斯的Lisa计算机。Lisa计算机是一款具有划时代意义的计算机，可以说没有Lisa计算机就没有Macintosh计算机（在开发Mac计算机的早期，很多系统软件是在Lisa计算机上设计的）。它是具有16位CPU、鼠标、硬盘，以及支持图形用户界面和多任务的操作系统。Lisa计算机在当时全世界的计算机行业中处于至少领先5年的水平，但是高昂的价格使其成为一款夭折的产品。物即使再美，但价不廉，也违背了商业逻辑，因此Lisa计算机不具备商业价值，亦不能被称为好产品。
好产品必须具备三大基本要素——有用、好用、有价值，三者缺一不可。若违背了“有用”的要素，就好像为了一个伪需求去设计一个产品，结果将其投放到市场上，发现找不到用户。若违背了“好用”的要素，则产品的使用体验很差，很快会被其他竞品超越，最终被淘汰。若违背了“有价值”的要素，就像上文中提到的Lisa计算机一样，产品做得再好，但违背了基本的商业逻辑，用户都买不起，“有用”和“好用”对于用户来说又有什么意义呢？
很多看似复杂的知识体系往往是建立在一些基础的概念或理论之上的，了解并掌握支撑整个知识体系的基本概念和理论，是打开这个知识体系大门最好的方法。例如，经典力学建立在“牛顿三大定律”的基础上，整个几何学建立在几条公理之上。
事实上，产品经理的知识体系也是建立在3个基本概念所形成的框架之上的，这个底层的框架支撑了整个产品知识体系的发生和发展，它就是前文中提到的用户-需求-产品框架。我们来看看整个产品知识体系是如何围绕这个基础框架展开的。
首先，围绕着用户这个基本概念，衍生出用户挖掘、用户分析、用户调研、用户访谈、用户画像等知识。
其次，围绕着需求这个概念，衍生出需求识别、需求分析、需求真伪评估、需求价值评估、需求评审、需求优先级评估、需求池管理等知识。
最后，围绕着产品这个基本概念，衍生出产品定位、产品分析（竞品分析）、行业分析、商业分析、产品设计、产品管理、产品数据分析等知识。
首先，从用户和需求的关系展开，用户产生需求，产品经理需要掌握挖掘用户需求并撰写用户需求分析报告等知识。
其次，从需求和产品的关系展开，从需求到产品的过程，指的是需求分析、产品设计，以及产品研发的过程。整个过程中，产品经理要掌握基础文档的撰写方法，以及产品原型图、流程图、架构图的画法等知识；在产品研发的过程中，产品经理需要和技术人员、设计人员、测试人员及运营人员等协作，所以也要掌握一定的技术、测试、设计、运营等知识。除此之外，产品经理还要掌握从需求分析到产品设计再到产品研发上线，整个过程中所需要的项目管理知识。
最后，从用户和产品的关系展开，产品经理不仅要掌握提升用户体验的知识，还要掌握产品上线后的数据分析、用户反馈、版本迭代等知识。
以上从几个基本概念和概念之间的关联关系衍生出的知识模块构成了产品经理所要掌握的产品知识体系的所有内容。细心的读者会发现，本书的内容结构也是基于这个基础框架而设计的。
无论是刚担任产品经理的读者，还是已经工作了好几年的产品经理，都可以试着用用户-产品-需求这样的基础框架，从基本概念和概念之间的关联关系出发，审视自己目前所掌握的产品知识，哪里不会补哪里，逐步构建属于自己的完整的产品知识体系。
文档撰写能力是产品经理必须具备的最基本的能力之一。在实际的产品工作中，产品经理要输出各种类型的文档，例如商业需求文档、市场需求文档、产品需求文档以及竞品分析文档等。写作本质上是把自己的思考进行文本化表达的过程，最终目的是让阅读对象清晰地阅读并理解文档的内容。撰写产品文档并不需要产品经理拥有很强的文字驾驭能力（当然，有这种能力更好），只要掌握基本的文档撰写方法和规范，就能写出合格的产品文档。
图2-1是产品经理在撰写产品文档的过程中可以使用的一套完整的产品文档撰写方法，这个方法有3个步骤，分别是定范围、选模板、守规范。本节将详细介绍如何利用这3个步骤撰写一篇产品文档。
当产品经理要撰写一个产品文档时，首先要定好产品文档的范围，通常要明确以下几点。
▲图2-1 撰写产品文档的基本方法
确定文档范围后，接下来进入文档正文的撰写阶段。先根据文档类型选择一个合适的模板，模板提供了一种通用的格式框架，文档输出者可以直接套用格式框架，无须重新设计，在提高文档输出效率的同时，这也在一定程度上使得不同时期、不同人输出的文档具备统一性和规范性。
而产品工作中的很多文档类型（例如产品经理经常需要写的三大文档，以及产品体验报告、用户调研报告、行业分析报告等）有比较固定的模板。产品经理在撰写文档时，只需要按照固定的模板填充需要的内容，就可以快速、高效地输出专业的文档。
规范化是产品经理在职业成长过程中需要具备的一项基本职业素质。规范包含的内容很多，小到文档撰写、原型设计的规范，大到用户调研、需求分析以及产品设计的规范。做事规范化是产品经理专业化的基本要求之一，文档撰写通常需要遵守以下几个规范。
产品文档标题的命名不仅要考虑标题是否可以准确表达文档的定位和类型，还要考虑标题名称是否会引起歧义。通用的命名规则为描述对象+版本号，例如，“CRM系统产品需求文档V1.0.0”文档通常用这个格式来命名，标题中加版本号的目的是记录整个文档在输出过程中的迭代过程。当然，如果输出的文档是最终版，且以后也不会再次修订，则无须添加版本号。
在文档撰写过程中，要注意文本表达的规范，尽量避免使用口语化的表达，如“我认为” “我觉得”“接下来我们”“那咱们”等表达句式。这种口语化的表达会降低文档的专业性和严谨性，也会给阅读对象留下不专业的印象。
一个文档经常会被修订多次才输出最终版，因此每次编辑结束的时候都需要进行版本的更新，以保证其他编辑者了解上个版本编辑过的内容，同时让阅读者能了解文档的更新历史。版本更新的内容包括版本号、修订人（当前版本的修订人）、修订时间（当前版本的修订时间）、修订内容（当前版本新增或删除了哪些内容）、备注（对当前版本的一些附加说明）等。
其中版本号是用来识别当前版本的命名方式，标准的版本号采用“VX.Y.Z”的格式。例如，V1.1.0中，V表示版本号，即Version Number；X、Y、Z 为非负的整数，X是主版本号，Y是次版本号，Z为修订号。首次发布的版本命名为V1.0.0，后期每更新一个版本，就在主版本号上加1。
以下是文档版本更新的一些通用规则。
最后，除按照以上几点要求规范自己的文档输出之外，读者还可以在平时的产品工作中不断地实践和积累，总结出一套属于自己的规范，为产品工作的专业化和职业化打好基础。
BRD、MRD和PRD是产品经理日常工作中接触最多的三大产品文档。三大产品文档整体符合做什么、为谁做、怎么做的文档定位，是从产品立项到投入研发的过程中，在不同阶段面对不同对象输出的需求说明文档。本节结合图2-2对三大产品文档的定义与作用进行详细介绍。
▲图2-2 三大产品文档图解
BRD（Business Requirement Document）叫作商业需求文档，是在整个产品生命周期中最早创建的文档，作用是描述整个项目的商业模式闭环。BRD以“做什么”来展开，汇报对象偏向于公司高层和整个项目团队，目的是在获得高层的支持的同时与整个团队达成产品商业目标的共识。
MRD（Market Requirement Document）叫作市场需求文档，在产品项目中属于“过程性”文档，是产品项目由准备阶段进入实施阶段时输出的文档，其作用是对BRD中规划的产品进行市场层面的说明。MRD主要写给市场和运营部门，以“为谁做”贯穿整个文档的主题，目的是描述市场格局以及给用户分群和画像。MRD在产品项目中起到一个“承上启下”的作用，向上是对不断积累的市场数据的整合和记录，向下是对后续工作的方向说明和工作指导。
PRD（Product Requirement Document）叫作产品需求文档，是产品项目从概念设计到原型设计的直接产物。PRD主要输出给产品研发部门，以“怎么做”贯穿整个文档的主题，目的是让研发人员按照文档的需求逻辑一步步开发出满足需求的产品。
以上介绍了三大产品文档的基本定义和作用，回答了What（是什么）和Why（为什么要写）的问题，本章接下来会分别介绍如何写好三大产品文档，回答How（如何写）的问题。
图2-3给出了一份标准的BRD模板，考虑到BRD的输出目的和展示对象，在对文档格式没有特定要求的情况下，一般采用PPT输出BRD。
BRD模板主要包括6个模块，分别是方案背景、方案预测、产品规划、盈利模式、收益和成本以及风险和对策。下文将介绍每个模块的详细内容。
▲图2-3 BRD模板
方案背景主要说明发现了什么需求，为了满足需求设计了什么样的方案，方案具备什么样的优势。其中具备的优势包括以下几种：
在BRD方案背景模块的描述中，要尽可能地提供多维度的优势作为论据，以说明产品方案的可行性。
方案预测分为方案阶段预测和未来价值预测两个部分。方案阶段预测主要描述方案所经历的阶段，以及描述每个阶段所要达成的阶段性目标。未来价值预测主要描述整个方案在未来完成后可能产生的商业价值。
产品规划模块主要包括需求逻辑产品化闭环和产品架构图两个部分，其中需求逻辑产品化闭环指的是方案背景中介绍的解决方案具体做出了什么样的产品，这个产品可以是一个CRM系统或者一个App等。
而产品架构图则主要介绍产品的设计架构，根据介绍需求，选择展示产品的业务架构图、功能架构图、信息架构图或者混合架构图。关于产品架构图的定义和画法会在第5章详细介绍。
盈利模式需要体现两个方面——产品盈利闭环和盈利数据。其中，产品盈利闭环主要介绍产品的盈利方式有哪些，以及这些方式是否具备可持续性。介绍产品盈利闭环的同时需要用盈利数据作为支撑，从而使盈利模式更加有说服力。
收益和成本也体现在两个方面——收益预估和成本预估。其中，收益预估需基于盈利模式中的盈利数据做更全面的描述，即这个产品方案有哪些盈利点，整个盈利模式可以产生多大的收益。成本预估则需要罗列出各种成本支出，包括但不限于方案执行过程中的各种成本，以及后期产生的运营和维护成本，最后还需要得出总的成本支出，作为投入产出比的计算依据。
风险与对策同样体现在两个方面——风险种类和应对方法。风险种类主要描述从方案立项到项目执行过程中所存在的风险。基于不同的方案背景，这些风险包括但不限于政策风险、行业风险、资本风险、经济风险、公司风险、市场风险、技术风险等。面对风险一般的应对方法包括但不限于接受、规避、降低、转移、共担等。在进行BRD风险与对策模块的介绍时，要根据具体的方案背景，找出可能存在的风险以及应对风险的方法。
图2-4展示了撰写MRD的通用模板，和BRD一样，在对文档格式没有特别要求的情况下，通常都使用PPT输出MRD。
整个文档框架主要分为4个模块，分别是市场说明、用户说明、产品说明、竞品说明。下文将对每个模块的内容做详细介绍。
▲图2-4 撰写MRD的通用模板
市场说明模块主要包含3个部分的内容，分别是市场规模、市场增速、市场潜力。
市场规模的大小直接决定了产品最终的利润大小，这也是整个MRD中最核心的模块。对于不同类型的产品，市场规模的描述方式也有所不同，直接产生现金流的产品一般用交易额来描述市场规模，而间接产生现金流的产品则通常用用户量来描述市场规模。
计算市场规模在时间维度上的变化，就可以得出市场的增速（值得注意的是，增速有正负之分）。在实际输出市场说明模块的内容时，建议将市场规模和市场增速放在一起用图表进行展示。
市场潜力预测是指在某种市场环境下，对市场需求所能达到的最大数值的测算。基于市场规模和市场增速，给出合理的市场潜力预测值。
用户说明模块主要包括5个部分，分别是用户定位、认知程度、用户画像、需求场景、用户分析总结。
在MRD中，用户定位最好能用一句话清晰地描述，例如淘宝的用户定位是18～65岁有网购需求的消费人群，keep的用户定位是有健身需求的大众人群，钉钉的用户定位是有办公需求的商业组织或个体。
认知程度通常是新兴产品或者行业需要调研分析的一个重要维度。例如，对于一些VR（Virtual Reality，虚拟现实）、AR（Augment Reality，增强现实）以及人工智能（Artificial Intelligence，AI）产品，认知程度要说明用户对新技术、新产品的态度以及预期，是否愿意接受和尝试。了解用户对产品的认知程度，在很大程度上可以帮助产品经理做前期的设计决策，以及中后期的营销、运营决策。
用户画像主要介绍用户的人群分布特征，例如性别分布、年龄分布、地区分布、职业分布、收入分布等。
需求场景主要描述用户与产品交互过程中需求发生的主场景，以及要描述清楚在该场景下产品是如何满足用户需求的。
最后对用户说明模块的整个内容与分析过程进行整理，形成完整的用户分析总结。
产品说明模块主要包括3个部分，分别是产品说明、产品架构、产品路线。
首先，产品说明部分要说明该产品的产品定位和产品核心目标。产品定位需要用形象且简洁的语言，准确地传达产品的核心能力和边界，例如，微信小程序定位自身是一种连接用户与服务的工具。通过简洁的短句传递产品的定位，产品说明对内可以明确产品的核心能力和发展导向，对外可以占领市场，提高用户对产品的认知度。
产品定位和产品核心目标都是对产品的能力与边界的描述，前者以静态视角描述产品是什么，后者以动态视角描述产品会怎样。例如，微信的核心目标是连接人与人，满足人们的社交需求；淘宝的核心目标是连接人与商品，满足人们的购物需求；百度的核心目标是连接人与信息，满足人们的搜索需求；钉钉的核心目标是连接人与工作，满足人们对办公和协作的高效率需求。
其次，MRD 中的产品架构和 BRD 中的产品架构是一样的，目的都是描述实体产品的设计框架，根据侧重点，选择展示产品业务架构、产品功能架构，或者产品混合架构等。产品架构图的定义和画法会在第5章详细介绍，这里不再赘述。
最后是产品路线部分，这部分主要描述从需求到产品需要经历哪些阶段，对此有一个明确的计划，例如常规的产品路线包含需求输出、产品方案设计、产品上线发布、产品启动、产品运营等阶段，MRD要说明每一个阶段的目标以及时间节点。
竞争说明主要分为4个部分，分别是竞争格局、代表性竞品分析、潜在替代品威胁、竞品分析总结。
竞争格局主要描述当前市场同行业内存在竞争关系的所有产品以及其所属公司的信息，将所有产品按照某个具有代表性的指标（例如市场份额、交易额、用户量）进行排名，以不同的竞争维度对比分析当前的竞争状况。一般的竞争维度包括产品获客的竞争、产品功能的竞争、用户体验的竞争、产品价格的竞争以及其他竞争等，根据不同竞争维度下的对比分析，总结出当前市场的竞争格局。
代表性竞品分析主要分析竞品的3个方面，分别是产品定位、产品核心目标、差异性对比。目的是针对一个或两个典型的竞品，分别分析这些竞品的产品定位和产品核心目标，从不同的维度分析竞品的优劣势，并和自己的产品进行对比，输出竞品分析报告。
潜在替代品威胁指的是当前市场上是否有自身产品的替代品或替代方案，如果有，要进行介绍说明，并分析替代品的威胁程度，以及给出应对方案，最后结合竞品分析的内容和分析结果进行整理和总结。
图2-5是撰写PRD的模板，整个模板框架主要分为6个部分，分别是基本规范、文档概述、产品说明、功能需求、非功能需求和附录。
前面介绍BRD和MRD时，建议采用PPT的表现形式来输出，而PRD的目的和阅读对象决定了它更适合用传统的Word文档形式来输出。本节将会对PRD的每个模块的内容做详细介绍。
▲图2-5 PRD的模板
基本规范模块包含3个部分——文档封面、文档目录、更新记录。文档封面尽量只包含简洁的标题和版本号，文档中注意添加页脚和页眉元素辅助说明内容。关于文档的撰写，建议使用Office软件自带的标题格式，这样完成后用户可以自动生成文档目录。文档更新记录指的是在文档迭代的过程中，每次改动需要进行版本号的变更，以及记录变更的内容。
文档概述模块主要分为4个部分，分别是背景概述、范围和边界、阅读对象、术语定义。其中背景概述主要描述整个项目的初始需求背景，目的是让未参与过项目的人能通过背景概述了解该项目。
范围和边界主要定义了项目的影响规模，包括产品边界、业务边界、运营边界、技术和人力资源边界等。阅读对象主要用来限制哪些组织或者个人可以阅读此文档，有利于控制文档的传播效率和查看权限。术语定义主要用来详细介绍文档中可能出现的专业术语，确保所有术语都有唯一的注解。
产品说明模块主要分为两个部分，分别是产品简介和产品流程。产品简介作为背景概述的补充，主要用于介绍产品的基本情况，包括产品定位、用户使用场景以及产品的功能介绍等。产品流程则提供核心功能的业务流程图以及操作流程图，以方便阅读者快速了解产品的核心流程。
功能需求是PRD的核心内容，主要用于向研发人员说明产品的实现逻辑，如图2-6所示。功能需求主要包括功能简介，用于对功能做简洁的描述；场景描述，用于描述功能的使用场景；功能优先级，用于明确这个功能的优先级；输入/前置条件，用于描述进行一个功能操作所需要的前置条件，例如收藏功能通常与账户体系关联，要使用此功能，需要登录才可以，所以用户已登录就是收藏功能的前置条件；需求描述，用于对原型和整个功能需求进行原型展示和详细描述；输出/后置条件，用于描述进行一个功能操作将产生的结果，例如，很多 App 有夜间模式，开启夜间模式是一个功能，这个功能的后置条件就是整个 App 的视觉风格变得适合夜间阅读，如果打开了夜间模式，但是 App 的视觉风格并没有变化，说明出了 Bug，则需要定位问题并修复；补充说明，用于对需求进行其他的解释说明。
非功能需求是对功能需求的辅助和补充，非功能需求一般包括但不限于技术需求、运营需求、财务法务需求、其他需求等。
附录指附在产品说明文档后与正文有关的其他文档或参考资料，是文档的说明或补充部分，并不是必需的。
▲图2-6 功能需求描述范例
