启示录：价值、可用性、可行性

这是《启示录》（Inspired, Marty Cagan）的结构化读书笔记，以「价值—可用性—可行性」三元框架为主线，把零散概念串成一篇完整的文章。

引言：产品经理真正的工作是什么

很多人以为产品经理的核心工作是「管理需求」：把需求写清楚、排好优先级、盯开发进度。但书里给出了一个截然不同的答案：

产品经理的核心工作不是管理需求，而是降低产品失败的风险。

风险只有三类，对应三个问题：

风险	问题
价值风险	用户到底要不要？
可用性风险	用户到底会不会用？
可行性风险	团队到底能不能做？

作者真正反对的，是一种极常见却极危险的产品开发模式：

高层或市场提出想法 → 产品经理写文档 → 开发照着做 → 上线后看结果。

这个模式的问题在于，它把最关键的问题——「用户到底要不要？」——留到了最后。而一旦产品开发完成，才发现用户不要，代价就高得难以承受。所以作者认为，产品经理不该只是「把需求写清楚的人」，而应是负责发现正确产品的人。

放到今天，这个判断对 AI 产品尤其锋利：技术令人耳目一新，不代表用户需要它。 很多 AI 产品失败，不是因为模型不够强，而是场景太泛、价值不明确、没有形成稳定的用户工作流。做 AI 产品时更要追问：用户原来怎么完成这件事？AI 是否真的让他更快、更便宜、更准确？用户是否愿意改变原来的流程？

一、贯穿全书的三元框架

价值、可用性、可行性，三者构成了全书的方法论骨架。判断一个产品时，用三个问题对照：

判断	问题	失败表现
价值	用户想不想用？	做出来没人要
可用性	用户会不会用？	用户想用但用不起来
可行性	团队能不能做？	想法很好但做不稳、做不起、维护不了

一个产品必须同时满足这三点，缺一不可：

只满足价值、不满足可用性：用户想要，但用不起来；
只满足可用性、不满足价值：体验很好，但没人需要；
只满足价值和可用性、不满足可行性：概念很好，但无法落地。

所以产品经理的核心任务不是写需求，而是不断回答三个问题：这个产品是否值得做？用户是否会用？我们是否能做出来？

由此得出三条核心结论：

可行性不是「技术能不能做」，而是能否以合理成本、稳定质量、可持续方式做出来。
开发人员不只是执行者，也是产品探索的重要参与者。
好产品不是想象出来后交给开发实现，而是在价值、可用性、可行性之间反复权衡出来的。

下面的第二、三、四节，分别展开这三个维度。

二、价值：用户想不想要？

价值问题回答的是「做出来有没有人要」。书里没有给出万能公式，而是反复提醒：别把「收集需求」误当成「理解需求」。

市场调研是输入，不是答案

市场调研能告诉你「用户现在怎么看、怎么说、怎么用」，但它很难告诉你「未来应该创造什么」。几个关键判断：

用户知道自己的痛苦，但通常不知道最好的解决方案；
用户容易描述旧世界里的改良，不容易想象新世界里的产品形态；
用户研讨会适合用来听问题、看反应、找线索，不适合用来投票决定产品方向。

一句话总结：市场调研是输入，不是答案；用户反馈是线索，不是产品定义。 数据驱动不等于数据替你决策，用户驱动也不等于用户替你设计产品。产品经理的责任，是把市场信号转化为有价值、可用、可行的产品方案。

消费者分类：谁最值得注意？

书里用「情感状态」对技术接纳曲线上的消费者做了分类：

技术爱好者（创新者）：因为产品用了新技术而购买，对技术本身痴迷。对产品经理来说，他们是最没有参考价值的人群——需求与大众不同，容易误导判断。
非理性消费者（尝鲜者）：情感需求与大众相同，但更强烈，会为满足情感付出远超问题本身的成本。
普通大众：与非理性消费者同样的情感需求，只是程度更弱，随产品完善逐步加入。
理性消费者（早期大众）：只买实用、成熟、性价比合适的产品。
超理性消费者（后期大众）：情感需求更弱，产品有半点不合意就不掏钱。
观望者（跟随者）：约 15%，只买公认好用的产品。

在这几类人中，非理性消费者最值得产品经理注意——他们最敏感、最不掩饰，是早期最真实的需求信号。

新生测试：以新手视角发掘情感需求

作者（书中的杰夫）提出的方法是「新生测试」：回想踏入中学第一天，小学的一切成绩和奖励都失效了，一切对你都是新鲜的，此时你最敏感，最容易感受到细微变化。带着新生的感觉去发掘每天折磨大众的情感——孤独、恐惧、挫折、不满——离发现新产品的日子就不远了。

三、可用性：用户会不会用？

价值回答「想不想要」，可用性回答「会不会用」。这是很多技术型产品最容易翻车的地方。

可用性的本质：三个「不被」

可用性的定义一句话就能说清：用户能不能在不被解释、不被培训、不被强迫的情况下，完成他想完成的任务。

不被解释：如果必须有人在旁边解释用户才知道怎么用，说明产品本身没把意图表达清楚。好的产品应该会自己说话。
不被培训：培训有价值（尤其 B 端），但若一个产品必须依赖大量培训才能完成基础任务，可用性往往有问题。大众产品尤其如此——用户不会想「我应该学习这个产品」，只会想「这东西怎么这么难用」。
不被强迫：有些企业产品看似天天被用，但不代表可用性好，用户可能只是被制度强迫使用。

很多难用产品的根源，是团队把内部复杂性暴露给了用户：

内部复杂性	用户看到的糟糕体验
数据结构复杂	表单字段特别多
权限系统复杂	用户不知道自己为什么不能操作
流程状态复杂	页面上出现一堆看不懂的状态
组织分工复杂	一个任务要跳转多个系统
技术限制复杂	用户必须按系统要求改变自然流程

所以好的产品设计不是消灭复杂性，而是把复杂性留在系统内部，把简单性呈现给用户。

关于可用性与美感：可用性解决「能不能用」，美感影响「愿不愿意亲近」。可用性首先要求产品能被理解、被操作、能完成任务，但视觉设计同样重要——尤其消费级产品，视觉不是装饰，而是价值感的一部分。

最后是验证方式：可用性不能靠团队内部争论验证，最有效的方法是找目标用户，让他在原型上完成真实任务，观察他在哪里卡住。 注意，是观察，不是问意见——用户常说不清自己为什么卡住，但行为会暴露问题：停顿、反复点击、找不到入口、读不懂文案、误解按钮、走错流程、完成后不确定是否成功。

为什么开发人员容易低估可用性

书里有一个重要观点：开发人员通常不擅长用户体验设计，因为开发人员脑子里想的是实现模型，而用户看重的是概念模型。

实现模型：系统内部怎么运作——数据库怎么存、接口怎么调、权限怎么判、状态怎么流转、异常怎么处理。
概念模型：用户以为这个东西该怎么运作——点保存就该保存、取消订单钱就该退回、上传文件就该马上看到、邀请同事他就该收到通知。

用户不关心系统内部复杂性，只关心产品是否符合直觉。

放到 AI 产品上，这个矛盾被放大得淋漓尽致：一个「功能强大但用户不会用」的 AI 产品，问题通常不在「用户笨」或「不会写提示词」，而在产品没有把技术能力翻译成用户能理解、能操作、能获得结果的任务流程。用户教育只能补救，不能替代产品设计。

B 端系统的特殊提醒

B端系统（面向企业、商家、员工的后台系统）尤其要小心一个误判：

使用频率高，不等于体验好；被迫使用，不等于用户认可。

因为 B 端用户往往是被公司制度「强迫」使用的，表面的高活跃度会掩盖真实的可用性问题。B 端同样要过「三个不被」这一关。

四、可行性：团队做不做得出来？

可行性是最容易被窄化的一环。很多人理解可行性，只会问一句「技术上能不能实现」，但这只是最低层的问题。

可行性有五层

真正的可行性至少包括五层：

层次	要问的问题
技术可行性	现有技术能不能实现？
成本可行性	要投入多少人力、时间、算力、资金？
性能可行性	能不能支撑真实规模的用户和数据？
运营可行性	上线后能不能维护、客服、审核、监控？
商业可行性	做出来后是否符合公司的商业目标？

由此：一个方案技术上能做，不代表它值得做；一个 Demo 能跑，不代表它能产品化；一个功能能上线，不代表它能长期维护。

为什么产品经理必须理解可行性

产品经理不需要亲自写代码，但必须理解技术约束，否则会有三种后果：

提出空想型需求。「完全自动判断用户意图」「AI 自动处理所有客服」「所有数据打通实时决策」——这些听起来很美，但背后是数据质量、权限、准确率、延迟、成本、风控等一长串约束。不懂约束，就容易把愿景误当方案。
错过更好的技术机会。可行性不只是限制，也可能是机会。开发人员参与早期探索，常能带来关键输入：「不用做完整系统，先用规则引擎就够」「换一种数据结构，体验能快很多」「这个模型不适合实时生成，但可以预生成」。
让开发阶段变成灾难。前期不验证可行性，到了开发阶段才发现做不了，结果就是返工、砍需求、延期、团队互相指责、上线质量差、体验被迫缩水。

所以可行性的核心不是保守，而是现实：不是「技术难就别做」，而是要知道哪里难、为什么难、有多难、能不能绕过去、能不能分阶段做、能不能先验证核心假设。优秀的产品经理不是只会说「我要这个功能」，而是能和技术团队一起找到在当前资源下，最小但有效的产品方案。

五、定义产品：把三者编织起来

当机会被判定值得探索后，产品经理进入第二项工作：定义产品。这一步是把价值、可用性、可行性三个维度同时织进一个方案里。

产品定义，不只是列功能

作者强调，探索解决方案时要覆盖：基本产品特征和功能、用户体验、发布标准，以及价值、可用性、可行性的验证。换句话说，产品经理要回答清楚：

我们给谁做？解决什么问题？用什么方式解决？用户怎么完成任务？哪些功能是必须的？哪些可以不做？如何证明方案可行？什么状态才算可以发布？

这才是产品定义。

产品经理不应该独自定义产品

「产品经理负责定义产品」不等于「一个人关起门来想方案」。恰恰相反，产品探索需要多方协作：

产品经理更关注价值；
设计师更关注可用性；
开发和架构师更关注可行性；
营销和销售提供市场输入；
客服和运营提供真实问题。

这正好呼应了第一节的结论：好产品是在价值、可用性、可行性之间反复权衡出来的，而这种权衡天然需要多角色碰撞。

产品原则：取舍的标准

定义产品时必然会遇到取舍。书里给出的工具是「产品原则」——当我们必须取舍时，什么比什么更重要？

比如：易用性比功能丰富更重要？隐私比增长更重要？速度比视觉效果更重要？标准化产品比大客户定制更重要？

产品原则不是产品功能，也不是拿来装饰墙面的口号，而是拿来拒绝诱惑的标准。 作者举了电影网站的例子：如果产品原则是「社区用户的影评比专业影评更有价值」，那么当制片厂想在网站上发评论时，团队就能据此判断是否接受——决策不再只靠职位、声音大小或临时利益。

落到 B2B SaaS 上，产品原则可以这样写：

我们优先做可被多数客户复用的标准能力，而不是为单个客户做一次性定制；优先降低一线员工的操作负担，而不是满足管理层对复杂报表的全部想象；优先保证核心流程稳定可靠，而不是快速堆叠边缘功能。

有了原则，当销售带来一个大客户要求做 7 个专属功能时，团队就能用原则判断：这些功能多数客户也需要吗？破坏标准流程吗？增加长期维护成本吗？答案不好，就拒绝或转成更通用方案。

产品团队要先建立共同的价值判断标准，再讨论具体方案；否则每一次产品决策都会被临时压力、个人偏好和部门利益拖着走。

六、发布与迭代：平滑部署

产品定义完成、开发上线，还要处理一个现实问题：用户其实不喜欢变化。即使新版更好，强制切换也会引发抵触。

解决方式是平滑部署：发布两个并行版本，邀请有兴趣、有时间的用户试用新版本；新版本运行正常、大部分用户习惯后，再把新版本设为默认；同时保留旧版本一段时间，并公示旧版本停止支持的最后期限，让没来得及习惯的用户能照常使用。对用户量庞大的产品，这个过渡可能需要几个月。

产品经理还要准备好承担来自开发和运维团队的压力——毕竟支持并行版本不是件容易的事。

结语

把全书串起来，其实就一句话：

产品经理不是在「写需求」，而是在「降低风险」——用价值回答「要不要做」，用可用性回答「会不会用」，用可行性回答「做不做得出来」，再在产品定义和迭代中反复权衡三者。

从挖掘需求（市场调研、消费者分类、新生测试），到验证可用性（三个不被、隐藏复杂性、观察而非问意见），到评估可行性（五层、技术参与），到定义产品（协作、产品原则），最后到平滑部署——这是一条完整的产品方法论闭环，也是一条对今天的 AI 产品仍然成立的路。