原型图会画、PRD能写，但要走向高阶，产品经理必须具备战略规划和架构能力。这篇文章从「战略路径」到「架构拆解」，一文梳理产品人通往核心价值与业务掌控的能力地图。
之前我写过一篇《年轻人不要随便提意见谈战略》，劝诫年轻人不要随便谈战略。但这个命题对于产品经理而言不成立，想成为产品专家或高级管理者，就不得不谈战略，这是产品经理走向高阶的必经之路。
1.为什么要做战略规划
国家会有五年规划，公司会有长中期战略计划，那么对应到产品经理，也应该要有战略规划，而且这个战略规划是需要匹配公司整体战略的。
产品经理的战略规划能力和业务架构能力是支撑公司业务长期价值与高效落地的核心素养，二者相辅相成。战略规划为产品指明方向，业务架构则将战略转化为可执行的业务框架。
战略规划是产品经理从“做正确的事”出发，结合公司战略或业务战略，并基于市场/用户/公司资源的全局判断，定义产品核心价值与发展路径的能力。其核心在于“方向感”与“前瞻性”。
通俗来说就是明确产品分别在什么阶段做哪些功能，并制定分阶段落地的路线图。
如果你没有好好想清楚你未来半年，甚至1-3年需要做些什么，而完全是走一步看一步，那你就会越走越乱，迷失方向。
没有想清楚未来，就会迷失在现在。
2.怎么做战略规划
那么问题来了，产品经理如何做产品战略规划呢？简单来说，做产品战略规划其实可以按照下方的步骤循序渐进地进行即可。
行业趋势&角色分析
用户需求分析
竞争对手分析
自家公司分析
2.1行业趋势&角色分析
第一步就是要弄清楚自己产品所在行业的情况，了解行业趋势的时候，其实可以问自己如下4个问题。
这个行业有哪些玩家？他们之间的关系是怎样的？行业集中度CR5是多少？
未来几年，这个行业会发生什么变化？在这些变化中会有什么机会和风险？
行业里的玩家会如何抓住变化中的机会？整个行业的价值链是怎样的？
这个行业会涉及哪些角色(用户)？他们的体量有多大？
针对第4个角色分析的问题，我们可以选取音乐行业为例予以说明，下图就是网易云音乐的角色分析。
面对这个问题很多人能想到一部分答案，但想不完整。产品经理在思考这个问题的过程中，就能慢慢推演出下个问题用户需求分析的答案。
做行业角色分析的过程中，我们也能发现哪个角色(用户)存在的机会多，未来的商业价值更大等，进而在做产品战略规划的时候，能提前考虑如何做商业价值变现。
2.2用户需求分析
不同角色其需求是有差异性的，在完成上述步骤后，我们就应该做关键角色(用户)的需求分析。
首先我们可以把关键角色的需求全部罗列出来形成一个需求池，而后我们再看关键角色的一些关键需求有没有被很好地满足，然后再寻求单点突破，在关键需求上做深做透做出差异化。
2.3竞争对手分析
在2.1行业趋势分析阶段，我们就已经找出了相关竞品。关于竞品分析可以参照我之前的文章《万字长文：竞品分析流程框架方法论》，这里不再赘述。
嫌文章长的我这里介绍一个简便易用的方法：罗列出自家产品和关键竞品的二维对比表格，标注出双方产品已经满足/未满足的需求点即可，这样我们的机会点可能就在竞品未满足的需求点里面。
可能有读者会问：我觉得上来直接做竞品分析就可以了，前面2步感觉有些多余没有必要，还浪费了很多时间。但我个人觉得不能跳过也不会多余，原因如下：
市场体量大且竞争激烈的市场一般都高手林立，他们都有自己的核心优势，新入局者如果想复制竞品曾经使用过的策略来抢市场，则很难产生差异化吸引到用户。比如淘宝复制出来的淘特无法狙击拼多多，比如京东想在餐饮领域跟美团PK就得搞点不一样的玩法。
通过步骤1和2，可以帮助产品经理更好更全面的理解这个行业的过去、现在以及将来，并且可以着眼于未来、用未来可能发生的变化来推导现在应该如何规划。
步骤1和2的推演过程，可以帮助产品经理对这个行业有个宏观的认识，形成较为全面的框架体系，如果直接到步骤3，就少了这么一个探索求证的过程。
做竞品分析的时候，需要特别注意一点：我们不仅要看竞品做没做某个功能，还要看竞品是在什么时间、什么阶段以及什么背景下实现了某个功能。
比如我们在做B2B或者B2C电商平台时，都会想到通过吸引外部商家入驻的方式来扩充平台的商品种类和数量，进而让买家能实现一站式购物，同时平台也可以通过抽佣或服务费的方式获得收益。
我们在做竞品分析时，不能只看该平台有无商家入驻功能，还要看是先有的自营还是先有的商家入驻，商家入驻是在平台运营多久之后上线的，是全国全品类放开，还是先局部细分品类试点，如果是试点则需要了解试点了多久。
看似关系不大，实则内有乾坤。了解对手的运营路线和打法之后，对于我们来做决策时多了一些参考，资源调配时也会更有的放矢，就可以按节奏配备商家运营团队，否则太早了会浪费人力，太晚了会影响业务开展。
2.4自家公司分析
在这个阶段，我们需要分析我们公司相比于其他公司的优势在哪里。
可能是资金充足，也可能是技术人才储备，亦或者是供应链资源。基于这个基础，再从上一步所梳理的机会点中挑一些可做的需求出来，最终构成我们未来要实现的功能清单。
我见过很多公司根本不考虑自身实际情况去做产品战略规划的，比如不具备供应链资源，却异想天开想在全国主要城市搞区域前置仓，比如没有资金优势却想着学快驴进货搞终端补贴。
3.业务架构&产品架构&信息架构
产品架构是一位资深产品经理必须掌握的能力，广义的产品架构包括3部分：信息架构、产品架构与业务架构，三者之间的关系是递进式的。
信息架构是最前端的表现层架构。
产品架构是连接业务与用户表现层的产品功能、系统的架构。
业务架构则是包含商业逻辑在内的业务运转机制的架构。
3.1信息架构
信息架构主要是将产品的各个功能、界面信息以最合适的方式展现给用户，比如：菜单导航、页面布局、页面元素、页面层级和跳转流程等都是信息架构的部分。
哪些内容放在哪个位置，各个功能的入口在哪儿，如何减少用户的操作路径和点击步骤，这都是信息架构的内容和范畴，下图是我们常见的电商小程序/APP页面。
信息架构没有对错之分，但却有好坏之别。好坏会直接影响用户体验，影响产品的转化率，影响用户的留存率和推荐率。
因为信息架构是直面用户的，所以很多产品为了减少出错几率，就会像素级的复制竞品的信息架构。所以读者不难发现，很多同类型应用的信息架构也就是前端页面相似度极高。
3.2产品架构
产品架构简单来说就是将很多产品功能(点)抽象化，模块化，并梳理出各个产品模块之间的关联关系，让我们清楚地知道各个模块之间的业务流、数据流转关系。
梳理产品架构的前提，就是上述2.2用户需求分析中我们收集整理需求列表，然后我们就可以基于对业务的理解，对信息流和数据流的理解，而后抽象、整合、归纳出各个功能模块。
产品架构没有统一的标准，但却有个大的前提：就是按功能和模块划分的时候要符合逻辑、符合业务、符合行业，这样内部用户在使用时才能更清晰。
产品架构也可以让我们清楚地知道，产品未来的蓝图是怎么样的，我们当前做了哪些部分，还欠缺哪些部分，继而为后续迭代计划做好准备。
有些人也会将产品架构称之为系统架构或者总坪图，但这种叫法不够严谨。系统架构图还应该包括一些网络服务器以及安全相关的内容。
简言之，产品架构图是面向内部管理层、产品研发体系员工的。
3.3业务架构
要做业务架构，首先得理解公司的业务是什么或者有什么。
我们先看一张B站2025年Q1的财报数据，通过财报我们可以看到B站整体的业务有4个大的版块，营收占比最高的是增值业务，B站对于增值服务的解释是“高级会员计划、直播服务和其他增值服务”。
业务架构的目的就是达到各个业务之间互相配合达到整体最佳协同，同时也能基于战略和商业逻辑，体现出各个系统功能对业务线的支撑，从而实现飞轮效应。
我们可以用一个公式来定义业务架构，业务架构=业务目标+业务流程+业务要素，从公式中我们能看出，最重要的是识别出业务流程中包含的业务要素。
设计好业务架构要考虑的方面比较多，既要做到业务彼此隔离、业务与技术(平台)隔离，又要能从业务架构中能看出整体业务的流程运转、业务产品的能力、业务领域对象等。
为便于理解，我在www.uml.org.cn网站找了一个现成的案例来予以说明。优惠券是电商业务中比较常用的功能，我们以这个实例来展示其最终的业务架构图是怎样的。
业务架构图整体包括：场景层、产品功能层、领域模型层、依赖层，画业务架构图要体现两点出来：业务流向和产品功能。
画业务架构图需要对UML有一定的了解，限于篇幅本文不做展开，有兴趣的读者可以去www.uml.org.cn搜索关键字业务架构图做扩展阅读。
3.4三者的关系
当某个产品它的业务模式和产品表现形式都比较简单时，我们不需要将信息架构、产品架构、业务架构分开考虑，而是统筹在一起即可，有些可能只做信息架构和产品架构即可。
而当我们面临的业务和产品比较复杂时，就需要在产品工作流程中将这3个架构分开思考和设计，从而保证每个架构都思考得足够深入、全面和准确。
在做这3个架构设计时，产品经理既可以从信息架构开始从下往上思考，也可以从业务架构开始从上往下思考。个人建议两种路径都可以试下，从而保证架构的一致性。同时也有助于培养产品经理系统思考的能力。
有读者可能会问，我做产品经理这么多年，压根都没做过这3个架构，公司也没有要求我们做这些架构，还不是一样过来了？
我想说的是初中级产品经理可以不考虑这些，项目赶进度也可以不考虑这些，但如果你想走的更高更远，就需要去思考这些。
这3个架构可以看做是一种产品经理方法论，也可以看做是我们训练逻辑思维和深度思考能力的磨刀石，我们练的越多，系统深度思考能力就会越强。
关于信息架构和产品架构，可以看下《用户体验要素》这本书。
4.结束语
对于资深产品经理而言，做产品战略规划和3种架构的能力，远比画原型写文档的能力重要且高阶得多。
所以，一定要抓住任何机会来训练这方面的能力，大到产品方向，小到产品功能，都不要只考虑现在是什么样子，而是往后思考几年后会是什么样子，再来反推现在应该做什么。
有兴趣的读者可以找些UML和领域驱动设计DDD方面的书籍和文章来看。DDD是一种软件设计方法论，核心思想是通过领域模型将业务逻辑与代码实现紧密结合，旨在通过领域建模解决复杂业务问题，从而提高系统的可维护性和可扩展性。
以上，希望本文能对您有所帮助。