B端产品是微积分模式，而C端产品是概率论模式
为什么这么说？
举个例子。
如果你入职一家HR SaaS企业（即面向B端企业，提供组织人事、招聘管理、绩效考核、考勤管理、工资税收、社保对接、学习培训等服务），主要负责考勤管理方向，你会如何进行产品规划与迭代？
如果你入职一家互联网娱乐企业（即面向C端用户，提供图文资讯、短视频、中视频、直播等服务），主要负责其中的短视频平台的产品迭代，你又会如何进行产品规划与迭代？
显然，这二者之间的产品规划路径，一定有所差异。原因是：
- HR行业：它就像上学时，所有考试内容都在教学大纲以内，只要你规划合理且努力学习，就可以取得不错的分数。比如：
- 政策明确：即《劳动法》和《劳动合同法》
- 业务明确：即人员流转、人员招聘、绩效考核、假勤管理、工资税务、社保、组织培训等
- 需求明确：合规、降本、增效
- 娱乐行业：它就像旅游时，你的每个决策都会导致遇到不同的人、发生不同的事儿、看到不同的风景，最终的体验也会天差地别。比如：
- 政策变化：新鲜事物的出现，政策也是边摸索边制定（当然，此处指的是10-15年前，而不是现在）；
- 业务变化：上半年可能还是图文，下半年就会变成短视频，明年可能又变成娱乐直播，后年可能就变成电商直播；
所以，B端产品规划/设计可以【以终为始，日拱一卒】，而C端产品规划/设计，则只能【小步快跑，快速迭代】。
这就像是微积分与概率论的差异。
前者目标、需求相对明确，关键是探索、设计、规划最优路径，从而快速抵达终点。比如计算一滩水的面积，只要把它分拆成足够细的颗粒度，则一定可以达成目的。
后者目标、需求不明确，路径选择差异巨大，则只能通过不断预测、行动、调整，最终才能抵达目的地。比如让你给新同事安排一顿午饭，每个同学的口味、偏好、忌口都有差异，无法事前预测，只能边预测、边沟通、边调整，最终才能确认。
新入职产品经理，如何在1周内，输出产品规划与路径？
基于【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端产品规划与设计都是微积分模式，所以为了避免思考不周、路径不清，导致扩展性不足、前后返工等现象。
设计方案之初，依然遵循【以终为始，全局思考；从始至终，最小闭环】产品原则，将【全局】聚焦在【加班】模块的设计，而将【局部】聚焦在当前可落地解决的能力之上。
关键点就是：全面梳理与抽象【加班】相关的能力，包含当前已有能力、当前紧急需补齐的能力，以及未来需扩展的能力。
同时，还需梳理清楚，下一步要做的【综合工时】与【加班升级】之间的关联性，以及其与当前系统的关联性。
以此类推，当后续要进行迭代升级【假期】模块时，也遵循对应产品原则进行设计。
特别说明：经过前期的迭代与思考，假期演化路径设计时，进行了两点的升级：
- 需求量：将当前对应能力的需求情况，同步加入到演化路径图中，让它的优先级显得更清晰；
- 能力颗粒度：将假期相关的能力颗粒度，拆分的更佳独立、细致，就像高清地图一样，让需求的颗粒度显得更清楚。
如何进行B端产品规划？
遵循【以终为始，全局设计/规划；从始至终，最小闭环落地】产品原则。
B端产品功能模块多，系统逻辑复杂，客户需求分散等特性，决定了产品规划的复杂度。
经过一段时间的探索，笔者有两个亲测有效的思路。
第一，战略上必须决策，有舍有得。笔者所负责的考勤模块，1年多时间解决了1000+条需求，确实提升了对应系统的能力，却依然还有4600+条需求待解决。
显然，如果继续采用这样的产品路径，并不是一种好策略。资源有限，需求无限，必须进行战略决策，进行产品规划的取舍。
聚焦主要围绕这么几个方向展开：
- 目标行业：全行业 vs 核心行业，哪几个行业优先？
- 目标企业规模：初创企业（0-50人）vs 中小企业（50-200人）vs 中型企业（200-700人） vs 大型企业（700-2000人） vs 巨型企业（2000-10000人及以上），哪个规模优先？
- 目标角色：用户价值优先（即考勤HR/业务员为主） vs 客户价值优先（即企业CEO/老板为主） vs 企业商业价值优先（即企业科技能力/营销能力为主）？哪个角色的需求优先？
- 需求类型：关键行业的重大型需求 vs 全行业通用性需求 vs 实施/销售/续费卡单需求 vs 付费的定制化需求？哪种类型的需求优先？
经过反复的讨论与数据验证，最终形成以下决策：
用户价值优先（即考勤HR/业务员为主），聚焦三大行业（你看不见，看不见）的X型企业（不可说，不可说）的通用型需求，且不做重大型项目（一般指超过1个月以上周期）
第二，全面梳理路径，贴合战略落地，全面权衡产品能力、需求量、成本，形成最终项目规划。
全行业需求量大，目标客群需求量也大，则优先级高（P0）；
全行业需求量小，目标客群需求量大，则优先级可调高（P1）；
全行业需求量大，但目标客群需求量小，则优先级适度放低（P2）；
全行业需求量小，目标客群需求量也小，则可暂时忽略（P3）。
放弃P2/P3级别需求，聚焦P0、P1需求。
再进一步权衡P0、P1需求中的通用/关键产品能力与成本。
如果投入成本超1个月，则优先级下调一级；
如果能力不够通用，则优先级也下调一级；
如果不是产品关键能力，则优先级也下调一级。
最终形成一个规划：优先做P0项目，其次做P1项目。
晚餐时刻：吃完散席，下次再聚
1、B端产品设计是微积分模式，而C端产品是概率论模式。所以B端产品规划/设计可以【以终为始，日拱一卒】，而C端产品规划，则只能【小步快跑，快速迭代】
2、 B端产品设计/规划，遵循【以终为始，全局设计/规划；从始至终，最小闭环落地】的产品原则，解决规划无章法、产品方案设计不全面、产品路径不合理等，导致前后迭代返工、相互矛盾等问题。
3、同时，一定优先遵循【需求是1，方案是0】的产品方法论。
4、相关文章推荐：
你有方法论吗？
高阶产品如何处理需求（附案例）？
