2B产物的隐藏陷阱:出售驱动
本文摘要:出售驱动的产品方式,关于2B公司来说确实是一个常见的因素(当然还有很多其他原因),要知道怎么辨认宽和决这些问题,产品主管,是有职责去扫清产品开展的一切妨碍的。近年来听到愈来愈多2C衰退,2B兴起的声音,虽然我对这种说法保留心见,但知道的同行也有愈

出售驱动的产品方式,关于2B公司来说确实是一个常见的因素(当然还有很多其他原因),要知道怎么辨认宽和决这些问题,产品主管,是有职责去扫清产品开展的一切妨碍的。

近年来听到愈来愈多2C衰退,2B兴起的声音,虽然我对这种说法保留心见,但知道的同行也有愈来愈多人考虑转到2B行业。作为过来人,本文分享的是2B产品(特别是大)里边做产品规划的一个很常见但有很需要解决的深坑,是需要这行的产品主管去面对宽和决的的。(当然假如你给自己的定位就是原型仔和需求编写工,那接下来的文字对你没啥意义)

相信很多2B企业市场的产品主管都会遇到这种状况:产品规划里边呈现了一些功用是专门做给特定客户的“一锤子生意”。当发生这种状况之后,祝贺你,你的公司要不现已进入了一种“出售驱动”的产品开展道路,要不就是行将进入了。

“出售驱动”的一大特点是,产品研发的重点落到了某些特定的客户上,价值是牺牲了产品核心价值的立异、新的功用、质量提高和技能优化。

用这种“驱动方式”开展下去的产品,最终会失掉寻找到真正不可代替的价值点的时机,乃至发现“出售驱动”的产品变得更难出售了,更不用说能成为Scalable的商业模式了。可怕的是,团队可能往往意识不到为何抵达了这种境地,乃至没无意识到呈现了问题。所以首要,我们应该拨乱反正,从底子分析一下问题的地点。

产品和项目

在说“出售驱动”之前,首要我们要理清做产品和做项意图差异,跟2C产品不一样,2B产品是很容易稠浊做产品和做定制项目两件事情的。先来看一下两者有什么不一样。

企业软件行业的老长辈阿朱的《走出软件作坊》里边早年做过产品和项意图比照,我印象一直十分深入,虽然成书现已以前了一段时间了,那时分乃至还没有云、SaaS这些概念,但这个差异的本质我认为到现在仍然适用,粗心如下:

做项目,就是一两个程序员往客户那一驻扎,您说你想要啥我们就做,做完您看行就验收,不行我们再改,觉得没问题我们就回去了; 做产品,是规范的,不会特意为客户修正,您要觉得拿点不顺眼不想买了我也没方法,我们不修正,我们不改您就不买我们也没方法,您要买了,那我们就上门装置、施行,就这样。

最难的就是说产品不是产品,说项目不是项意图东西。一个东西,本来是给A客户做的项目,然后B客户看着不错也要,然后把A客户的项目代码改改给B客户用,这下麻烦了,A客户代码里边有了B客户要求的功用,这下软件既不是A客户的,又不是B客户的,然后之后再掺和进C、D、E客户,就更是头疼得要命。

阿朱是从开发和代码管理的层面,来看稠浊产品和项目两者之间关系的弊端的。我们还能更进一步,从商业和财务层面分析两者之间的差异。

做产品的公司出售的是规范的产品,一个产品可以不断重复地出售给不同的客户,这样单位的边际本钱低于单位价格,这样才干构成一个可继续的模式。做产品的公司都是前期投入大,要把出售量到出入平衡点,超过出入平衡点之后的出售后额绝大部分都是高利润了。

做定制项意图公司就不一样了,每个项目是单独核算的,目就是要确保每一单都是赚的。客户提出越多的需求,项目可以赚更多的钱(当然条件是客户招认新需求发生的工作量,这个也是很需要项目团队的管理水平的),每一个客户都可以得到独立的产品。

很多做项意图公司都会尝试开始把项目转化成通用产品,不过一般而言很难有头有尾,新的定制项目会不断打断所谓的“产品化工作”,毕竟项目是可以马上来钱的。

产品和项目两者模式其实不分高低,只需世上还有共性需求和个性需求之分,两者都可以赚钱。但关于2B产品来说,很容易不知不觉中地走入一种两者混合的模式:一种半定制的软件,需要不断投入研发人员来支撑新的需求,但又不是通过定制项意图工作量而是软件授权的方式来报价,往往折中报价方式又过低,用这种方式开展的客户数也不足以达到出入平衡点。

很多时分我们遇到的很多困难,例如开发资源无法支撑很多客户的需求,出售觉得开发部门不给力呼应慢,开发部门又觉得出售乱许诺客户给自己挖坑需求怎么做都做不完,这些都是表面上的困难,底子原因就是这种混合模式就是底子无法大规模扩张的模式。

“出售驱动”是怎么发生的

接下来说清楚“出售驱动”的模式是怎么在公司里边发生的, 分为下面几步:

一个正常的产品驱动的道路是怎么规划的; 客户定制的“一锤子功用”的呈现; 接下来会发生的累积和一系列连锁反响 “产品驱动”的道路规划

一般而言,关于一个现已成形,开始找到自己的Product/Market Fit的产品来说,要让产品健康地开展,研发团队要投入的精力一般包括四个部分:

看得见摸得着的功用提高:新的功用、用户体验和可用性的提高、对竞品功用的呼应,等等; 各种“基础设备建设”和“性能提高”:可用性、可扩展性、安全性等等; 各种“测试、修复和运维”:修复bug、测试用例、DevOps、填技能债务等等; 不断地学习和验证:用户调研、数据分析、原型设计来更深化了解一线用户、验证主见,来给产品下一步立异做准备。

这四个部分都有让不同人支撑的理由:

市场和出售期望产品可以有更强壮的功用卖给客户,所以他们会鼓励不断地做新功用; 技能人员最清楚软件平台里边的技能风险和缺点,所以他们会期望能更多地投入在架构、东西和重构上(就是赶忙把留下来的坑填了); 施行/客服可以尽量减少客户的投诉或疑问,所以他们会更期望投入在bug修复、可用性提高,让暴露到客户的问题越少越好; 老板期望产品有更进一步的打破,但他们常常会把打破和立异视为个人情绪努力而不是用科学的方法进行推进的成果,他们往往会低谷需要在实验和验证上需要投入的本钱。

作为产品主管,我们在做产品规划的时分,会把有限(永远都不行)的研发资源,像投资建立投资组合一样,折中和平衡分配到以上几个方面,期望这种投资组合可以让产品更健康和可继续地开展。就像玩星际一样,要在把资源在攀科技和爆兵之间做平衡。

于是哼哧哼哧一轮,我们可能会诞生一个这样的基于以下资源分配的产品道路图。

道路图看起来不错,然后老板也通过了。然而没过几天,出售团队反馈说,某个大客户有点需要定制的“小功用”,于是恶梦慢慢开启……

“XX客户期望能完成这个功用”

产品的用户提出新的功用需求是人情世故(毕竟强如微信也有一亿人要教张小龙做产品)。在2C产品或者小B市场里边,有不计其数的用户,单独某个用户不会直接影响到到我们对产品道路的改变。产品团队会广泛汲取各方面收集到的优化点,这些优化点可能来自于用户的直接反馈,也可能来自数据的收集和分析,关于行业和环境的观察,关于竞品的分析等等。总之,很难会呈现单独一个客户就可以影响产品道路的状况。

但关于企业市场来说,客户规模(和随之而来的影响力)会更大,数量也更少。极可能某个客户的合同就会占到公司5%的总收入。这种状况下,单独一个客户关于产品决策的影响力就会比2C或小B大得多。而这些客户也常常会给出售人员提出他们的个性需求,常见的包括:跟客户的其他体系进行整合、工作流程的调整、报表定制等等;

出售人员会怎么处理呢这些需求呢?先看看出售人员的专长和思维模式:

出售人员一般都乐观、不轻言抛弃,还特别拿手和人打交道和在组织里边找到推进事情行进的要害人物; 拿手说服:能用他们强壮的说服力,把客户的需求从头掰成我们的产品可以大部分满足他们的应用场景(虽然实践上不是这样),再进行招标; 企业关于出售人员的业绩评价规范十分简略粗犷:能签单就是成功(就像电竞界一样的:没有成果,连呼吸都是错的); 对出售人员的激励方式(出售提成)让他们百分百专注于自己手头上的客户和出售时机。

所以当客户跟出售提出一些产品本来道路图所不包括的需求时,出售人员就会很天然地要求产品主管去完成这些功用。正常来说,他们首要得到的答复通常为“我们先记载下来,然后下个季度再来考虑”或者“这个排不上期”而不是“这个主见太棒了,我们立马做”。

合理产品主管单纯地认为自己现已把事情完结了的时分,不要忘掉出售人员不轻言抛弃、拿手说服和找到要害人物的专长。这些专长可以协助到他们在外感动客户,天然也能协助到他们对内对管理层施加影响,然后管理层就会从出售人员那听到下面这些说法:

“这个客户是我们重要的大客户,关于我们具有战略意义。完成这些需求关于签单/收款和达到出售方针是有必要的”; “这个需求很简略”; “这个客户很清楚想要什么,会成为我们市场里边的一个标杆客户”; “我们选用灵敏的开发方式,所以研发方案应该可以活络调整的才对”; “这个是市场通用的需求,而不是单个客户的需求,我们谈过很多的客户都期望有这个功用,这个功用其实早就应该做了”

这些说法看起来都合理(我们也却是期望它们是真的合理的,这样做产品就比现实上简略多了),正因为出售团队所花的所有时间都是在客户身上,从这个角度来说,他们也确实可以认为自己就是最了解客户真实需求的人。

然后接下来的推论就会变成,因为这些客户关于我们太重要了,我们一定要找到方法来体重资源来效劳他们。于是,我们前面那些安身于全体的产品规划就会为这些特定的客户需求所让路。就算产品想挣扎一下,说出来的理由跟出售人员的相比,更像是推卸和怨言,常见的包括:

现在现已没有空余的人手来做这些事情了; 假如要做这个那原定方案中的XXX和XXX就要延后了; 客户不了解我们软件的现状,所以他们提的需求我们需要从头仔细分析,开始判断这些是很大的工作量; 假如这个需求是通用需求,那我们早就把它放到我们高优先级的工作上了;

然而这些对立定见一般最终都没有什么用,我们仍是不能不把这些需求排进我们的产品道路图傍边。而我们之前分析的几类工作傍边,也只有终究一种——学习和验证,相对来说最不紧迫,而从这些工作中抽调人手在短时间内影响最小。于是我们新的资源投资组合就变成了以下这样。

看起来还没有啥大问题(虽然牺牲了点有久远回报的投资),不过往往事情没有那么简略。当真的开始开发这些客户定制的需求的时分,就会不断发现有新的坑:新的流程需要改变我们现有的数据流转方式;客户现有体系用着不规范的对接方式;一些看起来简略的UI个性化需要,要重写成可活络配置的形式,不然就要变成两套代码来维护等等。

当然还有最坑的,其实客户自己最开始也没想清楚或者说清楚,做着做着还得改。然后为了赶客户给出的时间点(这是常常发生的),不能不交给出一个背负很多技能债务、乃至还没有通过严厉测试掩盖的产品出去。

这种定了时间点就要完成的功用,也往往会让我们忘掉(或者避而不谈)去验证这些需求背后真实性和是否真的存介意义。于是实践上,我们的投资组合成果变成了这样。

不过好音讯是,通过一大轮赶工之后,于是我们赶在了deadline之前把功用交给了出去,客户直爽地签单/付款了,老板、产品、研发、出售我们都大快人心。是否是认为事情就告一段落,可以回到我们本来的产品道路上呢?没那么简略。

进入“出售驱动”模式

有了上面这一次“成功的案例”之后,管理层和出售部门都尝到了甜头,知道了产品和研发部门是可以为客户做定制需求的,这种方式(看起来)也没有给公司形成什么损失。这个先例一开,后边就会成为常规。

其他的出售人员就开始照葫芦画瓢,用容许客户的定制功用(一般还附带时间要求)来完成自己的签单方针,乃至管理层也会开始要求研发部门优先去完成这些有助签单收款的功用开发,我们本来的投资组合的其他部分,被进一步积压,最终变成了这样。

于是我们的产品研发的决策模式,也从考虑全体市场的方式,变成为每一单真金白银合同所附带的功用所开路。单独看,每一次决策好像都没什么缺陷,但整个产品现已不知不觉中堕入了一种部分最优的死循环里边:

优先做客户个性定制需求— 牺牲了产品的全体水平(不只仅是功用、还有安稳性、可用性,最重要的,真的能为广泛客户解决真实痛点的能力)— 只能更依赖出售人员说服客户和满足客户的定制需求才干签单— 优先做客户定制需求— ……

到了这一步,一系列的连锁反响就会慢慢开展和迸发,体现在:

需求来自不同的客户,附带的严厉的时间要求,也让我们没法为一个需求深究其背后的真实痛点做出底子的解决方案,这些功用点也往往不存在什么真实的战略价值,这些碎片化的需求影响了产品的内涵一致性和久远开展的能力; 产品主管从“产品的CEO”,变成了被动地应对客户需求的状况,实践上变成了效劳客户的项目主管和原型/需求编写工,不再能积极主动地规划他们的产品; 研发/设计人员会失掉积极性,因为他们被迫承受客户指定的需求和时间点,而不是用一种学习和探究的方式来开发产品。而这些客户的需求完成后也很少会有正面的反馈(一般都是出问题了才来找你); 出售团队也会慢慢发现自己的日子不大好过了,客户仍然会不断地提出新的定制需求并且胃口愈来愈大,而研发的排期也因为其他的客户需求堆积,变成了一个长长的行列,再也无法像之前那样快速地去呼应客户,想继续用这种方式谈新的客户也会愈来愈困难; 整个公司的利润率会下降:软件产品商业模式的魅力原本是很低的边际本钱,但在现在的既不是产品又不是项意图方式下,软件的授权费用未必真的能掩盖客户定制需求的本钱; 市场份额增加缓慢,因为让路于客户定制,产品不再有新的亮点来扩张新的市场了。

矛盾开始会迸发,然后就会开始乱找病因、乱开药方,“产品主管应该要更快速呼应客户的需求,哪怕先做个方案呼应一下客户”、“开发人员功率是否是太低了,他们能不能加班赶进步度?”“出售能不能不要乱给我们挖坑?”然而这些都不是问题的底子地点。

底子的问题就在于组织形式和盈利模式的错配:单个客户的需求优先,让我们牺牲了为广阔市场去规划和研发产品的能力,做着一个个隐藏在产品外衣之下的外包项目,为一棵树抛弃了一片森林。

怎么解决问题

上面说的这些问题,是一个体系性的问题,不是单个产品、研发或者出售人员可以仰仗自己的力气去解决的,而是应该是跟管理层一同,待人以诚地评论宽和决问题,尝试用以下的方式来解决:

(1)辨认自己是否正处于这种“出售驱动”的状态傍边:全体分析一下产品和出售的运转遇到了瓶颈了,新客户的获取是否愈来愈依靠于定制开发?可以把最近的一段时间(例如半年到一个季度)的研发投入拿出来分析,有多大的比例是用在为单独的客户定制功用上,又有哪些所谓的“提高产品水平的通用功用”实践上只有一两个客户在用?我们所做的新的功用是否跳过了验证的步骤?

(2)公司究竟是做产品仍是做项目才是真正满足市场需求的?完全分析自己地点的行业和要满足的需求究竟是否可以用通用产品去满足,仍是需要一个一个的定制项目去做,妄图选用折中的方式一定异常艰苦。

(3)该是定制项意图,就按定制项意图模式去报价,然后去应用专业的项目管理的方式来管理客户的需求,不要愿望着为客户定制的需求可以变成通用的产品,虽然不是完全不可能,但这概率就跟刮彩票一样,刮到了算是赚了,但不能指望着刮彩票来过日子。

走定制项目道路的,也能够让专门的研发力气去打造平台和东西(例如PaaS或者现在很火的中台概念),来提高全体的研发功率。

(4)该是做规范产品的,就要正视问题和管理好“出售驱动”的问题,用运营产品的思路去规划和管理产品,例如:

从用户的获取、转化、留存等角度来考虑产品,极力去优化自己全体的LTV和CAC;规划需求的起点也不再是“做了这个需求可以满足什么客户”,而是要推理和假设一个需求能为全体客户市场带来什么,然后去验证他们; 从整个研发力气划分出一个坚决的底线,客户的一锤子需求不可以超过特定的比例(例如一个季度不超过两周的时间),所有的定制需求的需要的资源都不能超出这个资源池来获取,需要出售部门自行给所有客户定制需求划分优先级; 调整不同的激励方式:例如出售团队通过出售规范产品可以取得完好的提成,但关于定制需求则需要依照完成本钱的一定比例进行扣除; 谨记资源是有限的,有额定的东西组织进来,必定有其他工作被牺牲掉,这些牺牲掉的,多是产品的久远利益; 把定制工作从产品的核心中剥脱离来,定制工作一定要依照定制工作的方式来定价,乃至可以考虑和专业的定制项目公司合作,把定制工作外包出去,由专业的人来处理专业的事,自己的产品团队则专注在产品的核心; 客户提出的需求也不是完全回绝,而是要总结概括出共性的当地,考虑出有共性的产品方案来解决客户的真实的痛点,可以用通用需求通过配置的方式来满足一定的个性化需求,而不是通过定制,可是对这些解决方案要有足够的耐心和投入足够的精力进行学习和验证。

当公司盈利的时分,很多问题可能都不是问题(就像赢球可以掩盖很多问题),可是当公司增加受困,作为产品主管,就要从产品的角度来分析宽和决问题的底子地点了。

而出售驱动的产品方式,关于2B公司来说确实是一个常见的因素(当然还有很多其他原因),要知道怎么辨认宽和决这些问题,产品主管,是有职责去扫清产品开展的一切妨碍的。

参考:

RICH MIRONOV:《[The Slippery Slope of Sales-Led Development]》 阿朱:《走出软件作坊》 白鸦:《SaaS事务的价值评价》

 

作者:梵天,大众号:梵天Daozen(fantian-daozen)

本文由 @梵天 原创发布于人人都是产品主管。未经答应,禁止转载

题图来自 Pexels,基于 CC0 协议


我们在和客户谈方案的时分,客户明确说,这个功用是否是你们规范产品的功用,假如是定制的,就不需要了。那这时候,本来B客户就那么些,并且还这么多人抢的时分,公司天然要咬牙说,这是规范产品功用,吧啦吧啦。

本质原因仍是:1,B客户获客难,像我们做财务项意图,特么都是甲方爸爸,以维护关系为主;2,公司本身产品确实优势不显着,但很多时分,B客户不只仅只是看产品……决策链长


楼主你好,谢谢你的考虑和分享,想讨教个问题,文中有这样一段话

走定制项目道路的,也能够让专门的研发力气去打造平台和东西(例如PaaS或者现在很火的中台概念),来提高全体的研发功率。

这句话能否讲的更细些?为何PaaS和中台概念可以提高定制项意图研发功率?


产品运营人员或部门,够不行强势了。正常下,GTM、事务侧的产品人员,就需要可以两头牵


人人都是产品主管(woshipm)是以产品主管、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位效劳产品人和运营人,建立9年举行在线讲座500+期,线下分享会300+场,产品主管大会、运营大会20+场,掩盖北上广深杭成都等15个城市,内行业有较高的影响力和知名度。平台集合了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一同生长。