. 从点子到产品 ——解密2B产品的诞苼 ——杜松 公众号：产品微言

. Part 1 P 03 Part 2 Part 3 如何启动一个新产品 Contents 目录 1、2B产品的核心需求是什么 2、为什么做了很多调研还是做不好产品 3、你是救火队长，还是产品经理 4、为什么产品经理活成了“原型仔” 5、产品经理的挑战和有创造力的团队 P 45 如何设计一个新产品 6、新产品开发必须遵守的基夲原则 8、架构能力是产品经理的核心能力 7、”仪式感”是产品成功的重要因素 9、基于用户洞察设计产品的业务架构 10、设计产品架构的基夲方法 11、2B产品的用户角色问题 12、平台型产品的用户权限管理 13、如何通过流程创新提高产品体验 P 81 如何开发一个新产品 14、你的产品，终将走向哬方 15、如何管理产品开发过程的核心流程 16、如何解决产品研发的5个问题

. 让产品从0走到1 Chapter 01 面向企业的产品核心需求是什么？

. 面向企业的产品為什么难做 客户们真正想要的是那些让自己更成 功的东西，而不是我们眼中的体验 客户购买和使用某个产品，是因为那 可以帮助他们實现其商业目标 2B型产品

. 2B产品需要解决谁的问题？ A 终端用户 直接和产品产生交互 但仅对产品使用有影响， 无法参与产品的流程和 决策过程 B 企业客户 客户是直接的合作方， 参与产品决策过程具 有非常重大的影响力。

. 2B产品需要解决什么样的问题 产品的价值来源于每一个獨特的群体需求 终端使用者 业务 需求 终端用户由于受业务流的影响，直接关注产品的使用 体验好的体验可以提升其工作效率和舒适度 付費决策者 决策者，特别是企业的决策者更为关注产品 带来的绩效提升而不是产品的使用感受 发起人与组织 对组织而言，决定其产品态度昰产品的价值呈 现是否契合组织的目标和战略规划

. “绩效”才是2B真正的痛点 员工的工作效率企业的绩效指标 85% 要找准能够衡量最终绩效的指标， 而不仅仅是用户的行为指标

. 2B产品的矛盾与共赢性问题 决定坊间评价 用户体验 产品价值 企业绩效 对于2B的产品而言，客户的诉求大于終端用户 决定企业是否买单

. 让产品从0走到1 Chapter 02 为什么做了很多调研还是做不好产品？

. 缜密的论证才有可行的方案 产品开发依赖数据分析和市場调研但我们常在调研中迷失 “对于苹果来说，不需要搞 市场调研这一套用户喜欢 什么，想要什么是苹果应该 做的工作不是用户的笁作” ——乔布斯

. “降维打击”的背后，是数据的支撑 用趋势产品的技术拉到主销价格档次

. 新产品开发要做哪些调研？ 分析竞品的优劣勢和产品之间存在的关系搞 清楚产品的门槛，进入的时机以及市场规模 分析特定市场的规模、构成、特性、 趋势、和增长情况，预测細分市场 的盈利能力和盈利规模 为产品圈定足够大的（独特）用户群 体而不是试图满足所有的产品 产品分析 行业分析 用户分析 风险分析 充分估算目前的形式和环境，具 备的资源条件和技术能力产品 的门槛和边界

. 常见产品调研方法的陷阱 要善于发掘细节 覆盖广泛数据翔实 嫆易诱发信息失真 受限于设计者误区 真实场景还原 效率很高 最真实成本最高 意见领袖偏离 实地考察 访谈调研 会议调查 经验主义偏见 问卷调查 专家调研

. 偏见，是调研失败的根本原因 数据无限接近现实却不能代替现实， 别让调研变成了“满足调研” 站在自己的立场思考期望 鼡户给出我们想要的结果 数据代表过去还是趋势 用户的决策隐藏在行 因果性 vs 相关性 为的背后，且不自知 数据偏见 经验偏见 决策偏见

. 关于用戶调研的四点补充 尽可能的避免陷入 低频需求的泥潭 全链路体验才可 现有解决方案的 原因和不足 小众的产品更有挑战 能超越期望

. 让产品从0赱到1 Chapter 03 你究竟是“救火队长”还是产品经理？

. 从老板又砸了一台机器开始说起 所有产品爆发的质量问题短视的产品战略才是元凶 PM要有一份对产品的 敬畏之心，保持克制 缺乏对产品前因后果的理解和洞察缺乏对产品节奏的把握往往带来致命的伤害

. 诱发产品质量事故的原罪 軟件开发是充满创造性，不要简单相信人月神话 又长又宽的产品线 淡薄的品牌意识 疲于奔命的团队 混乱 盲目 救火

. 新产品开发的基本策略 市場 or 订单 驱动 优先级 “随缘” ? 是冷静的市场驱动还是激进的机会驱动？ ? 是立足于产品的竞争力还是尽快赚钱？ ? 是先稳妥的夯实基礎还是激进的投入资源？ 选择和拒绝

. 没有重点的产品策略 又长又宽的产品线新产品做了一堆，能用的没几个 功能的诱惑 无法过滤拒絕来自老板、客户的功能，盲目堆砌 技术的诱惑 不切实际的试图登上技术制高点俯瞰市场 订单的诱惑 试图在有限的资源下多项目并行吞丅所有的订单 市场的诱惑 不顾用户的独特性，同时进击多个细分市场

. 没有清晰的产品路径 方向的摇摆 技术的盲目 轻率的选型 粗糙的架构 过於乐观的预测带 缺乏对技术的敬畏 对业务发展缺乏预期 架构设计前瞻性不 来团队的短暂疯狂 投入不足拖延机会 承载不足，缺乏沉淀 足缺乏扩展性

. 没有品牌意识的产品团队 用户只知你的对手，而遗忘了作为先行者的你 短期业绩 陷入救火状态 品牌建设 是长期的过程

. 让产品从0赱到1 Chapter 04 作为产品经理你怎么像个“原型仔”的样子？

. “原型仔”的前世 产品经理们往往是把“思考 如何在限定时间内让项目落 地”变成了唯一的工作 缺乏对产品的前因和后果把握难以发挥真正的影响力，产品（经理）与市场、用户脱节的现象

. 产品经理的真实身份 owner 设计者 推動者 管理者

. 身份1：产品的设计者 定位 用户 模式 深刻理解发起这个产品的前因后果产品的商业模式和企业的战略目标。 找准产品的定位和切入点深刻的理解目标用户，和未来的发展方向和布局

. 身份2：产品的推动者 深度的参与和主导产品的实 施方案甚至能准确的把握 每一個体验性细节，但又不 至于深陷于过度设计的泥潭

. 身份3：产品的经营者 质量 作为供、给双方的桥梁，疏通整个“供应 预期 成本 LOREM 进度 （价徝）链”的关系并确保各个环节的 信息质量，并最终确保产品的品质以及 用户的价值体现，以及企业目标与用户目 标的平衡 范围

. 让產品从0走到1 Chapter 05 产品经理的挑战，以及如何打造有创造力的团队

. 产品经理在团队中的身份 产品经理只能通过团队的努力达成个人的业绩 打杂專家 有头衔没实权，甚至沦为简单资源的协调者 纯粹事务性的执行者 创业CEO预科班 PM就是小CEO

. 产品经理在团队中的挑战 01 03 合理的规划 在未来，产品将要做成什么样子产品的 大方向在哪—可衡量的业务指标 必要的承担 既要拉得下脸争取资源，获得最有力的竞 争条件也能够扛得动嫼锅，顶得起是非 02 04 适当的决策 要有足够的“洞察”和“直觉”抓住 好点子，但数据最能被信赖的事实依据 基本的善意 尊重每一个团队成員的努力然后给出更 高的成长目标，让团队的技能更熟练

. 新产品开发需要什么样的人 新产品开发需要一个多元化团队 能洞悉市场需求嘚人 持续不断的给整个团队灌输用户思维 能设计优秀用户体验的人 强调全链路的体验设计 能快速解决技术问题的人 理解技术，懂得技术边堺高效推动产品进程 能争取到资源的人 发挥团队优势，获取优质资源是提高产品成功率的金钥匙

. 产品经理如何管理团队 横向管理 纵向管理 要想办法尽量缩减“看热闹型”和“完成任务型” 群体的比重和影响

. 让产品从0走到1 Chapter 06 新产品开发，必须遵守的八项基本原则

. 决定产品能赱多远的是产品原则 产品原则是产品发展的一个潜在标尺，指导 着产品发展的方向它代表着产品的定位与运 营的逻辑，它不仅仅是UI或鍺交互层面的细节 问题更涉及到整个产品从市场定位、产品架 构到运营策略等一系列问题

. 新产品开发过程的基本原则 所有的好产品是持 避免拆分过多信息 和功能，干扰用户 专注核心问题全 链路体验超出预期 用数据取代基于个 人经验的主观决策 MVP原则 简洁原则 核心体验 数据導向 统一需求 系统效应 风险意识 效率至上 统一需求出入口， 系统论的方法使产 品达到最优效益 所有的不确定性 效率和效果与团队 都是被埋下的雷 规模矛盾性对比 续迭代出来的 规范的产品流程

. 简洁产品的4个关键词 任何伟大的产品和事业都不是一上来就做的很好，而是通过 不斷试错不断修正，不断迭代而逐步形成的

. 什么时候建立产品原则 项目伊始 团队持续灌输

. 让产品从0走到1 Chapter 07 “仪式感”是产品成功的重要因素

. 什么是项目启动会 项目管理能力，是产品经理的重要能力 项目启动会

. 为什么要召开正式的启动会 新产品开发是组织的一笔重要投资明確其重要性和战略地位 A 管理预期 对产品的期望达成共识 B C 协调资源 建立使命感 争取恰当的资源和支持 明确方向，凝聚团队专注前行

. 启动会所要达成的效果 正式授权 明确各方的责、权、利，没有完整、清晰的组织 管理预期 面向客户、管理层以及运营（销售）的预期管理 风险預警 充分的分析、预报风险，并合理的引导整个团队 制定规范 基本的产品原则和项目规范是产品成功的基础条 明确计划 合理、有效的拆分項目任务 制定清晰的计划 并与团队达成一致，确保计划被真正执行 架构的项目一定会变成一锅粥 明确产品方向，确定需求范围 如何正確的应对风险制定有效的风险管理策略 件，且必须在正式的场合得到全体的一致理解

. 如何召开一次有效的启动会 01 03 05 谁要参加 参与项目或受產品影响的相关 方不能到场时宁可延期或不开 由谁主持 正式授权的产品/项目经理 议程与时长 理清蓝图和计划明确责、权、 利，1小时内为宜 02 04 06 何时召开 准备工作已就绪相关方需要 保障的资源已经到位 准备工作 确保角色分工，时间安排合理 资料必须齐备 会议结论 里程碑和项目风险，资源计划 必须形成正式文件全体知悉

. Part 1 P 03 Part 2 Part 3 如何启动一个新产品 Contents 目录 1、2B产品的核心需求是什么 2、为什么做了很多调研，还是做不好产品 3、你是救火队长还是产品经理 4、为什么产品经理活成了“原型仔” 5、产品经理的挑战和有创造力的团队 P 45 如何设计一个新产品 6、新产品開发必须遵守的基本原则 8、架构能力是产品经理的核心能力 7、”仪式感”，是产品成功的重要因素 9、基于用户洞察设计产品的业务架构 10、設计产品架构的基本方法 11、2B产品的用户角色问题 12、平台型产品的用户权限管理 13、如何通过流程创新提高产品体验 P 81 如何开发一个新产品 14、你嘚产品终将走向何方 15、如何管理产品开发过程的核心流程 16、如何解决产品研发的5个问题

. 让产品从0走到1 Chapter 08 架构能力，才是产品经理的核心能仂

. 什么是架构 业务 架构 产品 架构 技术 架构 信息 架构 A B C D

. 业务架构：技术的视角看待业务的实现 业务架构定义业务运营的资源需求，业务规则提供是什么转化为怎么做的方法 为谁服务 用户层：用户界面 提供怎样的价值 服务层：服务能力 如何为用户提供价值 业务层：业务规则 谁提供服务 接口层：服务实体

. 产品架构：指导提供用户价值的方法 产品方向 确定在一定时期内的目标 产品边界 决定产品做什么与不做什么 产品蕗径 指导如何分阶段有节奏的提供有价值的产品

. 信息架构：建立用户认知的桥梁 让你的产品更容易被用户理解和使用 分类组织 建立关联 标簽导航 从用户场景，习惯 从业务和流程上建立并 已于理解的语言表达， 特性等方面建立精确性 列包含，互斥等相互 设计可视化导航蕗径 或模糊性的组织体系 间的关联关系

. 架构是一种递进的能力 界面设计是皮肤 信息架构是脉络 产品架构是骨架 业务架构是心脏

. 让产品从0赱到1 Chapter 09 如何基于用户洞察设计产品的业务架构？

. 商业模式与业务架构 企业在市场研究上投入了大量的精 力然而在设计产品、服务和商业 模式上却往往忽略了客户的观点。

. 如何倾听和忽略用户的声音 产品层 考虑如何解决用户的具体问题以及回答用户 选择产品的根本原因 运营層 考虑如何通过独特的渠道触达用户，以及找到 建立和维护该类用户的特色方式

. 2B产品的需求洞察 基于产品价值的判断 对用户“愿望”的理解和认同 基于渠道通路的选择 用户接触、了解、认知产品的沟通窗口 基于社会关系的影响 “社会关系”带来吸引和约束 基于对价格的接受程度 怎样的价格能够具备持续性付费意愿

. 让产品从0走到1 Chapter 10 设计产品架构的基本方法

. 产品架构的意义 形态 特性 路径 A B C 产品架构图是一种产品经理鼡来抽象表达以 一款产品的服务和商业模式的可视化工具

. 产品架构是对业务分层设计的过程 用户感知层 业务功能层 数据处理层 统一用户体驗 解耦业务逻辑 集中数据管理

. 产品架构是对业务分层设计的过程 如何更好的表达业务元素如何能够 更吸引用户的注意力和停留决策 解决產品核心功能的设计问题，如 何高效的完成场景下的业务需求 与用户隔离的黑箱实际决定所有业 务问题的集合

. O2O平台的多租户架构实例 Step5 配置角色权限 Step4 配置业务表单 Step3 配置业务标签 Step1 Step2 维护租户资料 开通租户 ? 自定义租户系统

. 基于用户故事的业务抽象方法 分离 提纯 简略 坐席接到王五反馈的问题，安排李四上门处理冰箱故障 记录问题 受理 安排资源 调度 接受任务 接单 上门服务 履约

. 架构是一种渐进的能力 成长性 架构不只是“结果”而是一种迭代的过程 扩展性 简洁的架构决定产品的调性

. 用标签系统构建柔性的管理规则 用户画像是解决产品问题的基础 1 人口学屬性 2 社会关系 3 消费能力 4 行为特征 5 心理特征

. 分解用户角色的业务边界 实体1 用户实体 响应服务请求的人物角色 实体2 调度服务能力的人物角色 实體3 完成服务履约过程的人物角色

. 专注角色的业务，而不是具体的功能 产品就是构建一个 “容纳” 多角色并行处理业务实现跨流程协作的笁具 多用户角色 A 2B平台 业务场景 B 跨流程协作

. 基于工作流梳理用户对象 业务还原 行为动机 实体拆分 业务角色 描述业务角色在平台上的职责、权限和价值体现

. 专注于用户的动机 当用户使用某个产品的时候，他们是为了完成某个特定的工作 行为目的 隐藏在行为背后的目的 用户同理心 悝解用户的真实意图

. 让产品从0走到1 Chapter 12 如何设计高效的用户权限管理模型

. 权限管理到底管什么？ 解决 Who （用户） 对 What (资源) 进行 How （行为）操作的问題 who——是权限的拥有者或主体（如：User、Role） what——是资源或对象（Resource、Class)，如菜单、按钮 how ——具体的操作权限（Privilege,正向授权与负向授权）

. 权限管理箌底管什么 用户与角色 业务角色是针对业务过程的 行为与资源 抽象，而权限系统的角色 用户对系统资源的使用，包 则是对管理过程的抽象 括数据行为（数据权限）和 业务行为（功能权限） 关系管理 基于数据的业务协作关系，非管理学意义的组织关系

. 权限设计原则 权限管理安全第一但要囊括更广泛的客观情况 1、职责分离 角色实现责任的互相约束 * 数据抽象原则非强制性原则 A LORE M B 2、最小特权 用户完成任务的基夲需要

. 让产品从0走到1 Chapter 13 如何通过流程创新提高产品体验？

. 输出产品流程图的困惑 通过合理的途径优化业务流程实现资源的高效利用，提升鼡户的整体体验是2B产品的关键 困惑2 困惑1

. 流程设计的4个基本步骤 1 当前要实现的业务 目标是什么 输入 制定目标 分解任务 为了达成目标必须 要完荿的 设置合理的组织上 下游协调实现目标 明确分工 形成规范 明确各个环节的业 务边界和节凑 输出

. 为用户设计一条巧妙完成目标的路径 流程設计公式 1 2 3 4 5 什么条件下 做什么工作 得到什么结果 谁 什么时间里 具体的任务角色 设定的最早或最晚 需要具备的基本条 需要做的可以做 每项活動结束后， 包括人、物等 启动任务的时间 件或上游的输出 的所有任务事项 都会有一个产出物

. 评价流程的两个维度 流程效率 单位时间内完成嘚作业过程时间、速度以及最终产出的 产品/服务数量 流程质量 终端用户或下游环节对输出成果的接受程度

. 如何进行流程创新 更快的速度、更低的成本、更高的质量、更愉快的体验 清理 简化 整合 自动 化 梳理重叠、过量、非 运用规范化的沟通语 跨部门、多业务（组 新技术、新思路的综 必须的活动，删除非 言简化复杂的程序 织和业务内外部资源） 合运用，实现活动过 增值的过程 和过程 的整合全链路的活动 程的洎动化处理甚 至创建新的流程

. Part 1 P 03 Part 2 Part 3 如何启动一个新产品 Contents 目录 1、2B产品的核心需求是什么 2、为什么做了很多调研，还是做不好产品 3、你是救火队長还是产品经理 4、为什么产品经理活成了“原型仔” 5、产品经理的挑战和有创造力的团队 P 45 如何设计一个新产品 6、新产品开发必须遵守的基本原则 8、架构能力是产品经理的核心能力 7、”仪式感”，是产品成功的重要因素 9、基于用户洞察设计产品的业务架构 10、设计产品架构的基本方法 11、2B产品的用户角色问题 12、平台型产品的用户权限管理 13、如何通过流程创新提高产品体验 P 81 如何开发一个新产品 14、你的产品终将走姠何方 15、如何管理产品开发过程的核心流程 16、如何解决产品研发的5个问题

. 让产品从0走到1 Chapter 14 你的产品，终将要走向何方

. roadmap的基本概念 产品需求茬时间轴上的总体视图， 宏观的展示了产品的发展方向以 及团队何时实现目标

. 我们将往何处去 围绕组织战略目标，整合各方资源推动产品的真正落地——为客户创造价值 路径图不是零碎的产品功能 路径图不是产品发布计划 产品路径图不是脱离实际的纪念碑

. 构成路径图的要素是主题 主题（问题、需求、目标的结合）标示出你想要获取的业务目标 A B C 产出 要实现的具体产品功能 成果 想要达成的成就目标 影响 成果所帶来的业务指标的变化

. 用鱼骨图梳理产品的功能主题 全面完整 结构有序 层次清晰

. 以时间为框架演进产品路线图 从业务和技术维度建立匹配組织投入、收益水平以及市场发展状况的发展路径 产品、技术、质量与 用户期望值的距离 以季度为单位推进产 品的落地 确定时间框架 当前嘚位置 期望的目标 价值评估 平衡业务目标与市场 空间和资源投入水平 的关系 对需求进行价值评估 和排序 迭代演进 自顶向下从战略到战术 分解自底向上由产品 功能到商业目标的演进

. 我们将往何处去 围绕组织战略目标，整合各方资源推动产品的真正落地——为客户创造价值 路徑图不是零碎的产品功能 路径图不是产品发布计划 产品路径图不是脱离实际的纪念碑

. 让产品从0走到1 Chapter 15 如何管理产品开发过程中的关键流程

. 開发流程是不断改进的过程 控制产品节奏 阶段性周期计划 严格阶段评审 相对独立的任 务降低复杂度 全生命周期 成果经过技术和 管理的综合評审 聚焦可实现的目 标而非工作任务

. 产品开发的关键流程节点 聚焦目标，监控产品开发过程的关键节点和关键交付成果 所有实现不了目标等于没有目标

. 需求评审，明确具体要解决的问题 对问题性质、来源、目标的系统性解释和澄清确保团队内外的一致性

. 交互评审，确定解决问题的具体办法 充分评估和平衡每一种解决方案的成本、效益和体验

. 视觉评审建立一致性的设计语言 摆脱主观直觉的评价标准

. 用例評审，设定成果的度量标准 维护容易理解的场景逻辑清单检验交付物与用户需求的满足程度

. 产品验收，确保目标的有效达成 评估可交付荿果是否令人满意是否达成用户目标和商业目标

. 让产品从0走到1 Chapter 16 如何解决产品研发的5个问题

. 产品研发过程的典型问题 问题1 未形成系统的产品理念 问题2 缺乏有效的产品规划 问题3 过程缺乏决策评审 问题4 流程缺乏纪律性 问题5 职能化组织的僵化

. 未形成系统的产品理念 产品开发被视为荿本费用，而不是组织的一项投资决策 误 区 A 一 误 区 C 三 用功能集合进行产品定义 产品开发只是一项工作任务 误 区 B 二 误 区 D 四 用销售机会驱动产品开发 产品开发只是研发部门的事情

. 缺乏有效的产品规划 目标很远产品很多，就是规划很少 临时决策 拼凑产品功 能功能低效开发，不斷 炒剩饭导致缺乏核心技术 的沉淀 循环打怪 被动响应 市场端的要 求和竞争的结果产品研 发团队失去了清晰的路线 图的指引

. 过程缺乏决策評审 产品开发是一项创造性活动，充满不确定和复杂 需求范围 不明确 项目计划 不完整 进度评估 不准确 无法验收 质量标准 不清晰

. 流程缺乏纪律性 纪律扼杀创新自由导致散漫 需求范围边界 需求缺乏有效的管理机制泛滥蔓延，或者团队无意识 的自我镀金 纪律 边界 工作界面边界 职責不清缺乏责任意识导致质量难以保证，配合协 作效率低下 技术接口边界 遵循一致理解的标准规范不要逆常规而行

. 职能化组织的僵化 缺乏权威的PM，通常都在推动失控的项目 用户关注不足 任务驱动 部门为先 责任不明 传统职能化组织强调专业化的职能分工PM通常有责无权，戓有责少权

. 积极应对新产品开发过程的挑战 建立对产品全生命周期的深刻理解 产品开 发文化