今年我第一次组织构建一个全新的产品线——移动标准化产品线,一路上磕磕碰碰也跳过不少坑。本文总结一下从0到1的To B产品线有哪些管理难点,欢迎拍砖。
产品从0到1,就是把一个点子完整落地到成功上线。首先,从0到1的产品和针对原有产品进行改造的区别,就在于从0到1的产品没有原框架可参考,也不能知道产品本身是否适应市场需求。针对这类需求变化迅速、市场方向不明的产品,我们作为项目的负责人,应该怎么进行项目管理呢?
从0到1的产品,最关键是迅速进场
对于从0到1的产品,我们第一步就要去验证这个产品是否具有商业价值。
如何验证呢?以最小的成本,最快的速度迭代出一个最简易的版本,迅速投向市场。
经过分析,我们认为能够满足市场的产品,称作PMF(Product-Market Fitting);针对这个设想所作出的Demo产品,我们称之为MVP(Minimum Viable Product)。
所以对于从0到1的项目管理,我们就做三步:
第一步:市场调研,推演出可能的PMF;
第二步:做出最小可行化产品(MVP),投入市场;
第三步:根据用户反馈快速迭代版本直到项目失败。
PS:由于PMF失败的概率特别高,所以我们在做此类项目的时候都会戏谑地告诉自己做到产品死掉为止。
如果一个从0到1的产品像传统IT的产品实施那样去做,基本上还没做出来就已经死了,所以在近些年,通过大量的MVP验证可行性的小成本试错方式就诞生了。那么这种模型在To B产品的项目背景下,有一些问题需要我们重点关注。
To B产品从0到1的过程中,需要注意的问题
由于To B产品与To C产品对象的不同,注定To B产品的从0到1过程会很不一样。To C产品的可迁移性很高,每一个用户的需求基本相同,比如你玩抖音,你的需求就是刷小视频娱乐、消遣。
但是To B产品不一样,每个公司的管理模式不一样,每个公司的政策不一样,使得产品本身的可迁移性十分微弱,这个性质随着公司规模的增大迅速地体现出来。
针对此,一般来说To B的产品会有两条发展路径:
1. 面向大企业/政府的To B产品
面向大客户的To B产品,一般会锚定一个客户,用产品Demo先拿到单子,之后再用MVP进行迭代,迭代的过程中充分满足客户的各种定制化需求,形成方案包和程序包,用一个项目沉淀产品。之后再以这个项目作为扩展点扩展新的客户群体。典型的例子就是SAP的产品迭代方式,SAP每次自研实施的项目获得大成功之后,就会将沉淀的功能作为一个版本进行发布,它的每一个新版本产品和上一个版本的产品都会有很大不同。
针对大企业的To B产品,项目管理问题主要集中在沉淀产品和客户成功:
定制化需求的标准化可能性:
因为我们是用MVP拿到单的,最后产品上线运维结束之后产品其实大概率是没有沉淀的,因为项目组本身是按照实施的流程走的,并没有沉淀产品;而项目经理最需要最需要考虑的,就是沉淀产品。
项目经理在实施的时候一定要多加考虑标准化的可能性,而不是单单考虑结项收款。在一些企业的标准化系统中,总会出现一些奇葩到产品经理自己都看不懂有什么作用的功能,这些功能往往存在于深度客户化的项目中,如果这些深度客户化的功能放在标准里,标准系统的功能框架就会极端冗余,从而达不到标准的要求。
客户的需求把控:
一般来说,第一个大客户项目的上线需要做的客户化定制很多,一旦客户化定制过多,系统过于复杂,项目的风险管理就会变得极难控制,因为第一个项目必须成功的压力使得风险管理难度迅速上升,项目经理要着重平衡项目成功和需求管理的关系。一般来说,我们会出具几个方案,引导客户选择成本最低且能满足其需求的解决方法。
我们在和销售谈天的时候,总会吐糟一些公司无底线答应客户需求,结果发现最后没人把这些东西做出来导致项目失败的情况。大量的客户化定制需求必然造成项目进度吃紧、资源吃紧、质量吃紧。如果这个新的产品线不能在第一个客户获得成功,那么沉淀成产品的可能性几乎为零。
2.面向中小企业的To B产品
面向中小企业,由于客户数量众多,产品营利模式一般按照团队人头数收费,典型的产品比如有道云协作、墨刀、TeamViewer等等。这一类型的市场集中在长尾市场,其实他们的运营模式和To C的思维差不多,主要需要解决企业痛点,因为不愁没有客户群体,一般不会像面向大企业那样做产品。 针对小企业的To B产品,项目管理就主要集中在决策上了:
迅速决策,快速开发:
由于本身客户群体过多,意味着潜在市场和潜在竞争者也集中存在,项目经理要确保核心流程迅速迭代。如果不能迅速决策开发出MVP,率先进入市场,冷启动获取第一批客户,待市场进入红海阶段时,产品成为PMF的可能性就很低了;
我们有一些产品经理喜欢开会,大到发展路径,小到功能交互都要开会。大量开会的结果就是:没有任何的实践测试,沉浸在自己的会议中勾划整个市场,最终产品推出的时候直接因产品不符合市场被直接淘汰。成为PMF的过程一定是经过了大量的MVP试错过程,而非一步到位。满足核心需求,做市场需要的产品:
只做核心需求,只确认核心需求,只满足大规模客户的广泛性需求;项目经理一定要严格把控需求池,禁止核心以外的任何需求进入需求池,如果说一个Demo只能满足几个潜在客户甚至没有满足任何客户的需求,那么这个产品做出来也只能是自嗨,它的交互多友好UI多漂亮,不足以让企业主买账。
这里最典型的就是钉钉和企业微信。钉钉对企业主更友好,DING/签到/日志……都很好地满足了企业主对员工随叫随到的要求,而企业微信则更偏向于用户,用户可以自主选择上班和下班状态,也没有DING的这种随叫随到的功能。买账的是企业而非员工,我们也看到了钉钉的发展速度远超企业微信,这也是没有办法的结果。
总体上来讲,对于To B产品,项目经理应当更多地满足关键客户的需求而非广泛用户的需求;积极沉淀产品,防止将产品项目做成实施项目。同时,应当尽量做到快速迭代快速试错,而非将团队埋在大量的决策会议中——一步到位不适合初创产品。
本文来自微信公众号“智昊的学习笔记”(ID:hiyuanz),作者 智昊。
原创发布于管理圈,未经许可禁止转载。