1704234717
1704234718
每个小土包，都有几十支饿得不行的游击队在往上冲，每个人都清楚地知道，他们绝大多数都会死，但从概率上讲，总有人会登顶。这时候，如果选择慢慢来、想清楚了再上，就算路径正确，也是死路一条。因为等你爬了一半，就会发现山顶已经有人了，而——快，才有可能活下去。
1704234719
1704234720
听起来，像是有一种“别人孩子都去上补习班，于是我也只好给娃报名”的无奈，而事实上这是一个行业从新生到成熟的必经之路。
1704234721
1704234722
8.4.3 省时间的低成本验证
1704234723
1704234724
单纯为了速度而横冲直撞，是不可取的，也是得不偿失的。那么，如何合理而科学地加快速度呢？答案就是低成本验证。低成本验证的理念，本质上和迭代的思路完全一致：在一个快速变化的环境下，不断地用最少的时间、成本去获取市场反馈，不断修正前进方向 。下面举几个例子。
1704234725
1704234726
假设你要做一个交易系统。
1704234727
1704234728
正常的交易流程一般叫作“正向交易”，要满足买卖双方之间下单、付款、发货、收货等常规需求，是交易系统必备的。但是，“退款/退货”这种“逆向交易”要不要做呢？做的话，系统复杂度会大幅增加，实际工作量不只翻倍，往往会超出3～5倍。
1704234729
1704234730
怎么办？可以这样低成本验证：先在线上做一个假的“退款/退货”按钮，用户点击以后，系统直接给客服人员发邮件，由客服人工完成处理。这样运行几周后看看效果。如果客服只收到几封邮件，那么就继续采用“人肉”处理；如果收到的邮件多到人工处理不过来，就可以理直气壮地上系统了。
1704234731
1704234732
除此之外，不轻易做系统还有一个现实意义：上线容易下线难。功能上线后，如果只有很少的人在用，就会陷入尴尬境地。如果下线，这些在用的人会跳起来说：“我用得好好的功能，你们为什么要下线。”而如果迫于这种压力，勉强继续维护着这一功能，一方面有成本，也很吃力；另一方面后续新功能也必须考虑和这个鸡肋功能的兼容、协作。
1704234733
1704234734
现在的很多创业项目，启动阶段先做微信公众号、H5页面，而不是App，一个主要的出发点也是低成本验证。这么做，开发人力的成本可以低一些，用户获取的成本可以低一些，功能调整的成本也可以低一些。用一个简单的产品雏形把业务逻辑先跑通，然后再考虑是否要做客户端，是很值得推荐的产品策略。
1704234735
1704234736
再来一个案例，假设你想做一个垂直领域的导航站。
1704234737
1704234738
这个站点可以告诉创业者，创业过程中都会碰到哪些问题，可以用哪些服务解决，可以去什么站点获取资讯。我的建议是，先不要做网站，而是把精心整理的各种资料，通过一篇高质量的文章来传播，收集阅读、收藏、转发的数据，或者挑一些目标用户来问问反馈，再决定下一步怎么做。
1704234739
1704234740
最后来说一种有趣的低成本验证方法——利用公关手段。
1704234741
1704234742
经常看到阿里PR稿件中出现“阿里又要推出×××”“阿里开始进军×××”“阿里正在秘密研发×××”这样的标题，而这很多时候都是有意为之的小动作，甚至产品、技术团队都毫不知情，更谈不上真正开始投入资源了。而很多对手会被带到沟里，开始研究对策、排兵布阵。
1704234743
1704234744
大机构想推出新政策的时候，先借助合适之人如专家的嘴，或其他渠道如非官方媒体、小道消息等来透露给社会大众，试探他们的反应，得到相应的结果后，或顺水推舟地证实，或矢口否认地辟谣。不用担心最终没做会辜负期待，用户总是很健忘。回顾一下以往的新闻，能想到很多这样的例子。
1704234745
1704234746
广义的公关之法，其本质就是先不做，却告诉受众我已经做了，从而收集反馈，其优势在于成本非常低，验证非常高效。
1704234747
1704234748
小结一下，低成本验证的核心，就是看谁能用更少的资源、时间等成本，拿到一些假设是否成立的结论，而更深层次的目的，还是为了更好地服务用户，更好地达成公司的商业目标。
1704234749
1704234750
1704234751
1704234752
1704234754
人人都是产品经理2.0：写给泛产品经理 8.5 与用户一起成长
1704234755
1704234756
产品除了要通过规划和迭代，面对快速成长的问题，还需要在更大的时间尺度，比如5到10年上，考虑用户的成长。经过这么大的时间跨度，产品的用户往往已经不再是最初那批人，产品将面临这样一个选择：是跟着原有用户走，还是服务一批新用户？
1704234757
1704234758
举一个校园社交产品的例子。随着最早的一批学生用户毕业，这款产品是应该转而服务职场人士，还是服务新一批的学生？一些同行观察到了类似的现象：一个女性社区，随着用户从小姑娘变成少妇，几年间最活跃的版面也按照用户的自然成长规律，依次在服饰、装修、婚嫁、孕育之间切换。
1704234759
1704234760
事实上，产品往哪里走，并不是由产品经理决定的，而是由产品团队和用户共同决定的。产品与用户在几年时间内已经形成共生的关系，产品影响着用户，用户也影响着产品。
1704234761
1704234762
试图决定产品走向的产品经理，实在有些自不量力。下面，用豆瓣的成长故事来进一步说明产品发展的自主性。
1704234763
1704234764
豆瓣最早的产品是“读书”。对于一本书，如果想讨论内容，可以发书评，但是想讨论作者的八卦，怎么办？于是，豆瓣做了“小组”，把它当作“读书”的“垃圾桶”，有些奇怪的话题都可以去小组讨论。没想到，小组火了。这时，作为一个读书网站的豆瓣，最大的小组居然是“爱看电影”。豆瓣顺水推舟，又做了“豆瓣电影”，而另一些小组催生出“豆瓣同城”。
1704234765
1704234766
这个故事告诉我们，产品和用户是一起成长的，只有把用户当作产品的一部分，形成一个大的生态系统，才是正道。
[
上一页 ]
[ :1.704234717e+09 ]
[
下一页 ]