新入职的产品经理,如何在1周内针对B端产品输出规划和路径?作者结合相关案例,分享相关产品规划方法论,希望对你有所帮助。
一、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个月工期)?
- 如果投入成本超1个月,则优先级下调一级;
- 如果能力不够通用,则优先级也下调一级;
- 如果不是产品关键能力,则优先级也下调一级。
最终形成一个规划:优先做P0项目,其次做P1项目。
六、晚餐时刻:吃完散席,下次再聚
1、B端产品设计是微积分模式,而C端产品是概率论模式。所以B端产品规划/设计可以【以终为始,日拱一卒】,而C端产品规划,则只能【小步快跑,快速迭代】
2、 B端产品设计/规划,遵循【以终为始,全局设计/规划;从始至终,最小闭环落地】的产品原则,解决规划无章法、产品方案设计不全面、产品路径不合理等,导致前后迭代返工、相互矛盾等问题。
3、同时,一定优先遵循【需求是1,方案是0】的产品方法论。
发表回复