【新】当我们在聊用户增长设计的时候，我们在聊什么
上一篇文章感觉就是给自己挖了个坑，设计中的情怀，伦理和商业价值 - 每每提笔，便觉得心中郁结难抒，最终都能上升为设计价值观的问题，视角zoom out之后感觉自己快成了大仙儿。但是我还是会努力把之前的主题完结的！在未来某个时刻更新！
这篇搬运自知乎专栏的旧文章，写于去年年底，也是一篇自己很用心思考。对比现在已经过去了4个月，自己在Growth这方面也有了一些新的体验，我把最新的感悟加在了文章末尾部分，之前有阅读过本篇的，可以下拉到最后，本篇详细阅读需要 33分钟。
2019年还有几天就要结束了，年末时刻开始回顾起自己在用户体验和产品设计一路走下来的历程。一个奇特的趋势是，哪怕从N年前的实习开始，我做过的产品也全部都是2B类：销售软件，企业工具，广告平台和2B电商。2B类的产品重交互设计，主要的难点是复杂又狡猾的商业逻辑和各种剪不断理还乱的依赖性。别人可能做吐的mobile app，我居然一个都没有。带着这种想要转型的驱动力，在19年年初，我从Verizon Media (Yahoo!）的广告组跳到了Dropbox Growth组。老板把我招进来的时候是负责用户留存这部分的，结果部门重组，巧合地做起了完全陌生的移动端增长。从2B领域跨越到更加数据驱动的消费者领域，我每一天都在积累着新的感受。当周围的人反复说这“Growth Design“ 这个空泛又时髦的词时候，我不禁开始思考这个问题：当我们在聊用户增长设计的时候，我们到底在聊什么？
在写这篇文章之前，我分别阅读了国内外三本比较有名的书籍作为参考，行文内容可能会有少许引用，特作感谢：
《Hacking Growth 增长黑客》Sean Ellis
《硅谷增长黑客实战笔记》曲卉
《破茧成蝶2——以产品为中心的设计革命》刘津
前两本的作者基本上都是营销背景，对于Growth Hacking的介绍非常系统，大而全。《破茧成蝶》则是以设计师的角度，展现了对“产品设计”的未来瞻望。这本书对于传统行业的设计师具有启发意义，但对已具备商业思维的设计师来说会比较的浅显。与此同时，我在知乎搜“增长设计”这个词汇，大部分资料来自于国外较为古老的案例，多为《Hacking Growth》书中的内容。例如Dropbox 的refer 病毒传播，现在已被公司完全弃用。还或者是国内自成一体的产品运营策略。这些内容对产品开发流程着墨甚少，以设计师，工程师执行者视角出发的更少之又少。
这篇文章从我在Dropbox Growth组今年的实际经验出发，详细探讨但不仅限于：用户增长设计的基础框架，实践心得，我对国内外的观察，和仅代表我个人对于行业内一些观点和buzzword的看法。尤其对于设计师，我们该怎么从“用户体验”拥抱“用户增长”？
另外，啰嗦一个小声明：在真实情况下，科学性的公司策略制定非常复杂，取决于我们接触到的信息，团队的协作，公司文化是自上而下还是自下而上。而当下的策略书籍大部分都是以非CEO的身份写一部CEO视角的方法论。我一直相信的是，无论多么酷炫新鲜的方法论，如果缺乏底层逻辑的深入探究和情景再现 (contextualization)，这些framework可以带动用户增长的认知都是值得怀疑的。
1.增长黑客和增长设计
在聊增长设计之前，我们来看看什么是增长黑客（Growth Hack），Wikipedia给予它的定义是，
“增长黑客是市场营销中一个相对较新的领域，专注于增长。它开始于早期创业公司，这些公司需要在短时间内以小额预算实现大规模增长，但此后也吸引了更大的公司公司。增长骇客策略的目标通常是在花费尽可能少的同时获得尽可能多的用户或客户。成长型黑客团队由营销人员，开发人员，工程师和产品经理组成，他们专门致力于建立和吸引企业用户群。“
有趣的是，在这个官方定义中，我并没有找到设计师这个角色的存在。
究其原因是因为用户增长本质上是从营销发展过来的，传统的营销方式集中在品牌，流量，购买转化这个漏斗模型，与之对应的策略不外乎砸钱投放线上线下广告，这些工作大部分都有专业的销售团队带动。但这种单一的运作模式，远离核心产品团队，很容易遇到瓶颈。市场漏斗（Marketing Funnel）发展于传统行业，不兼具互联网思维。用户使用产品后，通过广告和普通营销方式维系用户忠诚度的效果微乎其微，用户该走还是走。
Marketing Funnel：意识 - 考虑（流量）- 转化
肖恩在2010年提出了一个全新的观点，对于传统营销模式进行了降维打击：我们可不可以自给自足地构建一个多职能的团队，把更多的关注点聚焦在促进用户对于产品价值的挖掘，在整个用户旅程的接触点中进行创新，多快好省地获取用户，带动公司盈利呢？
用户增长的AAARR模型
根据这个模型，硅谷一系列公司们纷纷组织增长团队。增长团队一定是跨职能的，通常需要有PM (Growth)，Designer，Engineer ，Analytics，Product Marketing Manager， UX writer，User Researcher 等等。
纵观用户增长的整个旅程，有很多接触点是远离产品的，例如说获客和留存的几个常见策略，SEO，广告，邮件营销等等，根本没有设计师的用武之地。但是，随着用户增长越来越火，越来越多的增长策略开始落地到产品内部，通过设计给商业赋能。那么设计师在增长团队中的角色就逐渐演变出了特别的 - 增长设计师。越来越多的设计师开始给自己“加戏”，我们现在的设计方法论是与众不同的“Growth Design”，“Experimental Design” , “Data Drive Design“ 吧啦吧啦。它真的是革命般地与众不同吗？
首先我们来看看什么是增长设计，以下有一段来自Growth.design的定义
“Growth design is a process at the intersection of Growth (a scientific method to improve business metrics) and Design (a human-centered process used to solve problems). It involves crafting meaningful experiences at scale so that an organization can exceed its business goals while delighting their customers.”
简而言之，它的新理念就是进一步在设计的领土内强化商业目标。传统设计里，我们往往从一个用户问题开始，做用户研究，提供解决方案。但在增长设计里，我们会从商业问题开始，例如说这段时间xx功能表现不好，在xx用户流失很大，然后做反推假设，下钻 (Drill down) 到潜在的用户问题，然后给予解决方案。从一个公司的视角来看，这个逻辑是自洽的，接地气的。因为产品设计最终服务于business，我们要去解决那些关键的，优先级高的，影响公司收益的问题。这个反向推论的过程正是从亟待解决，优先级高的商业问题开始。看到这里，你可能会反对我的观点，会觉得用户体验以人为本的价值观受到了挑战，我个人的观点是，Growth Design只是众多设计方法论的一种，或者仅仅是一个思维角度，它并不能取代广泛上的Design Thinking，它更适合创业型团队，并且只能在已有产品的基础上通过设计的手段给商业赋能。如果失去了一个优秀产品的前提，盲目追求metrics就是顾此失彼了。我还会在后文中再次展开说明。
前Pinterest的增长负责人 Casey Winters 曾指出，
“产品团队的目标是增加产品的价值，而增长团队则是帮助更多的用户能够最大限度地体验产品的现有价值，或者尽可能的去除妨碍用户发现其价值的各种障碍。”
a. 定义北极星指标 (Define North Star)
北极星指标可以理解为一个项目的终极目标，公司的mission。这个指标最好地诠释了一个产品贡献给消费者的价值。北极星指标不仅方便团队合作，让不同团队的往一个方向迈进，还可以帮助公司获得长期的可持续发展。北极星指标往往是公司所制定的，公司在不同发展阶段有不一样的北极星指标。早期创业公司的关注点可能在获客方面，中后期可能在于活跃度。
b. 定义KPI (Define KPI)
定义好北极星指标，我们会发现有很多其他的变量制约着北极星指标，分别立足于各个不同的团队和项目。获客，激活，留存，上游，还是下游，不同小组内的度量也不一样，从而产生不同的策略和业务线。我们做实验的过程中会立足于当前团队的KPI，定义首要度量，次要度量，反向度量，以及用户增长的模型。这需要和数据分析师，数据科学家的紧密合作。另外，KPI必须要合理。例如说转化率，每个人都想要提高转化率，但是这个事情真的不能强求，就是有一些地方“先天不足”，变现的机会小。所以在进行实验之前要评估机会大小（opportunity size），适当调整KPI。这一步是和了解问题结合进行的，没有先来后到之分，可以反复回访（revisit）。
c. 了解问题 (Understand problem space)
仔细分析完当下数据，就可以看看有哪些可以做实验和创新的机会。例如说，在查看所有变现入口时，我们发现某一个接触点的转化率非常低，为了发现潜在的问题，我们进行了用户流程的走查。这里需要注意的是，及时引入定量的用户研究，了解用户行为。不然我们难以发现问题的症结。
这里举一个例子。在Dropbox，免费用户在遇到90%的空间时，我们会提醒他，你的空间快满了，建议您升级至付费方案。对比其他转化入口，数据显示这一个入口的转化率非常低。在没有做用户研究之前，我们的假设非常陈词滥调和想当然：“UI展示不清楚”，“用户没有意识到他们的空间快满了”，“用户对于Dropbox Plus Plan不了解“等等。通过问卷调查用户访谈我们才发现，绝大多数的“空间快满用户” 非常清楚他们现在的网盘状态，并且70%的人遇到这种情况会删除一些文件，来避免警告继续出现。并且他们都不止一次因为空间的原因删除文件，其实最终问题还是Dropbox太贵 ，如果不在价格上“下功夫”，我们还是无法改变停滞不前的转化率。根据这些洞察，有一些不靠谱的假设被轻易地排除了。这些洞察还帮助我们挖掘了更深刻，成功率更大的假设。Growth Design虽然是个逆向推理的过程，但也并不是盲目试错。
d. 重新定义问题，形成假设（Reframe the problem and form the hypothesis)
重新定义问题非常重要，决定了设计师在增长团队的价值。我们常常会遇到这样的场景，增长实验以一个商业问题开始，大家看了一眼仪表盘（dashboard），开了个会，发现xx处转化率过低，于是群情激愤地说，我们来一起解决这个问题吧！于是大家开始写文档，纷纷围绕着提高转化率开始行动。丝毫没有提用户在哪里。你有没有发现哪里不对劲？用户不转化，数据不好看，这个不是用户的问题和痛点啊！设计师要么抓瞎搬像素，要么没有原则地追求短期目标，最终结果极有可能和北极星目标相背离。
继续拿上面的情景举例，通过用户研究，我们发现昂贵的价格使得用户宁愿花时间反复地删除文件也不愿升级，这是其实是一个不健康的工作流程。我们又有一定限制，草率地大幅度改变价格会让公司蒙受巨大的经济压力。通过进一步的思考，我们发现删除管理文件其实也是一种效率和时间上的浪费，对于有一些用户，他们其实没有意识到省钱是小，提高生产力对于他们才是最划算的。于是我们整理出了问题：用户在空间快满时，他们浪费了大量的时间在反复删除管理文件上，现在的界面并没有帮助用户平衡时间和金钱的关系，促使他们做出自信的购买决策。从而我们可以进一步思考有哪些可行的杠杆或策略，例如，个性化，关注更有可能转化的用户，使用新的文案，强调时间和效率，对于那些打死也不想升级的用户，与其反复警告他们并且强推升级，我们也可以考虑提供给他们快速管理文件的渠道，以防他们被激怒，完全离开Dropbox选择其他产品等等。
以上的例子是想说明，即使在数据驱动的环境里我们也要有清晰的逻辑，我们是通过帮助用户来提升公司长期的商业利益，而不是架空用户。
e. 方向探索：制定杠杆 （Explore and define the lever)
定义好问题，我们可以制定杠杆，可以称之为渠道和方法，也就是项目里的大方向。我通常会和PM一起脑暴不同的想法，这个时候要充分做到think out of box，确保探索充分，因为这样才能保证有影响力大的想法出现，而不仅仅是UI优化。
具体的接触点和杠杆，我观察到的有如下例子，在这里不做赘述：
f. 设计探索，挑选实验方案，制定优先级 (Build experiments and roadmap)
确认好大方向后，我们要做的就是探索具体的呈现，定义Road Map，分为几个阶段，每一个阶段里有一个不同的方向，根据这个方向，我设计了1，2，3，4个方案，要挑选哪几个做实验。
这里有一个实际的问题，如果这个项目有4个完全不同的大方向，每一个方向内有一些不同的设计，UI，文案，交互有些许不同，如果通过A/B 测试一次只设一个变量进行实验，进度会非常慢。如果一下子跳到改动较大的设计，存在风险，也丧失了学习的机会，不知道是哪个改动影响了数据。这种情况下该如何做呢？这里就涉及如何定义Roadmap了。Sean Hills 介绍了ICE ( Impact, Confidenc, Ease ）优先级排序的方法：多数情况下我们从有足够信心，简单，并且影响力大的点开始做起，把复杂，不确定，影响力低的点子放在后期去做。但是，这些风险低，简单，影响力大的东西其实并没有那么多，大多数都是风险低，简单，但是影响力也低的点子。例如只是对控制组的按钮，文字，等细节进行优化。所以，如果已知一个大方向风险相对不高，此时最好直接开发这个方案，即使与当下控制组差距较大。当观察到结果优于控制组后再去探究是哪些元素导致的。
最近有一个项目，我和PM一起定义好了项目的不同阶段，第一开始的计划是，第一步仅仅对button的样子进行优化。第二阶段，改变button的交互，还有其他一些零碎的视觉元素。第三阶段，展现完全不同的内容，实现个性化。这个计划非常符合逻辑，第一步，在控制组基础之上做最小改变，得到一些learning。然后再一步步实验，一步步提纯。我们去给Product Director 过我们的计划时，我们得到的反馈是，我们的迭代太细了，第三阶段的确略有风险，但是直接跳到第二阶段完全OK。于是我们重新修改了Roadmap, 第一步是更大范围的视觉优化，并且加快进入“个性化”尝试阶段的历程。
优先级排序是个复杂的话题，业界的方法还有很多，例如说Lean Matrix, RICE, Story mapping等等，在这里不做赘述。
g.评估和验证：什么才算客观的评估 (Evaluate and Validate)
首先，实验结果要具有统计显著性（Statistical significance）[1]如果没有达到显著性，说明实验结果可能是由于误差引起的。实验结果不能说明问题。
其次，实验结果要运行一段周期，我们团队大部分都会跑两个星期。因为实验的前几天数据波动比较大，也不能说明问题。最后，数据要客观对比着来看。在定义团队KPI中，我们提到了首要度量，次要度量，反向度量，北极星指标，不能狭隘地只关注一个指标。
另外，考虑依赖性（Dependency）。下面几个问题值得思考：我们的实验是否只关注了用户旅程的局部，我们的改动对于其他部分会有怎样的影响，有没有其他组在做类似或者有冲突的实验，他们的实验对我们的实验数据有影响吗？
最后，结合定性数据分析。如有需要，可以用可用性测试、用户访谈补充实验过程中的疑问。
3.增长设计带来哪些影响
Stanford D-school design thinking
上文我也提到，Design Thinking 的出发点来自于用户共情，共情的基础来自于大量的用户研究。Growth Design更像是一个反推的过程，出发点来自于定义北极星指标，和公司当前的mission相关，小团队又有更为具体的metric。说个不恰当的比喻，传统设计过程注重正向论证从0到1，Growth Design更像是已经有了0.8，0.9，通过一系列反证法，把这个零点几推进到1，甚至1+。
所以，增长设计的特点总结如下：
侧重用户旅程（customer journey）
快速迭代
设计体量小
在迭代中了解用户
数据驱动
适合做UI优化
适合接触点清晰，用户群清晰，模糊性小的项目
和营销紧密结合
适合利润敏感的接触点
不适合：
产品需要大浮动改动
需要复杂操作，任务导向的功能 （例如说很多2B产品）
0-1的项目
a. 经验和观点会大打折扣
在增长设计的环境中，我深深地感觉到我的工作经验和信念感大打折扣。在2C环境中，用户心理难以揣测，并且依靠着大量的数据支撑，很多设计动辄就是好几位数的利润影响。常年在2B的我没有数据，完全依靠对业务的理解，定性的用户研究（可用性测试，用户访谈）和引导者姿态的用户体验价值观来驱动我的设计方案。很多做2B的朋友跟我开玩笑说，2B最难的就是逻辑和业务知识，处理完逻辑和矛盾，方案就一目了然了。2C的难点在于有太多可以探索，尤其在增长的领域，每一个假设都有可能分分钟被推到重来，新的原则和价值观也在不断迭代更新。
b. 控制设计的完美主义和做多的欲望
在之前Yahoo （Verizon Media）广告组的时候，我非常自豪于自己的主观能动性。见到又老又旧不友好的设计，即使不在PM的需求之内，也会自己计划一些用户体验上的优化。直到我了解到Dropbox上很多老旧页面存在的原因，我才意识到我之前的观念可能在这里不适用。这些页面大部分是利润敏感页面，例如向上销售（Upsell), 登录界面。这些丑丑的界面，我们也想好好优化，做了很多次实验，但是表现始终不如当前的控制组。这种过于担心短期得失的心态不见得是最值得提倡的，但是有一点是肯定的，在做增长设计的一定要控制住自己多做的欲望和自以为是“优秀用户体验”的偏见，每一个决策有理论支持是不够的，在利润风险的夹持下，数据的支撑显得更为重要，设计不能大跃进。
c. 细节会被放大
这一点也是显然的，一个icon， 一段话都能带来乘数效应（Multiplier Effect）。
多文化设计：如果你的增长目标是面向不同文化的，不得当的插画比喻，颜色的错误运用，单一的货币单位，蹩脚文案翻译都能瞬间惹恼用户，分分钟劝退。
法律意识：有关增长的接触点往往和购买，注册，授权用户信息有关，这些都是重大的用户决策，我们要充分考虑用户隐私，安全，和信息的透明度。例如说协议条款必须要放在清晰的位置，用户的操作必须是有意识的，不能操控误导用户等等。最近在做Apple Sign In项目时，我们在文案上迭代了8次，一个用户协议授权的界面放在哪里不停讨论，为了保障用户账号的安全性不惜在流程上人为增加一些阻力。这些看起来和增长没有任何关系，但是信任，安全，规范的基础原则一旦破坏，哪怕是很小的细节，消极影响会被无限放大，是多少个增长实验都解救不了的。
情感设计和产品形象：之前我们都会认为产品设计中的情感，性格和形象都是一些虚无缥缈的东西。但在增长领域的用户旅程里变得重要起来，尤其是在获客层面，它能帮助用户快速认识这个产品带给他的价值。所以很多公司在产品形象和情感设计上下了很多功夫，产品色彩和品牌形象，插画的运用，文案的语言风格等等。并且不同元素的运用能够让用户识别哪个是适合他自己的产品，减少了我们引导用户的消耗。
d. 增长设计更容易踩雷
我个人觉得，增长设计虽然可以在短期内带领公司促进收益，但是它的弊病也是很明显的，并且更容易踩雷，包括但不仅限于
过于倾斜解决商业问题
难以做出大规模革新
视角狭隘, 只关注用户旅程的某一阶段
打折扣的设计质量
重复的项目
没有原则的设计
前文中“重新定义问题”，“Roadmap的制定”，还有“细节会被放大”中提到了1，2，3，6，这里想谈一下如何保证设计质量和避免重复的项目。
相比于交互和产品思维来说，我的视觉能力要略弱一些，加入Dropbox的其中一个目的就是想要督促自己把UI打磨地精致，但是半年过去了，我觉得我的视觉水平并没有得到想象中的锻炼，上线产品的视觉质量也没有明显提升。原因有几点，
对单一元素迭代周期太长，即使探索做的多，开发出来的也少。
跨平台，跨团队的合作不紧密，有关Growth特殊的设计系统不完善。
整个跨职能的团队过于注重商业表现而忽视设计美观和精致带来的价值。
第一点前文已经提到 （设计探索，挑选实验方案，制定优先级），第二点也是一个比较普遍的问题，这里想说说第三点。关于第三点，我后来的心得是，团队需要建立统一的设计原则进行第一轮的把关。否则我们会陷入这样一种心态：算了，就这样吧，反正可以通过实验进行验证，哪个好用哪个。通过实验验证之后，的确发现某一个方案表现的不错，于是我们最后的上线方案就停留在那一版了，其实探索和打磨并没有到位。我们错过了很多原本可以让方案更好的机会，这就是设计师完全丧失自己观点的弊病。
同时，设计原则要有度量（metrics）衡量其价值，这个制定的过程需要所有的利益相关者参与进来，通过监测效果不断完善。在2019年的Q3, 我花了三周的时间研究如何优化我们组的设计原则，最终目的是把它转化成真正可以操作起来的规范。这里不做赘述，如有时间会以另一篇文章的形式分享出来。
增长团队很容易陷入一个怪圈就是，做着做着实验发现这个想法在三年前已经做过了，然后我们还有数据分析，经验总结，应有尽有。宏观来看，会发现Growth Design就是对着几个button一直优化优化，优化到头秃，让人哭笑不得。我在Dropbox至少遇到过两次类似的场景。这其实是很常见的现象，真正有创新的想法的确不多，那些简单直接的方案很快都被捡走了，做着做着就发现增长实验大同小异。遇到这种情况首先是要把过去的经验和洞察仔细研读，来评估是否再值得继续探索。另外就是回到上文提到的内容，重新审视问题，避免长期UI优化，要勇于跳出框架，发现更大更有价值的问题。
Growth Design, Growth Hacking, Experiment Design, 其实都算是互联网届非技术领域的buzzwords，对待这些新的概念，没有必要抱着一种如临大敌，错失恐惧症的心态。无论什么方法都是为了解决问题，而不是用方法去适应问题。并且增长设计在2B领域目前还没有得到科学有效的应用， 不是说不能用，而是更具挑战性。在当前形式下，原因是多方面的:
2B类人工销售的力量大于数据驱动，短时间内无法改变。
2B的购买决策权不在于终端用户。良好的用户引导，激活体验无法带来明显直接的商业价值。
2B关注于提高生产力和效率，本质上是工具，通过增长杠杆赋予的价值远远小于产品的核心价值。
纵观整个用户旅程，流程比2C产品要复杂的多，有很多线下场景，并且涉及的人物角色众多。快速迭代的实验操作起来比较艰难，并且容易忽略很多dependency。
巴洛克风格建筑
包豪斯风格工业设计
Customer Growth好比巴洛克风格，Problem Solving好比包豪斯，这可能是一个不恰当的比喻。过于追求用户增长而放弃提升产品价值，并把它作为维系公司的手段，很有可能就会落入工业设计史中巴洛克-包豪斯的历史轮回。不断思考设计伦理和发展趋势，是每个产品人，互联网人需要思考和平衡的问题。
4月19日更新
这一部分和刚刚讲述过的“用户体验”对比“用户增长”有些类似，不过更像是实际工作中如何处理两者关系的延伸。
讲一个最近发生的事情：在Dropbox，我们不仅有Mobile Growth组，还有Mobile Core组。Growth主要负责如何拉新，激活，留存，相关的接触面有登录，新手教学，用户取消服务流程等等。Mobile Core主要做一些产品功能，例如管理文件，照片，分享等等，我们有非常多紧密的合作。在我的理解下，增长在中文语境下更像是“运营”，核心目标在于如何增加engagement，如何增加流量和转化率。其实作为设计师，我和同组的设计师觉得很不甘心，每次商业问题来的时候，我们都要花费很大时间重新定义用户问题，如果找不到用户问题，设计的过程会变得非常拧巴，并且结果也更加不可控：明明产品本身价值没有上来，为什么要依靠漏斗上端的力量卖力地向用户推销，去训练和培养用户的行为，有时候甚至要 “通过超剂量地增加对用户的教育和引导来降低新功能刚刚上线没有market-fit的风险“。这个逻辑就类似于，我卖的东西质量很差，却大把的资金投入到了广告，而不是提升自己产品的水平。这不是丢了西瓜捡芝麻吗？
于是在Q2 planning的时候，我和同事想要push more, 用更广阔的视角去审视Mobile 产品本身，而不是局限于只能做新用户引导（Onboarding），登录（Sign in/up）, 推销页视觉优化（Upsell optmization） 等等。Push的结果就是我们的Roadmap触及了很多core 组盘子里的东西，在这个过程中我自己心中有一些疑惑和不放心：把core组的东西也拿来做，这样是否显得太过强势。如果不push, 我又不喜欢让我的合作方说我思维狭隘，没有发觉问题本质的意识，没有退后一步（take a step back)思考。总的来看，可以总结为以下几个疑问：
Growth的职责和最终愿景（mission）到底是什么？
从Growth出发，向产品端Push的界限在哪里？
产品设计和增长设计该如何合作？
我把我的困惑跟老板沟通了一下，其实自己早先也有些模模糊糊的思路，但是和老板的交流让我更加清晰了：我们不应该在解决方式上把界限划分的非常明确 - Growth只能做onboarding，Core组只能做功能。无论是onboarding还是feature，都只是形式。
试想一下，如果Core mobile说他们想用一个Growth创造的模块或策略来提升他们的业务指标，我们能say no吗。另一方面我们要清楚不同组的业务目标，作为增长组，我们的核心KPI是转化率，是激活率，是参与度等等，我们就不合适去领导一个改变信息架构的项目，除非我们有足够的数据推论证明改变信息架构对于核心指标有直接相关性，注意了，这里的核心指标不一定是商业KPI。Core 组的核心指标可能是用户满意度，可用性，效率，任务完成度等等，如果他们确定改变信息架构有助于提升用户满意度，那么这个项目在他所管辖的范围内就是合理的。他们也会有类似于功能使用率（feature adoption）——我们共有的指标。无论你是推广教育用户还是附加产品价值，首先明确它的首要目标是否合理，是否是你应该关心的，和这个项目的形式并无限制关系。
通过这个思路判断，我们重新评估了road map, 过滤了一些不合适的项目。同时也保留了一些看起来根本不像传统意义上“增长设计”的项目。他们看起来更像是对已有产品功能的改进，但是通过过去的增长实验，用户研究，我们有足够信心相信它们能提升我们的转化率和留存，Core Mobile 团队也非常欢迎我们往前一步的探索。
通过这个例子是想说明，想要把一个产品更好的展示在用户面前，内在和外在都很重要。盲目抛开哪一个都会变得偏颇狭隘，这个事情告诉我如何利用产品设计和增长设计两种不同策略，殊途同归的达成我的目标，也启发我如何定义和调整自己思考的边界，什么时候“走出去”，什么时候“引进来”。
正文结束
我是一名在硅谷湾区的产品设计师 - 挂面(年少的我一面试就挂!)，目前在 Dropbox Growth 组负责移动端的用户增长。之前分别在 Yahoo (Verizon Media)和广告咨询公司 AKQA工作过。2B让我对复杂的问题和商业逻辑特别有热情，2C又给现在的我打开了新世界的大门。努力维持理性与感性的平衡，期待和热爱产品设计和用户增长的朋友交流 :)