最近做了近视手术，更新比较迟，写这篇文章的时候异常艰难lol。分享一些浅薄的思考，希望对大家有些许启发。阅读需要14分钟。
“增长”绝对是一个近些年被过度放大和夸张的buzzword，而且门槛也比较低。了解海盗模型AARRR，然后学一些常用手段基本上就能应付一些常见的商业问题，然后套方案。
Growth Hacking里增长实验的确具有参考价值，但是大部分所谓的增长团队还停留一些营销小技巧或者界面优化上。一个产品的UI一个月改四五次，对照着北极星指标看哪个表现好就用哪个，这个月KPI完成了，下个月继续优化。假设可以随意定，因为逻辑上正着说反着说都可以。
比方说要改版一个产品陈列页，
  • 如果我想要把它从list view 改成瀑布流，假设可以说
    ——“产品陈列页有更强的视觉冲击，可以促进转化“。
  • 如果我想要把它从瀑布流改成list view, 假设就可以说成
    ——“list view的浏览更高效，可以帮助用户快速找到他们想要的商品，促进转化。”
从结果来看，数据很有可能会有差异，但是综合各个变量，取决于业务负责人如何表述，A→B , B→A 都有说得通的论断。整个实验中间没有深入思考的过程，类似的增长实验基本上没有什么价值，孤立地为数据而优化，为了增长而增长。
增长黑客的确能为企业带来短期的收益，但是过分依赖小而快狭隘的增长实验，团队失去的是探索更具影响力的问题的机会，个人失去的是对独立思考和vision能力的锻炼。虽然我是个游走在产品表现层的人，但我觉得不是所有产品表现层的问题都是可以通过交互设计，视觉设计，UI优化可以解决掉。
我先从一些常见的界面优化的陷阱说起，然后讨论一下我理解的“增长”设计是什么样的。
不是数据的问题，是人的问题
前两天和我一个在Facebook的朋友聊起到，她在Facebook学到的最多的是，Everything is about a people problem。产品的核心价值体现在解决的不是技术问题，不是数据问题，reframe过后最终落脚点都是“人”的问题。数据只是结果，不是原因。一个产品今天的CTR降了10%，我们应该诊断背后究竟发生了什么，人的操作发生了什么变化，通过填补用户需求的Gap产生积极影响，最后积极的数据得以呈现。如果缺少了中间的洞察，很有可能就会成为上面漫无目的的假设和试错。
有的朋友可能觉得，“人”在C端产品才重要，2B产品解决的是工作，行业或者社会问题，不能以用户为中心。但其实，从更高的角度思考，一个行业的价值依赖于当下环境，它可以随着人的变化而变化，甚至被替代。从人的角度逆推更能带动行业的变革，而不是被既定的被业务牵着鼻子走。
数据具有系统偏差
我们一直以为数据是不会骗人的，是客观的，但却忽略了数据由人产出，依赖于系统，就必定存在系统偏差（System Bias - The inherent tendency of a process to support particular outcomes.）硅谷增长网红——Andreessen Horowitz 投资人Andrew Chen说过，虽然数据是具体的，但它往往具有系统性的偏见。它也不是正确的工具，因为不是所有的东西都是优化问题。把决定权仅仅放到你现在可以衡量的事情上，往往会降低问题中更重要的宏观方面的优先级。
数据度量是人制定的就必定存在偏差，尤其通过复杂算法定义的度量 （Algorithm Bias 算法偏差）偏差更会被放大。另一方面，那些最重要指标，例如长期留存，往往又是最难衡量的。即使可以量化，但也无法做到准确引导决策的程度。
提到通过数据做决策，此时必须要提及下面三个概念：数据驱动（Data Driven），数据启示（Data Inform），和数据感知 （Data Aware）。
数据驱动（Data Driven）是完全依赖数据做决策，应用范围比较狭窄，适合小问题，然后快速决策。数据启示（Data Inform）则是通过数据得出一些启发的建议，促进资源分配，大方向的筛选。而数据感知（Data Aware）应用最广，把数据当作决策判断众多因素的一环，和定量分析，设计直觉相互制约引导决策。可惜的是，我们在整个行业听到的数据驱动的声音最大，渐渐形成数据至上偏颇的价值观。不管不顾只狭隘地用数据做决策是对产品的不负责任，更是对用户的耍流氓。
警惕显而易见的优化
在产品设计中，我们要警惕那些显而易见的优化 - 就是那些你不用做实验也可以预估到结果的优化。那些显而易见的优化会带来明显的短期的数据提升，但是极有可能损害产品的长期发展，而这些恰巧非常容易被忽略。
比方说我要对用户流失进行优化，把取消付费服务的体验做得非常糟。增加阻力必然会减少用户流失。数据是降下来了，但因为糟糕的体验，用户再也不会考虑用你的产品了，甚至还给你写了个差评，在微博上投诉你，进而你将来的获客成本会变得更大。再举一个例子，产品某个功能的入口目前只有一个，现在我在某几个界面添加了额外的入口，数据表明这个功能的adoption提高了，最后我得出结论——这个产品决策是成功的。这一套逻辑是有问题的。添加入口必然会促进流量和使用率的提升，这个是显而易见的。但是不断添加产品入口的代价会不会让整个产品变得复杂？用户满意度会不会受影响？会不会影响其他功能的使用率？
以上类似的闭着眼睛都能预测出结果的增长实验没有太大价值。我们应该避免做那些显而易见易见的优化测试，而是把焦点放在模糊性高的问题上，往前推一步：如果要添加入口，应该在哪个接触点添加，要添加几个，天花板和底线在哪里？
狭隘的“原则”

最近总是看到类似”数据第一，业务第二，用户第三“，或者各种不同顺序的行业原则或鸡汤。其实问题还是源于大家对方法论的痴迷和对快速做决策的万金油的渴求。讨论是用户第一，数据第一，还是业务第一没有价值，我们关键还是开始要看解决的问题和目标。
增长和运营设计常常要在用户体验和商业影响力之间平衡，比一般的功能设计要更危险，更敏感，操作不好就容易被现实击碎理想，产生“产品设计向商业妥协”的价值观洗礼。但其实“用户体验“和”商业影响力”不是对立关系，不要先上所谓的”原则“，搞清楚谁是老大。更何况这些”原则“有的时候真的是鸡汤而已。我们应该从Problem Solving的角度来看要解决的问题和目标是什么，而不是先给自己套上一个枷锁，告诉自己我不行，必须要妥协。

千万别一上来就跪着走，一直跪真的就站不起来了。
过度优化，无法拓展

Dropbox有一个丑到暴的Upsell 界面，老旧的设计，密集的字体，但是从未大改。一轮轮的设计师们构思过更美观更符合当下设计语言的界面，但从未打败过对照组。因此我们只能让那个界面孤零零的在那里，独自扛起revenue的大旗，丑并重要着。
退一步来思考，当初一个个设计师参与进来，为这个界面优化的目的是什么呢？为了增加Revenue，促进转化？但是这个界面好像也没什么痛点啊，通过UI的手段硬着头皮去解决商业问题，是不是太拧巴了。如果UI的改版目标是【构建可以复用可拓展的模版，减少工程团队的压力】，那么这个优化就是有意义的。即使数据上并不好看，但是未来给我们打开了一个更大的探索空间，例如说个性化，社交刺激，新视觉语言，插画尝试，新的flow等等，可能会带来更大的revenue机会点。只可惜，这个决策应该在早期做。现在的界面被过度优化，营收表现已经触及天花板，大家由于背着KPI的压力，不敢大改，也无法向前走。
所以对于本身空间不大，或本身大方向没有探索全的接触点，不要过早地进行局部优化，甚至不要投入太多的资源，不要把路越走越窄，进退维谷。
扩大增长的scope

作为在增长领域工作的产品经理和设计师，我认为不要把自己的着眼点关注在实验上，而是做产品价值的探路者。我个人的见解，有以下几个方面：
  1. 关注在问题域，而不是单一问题
对于增长，我们关注的问题绝对不是类似于“文案不清晰”，“用户觉得图片没有吸引力”这样零星问题，而是整体规划为如何通过有机的体验让用户了解到产品价值，解锁他们的Job to be done. 具体可以放在AARRR模型里面进行反思，有哪些大块问题影响了整个漏斗，是用户划分不清晰，还是购买旅程，用户引导，产品的education，产品核心功能和用户期待脱节的问题？
  1. 通过增长的视角，影响产品核心功能
增长具有对转化漏斗的敏感度，它不应该仅仅负责产品的“头”和“尾”——非产品功能的部分，而是需要和核心产品部门紧密合作，帮助他们识别有较大用户价值的功能，一起推动产品目标和商业目标。例如今年我们做的移动端用户引导，发现用户引导的分享流程明显带动了试用→到付费的留存，于是从增长团队内部发起，把“分享”这一块内容的优先级提了上来，确保项目的价值和影响力。和核心产品部门的紧密合作甚至能发掘新的空白域，孵化0→1的前沿创业项目。
  1. 界面优化仍有必要，但交给平台自动化
完全关注于变现的界面优化仍有必要，但应该仅仅占据团队精力的5%-10%。界面优化其实是最没有技术含量的，最适合被程序化的。例如把一些销售页，notification，banner，onboarding等UI元素组件化，递交到后端商业平台（business platform）自动化，产品经理或者销售团队想在产品上做一个小增长实验可以快速测试拿结果，既不需要设计师上手画图，也不需要工程师hard code了。其实就是相当于产品内部的广告平台（你也可以理解为中台lol)。绝大多数公司在这方面还没有达到把onboarding，tooltip都自动化的程度，因为投入产出比需要长时间才能见成效，但这是一个未来的发展趋势，产品团队从而可以把资源和精力放到更多0→1的增长点上。
一个生硬的结束语：希望各位朋友们不要被一个个装模作样做样的词汇唬住，天天被新的概念搞得焦虑，回归本质才能connect the dots呀。
引用
https://andrewchen.co/know-the-difference-between-data-informed-and-versus-data-driven/
https://en.wikipedia.org/wiki/Systemic_bias
相关历史文章
你的创新是否还在套路里 - 谈一谈JTBD framework
【新】当我们在聊用户增长设计的时候，我们在聊什么
产品设计的量化
正文结束
我是一名在硅谷湾区的产品设计师 - 挂面(年少的我一面试就挂!)，目前在 Dropbox Growth 组负责移动端的用户增长。之前分别在 Yahoo (Verizon Media)和广告咨询公司 AKQA工作过。2B让我对复杂的问题和商业逻辑特别有热情，2C又给现在的我打开了新世界的大门。努力维持理性与感性的平衡中:) 

继续阅读
阅读原文