做一个好产品

引言

软件工程专业毕业，从事 SRE 工作三年多后，开始转型从事 技术产品策划 工作。

至今产品策划工作已四年有余，历经过大大小小十多款产品。听过看过见识过无数人给产品下定义，指责产品方案，甚至用排泄物来和产品做对比。不禁会让人反复思考，如何才能做一款好产品？

在网络上随意便可以找到无数关于**「做好产品」的资料，知识付费平台上也可以轻松找到许许多多「做产品」**的课程。但放眼望去却从来没有一篇文章能讲清楚 什么是产品，和 该怎样做好

什么是产品？什么是好产品？

关于产品有太多太多的定义，在这里我给出自己的定义，它也是本文的根基：

产品是 解决问题 的 思考路径 的 具象化体现。

一个好的产品，应以 最小成本 解决问题，具有 普世性 的思考路径，并且其解决方案应当是 可感知或可触及 的。

解决问题：产品的根本目的

如何才能够用最小的成本 解决问题？ 牛刀可以杀鸡，但是大可不必。

产品的核心在于 高效地 解决用户的实际需求，而不是过度设计或复杂化。一个好的产品应该像瑞士军刀一样，功能丰富多样，但每一个功能都能 精准地 解决特定的问题。

思考路径：用户解决问题的心智模型

越来越多的产品已经没有说明书，我们在使用微信的时候从来没有看过指引教程。

因为它已经将定义做到了极致的抽象，将产品做到了足够通用。你会发现按照自己的理解所做出的每一个操作，一切都能够**「顺理成章」** （微信群收款功能除外）

这就是微信产品的「思考路径」与你的「思考路径」完全重合而产生的 快感，它与在读书时不经意间读到某个观点，与作者产生**「灵魂共鸣」**时的快感是一样的逻辑。

更直白地说，思考路径即是每个人解决问题的方法。我们用真实的「路径」来做比喻，同样是从深圳去北京，光是在交通方式上就有 高铁、飞机、自驾 等多种方式，每种方式都是 不同思考路径的体现。

同样是坐飞机，我们又有 不同的航空公司、不同的目的地机场、直达 or 经停 等多种方式可以规划组合，这些都是不同人在面对不同的出行需求时，结合他所处的环境和掌握的信息，所做出的最符合当下情境的决策，即所谓的**「条条大路通罗马」**。

有些产品还会埋藏一些**「彩蛋」**，彩蛋一定不会是解决问题的 核心路径。用户在使用过程中，不经意间发现了产品中埋藏的彩蛋时会感到意外惊喜，像极了在读书时不经意间读到某个观点时与作者产生的 共鸣。

从发展心理学的角度来讲，「思考路径」的形成过程也符合人类认知水平的发展过程：随着个人经历的增长，基于对周围世界的不断理解，人们的认知水平也在不断地进行着**「同化 -> 顺应 -> 重组」**的过程。

具象化：将抽象思路转化为可感知的实体

有太多的产品文案宣传得天花乱坠，在这个谈 AI 色变的时代，甚至许多产品连要解决什么问题都还没有想清楚，我只愿称之为一个有待检验的「方案」。

任何脱离实际需求的炒作和噱头都是没有意义的，仅抛出虚无缥缈的概念和方案也只是夸夸其谈的文字游戏。

「产品经理」与「精神分裂」

行业习惯用「产品经理」这个称呼来泛指所有与产品相关工作的人，但今天我们主要特指的是**「产品策划」**这个工作。

按照上面的定义，要「策划」出一款好产品，让尽可能多的人喜爱使用它，而不是一看到产品就一头雾水，或是在使用过程中大骂爹娘，我们就需要在 解决问题 和 思考路径 上努力下功夫。

明确要解决的问题是基础，这一关绝大多数有解决问题能力的人都可以做的很好。大多数饱受诟病的产品，都是在 思考路径 上欠些考虑。

许多资料和课程中都会提到做产品的一个关键的「特质」，是要有**「共情」**能力。

所谓「共情」，就是要求在做产品策划工作时，尽可能多地代入不同种类的用户角色，甚至**「钻」进他们的脑袋里，「套」上他们的思维，「透过」**他们的眼睛和双手，假想 出 TA 可能会怎么做。

共情的底层逻辑，就是能够敏锐地 ****感知 ****或 捕捉 ****不同用户的 思考路径 。

因此，能够创造出伟大产品的人，TA 可能有着丰富的生活经历，TA 在生活中可能敏感又多疑，TA 可能会对身边的一切都充满着好奇，甚至 TA 可能是个怪人，如同精神分裂般地去剖析用户行为。

不过的确，许多伟大的艺术家和思想工作者都有精神分裂症。

产品与人性

反过来讲，难道不敏感多疑，没有精神分裂的人，就一定做不出好产品吗？当然不是！

也许具有上面描述的这样特质的人，在产品策划的行业中是「老天爷赏饭吃」，但靠自己的努力，一样也会有饭吃。这里努力的方向便是 剖析人性。

如果说共情的 底层逻辑 是不同用户的 思考路径，那么 人性 便是 思考路径 的 核心驱动。

产品设计必须深入 理解 并 回应 人性需求。这种理解不仅停留在表面的功能需求，更要洞察深层的心理和情感需求。

一个很经典的故事，微信的**「摇一摇」**功能上线于用户爆发式增长的 3.0 版本：

• 《人类的起源》：人类直立行走就是为了抓握东西，摇一摇是人类最原始的一个行为
• 摇一摇出现的「咔嚓声」是来福枪的声音，男生喜欢这个声音因为有一种热血沸腾的感觉，莫名会觉得很爽
• 很多女生其实并不是想搭讪另一个男生；女生不停地摇一摇，目的其实是检验她的魅力值
• 弗洛伊德《梦的解析》：「人类所有的动机都来自于性冲动」

掌握了人性的根本，也就能够自然推演出用户可能的思考路径，进而设计出普世的产品方案。

模型抽象

倘若已经掌握了足够通用的思考路径，并根据此制定出了完美的产品方案，一切就结束了吗？

答案依然是否定的。

学习过编程的同学应该都听说过**「面向过程」和「面向对象」**的概念，如果是一个简单的产品或工具，找到了足够通用的思维路径，用线性的方式将方法实现，就能够比较好地解决问题。

但在稍复杂的系统中，如果仅仅是把多条思维路径不加思考地**「拟合」在一起，情况就会变得糟糕起来，届时一定会有用户吐槽「繁琐」、「大杂烩」、「耦合深」、「找不到」..** .（当然如果本身它就是个「工具箱」，那并没有问题

在复杂系统中，概念定义、抽象，是必不可缺的工作，这也是在 B 端系统中常见的误区。

许多系统会被认为**「不需要产品」，研发同学自己就可以完成产品的设计和开发工作。的确，如果思考路径捕捉得足够准确，确实能够解决眼下的问题。但随着业务的发展，流程不断变得复杂，产品便会日益臃肿，变成一个使用和维护都十分困难的「缝合怪」。**

以计算机相关专业同学大学时都会做的「图书管理系统」为例，如何抽象？

• 识别核心功能、特征，分类分组

  • 图书
  • 用户

• 定义模型（甚至不需要产品来做）

  • 图书

    • 书名
    • 作者
    • 分类
    • ...

  • 用户

    • 姓名

    • 联系方式

    • ...

通过抽象，我们便可以明确系统的核心要素，定义实体间的关系，为后续的功能设计提供基础框架。

在一个经过精心设计的系统中，所有的 抽象模型 一定是 边界清晰、各司其职 的，所有的 使用路径 也一定是 水到渠成、顺理成章 的。

反之，所有 仅面向功能场景 而设计的系统中，用户永远无法理解产品设计的逻辑，因为他们在第一步：对抽象概念的理解 上就出现了问题，更别提要在「一堆字都认识却不知道表达什么含义」的系统中，去完成一个复杂的流程。

实体关系图（ERD）、统一建模语言（UML）和领域驱动设计（DDD）都是进行模型抽象的有效工具。（我们甚至在大学的计算机相关课程中有学习过它们

概念定义

update@2025-06-19

「对齐概念」这句话大家一定不陌生，然而大多数人都没有真正认识到「对齐概念」这一动作的重要性和背后的价值。

统一的概念是团队（产品、研发、设计、运营、市场）沟通的**「普通话」，** 概念模糊、定义不清不仅仅是 产品体验糟糕 的起点，更会为后续的沟通工作（不论是内部沟通还是与用户沟通）带来 巨大的理解成本。

在研发效能会议上，讨论**「** 基线 **指标」**时：

• 有些人会理解「基线」是该指标在公司整体的 平均值
• 有些人会把「基线」理解为是该指标 起始周期的数值

由于对于「基线」本身的定义不清，大家心中都有各自的基线，会议上大家鸡同鸭讲，反复在确认澄清，讨论变成了纠缠定义而非问题本身。

抽象如「工单」、「业务」、「空间」，具体如「保存草稿」、「提交重启任务」，一个清晰的定义能够提高沟通过程中的信噪比，是一切高效协作的基石。

一个基本的原则：概念定义应避免惜字如金， 清晰准确的表述 带来的收益远远胜过 含糊不清的抽象短语 。

角色

一个完善的产品系统中，除了做好最基本的抽象外，还要明确定义出用户的角色

在图书管理系统中，我们可以很轻松地定义出这两个角色

• 读者

• 图片管理员

用户故事

「用户故事」译自 User Story ，自从接触产品工作起，我就始终对这个直译耿耿于怀。

「用户故事」是将抽象模型转化为具体功能的关键环节，它描述了用户在产品中一条完整的使用路径，对应了我们前面提到的思考路径。

可以使用 角色 x 模型 这样简单粗暴的方式来得到许多用户故事：

	图书	用户
读者	- 浏览图书

• 借阅
• 还书
• 查询个人借阅记录 | - 新用户注册
• 个人信息维护 | | 图书管理员 | - 管理图书信息
• 处理借还请求
• 管理库存 | - 用户授权
• 管理用户信息 |

接下来需要做的事情，就是如何能够将这些用户故事（思考路径）具象化实现。这往往是刚接触产品策划工作的同学一上手便开始去做的事情，它会导致最终实现的产品 逻辑边界不清晰、功能之间强****耦合 ****等问题，是常见的产品设计的误区。

一个好的用户故事需遵循 INVEST 原则：

• Indepedent， 独立 ： 用户故事之间必须彼此独立，低耦合

• Negotiable， 可协商 ： 在开发之间需要卷入团队所有角色进行充分讨论，而非产品与开发角色之间的契约

• Valuable， 有价值 ： 用户故事必须对用户而言是有价值和意义的

• Estimable， 可估算 ： 实现这个用户故事所需要的开发工作量必须能够估算出来

• Small & Similar size， 小规模 ： 用户故事尽量切分在一个迭代内完成

• Testable， 可验证 ： 用户故事在开发完成后一定是可以被验证的

基于用户故事，我们可以通过 用户访谈、原型测试 和 A/B test 等方法，验证这些功能是否真正满足了用户需求，并在此基础上不断优化产品设计。

第一性原理

update @2024-11-05

国庆回老家，打开家里七年前的古董电视时，用惯了投屏操作的我仅仅在电视原生的操作系统里摆弄了两分钟，整个人就开始暴躁起来 —— 首屏永远是厂商内置的付费内容，我要在 数不清 的 Tab 页 ****的 最底部 的 文件夹 中才能找到自己安装的应用，更何况我还要把这样的操作路径教会给我的妈妈。

单从用户故事的角度而言，以下这些用户故事的的确确符合 INVEST 原则：

• 用户打开电视机

• 用户在首屏选择自己感兴趣的内容

• 用户在不同 Tab 间切换

• 用户在「我的」Tab 下找到「应用」入口，选取自定义应用

对于电视机厂商的 PM 同学来说，他们也确实圆满地完成了自己的产品工作任务，但最终的结果得到的却是 铺天盖地的用户吐槽，和广电总局的 一纸整治令： 国家广播电视总局 政策解读 多部门合力出招——治理“套娃”收费 还观众电视自由

对比之下，在使用 Apple TV 时，它带给用户的操作体验是和其它电视机厂商截然不同的：

• 开屏即是可 自定义的内容，无论是应用列表还是应用本身
• 遥控器方向键区域本身也是一个触控板，可以像 macbook 的触控板一样 快速移动定位
• 列表中当前聚集的内容会 直接播放 展现给用户
• 需要输入时可以 无缝联动 iphone 在手机端输入

抛开电视，苹果几乎所有其它的产品都会带给用户具有**「突破性」**的、不一样的使用体验。

如何讲出一个好的故事，既能完成产品工作，又能让妈妈用得满意？答案是，遵循 第一性原理。

第一性原理，是指回归事物 最基本的条件，把其 解构 成 各种要素 进行分析，从而找到实现目标 最优路径 的方法。

实践过程中，我们首先最需要搞清楚的是，我们究竟在解决什么问题。

If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.

― Albert Einstein

很多时候我们可能根本没有探究清楚当下面临的问题是什么。搞清楚问题，拆解问题，从头开始创建解决方案，这是第一性原理的精髓所在。

The only rules are the ones dictated by the laws of physics. Everything else is a recommendation.

― Walter Isaacson, Elon Musk

于是，这个世界上就有了这些伟大产品的诞生：

• 为什么松开刹车，车辆一定要缓行前进，然后双脚要在两个踏板间来回切换？ —— 特斯拉

• 为什么火箭一定要像放烟花一样放飞即损毁？ —— SpaceX

• 为什么手机一定要有物理键盘？ —— iPhone

• 为什么音乐播放器一定要有屏幕？ —— iPod

看起来它的定义和操作并不复杂，但在真正的实践过程中，想要做好它并不容易。原因可能有：

• 人们受限于 思维惯性，习惯于按照既有的思维模式和经验来解决问题

• 打破思维惯性，应用第一性原理进行思考，通常需要更多的时间和精力（可参考《思考快与慢》，系统一和系统二）

• 挑战现有的假设和方法，可能会让人感到 ****不舒服 ****或 不安全。人们会更想要呆在自己的舒适区里

• 上级可能并不会在工作中给予更多的时间和耐心，这会让产品设计面临 阻力 或 批评，进一步阻碍我们运用第一性原理（所以我们常常会听到，产品设计工作需要「灵感」）

再或者，可能是解决这个问题的方法 不在当前的维度，或是 不在我们认知范围内。即便我们应用了第一性原理的思维方式，但把知识储备翻到箱底也找不到一个解决方案。

解决方案：「多读书，读杂书」，这是我最初接触产品工作时，产品总监反复向大家提起的。积累了足够多的思维模型，我们越来越能够发现不同知识领域间的「融会贯通」，同时也拥有了应对复杂问题的有力武器。

制定游戏规则

越复杂的产品，需要考虑的 边界条件 和 异常因素 也就越多。

一个普通的抽水马桶，只需要实现好以下功能就足矣：

• 上水

• 水满停止进水（这也是最难做好，且最容易故障的）

• 排水

但现如今，一个智能马桶需要考虑的问题可能需要一个数十页的文档来专门说明：

• 感应

  • 自动感应冲水
  • 自动开合盖
  • 座圈感应加热

• 保护

  • 漏电保护
  • 水垢清除过滤
  • 电路防水保护

• 调节

  • 水温调节
  • 水量调节
  • 喷头位置调节

• ...

这些看似琐碎的细节，实则是产品成功的关键因素。此时就需要产品策划人员尽可能枚举不同场景下的用户行为（思考路径），让 边界、异常 都**「适得其所」**，这就如同是策划一款游戏，用上帝之手在制定游戏世界内的运行规则。

特斯拉的自动驾驶系统，就需要考虑各种复杂的边界条件和异常因素，如不同天气、道路状况、行人行为等，通过大量的数据分析和测试，不断优化其自动驾驶算法，确保用户的安全和驾驶体验。

产品工作的职责与边界

许多人会下意识地把产品策划的工作理解成是「画图的」，其实不然，只要能将产品逻辑表达清楚，让团队中的其它成员能够 准确地 感知到 ****用户故事 和 游戏规则， 那么即便是在白纸上用草图来呈现原型也一样可以。（但迄今为止我所遇到的「草纸产品」大多是不会用原型工具的空谈主义者

一个好的产品原型，是能够精准表达出交互逻辑的。但根据二八原则，在原型上填充体现 20% 的交互细节往往会耗费整个原型设计中 80% 的时间。再算上非单个原型页面能够体现的跳转、弹出等逻辑不好展现，产品通常会辅以文字来进行解释说明。

这里会有另外一个误区，有些产品会洋洋洒洒写上几万字的产品方案，但其实往往用 关系图 或是 表格 就可以将逻辑表达得很清楚（信息传达的效率：能图不表，能表不文）。

还有些产品本人会成为**「蜘蛛侠」**：像蜘蛛一样在蛛网上四处搜集拼接一切唾手可得的信息，不进行任何加工整理，直接端上一锅大杂烩，让人摸不着头脑不知所云。

一个好的产品方案，应该由逻辑清晰的原型和文字说明共同组成，不求原型图精美细致，不求文字丰富详尽。只要能够做到 让不同角色的人在看完方案后，知道在什么情况下应该做什么样的事，就足矣。

在了解清楚要 解决的问题 和 底层逻辑 后，交互设计师、视觉设计师便会根据产品的原型，来给出设计稿。通常交互设计师更偏重对用户使用行为、心理的研究，更注重 逻辑；视觉设计师更关注美感，更注重 视觉。在 B 端系统中通常不会配备专职的视觉设计，视觉工作由交互设计来兼职完成。

然而在许多团队中，交互、视觉的设计也需要由产品来一并完成，这就对产品的要求更上了一个台阶：产品策划要完成上方提到的种种工作。

结语

作为一名从 SRE 转型到产品策划的工作者，我深切体会到这条道路上的独特挑战。从事产品策划这份工作并不能够像此前写代码时**「0 error, 0 warning」**一样给予自己 及时 的 正反馈，产品工作往往需要更长的验证周期，即便你认为自己已经想得足够周全，最终依然可能迎来铺天盖地的 诟病 和 吐槽。

回顾这一路走来的心路历程，我发现产品工作就像是在玩一个 开放世界游戏：

• 产品方案的制定则如同设计游戏关卡，需要平衡各种规则和机制

• 每个用户都是独特的 NPC，有着自己的思维模式和行为逻辑

• 需要不断探索和解锁新的思维模型，就像在游戏中收集各种道具、尝试各种可能

如果游戏设计地足够精巧，通关的过程没有标准答案，正如每个产品策划的工作者也是在不断探索、试错和成长。但我更愿意相信，通过不断积累和思考，每个人都能找到属于自己的方法。

或许十年后再回头看，今天所写的这些思考也会显得稚嫩。但这正是产品工作的魅力所在 —— 永远有新的问题等待解决，永远有更好的方案等待发现。

欢迎来撩 :)