从点子到产品，解密2B产品的诞生

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

2. 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个问题

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29. 面对一个新产品，第一步做什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45. 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个问题

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

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

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

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

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

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

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

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

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

55. 洞察用户的痛苦，和他的期望

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

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

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

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

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

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

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

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

64. 让产品从0走到1 Chapter 11 2B产品的用户角色问题

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

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

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

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

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

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

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

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

73. 传统权限控制与RBAC模型 Role-Based Access Control——基于角色的访问控制用户权限用户1 权限1 用户2 角色2 用户N 权限N 用户用户组角色权限用户1 角色1 权限1 用户2 角色2 权限2 用户N 角色N 权限N 基本模型RBAC0、角色分层模型RBAC1、角色限制模型RBAC2、统一模型 RBAC3

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

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

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

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

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

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

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

81. 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个问题

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

105. THANK you 微信：1393901510 公号：产品微言邮件：dosong@foxmail.com