B端产品 | 通过“完成度”策略实现价值双赢

2021-12-09 1155

编辑导语:随着国内市场的发展和环境的变化,未来产品经理的职责可能不再需要身兼多职,而是有所“收敛”,这让产品经理可以更集中于某件事情上。本文作者便基于该观点对B端产品中的“完成度”及其相关方面做了总结,一起来看一下。


一、前言

国外的成熟saas企业中,岗位分工已经非常专业化。国内的产品经理定位则往往大而模糊,兼任着市场调研、交互体验、测试、项目管理、用户增长等工种的部分职责。

随着国内互联网的发展,相信产品经理的职责也会逐渐收敛到最核心的”通过产品方案满足用户需求“,即“get things done”。

这里再细分的话,可以分为几个环节:

  • 设计:根据场景,设计多种能够满足需求的方案

  • 甄选:综合考虑各种因素,选择最终付诸实践的方案

  • 实现:投入资源,将方案变成现实,并获得最大价值

  • 迭代:根据用户反馈和市场动态,不断迭代

不同的环节,对应着不同的专业方法。支撑在下方的则是产品经理的基础能力,如沟通、理解、逻辑、表达等。我将在专栏中,按照这几个模块,分享自己在工作和阅读中的思考与总结。

今天要介绍的概念“功能完成度”,对应的是“实现”。

二、“功能完成度”

理论上来说,某个产品和功能可以无限迭代,永远没有perfection。

现实中,尤其是对于B端产品来说,却是“满足用户需求到某个程度,就会停止投入资源”。

这个”某种程度”,就是我们要讨论的“功能完成度”。

1. “功能完成度”的策略选择

“完成度”策略,背后对应的是资源的分配,显性对应的则是交付时间和功能体验。

选择“完成度”策略的第一步,是将功能进行分类。

Amanda Kleha在如今市值已经超过130亿美金、ARR超过10亿美金的Zendesk工作七年,现在负责Figma所有marketing, sales, support(Figma在今年也达到150亿美金估值)。

她曾将Saas产品组合中的功能分成了三类(来源见图片水印)。



在这个分类基础上,我做了补充,并将“完成度”策略与之对应。



其中,A和D的分类与策略比较容易理解,比较tricky的是B和C。下个部分中,我将通过具体的例子来说明。

2. 应用案例

笔者负责的项目,是为某投资机构打造一款项目管理工具,用于投资团队实现投前、投中、投后的协作。我们的用户有这样两个突出的特点:

  • 工作节奏快、负荷高

  • 信息集中于纵向流动(汇报导向)

因此,我们的四类功能可以这样划分:

在应用“完成度策略”的过程中,最基础、最关键的步骤就是对功能进行分类。

但需要注意的是,分类标准并不是功能本身,而是具体用户和产品战略。

比如,同样是项目管理工具,商业化的Clickup追求“One app to replace them all”,需要避免用户因为某个功能的缺失而转向其他产品。

因此将大量的功能划成“Replacer”,然后通过快速迭代,为用户提供MVP,例如类 Loom 的录屏功能、类 Notion 的文档功能、类 Jira 的白板功能、类 Airtable 的表格视图,以避免用户流失。

(当然,对于快速迭代带来的技术债、bug和简陋的用户体验,Clickup也有对应的措施,这里就不展开说了)



而对于笔者的产品来说,一方面,工具本身没有商业化的预期,评价指标在于客户公司的满意度,另一方面,由于管理属性的存在,用户迁移到其他工具的可能性不大。

因此这些功能会被划成“Filler” ,需要用较长的周期去打磨后再上线,以提高用户对于工具“稳定性、小而美”的感知。

三、总结

随着国内互联网的发展,产品经理的职责会逐渐收敛到最核心的“通过产品方案满足用户需求”,即“get things done”。(对于产品经理本身的发展来说,我认为也是一件好事。毕竟职责的收敛也意味着精力的收敛,可以从大而全的虚浮,回归到对产品价值和个人思考力的打磨上)。

基于此,本文提供了功能分类的方法以及“完成度策略”的选择框架,并结合实际案例进行了说明。按照这个框架去安排不同功能的时间与资源,能够最大概率地实现最终目的:“用户价值”。

从底层逻辑来说,“完成度”策略的选择,是产品或者说公司战略目标在实践层的体现。这是所有策略的最终来源。

本文由 @大可可可 原创发布于人人都是产品经理。


最新文章排行榜