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

推荐订阅源

云风的 BLOG
云风的 BLOG
Blog — PlanetScale
Blog — PlanetScale
博客园 - 【当耐特】
博客园_首页
The GitHub Blog
The GitHub Blog
月光博客
月光博客
Hugging Face - Blog
Hugging Face - Blog
有赞技术团队
有赞技术团队
博客园 - 三生石上(FineUI控件)
D
Docker
Stack Overflow Blog
Stack Overflow Blog
WordPress大学
WordPress大学
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Apple Machine Learning Research
Apple Machine Learning Research
Vercel News
Vercel News
酷 壳 – CoolShell
酷 壳 – CoolShell
雷峰网
雷峰网
小众软件
小众软件
I
InfoQ
A
About on SuperTechFans
T
The Blog of Author Tim Ferriss
S
SegmentFault 最新的问题
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - Franky

人人都是产品经理

为什么你的产品找不到差异化?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端产品就很容易落地!
元方 · 2023-01-14 · via 人人都是产品经理

B端产品的使命是为公司降本增效,那么一个好的B端产品要怎么做才能够更加容易落地?作者从B端产品的产生以及方向的确定和后续的开发推广进行总结分析,希望能给你一些启发。

一、B端产品是未来

之前看到一个观点,C端产品(面向用户)已接近尾声,B端产品(面向企业)开始大放光彩。从逻辑上,目前确实如此,C端产品相当于是一个入口,如各大电商、各类内容平台(短视频、长视频、阅读等)、手机银行等等,都已被各大巨头分割。但是C端产品背后是由什么支撑呢?就是大量的B端产品进行支撑,比如直播带货再好,物流、信息流、财务流没管好,也会入不敷出,投入产出不成正比。

B端产品的使命就是为公司降本增效。降低什么方面的成本?提升哪个环节的效率?都是B端产品来挖掘的,可以说在目前经济形势不好的情况下,无论是互联网企业、传统企业,收入降低,那么降本增效控风险就尤其重要。

B端产品种类也很多,主要是围绕企业业务来发展,比如对外业务支撑类:销售系统、客户管理系统、供应链管理系统、广告系统等;内部协同类:各类办公软件、财务系统、人力系统、ERP企业资源管理系统等。

二、B端产品如何做?

那么B端产品如何从0到1,再到产出落地呢?笔者有五年B端产品经验,走了很多弯路也收获了很多经验。以下就是核心总结,希望对大家有帮助。

B端产品的产生会经历很多过程。

首先,发现机会(需求),如从某个业务方提出需求,或是众多需求中优先级最高的,但如果用户不提需求就没有机会了吗?这时候就需要勤劳,多和业务交流,调研不同角色用户现状,从中发现机会。此阶段还涉及需求是否有必要做,投入产出比有多高,是降本增效控风险的哪个点。确认产品目标及产品架构、不断提炼价值点进行立项申请预算也是非常重要的,你说不清楚目标、价值,你就要不来钱,项目就无法启动和开发。

然后,就需快速出最小MVP,即最小必要功能跑起来试点,这也离不开与业务的紧密连接。这里的mvp会出现几种情况,第一种是和业务想要的完全契合,现实概率很低,第二种是方向没问题,落地方案有问题,概率较大,则需立即调整;第三种是方向就错了,这种情况就要及时止损,重新再梳理产品目标。这也是MVP的优势,快速迭代、小步试错。千万不能在前面就把产品架构做的非常庞大,耗时耗力还经不起验证。

最后,就是全面铺开了,经过试点验证的mvp就开始想方设法大面积推广了,在此环节也是未知数比较大的一个内容,里面有很多坑,需要咱们开始就有风险意识去规避。

以上总流程中,个人认为最难的环节是两个,产品方向确认和产品开发后的推广。而且这两个环节也不是一次性完成就结束的,是持续不断根据业务发展而努力调整的。

三、产品方向确认

B端业务入门真的很难。

首先,业务现状散落在不同角色用户的脑袋里。他们日常工作的流程现状是怎样的?他们为什么要这样做?他们的目标是什么?操作人素质和意愿度不同如何沟通?可否利用软件产品能帮助他们提高工作效率?如果一线用户的诉求和总部整体管理诉求相互冲突怎么办?有两全其美的方法吗?如果没有要牺牲哪一方的利益呢?等等。

以上这些问题,在实际工作中,一直困扰着每个B端产品经理。而B端产品经理的每次选择,都会决定产品的发展发现,也会影响很多的参与方和间接利益方。

比如我曾经负责过的结算返佣系统,主要目的是保证操作人员把佣金计算好,再走审批流,再把佣金成功发出去、财务再根据付款单做账的流程。操作员听到有这个返佣系统时,高兴地跳起来,和我说终于不用自己根据复杂规则手动计算了。可实际上用户开始用这个结算系统时,苦恼地发现,不仅没有降低她的工作量,还增加她的工作量。

原来她只需要线下收集每个人的基础售卖信息,然后再根据规则Excel算出每个人的返佣金额,在提交财务去付款。上了系统后,不仅线下算一遍,还有再一笔笔录入系统或是批量导入系统,非常苦恼。

其实我作为产品经理,我也很为难。

根本原因是,返佣系统不仅只针对这一个一线公司,还有集团的其他一线公司,而且每家公司的根据不同地区市场等因素返佣规则都不同,每月也会变化,如果做到系统里面,自动计算每个人的返佣金额,系统规则将非常复杂且无法穷尽。研究了相关竞品,他们也很痛苦,每个月返佣结算都要一家公司配一个运维同事。40家一线公司就要配40个人,成本太高。

而且关键支持者是财务人员,他们要求结算系统快速开发和推广上线。

面对这些压力,最终确认1.0版本是把线下业务数据线上化,输出数据到财务系统保证做账数据准确,2.0版本再逐步优化线下业务数据如何智能化。

产品方向确认了,接下来产品架构、业务流程图、不同模块功能就呼之欲出了,最小MVP就很容易做了。

四、产品开发后的推广

  B端产品和C端的推广策略并不相同。B端主要是内部降本增效目标,可能局部看是增加工作量,但总体看还是降本增效。但实际操作用户并不能理解站在集团全局的思路,这种推广就比较难。如果集团能给一定支持,从上而下就必须要上线还好点,但对于没有多少集团支持,但还是要完成全国推广任务,就要想办法找到多种合适的推广策略。

产品如果是功能不够,就只能运营凑。产品推广策略中,比较好用的有以下几种方式。

首先,找公司试点。在产品设计初期就需把愿意尝试的试点公司拉进来,一起确认方案,这样不至于产品方案无法落地。但也会遇到产品方案只适用于试点公司,其他非试点公司则无法适用,则又要大改的风险。我负责的项目就遇到过类似问题,

为了规避这个问题,在产品设计之前的调研环节,尽可能的通过调研问卷、访谈等形式全面的先了解一线现状,然后从中按照一线公司意愿、典型业务规则、区域划分等条件,筛选出一定比例的试点公司,比如全集团50家公司,按照10%的比例,选择5家是比较合适的。再通过业务现状,选择比较典型的且意愿度很高的公司,这样不仅对产品的从0到1的开发很重要,对开发后的推广也至关重要。

其次,有了明星标杆案例后,就开始找各方资源进行支持,比如这个产品对谁最有利,就积极和有利的业务领导去沟通,通过数据指标量化、业务流程优化,如能节省多少钱、提升多少人员效率等入手,获得大咖的支持。这里还值得提醒,C端产品使用者一般是有利者,但是B端不一定。比如对财务有利的,对上游的销售操作人员没利,还徒增工作量,这时候优先级总体大于局部,多数大于少数就需要产品经理决策。

现在B端产品也在经历从线上化(初期线下数据录入到线上系统来),到数据化(无需人工录入,系统自动根据上游条件生成业务数据),再到智能化(运用原生数据、业务环节加工数据进行反哺业务)的转变。

本次文章针对的是第一步线上化的经验总结,后面会持续分享数据化、智能化的实践经验。

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

题图来自 Unsplash,基于 CC0 协议

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