经历了新品发布之后,学到了什么

最近参与了一个项目——新品发布。这里记录总结下自己学到的一些经验,绝对的干货。

以用户为中心——从用户出发其实不是那么容易

无论是招聘面试,还是媒体报道等公开场合,大家都很容易听到,始终以用户为中心,用户是第一位。

但是,实际公司的运营中,高层最先考虑的,是公司还在不在的问题。如果公司都快倒闭了,那么用户还是是不是第一位的。

当然上面是极端的例子,只是想说明我的观点是:在现实商业,任何时候听到以用户为中心这个口号,先默认存疑,因为它是只是一个目标,在资源有限的情况下,无法做到100%以用户为中心。

但是,即便它不容易,但是它是正确的方向,因为股东长期利益和用户利益保持一致(应该是姐夫说的)。所以,做不到100%,那就先做到90%,长期收敛于99.99%。

以终为始——产品的新闻稿和FAQ很重要

这个点对我触动很大,这里推荐大家去看一本书《working backward》中文名也叫《亚马逊逆向工作法》。

其中有提到,亚马逊会在各个项目或新产品,在产品设计前,提前写PR新闻稿和FAQ。

为什么要这样做?其实是以终为始的原则。先把可能遇到的问题,尽可能在产品设计前就写出来,然后进行讨论。

这次我们的产品设计和FAQ,其实做得不够好,产品设计的思路,可以预计用户100%必然会提出一些问题,但是对于这些问题,我们FAQ是在上线还没有真正出台。

对于一些问题,如果内部都认为是一个问题,但是这个问题还是只能等到临近上线才开始准备,这就不OK。

灵魂人物——最终谁来决定必须攻克的事项

产品设计了产品,产品从公司的利益出发,舍弃了一些功能,用户不满意,剩下的交给市场推广去攻克。

供应链这边需要知道新品实际的市场潜力,根据前期订单来决定发货发货日期,这就导致发货的问题也只能留给市场推广去公关。

市场推广,觉得产品本身就固定,工厂交货时间也不是市场本省能决定,那么,为了公司的利益,只能去公关。

这样整个流程跑下来,大家都知道,谁才是中心,肯定不是用户。用户最终承担了所有。

其实,凡是以公司利益为主,最终各个参与者,都会变得懒惰。每个参与者,都只是新品发布流程中的一个环,大家潜意识都是:问题不在我这边,在其他环节。

这个问题我觉得要解决,其实,我觉得需要有一个能拍板的人。这个人必须要真正以用户为中心,只有这样,才能迎难而上,释放价值。

那这个能是谁呢?至少是一个有拍板权,有强大的资源调动能力,且能够和资本扳手腕的人。

项目模型——为什么项目时不时要救火

除了顶层的问题——以用户为中心,还有一些内部协作上的问题。从参与进来之后,这个流程,能够感觉到,很赶,而且时不时会出现救火的时刻。

总结下来,我觉得是“模型”没有思考清楚。这里的模型,其实也是对大力开始执行前,对整个项目的全盘的思考。

为何是项目开始前?思考清楚模型呢?

这里有一个实际背景,就是项目负责人,其实一般都不会是全能的,在很多领域不能代表专业性。这就要求,在模型的完善阶段,需要调动专业性的资源,比如召集专业领域的人开会讨论。

如果项目开始之后,有参与者,假设叫小明,小明发现自己是项目中期被召唤加入,或者之前都不知道有这个项目。那其实都是有问题。

另外,即便参加了项目,但之前从未了解到有这个“模型”,也可能是会出大问题。比如可能等后期,小明发现,在模型中的一个部分,从自己的专业角度来看,是明显有问题。如果在项目开始前,小明就知道模型,那么当时肯定会提出。

所以,项目的负责人一定要确保要参与的人在项目开始执行前,知道有这个模型,且对模型的内容达成一致。

模型的价值性,不在于把所有都安排妥当,而是为了规避掉一些大的BUG或低级错误。模型这部分的工作不到位,或者根本没有一个成形的模型,那这个项目就犹如一个竹筛,时不时就会漏一些事项,然后出现集体救火的场面。

谈到救火,这次我也参与了一次,那是一个非常没有价值的事情,但是你不做,上线时间就会暂停,甚至整个项目出现崩盘的风险。但你做吧,事情本身就是极其常规的事项,即便做好了,价值性低不说,还花了不少的时间,机会成本尤其大。

总的来说,大项目需要非常科学的项目管理方法,来提高整体的效率。如果没有这类方法,你会发现,人力、时间、资金投入非常大,但是最终没啥效果。

结果低于预期,更有分析的价值

一个项目进行的过程中,有各种艰难险阻,其实都是很正常的。

当结果好的时候,会掩盖所有问题,因为有时候做对了一个点,就能撬动整个增长。而且只要结果好,大家没有分析总结的动力。

当结果差的时候,就很痛苦了,我们必须要主动去分析,不然,项目就崩盘。崩盘后的结果,可不是那么容易承受的。

那如果要去分析问题,这如何分析?当你发现核心的一个指标G低于预期,但是有10-20个因素可能影响这个指标G。

那么我们怎么做呢?大家聚到一起,然后讨论哪些是影响G的核心因素。

但是这样做真的有效吗?这真的是一个非常有趣的话题。

有这样一种场景,基本所有人都认为“有一个A因素”是至少排在前三的核心因素。但是这个A因素,是在项目上线前,就已经暴露出来。

也就是说,你甚至在项目开始前,一眼就能看到,这是个问题,大概率会暴雷。但是,现在,需要一起去讨论和证明“这个A是核心因素”。怎么证明呢?因为现在G指标太偏离预期,而A又是影响因素之一。

是不是很奇怪?只要你站在用户的角度思考,就知道A肯定是核心因素之一,但是,需要等到暴雷之后做一些“证明”。如果让大家讨论,最终不用想,都知道,讨论的结果肯定是——认为A是非常关键的影响因素。然后,大家再去制定针对A的策略。

但是,这个时候制定和项目开始前制定有什么区别吗?区别在于时间和策略本身。

第一个,就是时间,归因分析可不容易,现在除了A因素,你可能还有剩下的B\C\ D 等因素去测试。

第二个,就是策略。项目开始之后,你已经释放出去的信息,都是你后续新增策略需要考虑的约束条件。你得不停的琢磨,一项新的策略是否会和已经做出的策略产生冲突。

这样最终,平衡下来,最有可能的结果是什么呢?对某些核心因素,你可能无能为力。当然,运气好的话,你可能能够找到一些办法,来解决A。但是,因素太多,B/C/D就不见得有这样的运气。

回过头来,如果在项目开始之前,就对模型做反复的推敲,提前做准备,显然是有更多的操作空间。所以,我觉得还是前期的模型,前期的FAQ需要准备充分。

如果前期这些都做了,那么现在你面临的20个需要确认的影响因素,可能数量会锐减,而且因为提前有考虑,之前制定的策略,也会有留有一定的余地。不至于把自己逼到死胡同之中。

以后如果做新品,你会怎么去思考

今天之所以写这么多,主要还是觉得这种项目的机会非常难得,表面上,它只是我现阶段工作经历中的一次项目,但是实际上,它是一个规模不小的组织有计划的专业市场行为,这个行为的结果,可能是高投入高回报,也可能正好相反。

如果以后我有机会来从头设计一个产品,并且推广,那么今天的思考,肯定能有所帮助:

  • 整个产品的设计是以用户为中心为原则,还是以公司为中心为原则;
  • 是否有一个人,在坚持这条原则,是否会在关键时刻,迎难而上守护这条原则;
  • 产品设计前,是否有设计新闻稿,是否有FAQ,是否能承受主内外部的攻击;
  • 项目开始前,是否有模型,每一位参与者是否都有思考过这个模型,是否经过不断迭代并达成共识;
  • 以上这些都做好了,剩下的就是物理世界中对模型的实现。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注