B端产品实战指南:如何将业务需求快速转为产品需求

0 评论 1166 浏览 11 收藏 10 分钟

B端产品比较麻烦的一点,就在于业务方本身并不了解系统,而且缺乏必要的产品和技术知识;这种情况下,如何将业务需求转化为合理且有效的产品需求就很重要了。

作为B端产品日常中需要接触不同来源的需求,尤其是作为内部IT系统,业务方往往来自公司内部的办法和管理要求,以及公司内部使用系统的用户反馈、领导的战略性目标。

作为公司自研系统,公司自身业务发展迅速,导致系统功能冗杂,前端配置非常复杂,每次上线对于运营、开发、测试是一场不小的挑战。

那么对于一些业务方本身并不了解系统,也没有很多产品和技术知识的情况下,如何将业务需求转化为合理且有效的产品需求就很重要了。

举例来说,当业务方提出只是简单地【新增一个字段】时,如果按照业务方的视觉去看他会提出这些疑问:

  1. 为什么列表有这个字段,导出没有?(并不知道导出字段也是需要定制确认)
  2. 上线新功能后为什么我正在审批的单据和历史单据都受到了影响??
  3. 为什么我还要手动筛选这么多数据啊?不能自动化吗??你看别家的….

一轮又一轮的battle下是非常消耗团队的精气神的,那么如何能够将业务需求完美地转化为产品需求,能够既符合业务方的目标,也能够最大程度地提高产品团队的ROI呢?

一、识别业务方需求的来源和重要程度

1.1 掌握和业务方沟通技巧

任何一个系统不到公司战略性地位是不可能有充足的资源和时间的,从需求的漏斗模型来看,原始的业务需求需要在产品经理转换为产品需求之后,再根据技术框架和技术实现上的可行性,最后才会转化为可上线的最终需求。

所以这也考验了一个产品经理作为一个产品的掌舵人,在时间和资源都不算充足的情况下,怎么最大程度完成业务方的期望。

首先必须要对业务方的需求来源进行摸查,这是一个沟通技术上的范畴,需要你站在业务方的角度上,表明:

  • 目前系统的排期现状,同时作为一个产品经理也非常希望能设计出彩的功能,给业务方带来根本性的帮助
  • 希望业务方能告知需求的来源和预期是如何的,以便去向上争取更多的资源来共同实现目标。

目标是:既不让业务方的期望落空,也不让团队背负无法承受的负担,从而在双方之间绘制出一条可行且高效的实现路径。

1.2判断需求的重要程度

从上述步骤,我们可以从业务方口中套出需求来源和具体任务情况,这个时候就可以通过需求的【紧急程度】和【重要程度】分析出需求的优先级,可以利用需求的四象限来进行辅助划分:

紧急程度:

  1. 任务:是否是公司指派的紧急任务,比如领导明确要求多久之前需要完成。
  2. 类型:如果是需求类型就分为运营类需求、bug类需求、创意类需求、优化类需求;比如bug类就比较紧急,创意类需求就比较相对不那么紧急。

重要程度:

  1. 定位:与企业的战略定位,与产品的定位之间的相关程度。
  2. 价值:价值就是前面提到的广度、频率、投入、产出等维度。

二、将业务思维抽象为产品思维

在得到需求的来源和预期之后,我们要去了解当前的业务现状以及痛点。业务现状可以通过业务流程图或者泳道图的方式去呈现,这一步主要是摸清业务方对于业务痛点的程度,能亲自体验业务的操作流程更佳。需要产品经理能快速地理解业务的本质。

方法是可先从业务流程或者办法的描述中,抽象为系统流程图。

我的方法是:先通过业务流程在产品上的开始操作,以操作交互的脉络先梳理数据的流向,直到穷尽数据的所有分支为止,即为结束。所有影响数据及数据状态的分支,都要以流程判断的形式展示出来。

画完系统流程后,可以根据系统流程画出整体的架构图,这一类图可以更好地帮助产品经理去理解不同模块之间的交互,也是我们需要花很长时间去思考和构建的。

三、根据需求设计MVP

通过了解了需求的基本信息架构之后,就可以去设计需求的具体功能了,在前期细致的沟通与提问下,根据业务方的真实需求层次设计最小可行版本,这一步需要产品识别出哪些是“必须拥有”的核心功能,哪些是“锦上添花”的附加特性。这个过程不仅仅是简单的信息收集,更是对业务需求深度和广度的精确测量。

step1:定义核心功能:首先确定产品解决的核心问题和提供的核心价值。

step2:功能精简:只保留实现核心价值所必需的最少功能集。避免“特色蔓延”,集中资源打造核心体验。识别并剔除那些虽然吸引人但非必要的功能。这些可以在后续版本中根据用户反馈逐步加入。

step3:原型制作:用低保真或高保真原型工具(如Sketch,Figma等)快速构建产品界面原型。这有助于直观展示产品概念。确保原型能够模拟关键用户流程,以便测试用户体验。

四、拉通项目团队进行需求预评审

非常关键的一步:组织需求评审会议。

在会议上需要和研发团队详细讨论新功能的设计思路、预期目标、潜在的技术挑战及其对现有系统的可能影响。因此在会议上需要把所有风险暴露出来,鼓励研发团队一起提前发现并解决潜在问题。

最好是要求开发团队在开始新功能开发前,提供一份影响分析报告,列出新功能可能影响到的系统模块、数据结构、API接口等。这样上线的时候,方便产品经理和项目管理者全面评估风险和调整计划。

五、合理管理业务方需求预期

上线之后,管理业务方的预期也非常重要,很多不是影响业务流程的需求可以后置到下个迭代去优化,为业务能尽早上线使用争取最多的时候。在这个时候,产品经理需要利用对业务需求的深刻理解和对团队能力的准确把握,作为桥梁,协商出既符合业务紧迫性又兼顾团队开发节奏的时间表。

目标是:通过明确沟通项目周期内的可交付成果,设定阶段性目标,既维护了业务方对快速迭代的期待,也为团队争取到了宝贵的开发与调整时间,确保每个迭代都能稳健推进,最终实现双赢。

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

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

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

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