#20240304周-读书

AI summary

date

Mar 4, 2024

slug

newsletter-0304

status

Published

人人都是产品经理2.0

摘录

前言

一个产品从无到有的过程——想清楚、做出来、推出去，对应着互联网公司里三个最核心的岗位——产品、技术、运营。

产品经理最重要的能力是推己及人的同理心，以及同情共感的情商。

一位投资人前辈跟我说过——如果你不想仅仅做事，还想通过改变人来改变世界，有两种方式：第一，像现在这样，不断输出自己的总结、价值观与方法论，潜移默化地实施影响；第二，像乔布斯那样，做一个惊艳世人的产品，让世人自己去体会、总结。

初始：大话产品经理

产品经理思维方式和做事方法的核心：用心听，但不要照着做。

创造力、洞察力和对客户的感知力渐渐成为核心要素，而这些就是产品经理需要掌握的核心技能。

任何一个行业，从诞生到成熟，似乎都会经历从先重技术、抓生产制造，到重产品、抓创意设计，再到重运营、抓市场营销的过程。之后，再从一个成熟行业里诞生出更多新的、细分的行业，如此循环往复。

一看到问题，马上就想答案，这是典型的“学生”思维，因为我们所受的学校训练，绝大多数都是针对“经过简化的问题”：有确定的目标、完备的信息，有刚刚学过的解法，有标准答案……而职场中，面对的问题通常目标不明、信息片面、闻所未闻。特别对产品经理而言，各种用户提的问题，一般都是经过扭曲、有欺骗性的，要怎么解决也没有标准答案。

3.05m高的货车过3m高的山洞问题分析案例（多问问题）

为什么要过山洞？可能是因为装着一车西瓜，要运到山洞另外一侧的水果批发市场卖掉。所以，“过山洞”并不是目的本身。

提出这个问题的人是谁？是货车司机？我发现在绝大多数人的第一反应里，都觉得自己是司机、是货主、是批发市场的小老板，或者是路政部门的工作人员。角色不同，对解决方案的选择也会有差异。

是否有路可绕，绕路有多远？思路拓展一下，将问题转换为基于成本的考虑，成本涉及油费、时间，可能还有过路费。

过了山洞以后还有多远？如果还要跑一段高速，可能“放气”这一招的结果就很危险。

此事发生的频次是多少？如果经常发生，假设一个场景，这个山洞是几十年前造的，确实比较窄，如今经常有一些大车过不去，得绕路。这时候，也许“挖洞”扩建一下，反而变成了最应该做的事情，甚至新开路都值得。这叫“只做一次的事情找可行解，反复做的事情求最优解”。

产品经理碰到的实际问题，往往没有完美的方案，只有去用心研究，才能够找到相对合理的方案。

团队成员一般会分为以下三个角色。产品：让产品有用；技术：让产品可用；设计：让产品好用。

产品：关键词与分类

产品：解决某个问题的东西

某个：任何一个产品都没法解决所有问题。特别是在产品早期，要有针对性地满足某些用户的某些需求，要有明确定位。大包大揽是产品成功以后的结果，不是一开始的做法。

问题：理想与现实有差距，人们想缩小甚至消除这个差距，就会产生各种问题，用产品经理的话来说，就是有了用户需求场景。

用户：这个问题是谁的问题。
需求：问题的核心是什么。
场景：用户在什么情况，以及何时何地碰到这个问题。

东西：指有形的实物或无形的服务，一般是一个有目标的解决方案，包括常说的产品、功能、特性、服务、流程等。

客户（customer），指付钱买产品的人；终端用户（end user），指最终使用产品的人。

满足需求其实有三种办法：提高现实、降低期望、转移需求。

互联网从PC时代过渡到了移动时代

与PC产品更正式、更侧重工作场景相比，移动产品更随意、更侧重娱乐或生活场景。临时兴起的需求变多，需求也更加碎片化，经常要在短时间内快速满足很小的一个需求点。

用户场景从电脑屏幕前变成了生活中随时随地，有了新的使用时间、使用地点，需要更多地考虑用户使用产品时周围环境的因素。

产品经理都是分类控

从产品与用户的关系角度，分为三类：单点、单边、多边，其中多边又可以分为双边、三边等。

计算器是个典型的单点用户型产品。只要有一个用户使用，就能产生完整的用户价值。虽然启动简单，但没法形成网络效应，用户的转移成本很低。

电话是个典型的单边用户型产品，需要有一群人同时使用。使用这个产品的用户越多，每个用户的价值越大，产品也就有了网络效应，可以像黑洞一样把用户都吸引过来。

多边用户型产品一般都是平台级产品，需要几群不同的人一起使用才能产生价值。最典型的就是知乎这个问答网站——由提问者、回答者、围观者构成三边。少了任何一边都不行，可想而知有多难。但这样的产品一旦启动起来，惯性也更大，壁垒也更高，更难被干掉，而且市场也更倾向于集中，更容易出现垄断巨头。

从用户需求角度，把产品分为6大类：工具、内容、社交、交易、平台、游戏。

小结一条常见的产品发展路径：从一个小工具单点启动，快速获取用户，然后让这些用户彼此吸引，留下个人信息和用户关系，转社交，黏住他们；或者从内容转社交，建立互动探讨的机制；接着设法转交易，给他们卖一些符合调性的东西；继而引入各种合作方，成为平台……越往后想象空间越大。

用户类型角度：2B（to Business）与2C（to Customer）；2G，面向政府（Government）；2D，面向开发者（Developer）

企业vs个人：目标用户不同，2C的产品是个人用，2B的产品是企业使用，典型的如ERP及各种Saa S系统、协作工具、客服工具、HR财务系统等。

群体vs个体：一个B2B供应链的工具、平台，需要上下游一起用，才能产生效果。

工作vs生活：2B的产品是生产资料，2C的产品是生活资料。2B重商业价值，2C重用户体验。

产品形态角度

BS结构（Browser-Server结构）：对研发团队来说，大部分工作在服务端，或者说云端，客户端借助一个浏览器来做展示。这种产品特别敢于尝试新功能，有问题只需要在服务端修改即可搞定。它的研发过程相对简单，最大的优势就是“快”；跨平台

CS结构（Client-Server结构）：需要安装的客户端，还会有一个服务端，手机里的App、电脑里安装的软件就是这种。这种产品出了问题，经常需要改客户端，那就得重新通过渠道发安装包，用户还得升级后才能改正。

软硬结合：除了软件部分，还有硬件实体。比如各种手环、智能家居的电器。它对质量的要求更高，如果硬件上有Bug，要么召回，要么只能变废品。所以，有了硬件部分的产品，更新换代的速度会明显降下来，能做到6个月左右升级一次就已经很快了。

大实体：有软硬件更有服务。

概念：提出与筛选

产品概念提出的几个关键要素

核心用户：产品目标用户中最重要的用户是谁，表达为一个抽象的人群。核心用户定义得越精准，产品设计、推广等过程中的目标将越明确。

刚性需求：Ta们碰到最痛的痛点是什么。刚性需求要满足下面三个条件：真实、刚需、高频。

典型场景：这些痛点最常出现在怎样的生活、工作情况下。在某种情景下、某时某刻，用户能想到，最好是能第一个想到你的产品。这个时刻就是产品的唤起点。

产品概念：用什么方案解决，用一个词、最多一句话概括你的解决方案。“你为了解决什么人的什么需求，做了什么东西？”

竞争优势：相对已有方案，有什么突出优势。

竞品：相似的产品→能满足同样需求的不同产品（从表层到深层需求）→所有消耗用户时间的产品。竞品分析不应该单单停留在对“产品功能”的分析上，还可以去寻找你这个功能背后要满足的“用户需求”，能解决同样“用户需求”的其他解决方案，也是竞品。这种分析，会给产品带来新思路、新方向。

互联网/手机上的所有产品都是竞品，竞争的是用户仅有的那点时间。

产品如何寻找切入点（淘宝首页分析案例）

确定这个产品的核心用户

做用户细分，列出可能与淘宝首页发生关系的各种用户：买家、卖家、合作伙伴（即服务买卖方的服务商）、淘宝员工、竞争对手、机器爬虫，等等。

判断每种用户的价值，排个优先级。这个例子比较简单，显然是“买家”最重要（整个淘宝谁更重要很难说，但首页一定是买家更重要）。

判断“买家”这个用户群体的粒度是否足够细。如果够细，到此为止，如果不够，回到第一步再细分，并循环这三步。

确定这批核心用户的刚性需求和典型场景

类似地列出新手买家的各种需求：逛、购物、学习如何使用淘宝等。举个例子说明一下“逛”，“逛”不等于无目的的购物，而是“我没打算在淘宝买××，但我想来看看商家的底价，以及别人怎么评价这个东西”这类场景。

对这些需求做价值判断。这个例子中，我们优先满足“购物”。

判断“购物”这个需求场景的粒度是否足够细。如果够细，到此为止，如果不够，回到第一步再细分，并循环这三步。

寻找切入点，乃至后续的精细化运营的关键就是要对用户进行细分，所以，从目标用户中一层一层找到核心用户，是产品经理非常关键的一项基本技能。

如果产品的用户是多边的，先根据不同角色分类

新人、中间用户和专家

根据人口统计信息（包括年龄、性别、职业、所在地、消费水平等）

根据产品的业务场景

最外面一层的潜在用户，指向将来的想象空间与发展天花板；临近一层的目标用户，指所有现在能跟产品发生关系的用户群体；下一层的核心用户，指目标用户中最重要的那个群体；最里面一层的种子用户，指核心用户中最早接触的那一小批用户，通常是一些具象的、我们认识的个体。

种子用户是受你要解决的那个问题困扰最深的一小群人，最早的一批用户，通常是某种意义上的熟人，你很清楚每个个体姓甚名谁，他们也常被叫作“天使用户”、“铁粉”、“用户顾问”。

做产品要顺势而为。这个势，说大点是行业的浪潮、公司和产品的基因，说小点是用户群体的特质、需求的特性、场景的特点。

对一类用户、需求、场景的深入定制，一方面可以成就一个产品，成为对手进入的壁垒，另一方面，这堵墙也有可能成为这个产品的牢笼。

需求：采集与用户研究

产品经理理解用户需求的过程，并不违背人类认知新事物的一般规律——从观点到行为，再从行为到观点，一样会从定性到定量，再从定量到定性，以实现螺旋式上升，使了解和证实在不断迭代中得到进化。

完整需求采集（淘宝产品案例）

产品规划阶段：听用户“定性地说”，确定产品方向（做什么）；随机抽样了40个用户做访谈，据此写出需求列表。

项目早期：听用户“定量地说”，确定需求优先级（先做什么）；投放了20万份调查问卷，确定了需求优先级的排序。当然，这只是确定优先级的辅助手段，最终做什么，还是由产品经理决定。

项目实施过程：看用户“定性地做”，确定要先实现的那几个需求应该怎么做；设计的同时完成可用性测试，其间陆续找了10个用户来验证。

上线后的优化阶段：看用户“定量地做”，根据产品的用户使用情况做数据分析，不断地改进产品。

作为一个具备很多专业知识的产品经理，只有能做到秒变小白，回滚到自己完全不了解产品的心理状态，亲自去体会临场感，才能避免做出很多坑用户的产品。而最好的体会临场感的方式，就是到用户发生需求的场景里去。

腾讯的10/100/1000，相信很多产品经理都听说过：产品经理每个月必须做10个用户调查，看100篇用户写的相关文章，处理1000个用户反馈。其实不用纠结数字和形式，关键是要保持和用户接触的强度。

需求的三种深度

第一种深度——观点和行为。表面能听到、能看到的东西，一般是通过用户怎么说、怎么做直接表现出来。如果只到这个层次，是做不好产品经理的。

第二种深度——目标和动机。用户为什么这么说、这么做？如果能找到目标和动机，会稍微好一些。但相对第三层，这里还是要实在一些。比如，用户说希望开始每天健身、跑步，目标是减肥。再往深层挖，其价值观层面的需求可能是为了在朋友面前呈现出积极向上、健康的自己。

第三种深度——人性和价值观。最底层的，最稳定的需求，人类社会诞生的千万年来，基本上没怎么变。如果能把需求挖掘到这个层次，就找到了产品最本质的用户价值。

移动互联时代，随着各种需求场景的碎片化，意味着用户，特别是C类用户的使用行为越来越“浅尝辄止”，成为专家的可能性越来越小。所以，各种产品对新手的友好越来越重要。

制定产品原则的前提是一个产品做过需求采集且信息足够充分。

转化：需求分析与Y模型

从“问题中心”的思路出发，只要能搞定问题，用什么方法就不再是最重要的事情。

从“方法中心”的思路出发，方法本身就是核心追求，至于这个方法究竟能解决哪些问题，可以暂不考虑。

在一个团队中，技术人员的思维侧重方法中心，业务人员的思维侧重问题中心，而产品人员则要融合这两种思维——需要先“问题中心”，尽快找到“用户需求”，回答Why和What；然后“方法中心”，最终设计出“产品功能”来回答How。

“1”是用户需求场景，经常简单说成用户需求。这是起点，是表象，是需求的第一种深度——观点和行为。

“2”是用户需求背后的目标和动机，是需求的第二种深度，产品经理在思考用户目标时也要综合考虑公司、产品的目标。

“3”是产品功能，是解决方案，是实施人员能看懂的描述。

“4”是人性，或者说价值观，是需求的第三种深度，是需求的本质。

Y模型的不同阶段，各自需要回答的一些问题，可以总结为6个W和2个H。

“1”这个阶段的问题主要是Who（用户）、What（需求）和Where/When（场景）。

“1”到“2”和“2”到“4”这个阶段，对应上一章提到的需求的三种深度。其间，要回答Why：不停地往下深挖需求。当然，有些细碎的用户需求，不一定会挖到“4”，所以“2”到“4”是虚线。

“4”到“2”再到“3”的过程中要想清楚“How”：问题怎么解决。

“3”这个点，要回答Which和How many。Which是指选哪一个方案，做哪一个功能，这背后其实是对价值的判断，比如怎么评估性价比和优先级。How many是指这一次做多少个功能，考验的是对迭代周期、MVP的把控。

和任何一个市场一样，汽车也经历了“从无到有”阶段拼功能、拼价格、拼质量等，以及“从有到优”阶段拼个性、拼服务、拼体验、拼品牌等的完整过程。

我们没法创造需求，只能创造出用户没见过的解决方案，从而更好地满足需求。

需求分析可以分为两大步骤。先是“1→2→4”，要深入，尽可能洞察透彻；而“4→2→3”则要浅出，力争给出尽可能简单的方案。

从“Y模型”的角度来诠释，攀梯术做的就是 “用户需求（A）→用户目标→人性与价值观（V）”的探究。对于“满足需求的产品”与“让用户尖叫的产品”，其区别就在于“1”（用户需求）和“3”（产品功能）是否与“4”（人性）之间建立起了关联。

攀梯术的基本手段，是通过一系列直接的探询式问句来洞察人性。

“为什么那个东西对你来说很重要”和“那个东西对你意味着什么”

情境唤起：通过让用户假想、回忆（使用产品的）情境，引起Ta的思考。

假设某物或某状态的缺失：让用户思考，某物/状态如果缺失了会怎样。

反面攀梯：用户无法说出做某事或想要某种感觉的原因时，可询问Ta不做某些事情或不想产生某种感觉的原因。

时间倒流：对比让用户反思过去，并与现状对比。

重定向——沉默或重述确认：用沉默或通过再次询问确认的方式来鼓励用户继续讲。

功能：细化与打包

功能的价值判断

广度：潜在用户数*单用户价值

频度：需求频次*单次复杂度

强度：不可替代、紧急、持久

在产品的不同阶段，对上面提到的广度、频度、强度，会有不同的侧重点。

KANO模型：对功能进行分类。基础功能、亮点功能、期望功能、无差别功能、反向功能（成本、收益）

确定“最小可行产品”，即MVP（Minimum Viable Product）。MVP是指的是满足“用户愿意用、最好愿意付费”、“用户易于使用”、“团队有能力实现”的最小功能集合，有些可以直接作为最终产品使用，有些甚至只能用来演示。

我们经常听到迭代、敏捷、试错、小步快跑、持续交付等这些说法，其实它们都表达了相似的价值观——尽可能早地改正错误。

执行：立项组队与研发生产

立项就意味着研发资源的正式投入。在这个节点的验证，叫原型验证。之前的验证，主要目的是验证用户需求抓得准不准，而本次验证则是考察用户是否认可解决方案。（POC（Proof of Concept）产品概念测试）

NPS（Net Promoter Score）指净推荐值，是一种计量用户将会向其他人推荐某产品可能性的指数。作为一种流行的用户忠诚度分析指标，它专注于用户口碑。NPS =（推荐者数 – 批评者数）/总样本数×100%

MRD：Market Requirements Document，市场需求文档，除了描述问题，解释为什么要做这个产品，还要给出解决方案。这个文档比较像产品规划和商业计划书（BP, Business Plan），是写给资源拥有方看的。（Why：为什么要做这个产品；What：产品MVP包含哪些功能及要做什么；How：项目计划及风险对策等）

PRD：Product Requirements Document，产品需求文档，是在项目过程中写给开发、测试、设计师看的，仔细描述产品功能要怎么做。

产品经理视角的项目流程

成长：规划与迭代

成功的产品都是相似的，因为每个环节、每一步都要做对，而失败的产品各有各的不同，因为任何一环出问题都会垮掉。

发射火箭：这意味着点火之后，做任何事情都无法干预发射结果了，这叫发射火箭的模式。

开车出门：边走边看，就是开车出门的模式。（做产品）

这两个比喻在书中是用来说明，在做产品，特别是互联网产品时，很难做到像发射火箭那样，在点火前收集到足够充分、完备的信息，准备好一切后再发布，也就说无法事先“规划”。我们面对的局面往往是信息很难收集、市场在快速变化，所以做产品更像是开车出门，有一个明确的目的地，然后走一步看一步，这就叫作“迭代”。

再看这一对词，你会发现规划的一步步来，是以自我为中心、以公司为中心的，是生产驱动的。而迭代的一步步来，是需求驱动的，是对用户反馈的不断响应，需要根据市场信息的变化来一步步调整。

规划是战略布局，是定方向，做正确的事；迭代是战术实施，是定走法，正确地做事，二者各有短长。

提问（怎么在规划PK会上，通过提问题的方式把别人干翻。）

1. 每次对方讲完PPT。为什么要做这件事，不做的话会“死人”吗？

2. 看到对方从总体KPI分解出的目标。这是用户的目标还是我们的目标，是不是老板的目标，老板换了怎么办？

3. 看到对方从用户需求出发，引用了一个观点。这个用户有普遍性吗，能代表多少人，这类用户对我们的优先级是什么？

4. 看到对方引用一个数据来证明自己的观点。数据来源是什么，什么时候获取的，是怎么采样的？

5. 看到对方的规划写得太实在，都是项目方案。为什么没有看到这个产品线的大图，5年后这个产品是什么样子，你实现整个图景的路径是什么？

6. 看到对方写得太虚，都是画大饼。未来的确很美好，但怎么实现？现在如果只做一件事，最重要的是什么？你打算怎么做？

7. 看到一个运营方案需要资金预算。你能给出量化指标吗，ROI是多少，这笔钱真的能用在最看重的用户身上吗，会不会被不投钱就已经很活跃的用户花掉？

8. 看到要做的事情太多。这么多事情，你打算组建多少人的团队，他们都需要什么能力，怎么分工？如果只给你两个人，怎么办？

9. 看到要做的东西真的很吸引人。实现路上会碰到的最大问题是什么，你打算怎么解决？需要大家怎么配合你，你打算如何说服各个部门都来帮你？

10. 看到具体的项目。你这些项目需要占用的开发资源有多少，如何给技术同学带来成长和成就感？

通过问答的方式，可以提升思考的深度。

如何合理而科学地加快速度呢？答案就是低成本验证。低成本验证的理念，本质上和迭代的思路完全一致：在一个快速变化的环境下，不断地用最少的时间、成本去获取市场反馈，不断修正前进方向。

运营：先验证再扩展

如果一定要有所区分的话，那么产品经理的职责是将产品做出来，保证其“有用”，而运营的职责是将产品推出去，保证“有人用”。

产品希望知道的是，这个解决方案背后的那个问题，希望由产品来做把用户需求转化为产品功能这件事，因为这才是产品经理的核心职责，而细化功能、写PRD什么的，其实并不是关键。

从企业发展层面来看，依次要经历定位、需求、产品、流量、用户、收入、盈利、品牌这些阶段。对应要做的事情有：给产品定位→采集需求回来分析→做产品功能→产品上市以后要获取流量→把流量转化成有价值的用户→从用户身上获取收入→实现盈利→沉淀为品牌。

案例：商业模式、创新与行业

创新需要满足两个条件：市场有需求，技术能实现。

蜕变：从产品助理到CEO

如果你每天的工作都是写PRD、画原型、做Demo的话，那基本就是刚刚入门。你接到的是一个相对明确的任务，要能听懂，所以需要不少领域知识；要产出给技术人员看的需求文档，所以要懂点技术；要制作给设计人员看的原型，所以要懂点设计，这都是入门的基本功。

完美，不是无一分可增，而是无一分可减。

百度可以不注册就使用，不用知道你是谁，但技术驱动的中心化搜索，又能保证算法大权在握；阿里需要知道你是谁，依托各方利益交换形成商业模式，是一种运营驱动的“做生意”；腾讯不但知道你是谁，还要让个体之间互动，形成用共识来维护的集体社区，需要用产品来驱动。

好产品改变世界，产品经理改变产品，我们来改变产品经理。

生活中，处处皆产品，处处可用心。

以上内容仅供自己个人学习，如果介意烦请私信或留言。