一套适合To B产品经理使用的工作方法

从零开始学运营,10年运营老司机带路,2天线下集训+1年在线学习,做个优秀的运营人。了解详情

方法只是解决问题的一种手段,只要能达到最初目标,任何方法都有其存在的价值。

在《干货提炼:一名To C的产品经理,教你如何做好To B的产品》一文中,我们曾提到,做To C类产品,其核心是:创造需求场景 → 引导用户 →  建立使用习惯。而做To B类产品,由于产品经理很难创造需求,因此产品经理首先要能适配现有业务,才能再针对业务中的痛点逐步优化。

既然需要针对业务做优化,那么能把线下复杂业务形态完整的“搬”到线上,本身就具有一定的困难度。同时业务的流转涉及的关联角色复杂多变,对比线下自然存在
角色,线上我们需要定义的就是所为项目组的各类人员的分工,剩下的80%的工作重点就是“沟通与协调”。

对于To B的产品经理来说,“高效沟通”是最重要的事情之一。“高效沟通”的核心包括:“向上沟通”、“向下协调”。所谓“向上沟通”,就是指产品经理根据需求,提供1-2套解决方案,让需求方(这里说的需求方可能是业务方,也可能是上级领导)进一步讲述需求的本质,便于产品经理深入的挖掘到需求背后的产品价值。“向下协调”,则是指互联网项目推进的一套方法,也就是更偏向To C类产品的工作模式。

看起来,这两件事貌似并没什么困难。但实际情况中,To B型的传统企业转型的公司,其需求的来源往往会比较多维度,而且需求方对需求的定义相对To C类产品而言,较模糊、粗糙。他们的需求,一般情况都只是一种很粗浅的想法,抑或是纯线下业务的描述。这些描述第一时间很难“翻译”成为互联网的思维和想法。因此这样需求定义,就对产品经理的思维模式转变提出了新的要求。原本我们做产品,首先是把需求吃透,然后通过挖掘出来的需求场景,设计用户习惯,最后才是进入开发。项目推进过程中,从需求方到项目组,所有的人都应该明确的知道产品的定义以及产品设计的目标。

但是To B产品不同的是,我们需要在有限的时间内,消化和分解业务模型,了解业务常态。由于传统行业的业务模式大都趋于一种常态,所以将这样的业务模式放到线上,作为产品经理,就应该尽可能的把涉猎的业务模型组件化。组件化之后,“对上”提供视觉设计稿,辅助需求理解,进行产品评审;“对下”提供组件模块及组合说明,辅助研发测试实施工作。组件化的好处是,期间如果出现需求更改,或者是策略型优化,产品经理及时调整组件的丰富性,调整组件样式的视觉稿,就能快速的响应变化带来的影响,最大可能的保证项目推进的顺利。

组件化思维法,简单来讲就是:组件+UI设计稿+Excel+补充说明=PRD。此思维方法涉及到的每一个关键内容,对应的作用描述如下图深色色块所示:

大致了解方法之后,小Q就结合订单详情模块为例,说明如何通过组件化思维,来高效推进To B型产品。我们知道,根据平台自身业务需求,订单状态的设置存在差异,通常来说大致有以下几种状态:

  • 支付状态 : 未支付、已支付
  • 物流状态:未发货、已发货、已签收
  • 订单状态:等待付款、等待发货、确认收货、 交易完成、交易关闭
  • 售后状态:申请售后、退款完成

根据固定的状态设置,可以把界面的组合分为几种组件模块,然后映射到Excel表,加以说明和标注,如图表所示,右侧Excel表的底部一栏色块对应右侧原型图的不同模块,二者对应可解释说明不同模式下订单详情页面的组件元素有哪些?不同之处是什么?

利用这种组件拼接的方式,可以快速的遍历所以的订单详情页面,同时标注出不同场景下订单详情的差异化。根据不同的地方,协助视觉设计师提供关键页面视觉稿,同时,视觉稿的样式结合组件说明表,就可以用于研发测试人员熟悉产品设计并合理安排时间进行开发。剩下部分无法组件化的功能,就可以点对点的沟通说明,达到最终产品经理的设计标准即可。

小Q来总结

To B型产品经理,工作的本质是以用户为中心,深度还原用户使用场景,洞察业务与用户之间的情感链接。工作的关键是善于沟通,高效协调。方法只是解决问题的一种手段,只要能达到最初目标,任何方法都有其存在的价值。

#专栏作家#

Mandy权,微信公众号:小Q聊产品,人人都是产品经理专栏作家,善于资讯、教育、平台类产品设计与分析。

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

题图来自 Pexels,基于 CC0 协议

打赏也是一种认可
4人打赏
评论
有话不说憋着难受!
  1. 这个表格太实用了,一看就看懂,学习了

    回复
    1. ;-)

      回复