扫码阅读
手机扫码阅读

To B的软件产品死结怎么解?

104 2024-04-10

理论上,To B的软件产品就是服务于客户需求的,但现实往往并非如此。

01

“吐槽大会”

有一次,乙方过来拜访我们,这次拜访,一部分时间成了我们作为甲方对他们的“吐槽大会”。

该产品已经上线了一段时间,它提升了我们的平台能力,也为我们提供了更多的服务,但也存在一些“老生常谈”的问题一直没有得到解决。

对于该产品的主要问题和我们的期望,在会前双方都已经做了沟通,有具体的议程。这次来的,有对方的商务和某个模块的架构师与产品经理。为了避免太发散,从而能达到成效,我们也把问题和议程集中在某个模块。

在会上,该模块的架构师针对我们提出的问题,都给出了一些方案,但坦白说,我们对这些方案,不管是针对我们短期的问题,还是远期的期望,都不太满意。

对方也坦言,很多我们关注的根本性问题涉及到产品的底层设计,在他们这个层面无法解决,产品也不支持就单个模块进行升级和改造。而且,整体产品会收到各个客户的各种需求,我们提出的需求只是整个产品backlog里的一部分,不同客户间的需求,特别是涉及到底层设计的,可能会互相冲突,有时很难拿出一个两全的方案。

从我们的经验来看,即使我们通过不断施加压力,最终迫使对方交付了我们一直期待的需求,但在用户体验、质量、产品升级的可靠性等方面都会有各种各样的问题,还会有很长的磨合过程。

02

To B的悖论

理论上,面向商业用户,也就是To B的软件产品就是服务于客户需求的,客户理应期待他们所有的需求都能被实现。但是To B产品并不是外包开发,它的底座是一个成型的产品,而且是服务于它的全部客户的“公共产品”,针对某个客户的定制化开发只能是锦上添花,会受到产品本身以及其他客户需求的约束,这种复杂性也导致了交付、升级周期很长和很多质量问题。双方的预期会有很大落差。

我曾经开玩笑说,做To B或外包的,往往都是双方老板很开心,执行的很悲催。乙方的商务、产品经理和服务,甲方的业务运营、IT实施和运维团队,都是“夹心饼”,需要面对大量难解、无解的细节问题。当然,从职场的角度来说,这也产生了大量的工作机会。

做To C的产品经理的“话事权”会大很多,他们可以根据自己的洞见确立产品的整体规划和特性。普通用户对于产品特性和问题是没有话语权的。To C的压力更多来自于竞品。

03

To B vs To C

To B和To C的逻辑是完全不一样的。

从商业的角度来看:

国内著名商业咨询顾问刘润总结得很好,To C靠产品,To B靠服务

To B商业最大的特点,是流程和复杂。甲方的干系人众多、意见纷繁、流程长而复杂。To B,除了依靠产品,更要依靠销售和服务,去磨,去耗,去说服。是持久战,是消耗战,是堑壕战。简单来说就是人海战术。

而底座产品的复用,是抵消这些成本的杠杆。这也决定了底座产品只能照顾到各个客户间需求的最大公约数。

To B的另外一个特点是,甲方的决策者往往并不是产品的用户,所以产品好不好用这些细节问题,很多时候不是产品采购的决策因素。

To C的决策者就是用户,虽然个体用户没有影响力,但作为一个群体可以“用脚投票”决定一个产品的生死。所以除了满足需求,好不好用也很重要。

从需求的角度来看:

很多软件问题是由需求这个源头产生的。对于To B的项目来说,它们的需求往往是复杂而且全面的。

特别对于大多数的传统行业来说,推出一项新业务,往往都不是什么创新产品,都是市面上已经有的产品或服务,这些新业务是要在一片红海中挖掘机会。这就导致了这些业务的产品和服务范围必然是你有的我也要有,你没有的我就要有,要在同行已有功能和服务的基础上,推出更多的增值服务,才能形成差异化竞争。这导致的后果是,针对这些新业务的所谓“最小可用产品”,也就是MVP,也会非常的大而全。

我们大部分的敏捷教科书都教导我们,MVP一定要足够小,目标是尽快推出一个只具有最核心功能和卖点的产品,快速上市,从市场和用户那里获取反馈,也就是真实的日活和月活数据、用户行为数据,并根据这些反馈不断调整和优化产品,实现产品的持续迭代、优化和升级。我们所有人都一起见证了微信从一个相对简单的语言聊天工具,迭代成今天成为半个操作系统的平台产品的过程。但这是面向消费者,也就是To C的玩法。我们在非互联网的世界,绝大多数情况下面对的都是前面所说的To B的场景。

需求大而全带来的直接问题就是开发过程复杂,风险高,周期长,首次交付上线动辄需要一、两年的时间。后续升级也会遇到同样的问题。

从人员的角度来看:

以下应该是几乎所有To B项目的常见场景:

在甲方,业务方有销售部门、售前产品设计部门、业务运营部门、售后客户关系部门等,他们都是项目的干系人,在项目执行过程中,他们的利益都要被照顾到。如果是强监管行业,要满足上线的要求,除了要满足客户需求和市场需要外,还要满足各种合规要求,有多个部门要打交道。

在IT内部,也有大量的非功能性要求需要满足,系统才能上线,实施团队要和基础设施团队、架构设计团队、安全团队、流程管控团队、权限管理团队等打交道。

系统要在生产环境上安全、平稳地运行,需要满足一系列非功能性需求点,涉及到安全、灾备演练、系统配置数据、权限控制等。这里又涉及到多个部门的不断沟通磨合。

在这样一个复杂、利益方纷繁的组织内,决策过程必然冗长且复杂。

在乙方,往往有与甲方对接的商务、实施、服务人员,但他们完全受制于实际做开发和交付的产品团队。产品团队往往是一对多的局面,不同客户的需求相互交织在一个产品和团队里,彼此形成了复杂的依赖关系,牵一发而动全身。

04

总结

现在很多原本做To C发家的大厂都越来越重视To B市场,To C可能只能赚到人气和吆喝,但To B能赚到真金白银。但To B和To C是完全不同的逻辑和打法。To B产品和项目的实施和维护,对于甲乙双方的执行方都充满挑战,如何破局,是一个很大的话题。欢迎大家留言交流分享。

原文链接: http://mp.weixin.qq.com/s?__biz=MzI1MjQ3NzE2Mw==&mid=2247485078&idx=1&sn=d49378a5a0f5ff556fa3c2745280adfd&chksm=e9e26d12de95e404e6771a7c1f826e89497e4673fbf52bd1978b1d796fe6a59f24aac4db721f#rd