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

编辑导语：随着国内市场的发展和环境的变化，未来产品经理的职责可能不再需要身兼多职，而是有所“收敛”，这让产品经理可以更集中于某件事情上。本文作者便基于该观点对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”。（对于产品经理本身的发展来说，我认为也是一件好事。毕竟职责的收敛也意味着精力的收敛，可以从大而全的虚浮，回归到对产品价值和个人思考力的打磨上）。

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

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

作者 @大可可可

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！