1. 产品经理的问题域
- 定义:产品经理负责定义「解决谁的什么问题、为什么值得做、怎么算做对了」,而不是把功能做出来。
- 说人话:业主说要大阳台,其实想要的是晒太阳;产品经理先问清「你到底想解决什么」,而不是照着单子施工。
- 什么时候用:接到任何需求时,先分清自己是在定义问题,还是只在描述方案。
- 常见误区:把写文档、跟进度当成全部工作,忽略了问题本身是否成立。
- 证据等级:C
- 来源:行业通行做法
讲产品经理这一行最基础的那层东西:产品是什么、需求从哪来、用户为什么这么想、方案怎么比较、数据怎么看、技术大致怎么运转、生意怎么算账,以及在这些之上反复要用的思维模型。
这是一份知识底座,不是行动清单。 它不告诉你「今天该做什么」,而是让你在遇到一个具体问题时,知道它属于哪一类问题、有哪些现成的理论和框架可以用、容易错在哪里。
说明:基础理论这一层,证据等级差异很大。有严谨研究支撑的(认知负荷、损失厌恶、留存曲线形态一类)可以标 A;有行业调查或公开案例支持的标 B;更多是行业长期沉淀下来的通行做法与判断,只能标 C。凡涉及具体数字的地方都标了「待核实」,请以原始文献与你手上的数据为准——本书不编造数字,也不编造来源。
与《产品经理高性价比生存指南》的分工:生存指南回答「怎么做最划算」(成本、收益、证据等级),基本法回答「为什么会这样、底层的道理是什么」。前者是行动备选单,后者是查阅用的知识底座,两者互补、可对照阅读。
| 问题 | 去哪看 |
|---|---|
| 产品经理到底负责什么?和设计、研发、运营、项目经理怎么分工? | 1. 产品经理是什么 |
| 产品是什么?好产品凭什么好?工具型、平台型、内容型差在哪? | 2. 产品的基本常识 |
| 流量、存量、平台、网络效应、生态、监管,这些词到底什么意思? | 3. 互联网行业常识 |
| 需求是什么?用户说的和想要的为什么总不一样? | 4. 需求的本质 |
| 用户研究怎么做才有效?样本、提问、偏差怎么处理? | 5. 用户研究基础 |
| 用户为什么会这样操作?有哪些可复用的心理学与行为学结论? | 6. 用户行为的基础理论 |
| 怎么把一个模糊的机会,收敛成值得做的问题? | 7. 机会识别与问题定义 |
| 信息架构、流程、状态、可用性、无障碍,基本盘是什么? | 8. 产品设计基础 |
| 优先级怎么排?哪些排序方法真的有用,哪些是自我安慰? | 9. 优先级与取舍 |
| MVP、假设、实验、A/B、灰度,方法论怎么用才不作废? | 10. 验证与实验方法论 |
| 北极星、指标体系、漏斗、留存、归因,怎么搭、怎么防作弊? | 11. 数据与指标体系 |
| 相关与因果、幸存者偏差、辛普森悖论,怎么不被数字骗? | 12. 统计与判断常识 |
| 前端后端、API、数据库、缓存、云、性能、安全,够用就行的常识有哪些? | 13. 技术与实现常识 |
| 大模型能做什么、不能做什么?提示、上下文、RAG、Agent 的边界在哪? | 14. AI 技术常识 |
| 敏捷、需求变更、评审、上线、回滚、事故复盘,行业通行做法是什么? | 15. 项目与交付常识 |
| PRD 的信息结构、向上汇报的逻辑、跨部门说服,底层规律是什么? | 16. 信息结构与表达 |
| 增长漏斗、激活、留存曲线、渠道、推荐分享,基本模型有哪些? | 17. 增长与留存基础 |
| 商业模式、定价、LTV/CAC、毛利、单位经济、ROI,账怎么算? | 18. 商业与财务常识 |
| 有哪些反复能用的思维模型?什么时候用哪一个? | 19. 思维模型工具箱 |
| 提问、判断、复盘、知识管理,这些元能力怎么练? | 20. 元能力 |
每条长这样:
3. 需求不是解决方案
- 定义:需求是用户想达成的结果,解决方案是达成结果的手段。
- 说人话:用户说「想要一把更快的锤子」,他真正想要的是把钉子钉进去;锤子只是他想到的手段。
- 什么时候用:拿到任何一句「我要 XX」时,先追问目标,再谈手段。
- 常见误区:把用户提的方案当成需求,直接排期实现,结果做一个「更快的锤子」而问题依旧。
- 证据等级:A
- 来源:Clayton Christensen 提出的 Jobs to Be Done 框架;需求工程领域对「需求 vs 方案」的通行区分。
| 等级 | 含义 |
|---|---|
| A | 有公开可查的研究、标准或权威文献支撑,能指出具体出处(如认知心理学实验、行业标准、原厂技术文档) |
| B | 有行业调查、公开案例或多方实践印证,但缺少稳定统一的结论 |
| C | 行业通行做法或一线经验沉淀,没有直接研究文献;本书中相当一部分条目属于这一级 |
为什么理论条目也会有 C 级:很多框架(优先级模型、增长模型、协作方法)来自咨询与行业实践,不是对照实验的产物;它们有用,但不是定律。C 级条目请结合自己的业务上下文判断,别照搬。
有争议的条目会标注「争议」并列出反方看法。凡引用具体数字的,都标「待核实」。本书不编造来源,也不编造 DOI。
附:工具表
book/ 目录下的 Markdown 文件即可,无依赖、无后端。12 条
这一章讲清楚产品经理这个岗位的边界:它解决什么问题、和谁分工、靠什么推动事情。它是全书的地基,后面所有方法都建立在对「产品经理到底做什么」的清晰认识上。 条目按从最基础到进阶排列。
11 条
这一章讲产品本身:它是什么、凭什么好、边界在哪。这里只谈「产品」这个概念,增长与商业的话题留给后面的章节。 条目按从最基础到进阶排列。
12 条
这一章讲互联网行业的底层规则:市场怎么长、平台怎么运作、钱从哪里来、被什么约束。理解这些,才不至于把行业规律当成个人能力。 条目按从最基础到进阶排列。
11 条
这一章讲需求本身:它是什么、为什么会伪装、为什么用户说的和想要的不一样。后面的用户研究、机会识别与优先级,都建立在对需求的理解之上。 条目按从最基础到进阶排列。
11 条
这一章讲怎么了解用户、同时不骗自己:研究该从哪一步开始,用哪些方法,以及那些最容易踩进去的偏差。它承接前面讲的需求概念,也为后面判断机会提供依据。 条目按从最基础到进阶排列。
12 条
这一章讲用户为什么会那样操作:大脑怎么理解界面、记忆和注意力如何工作、什么样的刺激会改变行为。它是设计、增长和体验优化共同的底层。 条目按从最基础到进阶排列。
11 条
这一章讲怎么把一句模糊的「我觉得这里有机会」收敛成一个值得投入、能被验证的问题。机会本身还只是现象,问题定义清楚之前,一切方案都是赌博。 条目按从最基础到进阶排列。
11 条
这一章讲产品设计的基本盘:怎么组织信息与导航、怎么安排流程和状态、怎么让界面符合人的操作习惯,以及简单的力量。它是把需求变成可用东西的手艺。 条目按从最基础到进阶排列。
11 条
这一章讲资源有限时怎么决定先做什么、后做什么,以及每种排序方法背后的假设和代价。优先级本质是一个取舍问题,排序工具只是把取舍摆到台面上。 条目按从最基础到进阶排列。
11 条
这一章讲怎么用尽量小的代价,尽早发现自己想错了。核心不是「证明自己对」,而是设计一个能明确判断对错的检验:先写下会被推翻的假设,再挑最省事的手段去撞它。 条目按从最基础到进阶排列。
11 条
这一章讲指标怎么搭、怎么看、怎么防止自己骗自己。指标不是越多越好,关键是先想清楚要回答什么问题,再选少数几个能反映真实变化的量,并警惕被指标牵着走。 条目按从最基础到进阶排列。
11 条
这一章讲怎么不被数字唬住。数据本身不会说话,怎么解读、拿什么作对照、看哪一层才是关键;下面这些是最容易踩的坑和最常用得上的几件工具。 条目按从最基础到进阶排列。
11 条
这一章讲产品经理够用的技术常识:不必会写代码,但要听得懂研发在说什么、估得出方案的大致代价和风险,把需求说得清、评审时问得到点子上。 条目按从最基础到进阶排列。
12 条
这一章讲大模型时代产品经理够用的常识:知道它擅长什么、为什么会答错、几种改造手段各适合什么场景,从而把它放对位置,而不是被术语和演示忽悠。 条目按从最基础到进阶排列。
11 条
这一章讲把事从想法送到线上的通行做法:怎么选交付方式、怎么管住范围和变更、怎么排期应对不确定、怎么上线和复盘。它关心的是「事情能不能稳定地做出来」。 条目按从最基础到进阶排列。
11 条
这一章讲把想法讲清楚的基本功:怎么组织结论和理由、怎么写文档和汇报、怎么在会里和跨部门把事推动。它解决的是「同样一件事,为什么有人讲得懂、有人讲不懂」。 条目按从最基础到进阶排列。
11 条
这一章讲增长这件事的基本盘:用户从哪来、怎么被激活、为什么留下或流失、花钱买来的增长划不划算。它不教具体话术,而是帮你理解增长背后的因果结构。 条目按从最基础到进阶排列。
11 条
这一章把生意背后的账讲成人话:钱从哪来、每个用户划不划算、为什么账上有利润却可能发不出工资、什么时候靠规模才更省。它不要求你会做账,但要求你算得清自己所在这门生意的账。 条目按从最基础到进阶排列。
12 条
这一章收集一批反复能用、跨领域通用的思考工具:它们不解决具体的业务问题,但能改变你看问题的角度。每个模型都标明它适合用在哪、不适合用在哪。 条目按从最基础到进阶排列。
11 条
这一章讲决定长期上限的底层能力:怎么问问题、怎么区分事实与判断、怎么从经历里学到东西、怎么把自己的注意力用在刀刃上。它们是产品技能下面的地基,决定了你能走多远。 条目按从最基础到进阶排列。
这张表按「你要解决的问题」来查方法,不按学科分类。遇到一个具体问题,先在左列找到最接近的那句话,再看中间该用什么方法,最后按右列的出处回到对应章节或文献。五个分组覆盖判断、用户、设计、数据、商业五类共 41 个常见场景。
| 你要解决的问题 | 用哪个方法 | 出处 |
|---|---|---|
| 判断一个需求是真是假 | 真需求与伪需求 | 第 4 章第 2 条 |
| 判断该不该做某个功能 | 「值不值得做」的判据清单 | 第 7 章第 10 条 |
| 手上十件事,先做哪个 | RICE 打分 | 第 9 章第 6 条 |
| 两个都想要,只能选一个 | 机会成本才是优先级的本质 | 第 9 章第 1 条 |
| 评估一个机会值不值得投入 | 机会空间与机会成本 | 第 7 章第 7 条 |
| 把模糊的想法写成清楚的问题 | 问题陈述的四要素 | 第 7 章第 1 条 |
| 判断现在是不是做它的时机 | 时机窗口:技术、政策、习惯 | 第 7 章第 9 条 |
| 结果不确定时,这个赌要不要下 | 概率思维与期望值 | 第 19 章第 3 条;《思考,快与慢》 |
| 你要解决的问题 | 用哪个方法 | 出处 |
|---|---|---|
| 用户说想要 A,其实需要 B | 需求与解决方案 | 第 4 章第 1 条 |
| 判断一个需求强不强、够不够频繁 | 需求强度与频次 | 第 4 章第 5 条 |
| 用户抱怨很多,怎么分清现象和问题 | 从现象到问题:抱怨不等于问题 | 第 7 章第 2 条 |
| 想找到问题的根本原因 | 5 Why 的用法与边界 | 第 7 章第 3 条 |
| 理解用户为什么会误操作 | 心智模型与概念模型 | 第 6 章第 1 条 |
| 设计一次有效的用户访谈 | 用户访谈的技术 | 第 5 章第 4 条 |
| 设计一份不误导人的问卷 | 问卷设计 | 第 5 章第 6 条 |
| 判断手里的样本是否有偏 | 样本的代表性与抽样偏误 | 第 5 章第 9 条 |
| 你要解决的问题 | 用哪个方法 | 出处 |
|---|---|---|
| 写一份开发看得懂的 PRD | PRD 的信息结构 | 第 16 章第 3 条;《金字塔原理》 |
| 主持一次需求评审 | 三类评审会 | 第 15 章第 7 条 |
| 设计产品的信息架构 | 信息架构 | 第 8 章第 1 条;《信息架构》 |
| 设计空态、加载态、错误态 | 状态设计 | 第 8 章第 4 条 |
| 判断这次上线风险大不大 | 上线与回滚 | 第 15 章第 9 条 |
| 做上线与回滚预案 | 上线与回滚 | 第 15 章第 9 条 |
| 一次故障之后怎么做复盘 | 事故分级与无指责复盘 | 第 15 章第 11 条 |
| 拆解一个技术方案值不值得做 | 技术方案评审该问的五个问题 | 第 13 章第 11 条 |
| 在提示、RAG、微调之间选 AI 方案 | 微调、提示与 RAG 的选择 | 第 14 章第 7 条 |
| 你要解决的问题 | 用哪个方法 | 出处 |
|---|---|---|
| 设计一次实验来验证假设 | MVP 的真实含义 | 第 10 章第 2 条;《精益创业》 |
| 判断手里的数据可不可信 | 埋点设计与数据质量 | 第 11 章第 8 条 |
| 从零搭一套指标体系 | 指标体系分层 | 第 11 章第 3 条 |
| 防止团队为了达标而作弊 | Goodhart 定律与指标作弊 | 第 11 章第 10 条 |
| 判断两组数据的差异是不是巧合 | p 值的正确读法 | 第 12 章第 10 条 |
| 判断两件事是相关还是因果 | 相关不等于因果 | 第 12 章第 1 条 |
| 指标突然变好,是真变好还是回归均值 | 回归均值 | 第 12 章第 8 条 |
| 评估 AI 输出的质量 | 评估方法(离线集、人工、模型打分) | 第 14 章第 9 条 |
| 你要解决的问题 | 用哪个方法 | 出处 |
|---|---|---|
| 算一笔生意值不值得做 | 单位经济与单用户模型 | 第 18 章第 5 条 |
| 一个新产品该定多少钱 | 定价逻辑:成本、价值、竞争 | 第 18 章第 3 条 |
| 算 LTV 与 CAC 这笔获客账 | LTV / CAC 与回本周期 | 第 18 章第 6 条 |
| 判断增长是不是健康的 | 留存曲线的三种形状 | 第 17 章第 3 条 |
| 一门生意的毛利够不够撑住 | 毛利、净利与毛利率 | 第 18 章第 8 条 |
| 公司赚钱却现金流紧张,为什么 | 现金流与账期 | 第 18 章第 9 条 |
| 增长是不是靠补贴堆出来的 | 补贴增长的代价 | 第 17 章第 9 条 |
| 新客增长和老客复购,先顾哪个 | 用户生命周期价值与分层 | 第 17 章第 10 条 |
这本表把全书 20 章出现的高频术语各用一句话说清,供随时查阅。
| 术语 | 一句话解释 |
|---|---|
| JTBD(Jobs to be Done) | 用户「雇佣」产品去完成某项任务,关注他要达成的进步而非产品本身。 |
| 真需求 / 伪需求 | 真需求对应真实、可复现的任务,伪需求只是表面诉求,换个场景就不成立。 |
| 用户画像(Persona) | 基于调研刻画出的典型用户原型,代表一类人的目标、行为与处境。 |
| 心智模型 | 用户对事物如何运作的既有理解,界面若与之不符就容易出错。 |
| 认知负荷 | 用户理解和使用产品时需要动用的脑力总量,越高越容易放弃。 |
| 双系统思维 | 人脑有快而直觉的系统一和慢而理性的系统二,多数决策由系统一完成。 |
| 损失厌恶 | 同样大小的损失带来的痛苦大于等量收益的快乐,人因此更怕失去。 |
| 锚定效应 | 人做判断时会过度依赖最先接触到的参照数字或信息。 |
| 默认效应 | 多数人会接受预设选项而不去修改,默认值即是最强的引导。 |
| 习惯回路 | 习惯由触发、行为、奖励三步循环形成,重复后变成自动动作。 |
| 峰终定律 | 人对一段体验的记忆由最强烈的瞬间和结尾决定,而非平均感受。 |
| 社会证明 | 人在不确定时倾向跟随他人的行为,比如看销量和评价做选择。 |
| 用户旅程地图 | 把用户从认知到使用的全过程与各阶段情绪画在同一张图上。 |
| 同理心地图 | 用「所说、所做、所想、所感」四个象限梳理用户当下的状态。 |
| 需求层次(马斯洛) | 把人的需求从生理、安全到自我实现分成由低到高的若干层级。 |
| Kano 模型 | 把需求分为基本型、期望型、兴奋型等,不同类型的投入回报不同。 |
| 用户分群 | 按目标或行为把用户划成若干组,避免用一套方案对待所有人。 |
| 痛点 | 用户在完成任务过程中遇到的阻碍、成本或不满,是需求的直接来源。 |
| 用户故事(User Story) | 用「作为某类用户,我想……以便……」句式表述需求的简短描述。 |
| 场景与上下文 | 用户使用产品的具体时间、地点、设备与目的,决定需求的具体形态。 |
| 术语 | 一句话解释 |
|---|---|
| 北极星指标(North Star Metric) | 产品当前阶段最该盯的单一指标,同时反映用户价值与长期方向。 |
| 指标体系分层 | 把指标按北极星、结果指标、过程指标分层,下层用来解释上层的变化。 |
| OMTM(唯一重要指标) | 某个阶段只挑一个最重要的指标驱动决策,其余仅作参考。 |
| 漏斗分析(Funnel Analysis) | 把有先后的流程拆成步骤,看每一步进入与流失的人数。 |
| 留存曲线(Retention Curve) | 按注册后第 N 天是否回访画出的曲线,反映产品留住用户的能力。 |
| 同期群分析(Cohort Analysis) | 按加入时间或渠道分组,逐组比较同一阶段表现,避免新老混算。 |
| 归因(Attribution) | 把一次转化的功劳分配给用户接触过的多个渠道,不同分法结论不同。 |
| Goodhart 定律 | 当一个指标变成目标,它就不再是好指标,因为人会为达标而做弊。 |
| 埋点 | 为采集数据在代码中设置的记录点,口径统一才能保证指标可用。 |
| AARRR | 获取、激活、留存、收入、推荐五个环节,按用户旅程组织增长指标。 |
| HEART | 愉悦、参与、接受、留存、任务成功五个维度,从体验角度组织指标。 |
| A/B 测试 | 把用户随机分成对照组和实验组,比较单一改动带来的差异。 |
| 统计显著 | 实验结果不太可能由随机波动造成,通常用 P 值等来判断。 |
| 辛普森悖论 | 分组看是一致趋势,合并后却相反,源于各组样本权重不同。 |
| 幸存者偏差 | 只看到存活下来的样本,忽略已经消失的,导致结论被高估。 |
| 回归均值 | 极端表现之后往往向平均值靠拢,可能是波动而非干预奏效。 |
| 基准率(Base Rate) | 某事件在总体中本来就有的发生概率,是判断先验的起点。 |
| 贝叶斯更新 | 先有一个先验判断,再根据新证据按比例修正为后验判断。 |
| 相关与因果 | 两个量一起变化不等于一个导致另一个,需排除共同原因和反向因果。 |
| 先行指标与滞后指标 | 先行指标先于结果变动、可提前干预,滞后指标反映最终结果。 |
| 术语 | 一句话解释 |
|---|---|
| LTV / CAC | 用户终身价值与获客成本之比,衡量获客投入是否划算。 |
| 单位经济(Unit Economics) | 单个用户或单笔订单的收入与成本是否为正。 |
| 回本周期(Payback Period) | 从单个用户身上收回获客成本所需要的时间。 |
| 毛利率 | 收入减去直接成本后占收入的比例,反映业务本身的赚钱能力。 |
| 边际成本 | 每多生产或服务一个单位所增加的成本,决定规模扩张的经济性。 |
| 现金流 | 一定时期内实际收入与支出的现金,决定企业能否活下去。 |
| 账期 | 从交付到收到货款之间的时间差,账期越长占用的资金越多。 |
| ROI(投资回报率) | 净收益与投入之比,衡量一笔投入的产出效率。 |
| 商业模式画布 | 用九宫格梳理客户、价值、渠道、收入与成本等商业要素。 |
| 网络效应 | 用户越多,产品对每个用户的价值越大,形成自我强化的增长。 |
| 双边市场 | 平台连接两类互相依赖的用户群,一方的增长带动另一方。 |
| 规模效应 | 规模扩大后单位成本下降、效率提升,形成成本优势。 |
| 平台经济 | 以连接供需双方、撮合交易为主的商业模式,价值来自网络。 |
| 获客成本(CAC) | 获取一个新用户平均花费的营销与销售费用。 |
| 固定成本与可变成本 | 固定成本不随业务量变化,可变成本随业务量增减。 |
| 盈亏平衡点 | 收入刚好等于总成本、不赚不赔时的业务量或规模。 |
| 贡献毛利 | 单笔收入扣除可变成本后的余额,用来覆盖固定成本和利润。 |
| ARR / MRR | 年度或月度经常性收入,衡量订阅类业务的稳定收入规模。 |
| GMV | 一段时间内平台成交的商品总额,不等于平台自身的收入。 |
| 飞轮效应 | 多个环节互相推动、越转越快的增长循环,一旦启动会自我加速。 |
| 术语 | 一句话解释 |
|---|---|
| token | 大模型处理文本的最小单位,字数、成本与上下文限制都以它计。 |
| 上下文窗口(Context Window) | 模型一次能读取的最大 token 数,超出部分会被截断。 |
| 提示工程(Prompt Engineering) | 通过设计指令、示例和格式来引导模型输出更符合预期。 |
| 温度(Temperature) | 控制模型输出随机性的参数,越低越稳定,越高越发散。 |
| RAG(检索增强生成) | 先检索外部资料再让模型据此作答,以补充事实、减少幻觉。 |
| 微调(Fine-tuning) | 用领域数据继续训练预训练模型,使其更贴合特定任务。 |
| Agent(智能体) | 由模型自主规划、调用工具并多步执行以完成目标的程序。 |
| 工具调用(Function Calling) | 模型按需调用外部函数或接口来获取数据、执行动作。 |
| 幻觉(Hallucination) | 模型生成看似合理却与事实不符的内容,需要外部校验。 |
| LLM-as-judge | 用一个模型按标准给另一个模型的输出打分,用于自动化评估。 |
| SLA / SLO | 服务等级协议是对外的承诺标准,服务等级目标是内部设定的量化目标。 |
| API(应用程序接口) | 系统之间约定的调用入口,规定请求方式与返回数据格式。 |
| 缓存(Cache) | 把常用数据暂存在更快的存储里,减少重复计算与请求耗时。 |
| 消息队列 | 用队列在系统之间异步传递消息,起到削峰、解耦与可靠投递的作用。 |
| 技术债 | 为快速上线而采取的将就方案,日后需要额外成本来偿还。 |
| Serverless | 不需要管理服务器、按调用量计费的运行方式,弹性好但受平台约束。 |
| Embedding(向量表示) | 把文本等转成高维向量,使语义相近的内容在空间中彼此靠近。 |
| 向量数据库 | 专门存储和检索向量、支持相似度搜索的数据库,常用于 RAG。 |
| 多模态 | 模型能同时处理文本、图像、音频等多种类型的输入或输出。 |
| 推理成本 | 模型每次生成结果所消耗的算力与费用,直接影响产品定价与体验。 |
| 术语 | 一句话解释 |
|---|---|
| 信息架构(IA) | 对内容与功能进行组织、分类和命名的结构,决定用户能否找到东西。 |
| 导航深度 | 从入口到达目标页面需要经过的层级数,越深越容易迷路。 |
| 状态设计(空态 / 加载态 / 错误态) | 对无数据、加载中和出错等情形给出明确的界面反馈。 |
| 可用性(Usability) | 用户在特定场景下使用产品完成目标的效率、准确与满意程度。 |
| Fitts 定律 | 目标越大、越近,点击越快;常用操作应做得大而近。 |
| Hick 定律 | 选项越多,做决定的时间越长;选择过多会拖慢用户。 |
| 无障碍(WCAG) | 让残障用户也能使用产品的规范,涵盖可感知、可操作等要求。 |
| 一致性(Consistency) | 相同元素在相同情境下保持相同的样式与行为,降低学习成本。 |
| 视觉层级 | 通过大小、颜色、间距等区分信息重要性,引导用户的注意力顺序。 |
| 渐进式披露 | 先只展示必要信息,等用户需要时再逐层展开更多细节。 |
| 设计系统(组件库) | 统一的可复用组件与规范集合,保证界面一致并提高效率。 |
| 线框图(Wireframe) | 只画结构与布局、不含视觉细节的低保真草图。 |
| 高保真原型 | 接近最终效果的交互原型,用于验证体验和对外演示。 |
| 可用性测试 | 让真实用户操作并观察其表现,从中发现界面存在的问题。 |
| 启发式评估 | 由专家依据通用可用性原则检查界面,成本低但依赖经验。 |
| 卡片分类 | 让用户把内容卡片分组,据此推断符合其心智的信息分类。 |
| 微交互 | 按钮反馈、动效等小范围交互细节,用来提示状态、增强反馈。 |
| 响应式设计 | 同一套界面能适配不同屏幕尺寸与设备,自动调整布局。 |
| 容错设计 | 允许用户犯错并能轻松撤销或恢复,而不必从头再来。 |
| 认知走查 | 逐步模拟用户操作的每一步,检查是否会困惑或找不到下一步。 |
| 术语 | 一句话解释 |
|---|---|
| MECE | 相互独立、完全穷尽,把问题拆成不重叠又不遗漏的若干部分。 |
| 金字塔原理 | 结论先行、以上统下、归类分组、逻辑递进的结构化表达方法。 |
| PRD(产品需求文档) | 描述产品需求与方案的核心文档,说明做什么以及为什么做。 |
| DoD(完成的定义) | 团队约定的「一项工作算完成」所需同时满足的标准清单。 |
| 关键路径(Critical Path) | 决定项目最短工期的那条最长任务链,延迟它就会拖延整体。 |
| 需求变更 | 项目进行中对需求的修改,需要评估影响并履行变更流程。 |
| 事故复盘 | 事后不追责地还原事故经过、找出根因并给出改进措施。 |
| MVP(最小可行产品) | 用最小成本验证核心假设的第一版产品,用于尽早获取反馈。 |
| 灰度发布 | 先向小比例用户放开新版本,观察无异常后再逐步扩大范围。 |
| 敏捷开发 | 以短周期迭代、持续交付和快速响应变化为核心的开发方法。 |
| Scrum | 一种敏捷框架,由产品负责人、Scrum Master 和开发团队按固定节奏推进。 |
| 看板(Kanban) | 把任务可视化并限制在制品数量,用来发现和疏通瓶颈。 |
| 迭代(Sprint) | 固定时长的开发周期,结束时产出一个可用的增量。 |
| 里程碑 | 项目中的关键时间点或阶段成果,用于检查进度与对齐预期。 |
| 需求评审 | 开发前由相关方共同确认需求的范围、可行性与一致理解。 |
| 优先级排序(RICE) | 按触达、影响、信心和成本给需求打分,排出相对顺序。 |
| 干系人管理 | 识别受项目影响的各方,并持续沟通其期望与利益。 |
| RACI | 用负责、批准、咨询、知会四种角色明确每项任务的分工。 |
| 5 Whys(五问法) | 对问题连续追问为什么,逐层逼近根本原因。 |
| 风险登记 | 把已识别的风险、影响与应对措施记录并持续跟踪的清单。 |
20 张卡片,每张一句话说清是什么,再标出用在哪、别用在哪,供快速扫读。想展开看,去第 19、20 章对应条目。
一句话:回到最基本的事实,从零重新推导。 用在哪:老做法明显不合理时。 别用在哪:日常小事,照成熟做法更快。
一句话:要素互相影响,别只看单点因果。 用在哪:问题反复出现、按下葫芦浮起瓢。 别用在哪:简单直接的问题,别硬套。
一句话:结果不确定时,算各种结果乘概率的总和。 用在哪:下注、挑方案前先估期望。 别用在哪:只算期望,忽略输不起的极端。
一句话:收益再投入会加速增长,时间越长越明显。 用在哪:评估品牌、技能这类长期积累。 别用在哪:短周期目标,复利来不及发力。
一句话:一件事的影响,常常在第二层才显现。 用在哪:大决策前多问一句「然后呢」。 别用在哪:无限追问,会陷入分析瘫痪。
一句话:有些系统能在波动与冲击中变强。 用在哪:需要长期应对不确定的机制设计。 别用在哪:超过阈值就会被摧毁的场景。
一句话:能解释现象时,优先选假设最少的。 用在哪:多个解释都说得通,先试简单的。 别用在哪:别把「简单」当成「一定对」。
一句话:不问怎么成功,先问怎么做会失败。 用在哪:做规划、评估风险、长期目标。 别用在哪:列完失败清单,还得回到行动。
一句话:少数原因常带来多数结果,约二八。 用在哪:资源有限,要先找到关键少数。 别用在哪:别把二八当精确比例到处套。
一句话:估算时留出缓冲,错了也不伤根本。 用在哪:不可逆或代价高的决策。 别用在哪:可逆的低成本试错,不必留太多。
一句话:只在自己真懂的范围内下判断。 用在哪:接新方向、选投入领域时。 别用在哪:别拿它当不学习的挡箭牌。
一句话:类比有用,前提是深层结构相似。 用在哪:进陌生领域,快速建立直觉。 别用在哪:只像在表面,机制其实不同。
一句话:选一个,就等于放弃其他最好的那个。 用在哪:资源有限、只能做一件事时。 别用在哪:选项之间没有真实冲突时。
一句话:已花出去、收不回的成本,别影响下一步。 用在哪:纠结要不要止损、要不要停项目。 别用在哪:别把「已投入」当成继续的理由。
一句话:早先的选择会锁住后面的选项。 用在哪:定架构、定标准、定规则之前。 别用在哪:别拿它给「一直这么做」找借口。
一句话:找到投入少、撬动大的那个支点。 用在哪:资源紧张,想放大产出时。 别用在哪:杠杆放大收益,也放大风险。
一句话:系统的产出,被最弱的一环卡住。 用在哪:整体效率上不去,先找瓶颈。 别用在哪:到处优化,却绕开真正的瓶颈。
一句话:结果回到系统,影响下一轮的行动。 用在哪:判断一件事会不会自我强化。 别用在哪:回路慢或模糊时,别急着下结论。
一句话:看多做一个单位,会多发生什么。 用在哪:定价、扩产、加功能的决策。 别用在哪:只看总量,忽略了多一个的代价。
一句话:找亏损有限、收益可能很大的选择。 用在哪:试新方向、做小成本下注时。 别用在哪:别把「可能很大」当成「一定很大」。