听说你在做To B,这些坑是不是很熟悉?
一提到做To B,很多小伙伴就不禁吐槽“To B里面满满都是坑啊”,比如文中提到的这几点——需求混乱、改动频繁;研发周期长;产品定制化、项目化等。要想克服以上困难,做出一款优秀的ToB产品,我们还有很长的路要走。
在上一篇文章《敏捷开发不是口号,是时候分清快速迭代与整体规划了》中,很多小伙伴读后都引发了共鸣,有人说“我们是To B业务,但是实行的也是快速迭代,使用者提出问题,开发就顺手改了;然后改着改着就发现还有别的情况,可能改了也没用,或者改完也有问题”。
小伙伴们说起做To B的痛,每个人心中都是满满的苦水,那么让我们来总结一下这些坑。
一、需求混乱,改动频繁
对于这种现象其实在甲乙双方中并不少见,究其原因有两方面:
第一,甲方通常是较为传统的企业,虽然是用软件科技的方式进行工作,可还是存在外包的意味,并没有真正意义上的产品经理在中间收集需求,排期迭代;
第二,面对甲方,乙方的话语权很小,基本客户说什么是什么;再加上To B业务复杂,专业性强,导致产品经理的存在感很弱。
在上述流程中,大家都能明显看出来,如果客户直接让开发去改,会产生很多问题和隐患。
比如技术开发人员在改动时,如果不考虑到连带关系及潜在变动,往往会出现越改问题越多的情况。另外,没有统一的迭代规划,想到哪改哪,导致原有的排期进展停滞不前,到最后验收的时候通常会变成一个烂摊子。
面对这种问题,很多小伙伴都有同感,有人说做To B就是有无数的坑,这个还没填满就出新坑,导致大家很累很疲惫。我们通常所说的To B需要的To C思维往往会存在一些问题,比如上篇文章讲到的敏捷开发、快速跌代等,其实更多时候适用于反馈及时的C端产品,而并非分期交付的B端产品。
二、绕不过的定制化与项目化
项目产品化,产品市场化,这些理念看似很美好,可实际操作时往往会发现不通用,逐渐都变成了定制,而定制就会很重很累。
SaaS 在美国有很多上市公司,但是在中国没有几个像样的公司,原因在于——国内各行业没有统一的业务标准,SaaS很难盈利,很少企业能够坚守不做定制化的原则。如果做,就离产品化更远。
网上有个问题说“许多SaaS产品发展到最后慢慢走了老一代企业产品的路,项目化、定制化,产品被做得不堪重负,怎么看待/解决这个问题?”
一位前阿里的资深员工给出的回答如下:
“标准化产品与项目化、定制化之争,永远存在纷争,能不能做到坚守是关键。贪图一时的销售数字,第一次没忍住,丢掉了底线;第二次,第N次……我觉得可能会一次次失守,因为诱惑太大了。
但如果能以较小投入带来较大回报,何乐不为?比如从产品架构出发,做好底层规划与设计。iPhone无法提供全部所需应用,但通过App Store形式让用户更有获得感,阿里云无法做全部的服务,却提供了云市场满足大家服务的需求。
所以,如何让产品保持基本架构不变,又保持灵活性?还有很多形式,API、插件形式也可以采纳。如果架构上做不到,敢不敢把钱分一点出来,培养你的生态伙伴,大家一起服务客户。”
做定制化,则离产品化越远;不做,则失去了一笔订单。在利益面前懂取舍,是决定企业发展方向的关键。
三、To大B与To小B
同事说他一直在关注的两家公司,规模和创办时间都很相似,二者都是To B,又都具有代表性—— 一个是针对头部大型企业的公司A,一个是针对中小企业的公司B,时至今日,B公司已经获得了C轮数亿元的战略投资。此时的B公司正在依靠战略投资方广泛的关系网进一步拓展客户。
而专注于头部大型企业的A公司被客户搞得疲惫不堪,每多一个项目就要同比增加人员投入,利润虽然上去了,成本也是同比上升,所做的东西并没有完全形成自己的产品化,释放产能。当然,事情还没有结局,我们还不能看出A与B之间的胜负。
但至少在现阶段,B公司过得相对顺畅一些。为什么印象如此深刻呢?是因为我们在采购B公司产品的时候,被他们坚定的原则所震撼,一个很小的定制功能,对方终究是没能投入资源定制,我们购买时做了妥协。
而A公司前进路上遇到的阻碍会相对多一些,因为头部大公司数量有限,新兴创业公司很难被市场快速接受,经常性的一个现象是——在宣讲时,客户领导会被先进的理念所打动;而实际做决策时,依旧是选择了那些相对老牌的供应商。
这其中与品牌价值有关,也与B端在国内的历史特殊性有关。比如决策者和使用者并非一人,于业务使用者来说,已经有一定的使用习惯和产品认可,新兴公司要超越,需要完美的客户案例以及实打实的价值产出。这是一条任重而道远的路。
四、一直追求的产品化,并没那么容易
记得之前曾看过远望资本程浩的分享,他说To B为什么没有To C增长那么快,很大的一个原因是所有的To B类项目都有实施成本和实施周期,你产品化能力的好坏直接决定了实施成本,产品化能力强可以用更少的时间和资源投入去完成同样的任务。所以产品化也是我们一直强调的To B类业务必须有的非常重要的能力。
这种能力并非可以轻易获得,云知声CEO黄伟曾说:
“我理解To B有两种做法:一种是项目To B,一个客户给我提需求,搞一个团队,充分理解用户需求,搞到6-9个月,搬到另一个客户那完全不成立。还有一种是产品To B。
我们认为这是两种不同的思维,对团队的要求完全不一样。用产品To B意味着需要用一个相对标准化的产品。它的技术能力和技术方案,能适应大多数用户比较共性的需求。这是比较难的,但一旦你做到了,你就可以快速在不同产品间复制。如果你做不到,注定是项目公司。”
To B的公司核心在于产品化能力,从项目To B过渡到产品To B,前路艰难,任重道远。
五、研发周期长,看不到方向
很多人说,之前做To C 或者互联网类型To B的时候,一般从运营思维去做产品,一直通过MVP的形式去快速落地与验证,节奏很快但落地及数据反馈也很快、也很充实。
而现在做传统行业2B类软件,一个项目会几年的研发时间,这对于习惯了互联网和快反馈的产品研发人员来说,往往会如履薄冰。
此外,上千万的预算所要交付的成品,业务方没有跑过成型的业务模式,在过程中每次对接总有不同的想法,这样会让产品非常煎熬。
我非常理解那种感受,我曾用一句话形容过“一边走在悬崖上,一边眺望远方”。每个人都说前途 光亮,可都不知道怎么走,每向前一步,都需要很大勇气和胆量。
六、结语
如今C端互联网产品纷纷被大家叹息人口和流量红利减少,价值红利更加重要。比如留存、转化率以及客单价,从人口红利、到时长红利、再到价值红利,对应的是从野蛮式、到场景式、再到数据式的转变。
在此情景下,很多人觉得To B是一颗救命稻草,可是做了To B才发现,步步是坑。如今产业互联网和B端逐渐受到重视,但摆在B端面前的问题却一直存在,在供给侧改革的时代趋势下,To B产品能否完美出坑在各行各业开花结果,让国内的To B市场欣欣向荣,我们满怀希望和期待。
一起加油,共勉!
#专栏作家#
慕斯姑娘,微信号:musiguniang,公众号:产品那些年,人人都是产品经理专栏作家。关注金融科技和大数据领域,擅长产品规划和落地。
本文原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
甲方一般都会有上线的压力,很多需求人员都是没做过多少IT项目的(但是项目上线仍然是他们的KPI),需要以专业角度讲解项目上线的节奏和scope的控制,是对双方有利的,加上必要的强势。当然如果领导也很弱势就没话说了……
目前我还遇到一个问题,公司to b,产品是通用版的,但是到了后期公司对于产品经理的需求就不大了,因为产品基本都能满足用户了,产品慢慢的就变成跑市场了,应该怎么办呢?换公司?变市场人员?
懂产品的销售才是好销售,你可以做售前支持
稳住,好的产品是需要迭代的,会有新的需求的。
要理解公司的业务模式、管理模式、流程……
现在在公司里面做的就是2B的产品,只是我们的产品只是公司自己内部使用的ERP系统,物流行业,整天都是业务提过来的需求搞得头大,这种最坑的一点是,业务直接说,这里要做一个什么样的功能,你连了解具体的业务场景的机会都没有。很难把握需求的合理程度和需求规划。
同感,业务和前端销售不管场景不场景,直接说加功能,还有就是今天上午提的,下午又变了,然后第二天再加新需求和功能,好像每个功能能赚100W一样紧张
我身边几个人被To b坑了几千w
除了自身的理解,还有项目本身的管理模式等等也会造就一堆烂摊子出来。但是怎么解决呢?目前也没想到好的管理办法?
问题都知道,如何解决呢?
做to B业务的非常考验产品对于业务、对架构的理解深度,特别是产品架构足够灵活,做项目化就更容易。而在项目中能抽离可标准化的业务流程,项目也能帮助产品化;
另外,对于甲方提出的一些明显不合理需求,一定要学会拒绝!
理想的情况就是客户的需求与产品的需求能够清晰的被分离。
一句,我是甲方!!已经堵的哑口无言了
也在做TO B的产品,不过同时也有用户存在,一直在项目toB和产品toB之间平衡中,因为领导时间要求紧还要求是敏捷开发,往往有些时候会牺牲一部分产品TOB的需求,而去实现项目需求,搞得很狼狈,很希望能在这里得到解决方案呢
总结得很不错,我也在做toB,那如何解决这些问题呢
哎,扎心
🙄
测试
2b是苦逼的,坚守着
B端我觉得坑最多还是对于B端业务能力的理解,太多的领导需求了 😥