或者，Growth 的职能跟什么传统的岗位更有可比性？
各种有关 Growth Hacking 的传说，让人觉得 Growth 应该很偏市场，和神文案是一个类型。
包括这篇文章在内，这一类读的时候看不到反例材料，总是会让人忽视很多条件和缺陷。
各种文案渲染出来的景象，似乎是拍脑袋就出一个方案，然后大获成功。真相很少这么简单。这类成功故事其实各有各的环境，不能只看最后一步（ 也就是所谓的 Growth Hacking ）。很多人应该也有过网页上的分享按钮无人问津的经历吧？Hotmail 之类的加个签名就驱动了很多增长，不但后面的产品已经基本上无法复制了（现在常见的变体是要主动要通讯录权限），他们的产品也得打磨到明显超出市面同类产品一大截之后才能用这招。否则，很简单，见过大家吐槽 IE 浏览器要求把自己设置成默认浏览器的笑话吗？
大学学数学的时候，老师喜欢讲一个业内的轶事，就是高斯（小时候快速算出了1加到100的那哥们儿），被同时代的阿贝尔称为“狡猾的狐狸”，因为他发表的定理证明，往往流程简洁思路流畅，唯独看不到从当初的问题一路思考、试错，到最后解决方案的痕迹。被数学书上的“显然、明显、读者可以自证”折磨过的大家应该都可以理解。用现在的行话来说，这么干属于装 X 成功，但是对于读者来说，可能欧拉那种如实记载思考过程和走的弯路的材料，会更有帮助。
Growth业内的共识是，Growth Hacking 类的故事的终极目标——直接引入大量用户——并不一定是成功的标志，相反，产品没有准备好的时候，这么干反而是在“污染”用户，因为日后再去扭转一个用户对你的不良印象，比新争取一张白纸，要艰难很多。
更重要的事情，一个产品应该时刻有人能够回答的这些问题，比如，上文提到的“产品没有准备好的时候”，怎么识别？怎么达到？
我的观点，Growth 团队的职能更适合用财务、科研来类比。
提到财务的原因是，传统生产企业里，原料和资金的来源，去向，在企业中周转的过程，都会得到完整的记录，并且会基于此分析改进的方案。Growth 团队也同理，用户因为什么到达，中途做了什么，又因为什么原因，如何离开了你的产品，这一系列问题的回答和追踪，是 Growth 的职责。
另一方面，找到这些问题的答案，Growth 是一个产出对用户的理解的过程，需要高密度动用科学的方法，不断提出假设，验证假设，把验证正确的假设作为对用户的理解积累下来。最后，才是利用这些积累，做出看似漫不精心实则直击要害的产品调整。
当然，因为人性等等各种原因，我们可能只愿意奖励成功的案例，但“看起来很对的 xxx 想法其实是错的” 的发现，和对背后道理的发掘，同样都是重要的。诺贝尔奖也是非功不侯的逻辑，这个不要紧，但组织能针对这个方向做一些积累，会是件划算的事情。
