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