惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Tailwind CSS Blog
P
Proofpoint News Feed
V
Visual Studio Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
爱范儿
爱范儿
Microsoft Azure Blog
Microsoft Azure Blog
Recent Announcements
Recent Announcements
Vercel News
Vercel News
Hugging Face - Blog
Hugging Face - Blog
GbyAI
GbyAI
博客园 - 聂微东
D
DataBreaches.Net
酷 壳 – CoolShell
酷 壳 – CoolShell
Microsoft Security Blog
Microsoft Security Blog
L
LangChain Blog
美团技术团队
H
Help Net Security
aimingoo的专栏
aimingoo的专栏
C
Check Point Blog
U
Unit 42
博客园 - 叶小钗
有赞技术团队
有赞技术团队
M
MIT News - Artificial intelligence
MongoDB | Blog
MongoDB | Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
漫谈B端SaaS产品方法论
一个数据人的自留地 · 2023-04-12 · via 人人都是产品经理

最近B端的热度的逐渐上升,也出现了很多疑问,为什么做B端产品会更要求行业深度?B端产品与C端产品最大的区别是什么呢?本文作者将用通俗易懂的文字,为你解答B端SaaS产品方法论,推荐给对B端产品感兴趣的小伙伴阅读。

01 关于B端

最近B端产品的热度慢慢上升了些,笔者开始收到一些同行的咨询。在toB领域也算摸索了几年,攒了一些心得,整理分享一下。

首先提一个问题,B端产品与C端产品最大的区别是什么?

这个问题我也问过一些同行,答案不一而言。有的说设计风格,有的说行业垂直深度,也有说迭代速度。

我总结下来的答案是,最大的区别在于买单人。因为B端产品是面向企业售卖的,面向企业这个性质决定了它的一系列特点,这些特点又来源于究竟是谁在付费。

第一,产品的立足点在于帮助企业增长。由于企业的目标是尽量提高利润,那么其愿意购买产品的动力是产品可以帮助赚钱,或帮助省钱。与C端不同,C端用户的付费动机可以是用着爽,用着习惯,用着情怀。所以从这个角度往下切,产品经理必须要了解行业,了解一个企业基本的经营模式。这也是为什么做B端产品会更要求行业深度,源自于此。

第二,产品的买单人是高层及以上,统称决策者。由于产品是面向企业应用的,以及B端产品的客单价相对比较高,所以基本上企业的付费是走公账的,走公账意味着这不是一个个人行为,并且有较长的流程及多个角色的审批,那么就需要一位能够有决策能力的人来拍板。那么一个产品能否卖得出去,就一定考虑怎么打动决策者。

通常我们把决策者分为两种,总监级与老板级。总监级的特征在于,他承担了一个部门/事业部的KPI,他务必要让花出去的成本有所收获,所以他会计算ROI来决定要不要用某款产品。老板级的特征在于,除了希望公司多赚钱,他也需要监管员工的工作情况。

以及他很忙,希望定期能看到产品使用的数据报告就可以了。所以呢,打动总监在于,让他的产出更高。打动老板在于,帮他赚钱,或通过管理内部来省钱,以及不要给他增加工作成本。

当然对于小B公司来说,决策者有可能只是一个人,购买过程就会缩短很多,不过同时他们也会更在意费用多少,增加了一些价格上的纠结时间,所以最后也都是这么个意思吧。

把这个方法落到产品经理的工作中呢,我们就会发现,跟销售的同事保持良好的沟通很重要,因为他们非常清楚客户的诉求,客户的组织架构,客户的工作环境。

第三,产品的使用者往往不是决策者。高层或者老板级角色付费之后,一般是交给下面的执行者去实操产品。这两种角色的差异在于,决策者在乎收益,不在乎用户体验。执行者在乎用户体验,因为他们不想增加工作量,但不太会在乎收益,反正也没让他们付钱。所以做B端产品有个点要明白就是,用户体验没有那么重要。它不能直接决定用户的去留,连间接作用也比较弱。执行者往往只能用买好的产品,没那么多竞品可挑剔。但体验也不是完全无所谓哦,也要达到及格线的,不然执行者大量投诉,依然会给产品使用带来阻碍。

第四,产品的设计是基于实际场景出发的,绝不可以玩空中楼阁。当面向企业中的用户设计你的产品流程与体验时,要明白对方已经形成了他们内部的一些机制和方式,所以要先去了解他们,而不是闭门造车地臆想对方或许是这样使用的。作为B端的产品经理,我们可以优化他们的流程,不可以反对他们的流程。尽管都说产品要有创造力,那也要分场合,先保障基础功能可用才行。这里温习一下上面的知识点:与销售的同事保持良好的沟通,因为他们了解客户。最好能够去跟用户面聊,收集到一手的信息,记录与整理好对方的实际工作场景,然后才能设身处地理解对方的需求。我自己叫这种思维方式为“顺应”。cue一下产品原则之一:做一个好的产品,首先成为用户。

说完了差异,那么下一个问题,B端和C端最大的共通点是什么呢?

对于要一款要盈利的产品来说,无论toB或toC,本质上都要回答的是:用户是谁,你通过产品向用户提供了什么,用户在为什么而付费?

所以,结合这点及上面说的对于B端比较通用的几条规则,我总结了一个产品设计中使用的自查表。

漫谈B端SaaS产品方法论

使用方法是首先去填满它(……好像是废话),如果你发现有的空你都填不上,那不好意思你可能……只是个画原型的。当你填完之后,再从后往前反推一遍,你的答案成立吗?如果不能,很好,你还可以在正式开发之前校正你的产品路线。填写与反推可能是个反复的过程,会有点痛苦,好处是它迫使产品经理必须扎扎实实检查自己的需求是否真的有用,提升了需求质量。

插播一个小技巧:有个快速准确的方法检验一个产品方案是否可行——带着方案去准客户面前讲,观察对方的反应。通常对方有两种反应,第一种是微笑点头表示挺好的,第二种问你多少钱。不要被第一种反应欺骗,他们的意思是这玩意儿挺好的但是自己用不上;第二种反应出现的时候,恭喜,你的方案初步合格了。

02 关于SaaS

接下来我们往SaaS聚焦一下。为什么是SaaS呢,原因很简单,风大的先讲呗。

这里我会分三部分来阐述,一是商业模式的确立,二是产品设计与落地,三是1-100的经营思维。

第一,关于商业模式。

假设你现在是一个创业者,你的目标是做某领域里的SaaS佼佼者。那么你要怎么确定做什么产品?

可以从回答以下几个问题开始。

  1. 行业背景:该领域的产业链是怎么运转的?囊括哪些角色?
  2. 市场空间:每种角色的总的市场空间?目前已有哪些公司(用户群体划分)?
  3. 竞品分析:已经有哪些竞品攻下了这些公司?他们提供了什么?用户购买了什么?
  4. 需求分析:用户的需求都有哪些?哪些被满足?哪些没有?
  5. 落地路径:如果选一个未被满足需求来做,能否实现?实现路径?营收天花板?(注,这里的实现路径不仅仅是指开发过程,而是从整个公司的角度出发,让哪些人配合来完成生产+售出+售后的过程。)如果选已有竞品的需求,那么你跟他们的区别是什么?

在做以上的推理过程中要注意前后顺序,逻辑应该扎实地一步一步盘点,而不要跳脱。做商业决策是个复杂的事情,每一个因素都可能影响到结果,因素越多,最后带来的波动越大且不可控。我们都知道这不是个容易的过程,所以更要谨慎,切勿因为有些问题太难就糊弄过去,比如回答4的时候直接用竞品已经做好的事情来回答,那么就会失去潜在市场了,也不可能完整地完成落地。

我画了一张图示意盘点市场过程中应该明确了解的内容之一:

漫谈B端SaaS产品方法论

比较粗糙,反正就这个意思吧。就是说动手之前心里要有底。做产品绝不可以糊里糊涂。一个做决策的岗位一旦开始糊弄,就是整条业务线的灾难。

另外真正决定要做什么的时候,除了上述理智的分析,其实还有一个感性的因素存在。就是决心。《智能商业》里把它称为信念之跃。

第二,产品设计与落地。

做设计之前请先温习一个知识点:确保你足够了解你的用户。

设计分为两个部分,流程设计与体验设计。

流程设计的重心,是保证用户的业务能够完成闭环。闭环包括操作上对于用户的指引,比如步骤一操作完成之后引导去往步骤二,比如确认用户完成整个流程,不要让其不清楚自己处在流程中哪一步。闭环也包括数据流转的过程,比如用户行为数据收集,比如用户业务数据应用,要考虑的问题类似于用户从个人中心上传个人信息之后数据怎么放,如何统计如何刷新,其他模块是否能够应用,如果用的话数据以什么频率什么方式传递。整体设计基于对业务、用户、技术、数据的了解,所以对于产品经理的要求比较高。当PM在其中任何一环薄弱,就会直接严重影响产品质量。

体验设计的重心,在于不要给用户创造阻碍——包括流程性阻碍与细节阻碍。细节阻碍主要体现在交互设计上。这方面就考验产品经理的基本功了——交互设计能力,同理心与责任心。为什么要讲责任心呢,因为要做好这件事其实需要大量的心力投入,反反复复去思考与尝试用户实操的场景,观察与分析每一个细节。没有足够的责任心就不会支撑这种投入。如果是这方面经验略少的话,推荐读《About Face 4 交互设计精髓》,交互界的教科书之一。

第三,产品经营的1-100。

产品的经营分为两部分,单个产品的优化迭代,和整个产品线的规划。

对于单个产品来讲,迭代方式来自于两个方面,一是用户直接反馈,二是数据表现。优化的点也集中在两个方面,流程性问题,转化性问题。在思考具体做哪些优化需求时,可以参照下面两张图:

漫谈B端SaaS产品方法论

漫谈B端SaaS产品方法论

这个图的意思就是要对比最初做这款产品时候的预期与实际表现。对比的作用在于定位差异,然后寻找根因,分析之后尝试解决差异。这样能够保证产品路线不会走偏。这里也有一张自查表:

漫谈B端SaaS产品方法论

同理的,如果不知道怎么填,那么……就只是个画原型的。同理的,这个表格的填写也遵循反复推理的过程。不过这个比上次做的时候会简单点,毕竟聚焦到小颗粒的问题上了。

这个表填完后,最后一个格子“方案预期带来的”的内容将作为下次分析时候的基准线。

我在实操的过程中发现,以上这些问自己的问题,以及这些产出的文档,都是一环扣一环的关系。每一步踏出,都应该基于明确的信息,严谨的分析和推理。所以呢有必要存好一个产品的一生中的所有文档,这个思维我称之为“继承”。

单个产品的优化相对于整条产品线的规划来说是简单很多的。为什么产品线需要经营呢?因为每个产品都有它的周期,出生,兴盛,衰亡。产品依赖于用户,用户量是有限的,产品的增长就是有限的。但是一个公司的生意可以是无限的。所以一条产品线走到了天花板时,就需要第二条产品线。

与前文做商业模式的确立时候不太一样的是,这次的规划是基于已有业务去考虑的。这点可以参考许多SaaS的成熟玩家——金蝶明源广联达,他们都从一个点做起,比如说财务管理,然后延展其产品至整个业务线,这种方式叫做管道式发展,也可以称为纵向发展。当一条线的红利吃掉之后,开始开拓第二个点,然后再做一条管道。

管道发展起来,就开始横向发展。这样慢慢地产品从一个点,扩到一条线,再到一个矩阵,一张网络。就慢慢建立起了业务积淀和规模效应,从而发展出护城河。《智能商业》里提到一个点线面体的概念,类比于此。

以上,感谢阅读。

作者:一个圆圈儿

本文由 @一个数据人的自留地 授权发布于人人都是产品经理,未经作者许可,禁止转载

题图来自 Pixabay,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。