当商业闭环后,下一步是做什么?

原创: Kevin改变世界的点滴 Kevin改变世界的点滴  今天

大家好,我是 Kevin。这是我2019第35篇原创



我们在打造产品的mvp时候,因为所处场景不同mvp的概念也不同。比如在公司初期的mvp指的是商业闭环的1.0产品。


但有时候在项目中的mvp,是指的业务能够满足的功能最简单化。


最近带着团队进行商业闭环的验证,首先对于产品的商业闭环是否有效?或者产品解决的问题是否有壁垒?以及商业闭环后下一步的工作内容应该是什么?有几点我的思考今天与大家聊聊



用户交钱了可能是运气


商业闭环一定要是成批次的交付。如果产品上线后,几万用户只有不到几个用户转化,可见商业闭环的方向是错误的。


这样的收费不是解决用户的需求痛点,完全是碰运气靠着流量进行转化。所以转而尝试新的产品方向才是最佳策略。


但是多少的转化才是正常呢?有没有数据标准呢?


其实就像上面的例子,几万用户只有几个人转化结果显然是非常低的。当产品的价格在不到200元之内,团队是可以感觉到转化的到底。


另外就是随着时间,若7天、30天、甚至是每天的数据都在下降。可见转化的比例是不好的



团队需要精神粮食


项目因为开发或冷启动成本原因。通常会分主要业务、次要业务,但次要业务不等于不重要,反而是在现阶段战略上不重要。


开发项目因为上线也会有BUG,不稳定情况。很难看到产品带来的价值,相比运营等使用第三方工具,都是比较稳定可以见到非常快速的增长或策略有效化。


保持敏捷开发是一个团队基础,不要一次性做太大的需求。一步一步前进外,还要考虑每次交付的时间,甚至是团的工作制度。


每周一次需求评审、每周一版本,不断的给研发团队打气。同样要证明结果是好的,数据是往好的方面走,这就是团队最好的方向。


很多时候,创始人如果太过于强硬导致团队花费过多精力做研发。数据没有保证或未来没有朝着好方向变动,很可能会让团队受挫。



保证基础建设,步子不要太快


曾经有一个段子“步子不要垮的太大,容易扯着蛋”。但其实这个段子面向项目初期还是公司初期都是合适的,对于一个创业团队更是这样的,保证基础性建设与体验,比考虑做一个新的功能更为重要。


尤其是在商业闭环后,给予用户的产品更要保持稳定、减少BUG出现。所以接着上面说的,即使进入敏捷后。减少利用重构的方案,而是小心翼翼的多进行测试验证,页面不超过5个页面的功能都可以做。一旦超过5个,首先要考虑产品的稳定性与BUG数量。减少同步解决BUG、又在做新功能。



好啦,今天的原创就在这里。我会每周更新2篇产品工作案例


 

推荐阅读



坚持一年体验报告,招募500个产品经理


我的第一本书,给产品从业者



评论 Ctrl + Enter