B端产品设计进修:学习权衡

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

-- NO.12 --

这是Becomewiser的第12篇文章
全文约3077字,建议先收藏再看

权衡,这个词贯穿了产品经理的职业生涯。

每逢遇到了做决策的时候我们总说“价值导向”,但当这个词所涉及的组织和角色几何式上升,各方的着眼点及利益点都不同,我们应该满足谁的需求,资源又该向谁倾斜呢?

在B端产品的链路中,规模越大,组织和角色也越多。对于权衡,是很好的实践案例。

在全心投入B端产品的这半年,在这方面也有了些更深的认识, 本文将以B端产品设计为例阐述对权衡的理解,希望能给大家一些帮助。


01  什么是B端产品?
B端产品,其使用对象是企业或者组织,用于提升 效率、效果 等某一特定领域的问题。对比C端产品,其受众不再是个体而是一类群体,并且与业务的连结也更为紧密。

B端产品的产生主要源于企业的规模化,组织结构增多、分工也愈加明细。链路的加长却使线下运行的成本逐渐增高,无法使边际成本真正地降低。

将业务 简化、线上化、自助化 做到降本增效,也正是B端产品的作用。

另一方面则是由于市场成熟,业务模式的趋同。同一片红海不会只有一艘轮船,无论是为了保持先发优势还是想后发制人,很关键的一点在于 运营的效率。

效率的提升,能让我们更高效的管理、更敏捷的试错,从而更迅速的寻找优秀的业务模式。


02 如何进行B端产品设计?
2-1、梳理业务现状,确立产品定位
产品经理需要有很强的角色转换能力,对于B端产品而言,也称之为业务感。

设计B端产品需要将自身代入业务流程的每一环,对业务的现状进行调研以及梳理。

调研的主要目标如下:
1)业务是如何运作的?
2)运作过程存在什么样的问题?
3)哪些问题已经被解决了,是谁在解决?
4)目前已解决的问题是否符合该业务部门、实施部门的规划以及预期?
5)未解决部分不解决的原因是什么?
6)适不适合由你的团队来解决?
7)投入和产出是否匹配?
设计B端产品,大多会改变旧有的业务运作模式,可能是运作环境、运作流程亦或承载团队。过程中会面临无数的抉择,我们需要慎重考量 变更的收益能否抹平变更的成本。

在调研时应覆盖链路不同环节的角色,不能只偏重于业务部门,还应考虑协作部门。其次不应只调研一线执行人员,还应调研负责人的预期。

在调研清晰后才能确立产品的定位,它 面向什么角色提供什么支持。产品毕竟是权衡后产物, 只为自身创造的价值不能称之为价值。


2-2、优化并确定业务流程
在上一步骤,通过调研企业中各部门、系统的业务流程,经过分析、评审确定了其中不合理的环节,下一步则是优化并确定核心流程。

跨职能流程图的一轴为部门及角色,另一轴多为阶段,下图 是以用户运营系统为例绘制的跨职能流程图:
B端产品设计进修:学习权衡

绘制业务流程目的是 表达 业务的流向,表现业务部门的业务关系以及作业顺序,描述链路中起点、操作以及终点。

至于使用什么工具、横纵的规范、设计的细节其实并不是特别重要。


2-3、根据产品使用角色进行需求分析
B端的产品的需求,基本都来自于真实的业务场景,换言之,这些需求都是具有实现价值的。

但也正因为是真实的业务,所以需求会牵涉许多部门、角色。 链路的加长,会使“要不要做?什么时候做?怎么做?做到什么程度?”这类问题复杂了无数倍。

在这一方面笔者的做法是通过梳理系统角色,从角色出发来权衡需求。

B端产品设计进修:学习权衡
与平台相关的角色,可以粗略的划分为 决策者、直接使用者、间接使用者。

其具有以下特点:
B端产品设计进修:学习权衡
在进行权衡时,价值导向是第一位的,但由于不同角色需求的产出价值是波动的,所以并未在上图中表现。

在需求分析时,我们应 根据其 产出的收益决定资源的倾向、产品设计的深度 其次则是根据角色的代表、使用的场景、关注重心决定产品设计的侧重点。

1)决策者
决策者的主要代表是业务负责人、平台负责人、协作负责人,他们是决定是否使用这个平台的人。虽说价值产出会抖动,但决策者的需求优先级大多在第一顺位。

其关注的重心是 边界以及收益 ,边界是指业务流向是否正确、人力损耗是否减少,收益则是否正向、是否达到预期。

直接和间接使用者,更侧重于局部的价值,而 决策者则更侧重于全局 ,在产品设计上我们须考虑的是决策者的全局视图。

2)直接使用者
直接使用者首要的代表是业务运营,他们是产品发展的中坚力量。

其对产品的依赖性越高,产品创造价值的可能性才越大,业务运营的需求优先级略低于决策者,但大多数情况高于其他的角色。

在需求分析上,由于业务运营的需求零散且差异性高,我们需要提炼业务的共性,牺牲较为定制化的逻辑,对平台而言, 全局效率的提升会比个别业务的体验更为重要。

在上图中,还包含了平台的研发、测试以及运营。这是因为只有 支撑人员的效率提升,才有更多的资源能 投入到 业务需求以及非功能性需求的建设之中

在需求分析及资源倾斜时至少要 保证30%的资源分配给于非功能性需求 ,否则暂时性的繁荣迟早会被故障击破。

当业务支持和产品建设形成良性循环,能用和好用兼备, 业务运营乃至决策者的观感才会不断提升。

3)间接使用者
这一角色,多为与平台业务某一环节所关联的研发、测试成员。 其关注重点是, 做什么 以及 怎么做

前者是边界,后者则是接入或使用的流程和规范,在这里则不赘述了。


2-4、沉淀业务需求,封装标准化服务
B端产品的本份是降本增效以及建立规范,而建立规范又来源于“降本增效”的沉淀。

什么时候应该考虑标准化呢? 在观测时间线足够长的前提下,应符合以下的条件:

1) 系统建设足够完善

2)业务模式足够成熟

3)标准化的收益能超出变更的成本

如果标准化的需求被拒绝,不妨在深入思考需求背景是否符合上述的条件。

关于标准化的细节可以查看此前关于 《前端配置化系统的设计思路》 ,这次想谈谈标准化可能陷入的误区: 认为解耦一定能提升效率,更爱设计组件而非插件。

对于迅速变化的业务系统,插件更能够提升效率,组件却可能增加枷锁。判断是否插件的标准是:是否独立可用, 插件可以 灵活组装、随时舍弃 的,组件却是相互衔接且密不可分。

电脑主机上的USB接口,只要硬件符合接入标准,无论你是U盘、硬盘还是手机都可以与之通讯。而组件则如同电脑的主机,运作需要有电源,将数字信号转换为模拟信号则需要显卡。

但无论哪种思路,始终还是 为了快速响应业务 ,如果标准服务反而拘束了业务的发挥空间,影响了C端用户的操作体验,这就本末倒置了。


2-5、效果追踪与资源再分配
效果追踪,是权衡的重要工具,其作用是监测产品稳定性以及评估业务价值。

前者是 执行效果,后者则是运营效果,这两个数据的提升,都能帮助各个团队建立信心。

执行效果,指在一定时间范围内执行的任务数量、速度、成功率、错误率等,更偏向产品的风险控制,如果执行效果不达标,前进一步却退三步,支持再多的业务也没有意义。

而运营效果则是B端产品价值的体现,虽说B端产品的价值之一是降本增效,但当效率面向不同的业务模式、运营人员,会让量化变的很困难。而另一方面, 提升效率也不一定会提升效果

运营效果的追踪,一方面能够使运营闭环,另一方面则是为了 资源的再分配。

如果将企业比作一辆汽车,C端业务更多的是在踩油门,而B端支撑则更多的要考虑踩刹车。 提升效率不仅是简化链路、优化流程,还包含 停止投入

追踪业务效果,可以让我们知道业务的优劣对比,帮助我们决定资源倾向。


写在最后
最后谈谈个人心态的变化吧, 得益于B端的确定性更高,让我能够有信心、耐心,愿意看的更长远些。

以前的我喜欢追求产品设计上的难度,不喜欢做简单的需求,甚至还会对业务同学不耐烦。现在则 不再在意难度,只在意有没有用,也许有时做的事情并不“高级”,但我却能够坚定的往前走。

产品的路很枯燥也很漫长, 做好的产品,不是做好的产品经理。” 这句话与大家共勉。



随意打赏

提交建议
微信扫一扫,分享给好友吧。