1704198770
为说明想法提出的正确格式，让我们再回到食品连锁商店移动App的案例中。在第一次和第二次增长会议之间的那一周，团队成员可以针对促进用户消费的几个方法中的任何一个提出自己的想法。有的想法可能旨在吸引那些下载了App但还未购买的人下第一笔订单。有的可能针对已经购买过的用户，要么是吸引他们更频繁地消费，要么是增加他们的单笔订单金额。还有的想法可能是为了吸引更多用户从公司网站转到App，因为数据显示，从网站跳转过来的用户往往创造的价值更高。
1704198771
1704198772
假设App团队的产品经理提出了打造“购物清单”功能的想法，这个列表可以保存用户之前购买的商品，从而使用户可以轻松地再次购买。那么这个想法应按照下面这个格式提交：
1704198773
1704198774
想法名称：我们发现，给每个想法起一个简短的名称可以使讨论更容易也更高效。在GrowthHackers，为保证名称简洁明了，我们设定了不能超过50个字的限制。对于这个例子，我们不妨给它起名叫“购物清单”。
1704198775
1704198776
1704198777
1704198778
1704198779
1704198780
1704198781
1704198782
1704198783
1704198784
1704198785
1704198786
想法描述：想法描述看起来应当像执行大纲那样清晰明了，说明“谁”“什么”“何处”“何时”“为什么”和“如何”等问题。这个想法针对“谁”？例如，是所有的访客、新用户、复活用户还是从某个流量源获得的用户？要创造“什么”？是一份新的营销文案还是一个新功能？这个新文案或是新功能将在“何处”执行？是在App的主屏还是其他地方？它将在“何时”出现在用户屏幕上？比如访客初次访问网站着陆页的时间。除此之外，描述还必须说明“为什么”，即想法背后的论证过程。也要说明“如何”，即建议开展的测试类型，比如是A/B测试，还是要开发新功能，或是要展开新的广告攻势。
1704198787
1704198788
1704198789
1704198790
1704198791
1704198792
1704198793
1704198794
1704198795
1704198796
对于这个购物清单，产品经理可能会这样描述：
1704198797
1704198798
1704198799
1704198800
1704198801
1704198802
1704198803
1704198804
1704198805
1704198806
使用户轻松地查看并再次订购之前购买的商品将增加重复购买的人数，也会提高他们下单的速度。更便捷的再次购买操作应该能够刺激更多用户回购。购物清单功能应当添加到App的导航项中，使所有用户都能够使用，方便用户保存并回购他们喜爱的商品。这一功能应该先在早期用户中进行测试，再提供给所有用户使用。
1704198807
1704198808
1704198809
1704198810
1704198811
1704198812
1704198813
1704198814
1704198815
1704198816
假设：像任何其他类型的试验一样，“假设”应当简要说明预期的因果关系。同样，对于假设不能只是给出模糊的原因和结果，像“重复购买的用户不够多，我们应该激励用户回购”这样的话只是对问题和努力方向的一句陈述，而假设应该是：“通过给用户提供便捷查询并回购商品的功能，回购用户人数将提高20%。”
1704198817
1704198818
1704198819
[
上一页 ]
[ :1.70419877e+09 ]
[
下一页 ]