产品理念,是罗盘转动的磁场。
有两个产品同学想换工作,交流时他们都很坚定地表示要选择B端产品方向,他们都认为「以消费互联网为核心」的C端产品已进入发展瓶颈,B端产品才是更广阔的星辰大海。因此,他们都问到两个问题:
先回答第一个问题,首先我们有必要抽象发展本质:
镜同学一直认为产品经理的核心竞争力主要体现在「以专业能力为核心的硬实力」和「以沟通协作为核心的软实力」上,择业在于岗位匹配,好的成长环境是岗位达成的前提。
从这个角度来看,C端和B端对于产品成长(Professional Skills、Communication )的赋能价值并无太大差别,一般来说,一个更高质量的C端产品团队通常会比一个初创的B端产品团队,对个人的成长赋能更大。
事实上,有同学在面试辅导过程中思考学习非常认真,很快拿到offer后就开始纠结选择哪一个:有的关注产品线,有的关注公司规模,有的关注行业地位,有的在意直接领导。
其实,这些都是冰山表面,更重要的内核则在于抽象发展本质,我们不应简单地用短期的B/C端的产品领域来注释个人的长期发展。
好了,我们再说第二个问题:
说回B端产品领域,我觉得B端的魅力更在于通过复杂的、多维度业务场景的频繁击打练习,帮我们锻炼抽象能力,这是最高级别的价值赋能,就好比是撸铁塑身,你总得有压力环境吧,B端的产品环境就是那块铁。
事实上,镜同学沉浮B端产品十余年,也有一些关于B端产品设计理念的相关思考,我把这总结为十二个字:场景服务化、服务产品化、产品标准化、标准平台化。
众所周知,B端业务的一大特点在于客制化,这是催生客户场景需求繁多的重要原因,同时也是B端产品提供场景服务解决方案的前置因子。
用户需求松散地分布在业务场景中!
而回顾我的产品经历,不少高价值的B端需求并非实验室所刻意培养所得,而是从客户访谈时的场景抽象,而且,越是复杂的大项目,就越需要用高质量的服务去做场景适配。
如果将需求和设计比作一场旅行,路径一定是:从场景中来,到场景中去。
从这个角度看,B端产品团队应当具备将业务场景向服务转化的基础认知。
我甚至更认为,优秀的B端团队组织,其售前工程师应当是半个产品经理,以便可以将用户的场景需求提炼成业务解决方案。
如果说服务更多围绕的是业务模型,是高层级的需求轮廓,而将「服务产品化」则是产品经理的天然使命。
产品经理不是需求传话筒,但却是业务翻译员,这点既是是B端业务的发展护城河,也是B端产品人才的差异竞争力。
「将服务产品化」可以说是高阶产品经理应有的专业素养,既是产品洞察力,也是产品思维的具象表达。
先说两个概念:
初阶产品经理更擅长就需求谈需求,高阶产品经理则需要时刻保持将需求进行产品化的意识。
需求和服务其实是硬币的一体两面,是两个视角:站在消费侧是用户需求,站在供给侧则是产品服务。
如何从确定性的复杂业务场景中提炼用户需求,本身并不复杂,只需要专业扎实、抽象理解能力优秀即可。
而如何从不确定的场景中找出用户痛点,并主动思索逻辑或技术应用,主动将其封装成产品,却并不容易。
我们先看一个产品小案例,也是我们前段时间上线的「产品手册」服务:
因疫情影响公司一季度经营未达预期,这段时间,公司一直在强调业务导向,原来的PLG(产品驱动成长模式)也已悄然调整为SLG(销售驱动成长),反复强调各岗位要围绕“业务经营”协作,全力支撑业务发展。
雪花首先砸落到产品经理身上,业务人员连续多天在夕会上反馈需要各种产品手册,其实,大多产品手册都有归档给业务负责人,但业务团队各自小组分兵作战,再加上各自管理深度各异,一时间造成好像产品支撑不力的假象。
基于此,我马上安排产品经理在我们「运营管理后台」增加一个「产品服务支持」模块,功能也很简单,本质就是个文件管理:
产品经理上传产品说明书、培训手册等文件,市场运营人员可以登录运营后台搜索下载,并可联系产品经理寻求支持。
这个功能虽然很小,但这其实就是产品化的过程,并且收到了广泛好评,实际上,用户并没有明确提出来需要这样一个文件管理,我们是从反馈和场景中主动获取市场人员痛点,应用技术将其转化为一个产品服务。
事实上,从松散的垂直用户场景中,筛选痛点,提炼需求,对产品经理很有启发价值,我们体验产品时,可以有意识地思考分析,可能会发现很多产品都在试图践行产品化的理念。
再举一个小例子:
前天我又买了一个360监控摄像头,发现其硬件产品便宜了很多,但打开软件以后看到很多功能都被标记为增值服务,比如,人脸识别、巡航、区域闯入报警等功能都需要另行购买,即便上面写的是「限时免费」。
暂不讨论商业的对错和取舍,我们仍可以看到360试图将服务产品化的本质。
其实,将服务进行产品化的这个过程,需要操盘手足够细腻、洞察和本能,但这也完全可以培养,意识是行动的指南,人是环境的反应器,培养的关键其实就在于将自己植入语境,比如,好的职场、优质公众号、高质量的内容社区等。
好的语境会让你自生长,即便有些门槛,也足够覆盖时间的隐性成本。
将服务外向表达成产品,顶多只能说是敲开了市场的门槛,能否规模化、持续性增长靠的则是产品的标准化程度。
或者说,标准化其实是产品向商品转化的过程。
举个例子:
万物皆需求并非只是口头虚话,而是产品思维的意识应用,上周我参加契约锁电子签署的产品展会,看过他们的产品演示我当时就很有感触:如果说,客户演示是一款产品,他们的这款产品就非常标准。
简单来说,他们的产品演示非常标准、很有章法:
他们演示了四个系统,都是按照这样的三步操作,这样一套组合拳打下来,也让用户对产品价值记忆深刻;试想,如果A功能演示视频、B功能演示PPT、C功能演示系统,或者,随意组合,恐怕会让强迫症的受众抓狂,也会让产品价值弱化。
毫无疑问,标准化可以有效提高产品张力。
事实上,作为B端产品同学,我们的需求典型特征往往在于“功能上极度相似,细节上千差万别”,猛的一听,现有系统基本满足客户需求,真正开干发现几乎相当于重构。
未来细分领域的B端产品竞争,应该在于对产品标准化的能力和效率:能力体现在能否将产品的功能更通用、更拓展;效率则体现在与竞争者赛跑的速度。
身在安全行业,观察竞争对手的产品发展:有慢的变快的,有快的变慢的,有快的更快的,有慢的更慢的,但,加速的根本原因,大多在于依托标准化产品能力对客户定制化场景需求的支撑效率上。
什么是平台呢?ChatGPT给出如下定义:
在技术和商业上,平台通常指一种集成了许多不同组件和服务的软件系统或基础设施,它提供了一种中介服务来连接供应商和用户。平台通常允许第三方开发者创建应用程序或服务,这些应用程序或服务可以在平台上运行或与平台进行交互。这些第三方应用程序和服务可以通过平台来扩展平台的功能,为用户提供更多的价值。平台还可以指商业模式上的一种策略,即将供应商和客户联系起来,并在两者之间提供中介服务,从而产生利润。这种模式在许多行业都非常常见,如共享经济,社交媒体,电子商务和在线市场。通过建立平台,公司可以吸引更多的供应商和用户,并创造更多的价值。
同样也正是因为B端产品线繁多,产品矩阵宽广,标准化数字产品的持续发展到最后,一定是走向平台化产品。
所谓标准平台化是指以标准产品为基础,从业务角度耦合平台,围绕行业领域、深耕业务场景,持续发展的归宿在于升级成一个业务统一的平台:
将产品、资源、服务集中在一起,通过这个平台可以实现多方连接、互通共享,形成一个大系统。
好了,说了这么多,我们再简单总结一下:
从需求场景抽象业务服务→将业务服务设计成系统产品→将系统产品标准化→将标准化的产品迭代升级。
也许未来B端的终极向往或许是:面朝用户、背靠平台→春暖花开。
专栏作家
产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。
本文由@产品大峡谷 原创发布于人人都是产品经理
题图来自 Unsplash,基于CC0协议。
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
联系客服