The “What” - 从迷雾到蓝图，锻造产品的灵魂骨架

从用户需求到产品蓝图

最新推荐文章于 2025-10-22 06:30:00 发布

原创最新推荐文章于 2025-10-22 06:30:00 发布 · 921 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#软件工程 #产品经理 #设计语言 #sketch #figma #经验分享

组织建设同时被 3 个专栏收录

16 篇文章

订阅专栏

从灵光一闪到全球发布

16 篇文章

订阅专栏

产品设计

10 篇文章

订阅专栏

有小伙伴阅读了从灵光一闪到全球发布：构建产品创新的“价值环”框架后，对于其中第二段的内容“Phase 2: The “What” - 产品建模与系统设计”提出了一些疑问，针对这一段，我们再做一些细致的展开。

“What”阶段是整个产品研发中最激动人心也最容易迷失的环节。它是一场在“用户价值的星辰大海”与“技术实现的大陆板块”之间的航行。

在这之前也可前置阅读: 产品基础训练 - Persona[用户画像] 帮助此文的理解。

Phase 2: The “What” - 从迷雾到蓝图，锻造产品的灵魂骨架

如果说 Phase 1 的“Why”为我们点亮了北极星，指明了方向，那么 Phase 2 的“What”就是绘制我们航向北极星的精确海图。这不仅仅是罗列功能，而是一场融合了用户同理心、团队智慧与架构远见的“创世”活动。

在这里，我们不再问“为什么”，而是开始探索“是什么”与“长什么样”。这是一个将无形的用户需求，锻造成有形的产品蓝图和系统骨架的炼金过程。

奏鸣曲：关键输入 (The Overture: Key Inputs)

在开启这场激动人心的创造之旅前，我们需要备好行囊。这些输入不是官僚主义的文档，而是我们航行的罗盘和燃料。

理论知识: 每一个伟大的“What”都源于一个清晰的“Why”。输入决定了输出的质量。我们需要的是能够激发同理心和指明方向的情报。
实操建议:
1. 产品宪法 (The Constitution): 这是来自 Phase 1 的“产品简报”。它必须被打印出来，贴在墙上，成为一切讨论的基石。每当争论不休时，所有人都要回到这里，扪心自问：“我们正在做的事情，是否服务于这个核心价值？”
2. 鲜活的用户画像 (Living Personas): 别让用户画像只是PPT里的一张照片和几个标签。把它人格化！为“他/她”建立一个档案，包含痛点、期望，甚至是他/她可能会说的话。这是 Design Thinking 中“Empathize”的精髓。
3. 战场地图 (The Battlefield Map): 简洁的市场与竞品分析。我们不关心竞品有多少功能，只关心它们是如何（或未能）解决我们“宪法”中定义的核心问题的。
操作样例: 以我们之前的“企业内部知识库”为例：
- 产品宪法: “通过智能搜索和专家网络，让员工在30秒内找到答案，而不是花费30分钟。”
- 用户画像: “码农张三，入职3个月，因环境配置问题卡住，在公司庞杂的文档库中搜索了45分钟无果，焦虑地不敢打扰资深同事。” 这就是我们要拯救的人！
- 战场地图: “竞品A是文件列表，搜索烂；竞品B是论坛，信息陈旧且无人维护。” 这就是我们要超越的现状！

炼金术：核心活动 (The Alchemy: Key Activities)

装备齐全，现在开始真正的“炼金”。这是一个发散再收敛的创造过程，每一步都至关重要。

1. 同理心之旅：用户故事地图 (User Story Mapping)

理论知识: 在谈论功能之前，先和团队一起“扮演”用户。用户故事地图是一个强大的可视化工具，它将用户的行为按时间轴展开，让我们看到产品的全貌和用户的真实动线。
实操建议: 找一面大白板（或使用其它在线工具）。横轴是用户使用产品的主要步骤，纵轴是每个步骤下可以做的具体事情（用户故事）。这不仅仅是PM的工作，请务必让工程师和设计师全程参与！ 工程师会从实现角度发现隐藏的复杂性，设计师则能洞察交互的流畅性。
操作样例: 为知识库绘制故事地图：
- 横轴 (主题): 遇到问题 -> 描述问题 -> 查找答案 -> 验证答案 -> 解决问题/求助
- 纵轴 (故事):
  - 在查找答案下，可能会有：通过关键词搜索、按标签筛选、浏览热门文档、查看我收藏的内容等。
  - 我们立刻会发现，“查找”是核心，需要投入最多精力。

2. 创意风暴：结构化的“怎么做” (Structured Brainstorming)

理论知识: 纯粹的“头脑风暴”往往会失控。我们需要的是有引导、有规则的创意迸发。采用 Design Thinking 中的 “How Might We… (我们如何才能…)” 句式，将问题转化为充满机遇的挑战。
实操建议:
1. 设定明确的 HMW 问题: 基于用户故事地图的痛点，例如：“我们如何才能让张三在不知道精确关键词时也能找到答案？”
2. 先发散后收敛:
  - 发散 (5分钟): 每个人独立思考，在便签上疯狂写下点子，无论多荒谬。
  - 分享 (10分钟): 轮流分享，不许评判，只能提问澄清。
  - 聚类 (10分钟): 将相似的点子归类，并给每个类别起个名字。
    . 投票 (5分钟): 每人手握三票，投给自己认为最酷、最有价值的点子。
操作样例: 针对上述HMW问题，可能出现的点子有：AI智能推荐、相关问题联想、“找专家”按钮、可视化知识图谱。

3. 价值试炼：功能优先级排序 (Feature Prioritization)

理论知识: 资源永远有限，我们必须做出取舍。一个产品的伟大不在于它有多少功能，而在于它的核心功能做得有多好。价值驱动是这里的唯一准则。
实操建议: 使用简单直观的工具，让决策过程透明化。价值-复杂度矩阵 是最好的选择。
1. 横轴: 开发复杂度 (低 -> 高)
2. 纵轴: 用户价值/商业价值 (低 -> 高)
3. 将头脑风暴出的点子放在这个四象限图中。
- 高价值，低复杂度 (右上): Quick Wins! 这是我们MVP（最小可行产品）的核心！
- 高价值，高复杂度 (左上): Big Bets! 需要重点规划的战略功能。
- 低价值，低复杂度 (右下): Fill-ins. 可做可不做，有空再考虑。
- 低价值，高复杂度 (左下): Money Pit! 坚决避免！
操作样例: 关键词搜索是高价值、中复杂度；“找专家”按钮是高价值、低复杂度；可视化知识图谱是高价值、高复杂度。那么MVP就应该包含“关键词搜索”和“找专家”功能。

4. 蓝图绘制：C4架构协作坊 (C4 Modeling Workshop)

当然，这一部分我们将会在下一篇分享中进一步细化，事实上这对于很多团队也依然存在着巨大的挑战。

理论知识: 在这里，产品经理和系统架构师的角色深度融合。PM定义了“需要什么”，架构师则开始勾勒“如何实现”的骨架。C4模型是最好的沟通语言，它让技术和非技术人员都能理解系统。
实操建议:
1. C1 (上下文图) 共创: 再次拿出白板，PM和架构师一起画出系统的核心、用户和外部依赖。这个过程能确保双方对系统的边界和交互有共同的认知。
2. C2 (容器图) 定义: 架构师主导，向PM和团队解释高层次的技术方案。例如：“我们将用一个Web应用承载前端，一个API服务处理逻辑，一个搜索服务专门负责搜索。” PM需要确认这个结构能否支撑产品愿景和未来的扩展。
操作样例: 正如上一篇文章所示，C1图清晰地展示了“员工”和“管理员”如何与“知识库系统”交互，而C2图则将这个系统拆解为Web应用、API服务、数据库和搜索服务等几个关键的技术“容器”。

工匠的工具箱 (The Artisan’s Workshop: Key Tools)

无限画布: - 用于用户故事地图和头脑风暴，是团队思想碰撞的游乐场。
具象化魔法: Figma, Sketch - 用于创建线框图和交互原型，让想法看得见、摸得着。
唯一的真相源: 钉钉文档, 飞书, Confluence, Jira - 记录PRD、用户故事和开发任务，确保信息同步。
结构的语言: diagrams.net, PlantUML, Mermaid.js - 绘制C4图，让系统架构清晰、明确、易于维护。

宝藏：关键输出 (The Treasure Chest: Key Outputs)

当迷雾散去，我们收获的是指引后续所有工作的宝藏。

有生命力的产品需求文档 (Living PRD): 它不是一本写完就扔的字典，而是包含用户故事、验收标准、非功能性需求的“活”文档。它会随着认知深化而迭代。
可交互原型 (Interactive Prototype): 一个可以点击的、模拟真实产品体验的原型。它是对PRD的最好补充，能够让所有干系人（包括投资者和测试用户）直观感受产品的价值。
架构设计文档 (Architectural Design Document - ADD): 包含了C1、C2图、技术选型决策以及最重要的——关键技术取舍（Trade-offs）。例如：“我们选择Elasticsearch是为了强大的搜索能力，但需要接受它较高的运维成本。”
分阶段的路线图 (Phased Roadmap): 清晰地定义了MVP包含什么，以及后续版本可能探索的方向。它为团队提供了短期焦点和长期愿景。

完成上面的工作内容，“What”阶段的航行完成。

我们不仅产出了一堆文档，更重要的是，整个团队对产品的形态、价值和实现路径达成了深刻的共识。

我们带着一张清晰的海图，满怀信心地驶向下一阶段——“How”的工程实现。