新入职的产品经理，如何在1周内针对B端产品输出规划和路径？作者结合相关案例，分享相关产品规划方法论，希望对你有所帮助。
为什么这么说？
举个例子。
如果你入职一家HR SaaS企业（即面向B端企业，提供组织人事、招聘管理、绩效考核、考勤管理、工资税收、社保对接、学习培训等服务），主要负责考勤管理方向，你会如何进行产品规划与迭代？
如果你入职一家互联网娱乐企业（即面向C端用户，提供图文资讯、短视频、中视频、直播等服务），主要负责其中的短视频平台的产品迭代，你又会如何进行产品规划与迭代？
显然，这二者之间的产品规划路径，一定有所差异。原因是：
HR行业：它就像上学时，所有考试内容都在教学大纲以内，只要你规划合理且努力学习，就可以取得不错的分数。比如：
娱乐行业：它就像旅游时，你的每个决策都会导致遇到不同的人、发生不同的事儿、看到不同的风景，最终的体验也会天差地别。比如：
所以，B端产品规划/设计可以【以终为始，日拱一卒】，而C端产品规划/设计，则只能【小步快跑，快速迭代】。
这就像是微积分与概率论的差异。
前者目标、需求相对明确，关键是探索、设计、规划最优路径，从而快速抵达终点。比如计算一滩水的面积，只要把它分拆成足够细的颗粒度，则一定可以达成目的。
后者目标、需求不明确，路径选择差异巨大，则只能通过不断预测、行动、调整，最终才能抵达目的地。比如让你给新同事安排一顿午饭，每个同学的口味、偏好、忌口都有差异，无法事前预测，只能边预测、边沟通、边调整，最终才能确认。
因为【B端产品是微积分模式】，所以应遵循【以终为始，全局设计/规划；从始至终，最小闭环落地】的产品原则。
举个例子。
笔者当年从教育行业转到HR SaaS行业，负责考勤管理系统（一个SaaS系统中的子系统）。入职第一周的任务就是1周内完成某竞品的深度调研，并确认系统重构方案以及未来3-6个月的规划。
当时这个任务在内部已进行了2个多月，产品方案与需求文档均已完成80%以上，但过程中发现方案不佳，产品逻辑无法闭环，不能继续往下推进，只能推倒重来。
另一边研发同学“嗷嗷待哺”，等着方案确认后，快速落地。
基于【需求是1，方案是0】方法论的指引，围绕【需求】跟【方案】花了1周多时间，笔者做了以下输出：
首先是需求上，梳理了当前待解决的1736条需求情况，明确需求迭代路径。
基于当时的需求情况，明确了产品路径，主要拆分为三大期：分别围绕【排班】、【加班和假期】、【报表】模块。
决策逻辑是：权衡需求量、目标客群、场景关键度三个要素。
最终综合权衡后，优先级是：排班、加班、假期、报表、打卡。所以一期是排班、二期是加班和假期（其实这二者可分拆，只是当时没细拆）、三期是报表。
其次是方案上，主要输出三张图：流程图、产品架构图、实体关系图，就像财务上的三个报表（损益表、资产负债表、现金流量表）一样，对于一个新业务、新系统的梳理、设计来说，这三张图也是B端产品最基础且最有效的工具。
至此，需求与产品路径已然清晰，但如何落地依然是个问题。
当时就聚焦【一期：排班】以及【二期：加班】两部分，遵循最小闭环和前后依赖两个逻辑，分拆成N个子项目，每个子项目之间相互独立，互不影响，最终逐步进行迭代。
最终，历经半年多，完成了既定规划的一期排班与二期（加班部分），内外部的客户反馈不错。同时，也实现了考勤模块多年来，在内部【最佳产品功能】竞选中零的突破（每月1次，产品功能满意度>4分（5分制），且投票客户数>20人），奖励2000元团建奖金）。
特别说明：实际最后并未走重构的逻辑，而是基于【需求优先】原则，实行优化不合理结构与需求并行的方式（至于原因，可见总结部分）。
如果总结整个过程的话，可能对你有以下几个参考价值：
第一，遵循B端产品的【以终为始，全局设计/规划；从始至终，最小闭环落地】产品原则。
比如全面梳理需求，然后聚焦关键需求；
全面梳理产品架构，然后聚焦关键模块；
全面梳理产品实体关系图，然后聚集关键实体优化；
全面梳理规划，然后聚焦第一期闭环。
最终明确关键产品路径与规则，并进一步聚焦到每一个独立可上线的项目上，逐步迭代直达终点。
第二，遵循【需求是1，方案是0】的产品方法论。
起初，重构是笔者接收到的关键任务，聚焦点都在研究各类竞品的架构设计，因当时据说系统已经迭代了好几年，已到了无法继续迭代新需求的程度。
但重构解决什么问题？如果重构投入巨大，投入产出比是否合理？
最终破局点也是在全面梳理完需求，拿到对应的需求情况，以及明确产品路径后，才说服了整个团队，从现在看，无疑是一个正确的决定。
第三，遵循【需求价值 = 新价值-旧价值-替换成本】的产品方法论。或采用产品价值 = 用户价值 + 客户价值 + 商业价值 – 用户情绪成本 – 客户情绪成本 – 服务成本。
重构的话，唯一产生的价值就是【商业价值】，同时，对用户价值、客户价值几乎为0，用户与客户的情绪成本将激增（因重构就意味着更多产研资源投入，对需求的响应速度骤减）。
换句话说，新价值有限，替换成本高，明显不划算。
上面案例具备一定特殊性（即面对的是新环境，重大项目的规划与设计），如果放到日常产品规划与迭代中，是否还可适用？
从上述规划中可知，落地【加班升级】与【综合工时】两个子项目时，如何进行产品方案设计，以及确认演化路径，成为了下一步的重点。
B端产品规划与设计都是微积分模式，所以为了避免思考不周、路径不清，导致扩展性不足、前后返工等现象。
设计方案之初，依然遵循【以终为始，全局思考；从始至终，最小闭环】产品原则，将【全局】聚焦在【加班】模块的设计，而将【局部】聚焦在当前可落地解决的能力之上。
关键点就是：全面梳理与抽象【加班】相关的能力，包含当前已有能力、当前紧急需补齐的能力，以及未来需扩展的能力。
同时，还需梳理清楚，下一步要做的【综合工时】与【加班升级】之间的关联性，以及其与当前系统的关联性。
以此类推，当后续要进行迭代升级【假期】模块时，也遵循对应产品原则进行设计。
特别说明：经过前期的迭代与思考，假期演化路径设计时，进行了两点的升级：
遵循【以终为始，全局设计/规划；从始至终，最小闭环落地】产品原则。
B端产品功能模块多，系统逻辑复杂，客户需求分散等特性，决定了产品规划的复杂度。
经过一段时间的探索，笔者有两个亲测有效的思路。
第一，战略上必须决策，有舍有得。笔者所负责的考勤模块，1年多时间解决了1000+条需求，确实提升了对应系统的能力，却依然还有4600+条需求待解决。
显然，如果继续采用这样的产品路径，并不是一种好策略。资源有限，需求无限，必须进行战略决策，进行产品规划的取舍。
聚焦主要围绕这么几个方向展开：
经过反复的讨论与数据验证，最终形成以下决策：
用户价值优先（即考勤HR/业务员为主），聚焦三大行业（你看不见，看不见）的X型企业（不可说，不可说）的通用型需求，且不做重大型项目（一般指超过1个月以上周期）
第二，全面梳理路径，贴合战略落地，全面权衡产品能力、需求量、成本，形成最终项目规划。
放弃P2/P3级别需求，聚焦P0、P1需求。
再进一步权衡P0、P1需求，是否通用/关键产品能力？是否投入成本大（超1个月工期）？
最终形成一个规划：优先做P0项目，其次做P1项目。
1、B端产品设计是微积分模式，而C端产品是概率论模式。所以B端产品规划/设计可以【以终为始，日拱一卒】，而C端产品规划，则只能【小步快跑，快速迭代】
2、 B端产品设计/规划，遵循【以终为始，全局设计/规划；从始至终，最小闭环落地】的产品原则，解决规划无章法、产品方案设计不全面、产品路径不合理等，导致前后迭代返工、相互矛盾等问题。
3、同时，一定优先遵循【需求是1，方案是0】的产品方法论。
专栏作家
邢小作，微信公众号：邢小作之家，人人都是产品经理专栏作家。一枚在线教育的产品，关注互联网教育，喜欢研究用户心理。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。