惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
Engineering at Meta
Engineering at Meta
月光博客
月光博客
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
T
Tailwind CSS Blog
博客园 - Franky
The GitHub Blog
The GitHub Blog
大猫的无限游戏
大猫的无限游戏
The Cloudflare Blog
B
Blog RSS Feed
云风的 BLOG
云风的 BLOG
小众软件
小众软件
罗磊的独立博客
Microsoft Azure Blog
Microsoft Azure Blog
I
InfoQ
美团技术团队
H
Hackread – Cybersecurity News, Data Breaches, AI and More
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
C
Check Point Blog
WordPress大学
WordPress大学
博客园 - 【当耐特】
博客园 - 司徒正美
D
Docker

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
企业自研产品规划思考和经验分享
Thea小里 · 2023-12-05 · via 人人都是产品经理

大家对于企业自研产品规划有什么感想吗?下面是笔者对此的一些思考和经验的分享,对此感兴趣想要了解更多的同学接着往下看,可以收获更多内容哦!

如果两年前的我思考这个问题:企业自研产品的规划该怎么做?

我的答案大概会是:那是什么,能吃吗?

作为企业自研产品经理,最熟悉的一句话莫过于:“以业务为主,为业务赋能。”实际情况中,业务变了产品也得跟着变,所有的规划都会因为业务的变动而打断,所以表面上看来,做规划看起来是一件没有必要的事情。

但是经过我今年的探索来看,企业自研的产品规划还是必须得做,并且也有方法可循。

正好最近年度产品规划汇报完成了,也顺利通过了CEO的评审,接着这个时间点,跟大家分享一下我对企业自研产品规划的思考和经验心得。

一、为什么做不了产品规划?为什么产品规划总是无法落地?

之前听了杨堃老师的一场分享,将新时代下企业自研产品做规划的痛点说的十分到位。同时直播中也分享自研产品做产品规划的2个思维。

所以这里直接借杨老师的话解答一下为什么企业自研的产品规划难做:

  1. 市场环境多变,业务不稳定,IT疲于奔命
  2. 经营策略不具备连续性,朝令夕改,系统没法做
  3. IT规划太久远,太体系化,业务根本等不住
  4. 软件设计缺乏业务视角和思维,总局限于功能模块

其中业务不稳定、经营策略的朝令夕改,是造成企业自研产品总是难以完成和难以落实的重要原因。

二、怎么做出受业务认可,能落地的产品规划?

这里分享刚才提到杨老师认为企业自研产品做规划统筹的两种思维。

1. 结构化思维

这是我们最常见的产品规划方式,通常的路径为:

  1. 利益方梳理
  2. 梳理利益方痛点和诉求
  3. 确定痛点的解决思路
  4. 演进蓝图设计
  5. 功能模块设计
  6. 制定目标推进计划

2. 业务思维

这是一种以业务指标为导向的思维,它的规划路径为:

  1. 确定核心指标
  2. 拆解核心指标
  3. 制定目标策略
  4. 分析大盘数据
  5. 制定实施路径

1)那么这两种思维方式怎么应用?

关于这两种方法,我有一些思考,权当抛砖引玉,欢迎大家跟我一起交流:

①根据业务周期

如果业务本身处于发展期,它通常表现为:营收比较好看,对未来一段时间的营收也报以乐观预期。

那么这时候更适用「结构化思维」来规划产品。

因为此时企业允许产研部门以更长的时间和更多的人力去完成工作,此时的业务规划也通常更长远一些,产品能够根据业务规划产出更长远的产品规划。

如果业务本身处于平缓期或衰退期,它通常表现为:对营收十分看重,所有的事情都要以增长、业绩为主。

那么这时候更适用「业务思维」来规划产品。

因为此时业务会更着急看到核心结果指标的上升,对产研部门的响应速度、解决问题时效要求也会变得更高。

②看产品周期

如果产品处于上升期,它通常表现为许多功能还不完善,只做到了基础数据上线系统。

那么此时更适用「结构化思维」来规划产品。

如果产品处于平缓期,它通常表现为基本功能已经具备,核心流程完成线上化。

那么此时更适用「业务思维」来规划产品。

自研产品的衰退期,大概率要重构的。这种情况比较少,暂不讨论。

这两种维度,通常需要结合起来看,不可以分割开来。总体来讲,对于企业自研产品来说,业务周期的权重会更高一些。

即使产品的许多功能还不完备,但业务处于紧急需要看到营收的状态,产品还是需要以业务思维规划产品,更快地给出对方需要的解决方案。

三、两种思维的产品规划怎么做?

关于结构化思维的规划方法,我更推荐大家去阅读杨堃老师的决胜B端,里面有很详尽的解释。

这里我想重点分享一下市面上比较少提到的:业务思维如何做产品规划。

杨老师在分享中提到的路径是:

这个路径上的方法我觉得对于3-5年的产品经理来讲,是比较难做到的。我也在直播上询问了一下杨老师,使用业务思维做产品规划,不仅需要有一定的数据分析能力,也要有对行业、业务一定的了解。

如果上述的能力还没那么精深,我思考了一下业务思维的产品规划流程可以调整如下,比较适合年限在3-5年的产品经理使用:

  • 确认业务核心指标,拆解核心指标
  • 对业务管理层进行访谈
  • 制定目标策略
  • 跟随业务、数据人员分析大盘数据(可选)
  • 制定实施路径

图中标红的地方就是我进行了调整修改的地方。

这次的年度产品规划我也是用这个思路去做的,通过了CEO的评审。具体的方法如下:

1. 找到核心指标、拆解核心指标

可能有些产品伙伴看到第一步就有点容易被吓到,但是实际上业务核心指标和拆解一般直接问业务相关人员,或者数据组、策略组的同事就可以拿到,不需要自己去拆解。

拿到资料后,我们手上会有几个关键指标,这时候我们还不知道围绕这些指标做什么,没关系,可以直接进行到下一步。

2. 对业务管理层进行访谈

这是我加入的非常关键的一步。如果我们对一个行业和业务没那么精深,看着几个核心指标也思考不出什么的时候——直接去问问懂业务的人就好了。

例如我通过数据组的同事了解到知道某部门的核心指标是:客诉率、退款率、复购率。

那么与管理层访谈时,我就把握住了整场访谈的「主要线索」。

在一般的访谈中,业务方都喜欢明确地告诉我们,想要什么功能。

这次的访谈也是,对方告诉我:希望有一个学生评价的功能。

但对方告诉你需要的功能,却不会告诉你背后推导的过程,和业务的核心指标有什么关系。

这时候我们可以开始利用已知的信息来询问了:

我:“需要学生评价功能,是要因为要降低客诉率吗?”

对方回答:“是的。”

我继续问:“但是学生评价了跟老师提升教学质量没直接关系,你们打算怎么做呢?”

对方回答:“我们会根据差评的老师给出惩罚,例如扣除薪资。”

我:“你们是后面打算持续推进这项事情吗,我是指对老师加强管理,差评的老师需要扣除薪资。”

对方回答:“是的。因为对于我们来说,老师上课质量非常重要,所以我们会开始落实这些管理动作。”

这样我就得出了一个结论:业务想要评价功能的原因是他们明年要开始加强管理老师上课质量了。

后面的访谈内容我不再赘述,但是通过核心指标和访谈内容,可以顺延着理解出3件事情:

评价功能必须尽可能让学生进行评价,不能太复杂。

除了学生评价,也需要优化迭代目前的老师管理模块,并且需要有奖惩体系。(这个就可以列入产品规划里面啦)

老师的等级是与学生评价有直接挂钩关系,需要考虑后续功能的拓展。

这样,我们对于该部门的一些规划就有头绪了。

3. 制定具体产品策略

产品策略这里我沿用了杨老师的体系——OCSM,对应的分别是:

O:目标;本次产品规划的目标是什么,希望达到什么目的。

C:挑战;业务面临的挑战。

S:策略;本次产品规划的具体落地策略、方案。

M:度量;如何衡量产品规划的达成情况。

下面给大家举例一下我是怎么写的:

O目标:我的目标集中于两个:

  1. 提升业务人效;
  2. 增加老师管理体系,提升老师上课质量。

根据上文可知,第2个目标其实是我和业务访谈+核心指标的推导总结出来。

C挑战:这里列举出当前业务面临的问题与挑战。

举例我自己的情况:

  1. 老师数量大,难以搞人工运力一一管理;
  2. 老师课程质量,直接影响了学生的上课体验,是把控的重要环节。

不同的行业、业务,以及受到公司当前具体情况的影响,面对的挑战不同。产品经理也不用自己闷着脑袋去想,这一块可以多与领导和业务方沟通后再定出结论。

S策略:这里就是产品伙伴们比较熟悉的部分了。

可以使用架构图、里程碑、演进蓝图共同说明我们会有什么策略,会如何执行。

这里算是B端产品的基础能力,具体不再展开,大家也可以在网上搜索相关模版。

如果对这部分好奇的伙伴,也可以单独加我交流。

M量化:这一步需要选择出具体的产品指标来衡量最后的达成结果,选择指标时需要注意一个点,避免踩坑:尽量选择与产品密切相关的指标。

例如刚才所说,我的目标是建立老师管理体系,提升老师上课质量。用这个思路推导,能直观地反映老师上课质量的似乎就是学生的好评率了。

但我们深入思考一下:学生是否给好评,跟老师的管理体系直接相关吗?学生会因为我们搭建了一套管理体系就给老师好评吗?

答案是否定的。

学生是否给好评,与老师上课质量是否满意才是高度相关的。虽然我们搭建了一套体系,但老师最终的上课质量仍然不受产品控制。

所以我最后给到的量化指标是:完成占总课时数60%以上的评价数据采集,支撑教师级别管理和质量监控;首课完课率提升约5%(为什么完课率能和产品直接关联,这里涉及到内部一些业务逻辑,具体就不解释了。)。

大概这样下来,就能产出一份完整的产品规划了。

当然产品规划的格式还蛮多,大家其实可以根据具体情况来。

4. 与业务、数据人员分析大盘数据

与业务、数据人员分析大盘数据的目的是为了从全局的角度去梳理整个业务核心指标下,产品需要做哪些优化迭代。

例如:学生转化率=注册转化率电话接起率约课到课率*完课转化率

在不同的指标下,产品都可以找到优化迭代的地方指定设计解决方案。

如此,我们可以通过大盘数据得出一连串的产品需求。

这一步鉴于年末各业务线人员比较忙碌,这次的规划中我并未用上,所以在图里是标记了虚线的选做。

如果有条件的同学,可以选择去尝试。

5. 制定实施计划

最后一步的实施计划比较简单,也是产品伙伴们比较熟悉的步骤——拆解演进蓝图,分配项目人员。

这一步并不难,只需要跟相关人员提前沟通好一个结果就好了,大概我们这部分得出的结论会包括以下内容:

  • 目标:不同版本的预计实现目标
  • 项目:具体实现什么功能模块
  • 项目相关人员:按照实际情况填写即可
  • 衡量方式:目标的衡量方式

每个公司要求不一样,但大体按照这四个点总结都不会出错。

四、结束语

以上就是我目前对做企业自研产品规划的一些思考,还有本次年度产品规划的一些思路总结,希望对屏幕前的你有帮助。

如果你对以上内容有疑问,或者想更深一层地了解我是怎么做的,如何通过CEO评审的,可以留言交流。

最后祝愿所有做企业自研产品的伙伴们都能写出一份好规划并实施落地,取得耀人的成果。

“念念不忘,必有回响。”

共勉。

本文由 @Thea小里 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

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