一提到产品规划，我们不免会进入两个误区。一个是过度形式主义，认为规划就是完成一次汇报工作，虽然形成产品规划文档，但团队真正执行时并不会按照规划文档中的方向进行。另一个是容易形成宏大的产品构思，总想面面俱到，满足客户的所有需求，使得产品规划中的功能繁杂而冗余。
稍微强调两点，规划的目的不是为了汇报，本质是要构建一种全局思维和统筹意识，让协同团队能在产品价值和产品节奏上形成共识。此外规划也并不提倡输出大而全的功能列表，而是要在产品理念（产品主旨）上形成最小价值功能集合。
既然我们做产品规划的锚点是产品价值，到底应该如何进行产品规划呢？产品价值的判断标准又是什么？如何能把它呈现出来让参与者都能理解呢？产品价值如何能与技术资源排序之间产生关联关系？本章我会重点围绕产品规划的六步法为你详细解读，它们分别是：产品概念定位，产品架构，场景定义，能力定义，全功能定义，产品路线图。
01
产品概念定位
Product Planing
产品概念定位，行业还有一些说法，叫‘产品战略’、‘产品主旨’或‘产品理念’。本质上讲的都是同一件事，就是要讲清楚产品的第一性原理和长期愿景，以及遵循的原则底线。简单来讲，产品概念定位包含两个部分，第一，指明产品存在的意义和价值，究竟要为谁解决哪些问题。第二，产品决策都遵循哪些基本原则，哪些事情可以做，哪些一定不能做。而要回答这两个问题，就有必要深刻解析企业战略的内涵。在第五章‘战略的本质’中我提到，企业战略定义的是企业的业务边界，它核心在谈企业为客户、为社会所能创造的价值。产品战略是企业战略的延续，它核心在谈产品究竟能通过什么方式支撑企业战略。
产品战略要以企业战略为依托
不论是企业战略还是产品战略，本质都在服务于同一张价值网络。因此当我们在谈一个产品概念时，不能忽略企业战略的宗旨。谷歌提倡‘不作恶’，谷歌在做任何一个产品决策时，始终要考虑‘产品决策是否可能对人类社会产生潜在的危害’。腾讯的战略愿景是“用户为本、科技向上”。张小龙在多次公开场合发言，始终强调微信‘用户为本’的产品设计理念，例如‘朋友圈’的产品理念，就来自人性中对自我人设的定义，对个人成就的彰显；‘小程序’的产品目标，是为了让用户能在应用之间自然流转，即用即走。腾讯在2018年提出要进入产业互联网，为产业打造数字化工具箱。腾讯产品团队在进行智能座舱解决方案产品设计时，依然遵循‘用户为本’的产品原则，比如在人机交互过程中‘坚决不泄露用户隐私’，利用技术手段‘确保用户数据主权和数据安全’等。
缺乏与企业战略连接的产品风险巨大
产品战略如果缺乏与企业战略之间的连接，就很可能会本末倒置、走向另一个极端。例如滴滴的使命是“让出行更美好”。产品定位是出行服务平台，主要解决不同出行场景下供需不匹配的问题，B端连接司机、帮他们连接更精准的打车客户群体，C端连接用户、为他们提供更高效便捷的打车服务。滴滴早期并未将产品战略与企业战略深度连接，产品迭代过度强化规模化扩张和用户增长，忽略了构建以安全出行为基础的产品能力，因此在用户服务过程出现安全问题。如今我们在滴滴司机端和用户端产品界面上可以看到各种以安全为核心的产品设计理念，例如司机端的信用体系，用户端的安全中心等，本质是在延续‘让出行更美好’的业务战略。
产品战略会随着企业战略而动态调整
产品战略并非一成不变，而是会基于市场竞争环境变化、政策及技术要素的变化、企业战略的变化、以及用户需求变化而动态调整。例如字节跳动将企业战略从C端市场逐步向B端市场转移，因此在产品战略上也要做出相应的调整，比如原本对内服务的火山引擎，需要从产品侧形成更强大的模块化和定制化能力，进化为标准的商业型产品。再比如微软早期主要围绕Windows生态构建C端产品体系，随着微软Windows生态的增长出现瓶颈，CEO纳德拉将微软业务的第二曲线定义为云服务，微软的产品重心也逐步向以云为基础的B端解决方案转移。
看到这里，你也不妨回顾一下，你所在的企业是否有关于使命、愿景或者价值观的战略性描述？然后尝试去回答，你所打造的产品概念定位：该产品究竟在为谁解决那些问题？该产品都遵循哪些基本原则？哪些事情一定不能做？
02
产品架构
Product Planing
第一步产品概念定位更多在谈一种产品的价值理念，一种产品打造的底层原则。但产品具体要怎么落地，却无从下手。这就需要我们将抽象的产品概念进行具象化，产品架构设计就是非常好的手段，以‘帮助核心群体完成特定场景任务’为视角，将产品所需要的功能模块完整呈现出来，进而更好与技术人员进行项目协同。这里稍微强调一点，产品架构并不等于产品经理熟悉的‘信息架构’，也不是数字化转型过程经常提到的‘应用架构’。这三者具体有什么区别呢？
信息架构
信息架构的主要目标是梳理清楚用户的功能入口，即‘用户路径’来提升用户体验。信息架构的对象是产品的‘使用者’，主要由产品经理输出。信息架构中需要定义产品呈现给用户的各个功能模块，用户通过哪些路径触发功能，最优路径是什么。不论B端还是C端产品，都需要进行信息架构的设计，区别在于B端产品复杂度更高，例如需要针对多角色进行不同的信息架构设计，以及要定义不同角色具体的功能权限及数据权限；而C端产品只需要做标准化的信息架构。
产品架构
产品架构的主要目标是梳理清楚产品背后的系统能力，即‘功能集合’来统一团队共识。产品架构的使用对象不是用户，而是产品的‘打造者’，包括产品经理、项目经理、研发工程师等。产品架构一般由产品经理或业务专家输出。产品架构核心以业务场景和用户需求驱动，关注产品如何能通过特定的功能集合满足市场需求。产品架构主要基于完整产品功能的视角，形成可视化的层级关系。
比如对于个人电脑产品而言，就包含硬件模块、软件模块及其他模块。硬件架构中包括处理器、内存、硬盘、主板、显卡、声卡、网卡、电源等。产品的各个子模块之间各司其职，相互协调。例如处理器是电脑的“大脑”，负责执行程序和数据处理；内存是处理器与硬盘之间的桥梁，负责暂存数据和指令；硬盘是存储数据的设备；主板则是各种硬件设备的连接载体；显卡、声卡和网卡分别负责图像处理、声音处理和网络通信。软件架构中包括操作系统、应用程序、驱动程序等。操作系统是管理硬件和应用软件的平台；应用程序是用户直接使用的软件，用于完成特定的任务；驱动程序则是连接硬件和软件的桥梁，确保硬件正常工作并与软件进行交互。除了上述基础模块之外，电脑架构中还包含扩展性接口模块，散热系统及安全系统等。
应用架构
应用架构的主要目标是梳理各个应用系统的功能范围、组件结构层级、接口规范、交互方式等，即明确企业数字化转型都需要哪些业务系统，各个业务系统的应用之间如何有机组合。应用架构需要根据业务总体架构进行设计，包括数据库、数据访问层、业务逻辑层、终端界面层，不同层级之间经由服务接口和数据规范进行连接。应用架构主要由技术团队负责，关注如何更好实现和部署应用程序，包括技术选型、模块划分、数据库设计、接口定义等。简而言之，产品架构解决的是‘做什么’的问题，而应用架构解决的是关于“如何做”的问题，即通过哪些软件系统来执行和优化业务过程。
信息架构、产品架构和应用架构并非毫无关系。信息架构呈现的是前端用户可见的功能层级关系，而产品架构则呈现的是系统所具备的完整产品能力。产品架构是信息架构的基础支撑，信息架构则是产品能力在交互端的外显和可视化。信息架构设计的好坏，会直接影响用户使用产品的效率和体验。应用架构的语境主要围绕软件产品实现，而产品架构的语境则会包含软硬综合系统级解决方案。产品架构的构建思路主要基于不同的产品能力进行结构化拆分，而应用架构主要针对应用程序的实现过程进行结构化拆分。应用架构和产品架构主要是从不同的维度在描述一个IT系统的能力，企业数字化应用架构可能会包含多个产品架构中的模块化能力。应用架构设计的好坏则会影响系统的稳定性和应用性能。产品架构设计的好坏，会影响产品和资源的组织形式以及团队协作的效率。
产品规划过程中，架构设计是非常重要的环节。尤其随着新技术要素比如物联网、大数据和AIGC融入企业的信息化系统，产品技术的复杂度变高，一张清晰的产品架构图不仅能让参与者对产品模块有个全局理解，也方便管理者提前做好对应的资源布局。当团队在谈论需求的优先级或产品排期时，往往会争论不休。这时候如果有一张完整的产品架构图，大家基于架构图中的模块及层级关系来讨论不同模块的重要性和优先级，往往更容易达成共识。此外，产品架构也能让产品经理在梳理产品路线图时，及时查漏补缺，确保各个业务系统之间能相互协同，避免前后端不一致、或者系统上下游缺乏联动的情况。因此，理解架构的原理、学会设计产品架构，是高阶产品经理的必备技能。除了信息架构、应用架构和产品架构之外，我们还需要关注业务架构、技术架构及数据架构，关于架构与系统的关系，产品架构的设计方法，我会在后续通过一个完整章节与你详细探讨。
03
场景定义（服务蓝图）
Product Planing
即便有了大而全的产品架构图，但产品经理始终找不到产品落地的方向，研发始终不知道要开发什么功能。为了进一步推进产品规划工作，我们需要跳出系统能力的视角，进入到以用户，也就是使用者为核心的语境进行思考。这就需要提出一个大家耳熟能详的词：场景。基于场景的产品设计将会成为产业时代的核心方法，它能有效帮助我们过滤出真正对用户有价值的需求，形成最小单元的产品功能闭环。既然场景是产品连接用户的纽带，也是产品战略得以最终落地的基础。那究竟什么是场景？场景都包含哪些要素？如何将这些要素有机融入产品规划当中？
‘场’指的就是时间和空间，‘景’指的是用户使用产品的情景。例如拿外出就餐来举例，如果是首次约会场景，你可能会选择一个安静舒适、格调高雅的餐厅就餐。如果是公司团建场景，你可能会选择娱乐设施齐全、食物丰富的餐厅就餐。场景永远基于用户需求视角，我们对场景的理解就决定了我们选择什么样的产品服务提供给用户。因此，对于C端产品的场景而言，我们更强调‘谁’在‘什么时间、什么地点’做了‘什么事情’，触发了‘什么情绪’。对于B端产品的场景而言，我们更强调在‘什么业务单元’，‘哪个角色’在‘什么时间、什么地点’做了‘什么事情’，然后完成了‘什么目标’。不难发现，C端产品和B端在场景定义的过程中基本语境是一致的，唯一的差别C端产品更注重‘情绪价值’，而B端产品则更注重‘完成目标’。
场景既然是用户需求的深层次表达，那如何才能和我们具体要做的产品功能关联上呢？这就不得不强调‘用户服务蓝图’的重要性。用户服务蓝图就是指我们在不同的产品触点下，给用户提供哪些产品和服务，才能帮助他们完成目标或触发情绪。谈到C端产品的情绪价值，这里我介绍个知识点：峰终定律（Peak-End Rule）。由2002诺贝尔奖得主、心理学家丹尼尔·卡尼曼提出。他发现大家对体验的记忆由两个因素决定：第一个是高峰时刻，不论是情绪高峰还是低谷，都能让人记忆深刻。第二个记忆点就是刚结束的那一刻。
在C端产品服务蓝图设计时，会更强调峰值和终值为用户带来的感受。比如同样是酒店服务场景，亚朵能在众多标准化传统酒店服务中脱颖而出，主要取决于‘用户服务蓝图’设计。例如办理入住时会送你一杯茶解渴，三分钟办完，然后给你做个‘免费升舱’，居住过程也有很多免费的小空间，比如图书馆、健身房、咖啡厅、包括酒店自营的商品选购，退房时送你矿泉水。此外，亚朵采取了会员制的管理模式，不断通过数据积累用户的房型偏好和生活习惯，用户在入住、使用和离店等各个触点可以享受个性化的订阅服务。这里我放了一张宜家的用户服务蓝图设计，欢迎思考，对于宜家的服务而言，用户的峰值和终值都有哪些体验，又能触发哪些情绪呢？
对于B端产品而言，用户服务蓝图的侧重点不是激发情绪，而是提供更多帮助，确保B端角色所对应的业务活动能顺利完成。例如某外卖网站的配送员使用的接单App就属于典型的B端产品，他的核心场景服务触点为‘接单-取餐-配送-送达’。我们在思考B端场景服务蓝图设计时，就不必过度强调‘用户体验’，而是要打造核心产品能力，让配送员可以高效完成送餐服务，以及要考虑到很多突发和异常情景，例如外卖配送车快没电了，或者餐厅有太多订单无法出餐，又或者联系不到用户怎么办？系统有没有能力帮助这个角色，让他顺利完成动作。因此，不论C端产品还是B端产品，场景定义的核心是从大而全的产品架构中，抽象出实现最小业务单元所需要的核心功能，以及从用户使用场景的视角来定义最基本的产品能力，帮助用户完成最终目标。
04
产品能力定义
Product Planing
完成了第三步‘场景定义’的工作，意味着我们的产品规划实施已经进行到一半。我们理解了企业战略和产品战略，并且从产品战略出抽象出基本定位和产品原则。我们也梳理出了完整的产品架构，明白要支撑产品战略落地，具体需要打造哪些产品能力。最后我们通过对场景的理解，定义出了最核心的用户使用场景和服务蓝图，这时候我们已经能做到理解用户/客户的基本需求，能真正从Top-Down(自上而下)的视角找到场景需求和产品功能的结合点，也就是进行产品规划的第四步：产品的能力定义。我们还以外卖配送员使用的接单App为例，来梳理具体需要哪些产品能力。
接单环节：骑手进行身份验证并登陆App，随后骑手能看到待接订单信息，包括餐厅位置、用户地址、预计送达时间、订单金额等，骑手可以选择接受某一订单，系统自动更新订单状态。
取餐环节: 骑手到达商家店铺，点击‘已到达’，数据同步至商家端和用户端，可通过扫描二维码与商家确认取餐。
配送过程：内置地图进行实时路径规划和导航，系统追踪并更新骑手位置，自动同步至用户端。内置沟通工具，骑手与用户、商家之间可以及时通讯。
送达环节：用户在线确认签收，如无法联系到用户、或因路况延时送达，骑手或用户可通过App上报异常，由客服介入解决。
当我们梳理完配送场景的核心能力后不难看出，要满足接单配送的业务场景，除了配送员App，还会涉及到多个产品和子系统的协同，比如用户中心、订单系统、商家管理系统、用户端App、客服系统、定位和导航服务、消息中心、支付中心等。看到这里，我相信你会由衷赞同前面我们提到产品经理的使命，他们绝对不仅是信息的传递着和协同者，还是产品的统筹者和规划者。产品规划的核心目标就是将抽象的产品理念形成具象的使用场景和产品能力，进而转化为开发可以落地的技术语言，也就是产品的全功能列表。
05
全功能定义
Product Planing
很多产品经理容易将需求、能力、功能这几个概念混淆。我稍微澄清一下，需求完全是从‘使用者’视角出发的，它的语境是‘使用者需要完成什么目标’。而能力是从‘产品’自身出发的，它的语境是‘产品需要具备什么样的能力，才能帮助使用者达成目标’。那么最后功能是从‘系统’的视角出发的，它的语境是‘系统具体要形成哪些功能列表进行研发实现’。
简单来讲，需求-能力-功能是逐层拆解的过程，需求指向‘目标’，能力指向‘路径’，而功能是具体的‘执行动作’。对于研发团队而言，他们更关注的是功能而非需求，因为需求无法形成代码，而功能却可以指导代码实现。这时候就需要产品经理从中进行语境的翻译，把用户/业务语境转化为研发‘听得懂、能理解’的技术语境。通常来讲，全功能列表中包含几个重要的字段：所属模块、子模块、功能名称、详细功能描述、相关依赖项、关联需求ID、需求描述、需求来源、优先级等。
为什么需要‘全功能定义’？这里‘全’强调的是功能的完整性和系统性。产品经理很擅长梳理功能列表，但并不是每一位都有意识去梳理‘全功能列表’。这正是规划思想的意义所在，产品规划并不是一次性的行为，而是一个周期性的行为。我们知道随着业务发展，产品对业务的支撑会出现错位情况，比如说当外卖订单增加，每位骑手在同一时间段都会接收到系统同时下发的多个订单，而系统需要做的是为订单配送的先后顺序进行合理排序，而配送员则根据系统的指引高效完成工作。
这时候我们就需要基于新的业务场景形成新的能力定义，比如增加配送调度系统的数据特征维度，进行相应的算法优化，让多订单配送排序更加合理。再比如骑手在骑行过程中很难关注手机屏幕的信息提示（盯着屏幕会有安全隐患），也就意味着无法实时与系统取得交互，那么当产品经理识别到这样一个业务场景，就需要思考如何通过引入新的产品功能解决问题，例如在骑手的头盔上增加语音播报的装置，并与各大业务系统数据打通。
由此可见，业务场景会随着业务不同发展阶段而变化，新的场景对产品能力会提出新的要求，这些新能力需要产品经理持续补充进产品架构图和全功能列表中，形成全局视角。当我们不定期复盘产品能力时，也有助于产品团队管理者进行资源布局的合理优化，例如当外卖员头盔需要带语音功能时，产品团队则需要补充语音产品经理。
产品架构图和全功能列表虽然颗粒度不同，但有一定的对应关系，产品架构是全功能列表的抽象，全功能列表是产品架构中细分模块的细节描述。所谓产品规划，无非就是让产品打造的过程越来越清晰，让每个团队都清楚自己应该做什么。那么规划环节最关键的一步，也就是最后一步，就是输出阶段性的产品路线图。这个过程不仅要决定我们做什么，还要找出做事情的节奏和规律，明确哪些事先做，哪些事后做；哪些事情在某些阶段我们坚决不做。
06
产品路线图（Roadmap）
Product Planing
如果说产品规划的前五步都是铺垫，那么真正驱动产品研发团队执行的，其实是最后一步：产品路线图的制定。产品路线图的核心目标是规划产品未来的发展方向，根据需求优先级，研发能力和资源情况定义关键时间周期内产品的迭代思路。主要分为中长期和短期路线图，中长期聚焦在1-3年的产品发展路线，短期主要聚焦1年以内的发展路线。根据产品形态和业务模式的差异，路线图的制定频次和要求也有所不同。比如对于软硬结合的系统级解决方案，产品迭代周期更长、因此1个季度或者半年制定一次即可；但对于纯软件产品，通常采用敏捷项目管理模式，迭代周期比较短，因此会采用月度规划频次。
产品路线图都包含哪些要素呢？第一，产品的战略宗旨和长期愿景，之所以要在路线图中呈现产品战略，主要为了让功能模块的实现始终以产品价值为原点，产品迭代方向要保持一致性，能力积累有延续性。第二，产品的原则和底线，主要为了避免我们在产品迭代的过程中忘记初心，任何一个功能的规划都不能违背基础原则。第三，模块及关键时间点（Milestone），注意这个时间点并非项目进度时间点，而是产品相关的关键大节点，例如对于C端产品，包括方案设计定稿、产品验收、产品上市等；对于B端产品，包括客户需求确认、方案设计确认、产品交付部署、客户验收等。此外，对于复杂产品体系，我们通常会将大的路线图进行模块拆分，以确保前端产品和后端能力之间可以并行开发，提升研发效率。
最后，我总结下产品规划的具体实施方法，一共有六步：产品概念定位，产品架构，场景定义，能力定义，全功能定义，产品路线图。这里主要指0-1的产品规划需要遵循的步骤，倘若你在负责迭代型的产品，并不需要完全按照这样的顺序。更依赖产品经理自身对业务场景和需求的判断力，例如你负责的产品只服务于小众细分业务场景，那么场景定义工作可能一次就完成了，更大的精力要用在能力定义和架构的优化，用更好的技术手段满足场景。
1. 产品概念定位: 源于企业战略和产品理念，包括两个要素，第一，产品定位，为谁解决什么问题；第二，产品原则，哪些事可以做，哪些坚决不做。
2. 产品架构：主要为落地产品战略，定义出支持业务场景、满足市场需求所需要的产品能力。产品架构关键在于模块层级的颗粒度划分，遵从MECE原则，相互独立、完全穷尽。
3. 场景定义：主要从使用者视角形成对需求的本质理解，C端关注用户使用场景，B端关注业务场景及关键角色和活动流程。
4. 产品能力定义：通过核心业务场景形成对产品能力的布局解读，将场景需求与产品功能连接在一起。
5. 全功能定义：基于业务发展、新场景挖掘不断扩充延展产品架构和功能布局，形成新的产品路线图。
6. 产品路线图：根据需求的优先级，研发能力和资源现状形成阶段性产品迭代方向，形成中长期和短期产品路线图。
