如何在入职1周内,输出产品规划?(附案例与方法论)

16 评论 7846 浏览 215 收藏 18 分钟

新入职的产品经理,如何在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】的产品方法论。

专栏作家

邢小作,微信公众号:邢小作之家,人人都是产品经理专栏作家。一枚在线教育的产品,关注互联网教育,喜欢研究用户心理。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 从您这篇文章上感受到了自身与优秀产品经理之间的差距与不足,希望大佬以后能再输出点干货,让我们学习学习

    来自浙江 回复
    1. 客气了,只要多实践、多总结,每个人都可以做到的,一起努力~

      来自北京 回复
  2. 真的是学到了

    来自上海 回复
    1. 这对于作者来说,是最好的反馈了,哈哈

      来自北京 回复
  3. 2B有明确的需求后,可以按照你这种思路往下迭代没问题,如果需求本身不明确的前提下,如何输出规划

    来自福建 回复
    1. 需求不明确,那就要明确产品方向与产品定位。可参考的几个思考方向:
      1、看用户:需求不明确的话,可能是对客户/用户的了解不够,建议就是走出去接触他们;
      2、看竞品:选择1-2款核心竞品,看看他们的新功能、主打的市场等,是否可跟进或差异化竞争;
      3、看行业:关注对应行业的政策、发展趋势等,是否有新的变化
      4、看自身:回到产品定位定位上,看当前客户结构、用户群体,是否可总结出一定的特性,明确自身产品的定位,以及与竞对的差异。

      来自北京 回复
  4. 为啥看不懂????

    来自山东 回复
    1. 哈哈,内容可能偏自身工作,理解起来确实会有难度,但为了保证是自身的实操经验,所以只能如此,期望后续可以再提炼简洁、易懂一些

      来自北京 回复
  5. 大佬太强了,好细

    来自浙江 回复
    1. 客气,一起学习交流,哈哈哈

      来自北京 回复
  6. 干货满满,受益匪浅!想请教大佬,B端重构涉及多个业务方的需求如何判断优先级和关键程度?

    来自湖北 回复
    1. 我的经验是:区分需求对不同业务方的影响力与收益两个维度,可以简单画一个二维表格,横轴是影响力,纵轴是收益。

      如果对于需求来说,对应业务的影响力大,收益也大,优先级肯定就是P0;

      如果是影响力大,收益小,那优先级至少也是P1(否则它会直接把你否决了);

      如果是影响力小,收益大,则优先级可以是P2(当然,这个P2跟上面的P1,需具体情况再分析,有可能这二者优先级会颠倒);

      如果是影响力小,收益也小,则优先级可以是P3;

      来自北京 回复
    2. 学到了,谢谢大佬,关于对业务的影响力我是否可以理解为 影响业务的工作严重程度?因为我们提的很多需求都是基于公司制定的办法和规章制度,所以一般只有出了新的规章制度和一些影响业务日常使用的需求我们会优先跟进,收益这部分我确实不太了解呢

      来自湖北 回复
    3. 嗯,那可以先试着给需求跟角色分类。

      从需求分类看,你说的规章制度等,都属于合规类需求,可定义为基础型(或叫符合预期型);但一款产品只提供基础型需求,对客户的价值可能有限,所以就可以在考虑增值型(或叫超预期型),甚至里面可进一步细分;

      从角色分类看,你除了满足用户(即使用产品的人),还可考虑客户(即购买产品的人),相关利益者(即与你合作的上下游的人),以及企业自身商业价值(即如何更好的盈利增收)

      收益不明确,可能是因为你形成了定向思考,框定了自己的需求,就只是基础需求,也框定了收益人,就是用户(或客户)

      来自北京 回复
    4. 学到了!感谢大佬,向您多多学习,请问您有公众号或者别的平台账号吗?想持续学习~

      来自湖北 回复
    5. 公众号跟简书都有,不过更新频率基本跟这里一致,名字也是我这个名字

      来自北京 回复