构建产品路线图的7个步骤,再也不被需求拖着走

0 评论 2542 浏览 9 收藏 9 分钟

产品经理要如何让手头负责的产品不走偏?产品路线图这一“角色”就起作用了。这篇文章里,作者就分享了构建产品路线图的几个步骤,不妨来看一下。

内部用户A提了一个很紧急的需求,说下个月就想要;

兄弟产品向你提了一个需求,说这个是上面的 KPI,不搞不行;

企业客户在制定来年规划的时候,又向你丢过来十几个需求;

……

我们该如何决策这些需求要不要做,什么时候做?决定不做什么和决定做什么同样重要。

资源永远是有限的,如何让负责的产品不走偏,不被需求拖着走?

答案是你得有产品路线图,产品演变、进化的路线,有了他,心里有数,不再人人亦云。

接下来,我们从多个维度来拆解如何构建产品路线图,让产品有主见,明晰产品的方向。

一、定位

1. 产品解决什么问题

那么产品是什么?为用户解决某一个痛点的工具。有人说,痛点是恐惧,用户不得不用这个工具去解决他的需求。

举几个例子。

比如闹钟,没有她,你会迟到,工作可能会丢,你会恐惧。

比如监控平台,没有她,开发、运维无法了解业务运行状态,出现问题如同盲人摸象,无从下手,慌得一批。

比如大数据分析平台,没有她,运营无法获悉业务的关键数据,只能拍脑袋决策,难以通过数据驱动业务决策、增长。

这些产品都解决了用户在某一个方面的恐惧。

2. 用户是谁

以大数据平台为例,用户是专业的大数据开发,还是运维?

如果用户基本盘是大数据运维,那么在产品设计时要考虑如何让运维能做大数据开发,化繁为简,屏蔽 Hadoop、Flink、Spark 这些大数据框架的概念,只描述业务逻辑即可。

3.产品差异化的能力

创业者选方向的时候有一个避不开的问题是,做的产品是否解决了某一个细分领域的痛点,毕竟通用类的产品,已经很难有机会留给你了。

竞品出了新功能,我们是否要跟进? 抄是最简单的,没有经过深度思考。

竞品输出的功能,是基于他的产品路线图输出的能力,对于你的产品来说不一定合适。

二、产品的基础框架

随着行业的发展,各行各业大都积累了对应的方法论,比如面向软件研发的 DevOps,机器学习研发的 MLOps、大语言模型的 LLMOps、数据研发的 DataOps,亦或是可观测领域的 OpenTelemetry 等等,这些方法论可以为产品的基础框架。

以数据研发为例,行业中有 DataOps理论,阐述如何提升数据研发的质量和效率。

DataOps is NOT Just DevOps for Data

顺势而为,把握行业技术的发展趋势。

如果是新的领域,亦或是ToC产品呢?

想清楚产品要解决什么问题,应该有哪些功能?不同角色在做什么?在整个体系中的定位。

三、模块间、产品间的联动

联动的作用是提升效率,对于 ToB产品来说,就是提升企业的生产力,如果一个按钮能把两个操作串起来,节省了用户操作的时间,这就是极好的。

先说说单个产品内部模块间联动。比如你使用 SQL 验证完数据开发的逻辑,接下来期望固化这个逻辑去跑实时/离线计算任务,如果此时有一个按钮,一键转计算任务,是不是很爽?

接下来说下整个工具链中产品间的联动,比如 在大数据平台做SQL查询可视化出图符合预期后,期望后续作为例行的报表查看,那么可以在SQL查询可视化的功能中增加一个按钮,支持添加到上层可视化平台的仪表盘中,这样用户不需要再去打开可视化平台,一步步在仪表盘中添加图表了。

联动对效率的提升是立竿见影的,以上面的数据研发为例,符合 DataOps 提升数据研发效率的初衷。

四、产品开放性

一个产品的功能常常无法满足一个领域所有的场景,怎么办?尤其面临的是多个非标准化的业务。

让平台专注于核心骨架功能的开发,以插件的方式提供开放能力,让用户参与其中,去解决业务个性化的需求。

比如开放数据入库的插件能力,让需求方来扩展数据入库能力。比如开放告警的回调能力,支持调用企业内部的网关。又比如 pipeline 的插件,把业务个性化需求通过自定义插件的方式加入到 pipeline 中。

产品的开放性带来无限可能,当然前提是你如何做好掌门人。

扩展阅读:《开发者关系:方法与实践》

五、LLM 重塑产品

分析产品的功能流程中哪些环节的效率值得提升?

比如数据研发阶段的ETL流程中通过大模型的能力,自动生成正则表达式

比如数据运维阶段日志中报错了,一键排查原因。

比如 SQL 查询时,通过自然语言来描述需求,让 LLM 和 大数据平台的元数据打交道。

等等这些功能,在过去无法实现,现在奇点来临,可以搞起来了。

六、产品融入到用户的工作流

如果你的产品是完全独立,用户主要通过进入产品页面去操作的话,也存在风险,因为竞品实在太多,可替代性很强。

那如何提升产品自身的不可替代性呢?

融入到用户的工作流,成为业务流程的一部分。

  • AS Code,将产品的功能配置化,对于喜好开发的人员来说,配置作为业务代码的一部分,提交代码时自动跑 CI 流水线,自动应用配置。
  • 比如 把数据查询加入到 CI 或 CD pipeline,作为pipeline 流程分支的决策条件
  • 比如通过 chatops,让日常办公软件中完成需求,不一定要去产品的网站

七、核心竞争力

再次回顾产品的核心竞争力是什么,如同 ToB 招标中的控标点。

思考产品存在的价值,为什么非你不可。

好了,有点晚了,今天先说这么多,希望能给你带来启发。

公众号ID:jishupm

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

题图来自Unsplash,基于 CC0 协议

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!