2.1万字全流程SOP：详解如何从 0 搭建线上业务的增长引擎？
-
-
chkcat 这家伙很懒，还没有设置简介...
0 人点赞了该文章 · 15 浏览
本⽂以增长系统核心逻辑+接手项目3周工作流+常见问题解决方案，梳理出一个可复用业务搭建工作流。此外，本文是从一个业务负责人的视角去写的，适合项目从0到1阶段的业务负责人，和2年以上工作经验，希望往业务负责人方向发展的产品经理和运营。
今年是叮当做运营&增长的第3年。
从2017年⾄今，叮当在企业培训的甲⽅公司做过偏品牌的新媒体运营；在⽤户增长服务⼄⽅公司做过项目经理，服务过三联，小米，知音集团等知名企业；负责过营销SaaS产品的从0到1的设计与运营搭建；在K12TOP的教育公司负责过新业务线的搭建。
这些职业经历中的公司有甲方也有乙方，有创业公司也有上市公司，有B2B的业务，也有B2C 和B2B2C的业务，做过运营也做过产品经理。
但有⼀点是不变的：“⼀切行为都是以业务的增长为核心”
在这些业务经历中叮当也完善了⾃⼰在业务增长⽅⾯的知识体系和⽅法论，过年期间写了本文初稿。
本文是从一个业务负责人的视角去写的，适合项目从0到1阶段的业务负责人，和2年以上工作经验，希望往业务负责人方向发展的产品经理和运营。
本⽂以增长系统核心逻辑+接手项目3周工作流+常见问题解决方案，梳理出一个可复用业务搭建工作流。
本文目录：
在写完1.0的初稿做阅读时，叮当发现一些概念定义的不是很清晰，故做了一些调整。
如1.0版工具部分叮当用了“营销自动化”，但实际上由于国内的互联网生态和SaaS的成熟度，都是达不到全自动化的。
国外主要是邮件营销，而国内由于互联网发展过快大部分用户都是直接跳过了PC时代，进入移动时代，用户最为聚集的平台是微信，而在微信的管制下，靠SaaS做到完全的营销自动化还是很难实现的（底层数据很难打通），最后叮当把这个章节改为了提高效率的“工具系统“。
本文内容适用范围：
1）已有业务，需要探索新的增长模式
如：电商产品，以前主要是做淘系流量，现在想尝试搭建私域流量提⾼复购。
2）完全是新的业务，没有团队，没有历史经验参考
如：公司是在某一方面很有资源优势（渠道，内容……），希望做出一款产品，成为公司新的营收增长点
本文80%内容来源于叮当的实操经验，20%内容来源于工作之外的学习与思考
1. 正式上手前你需要了解的
1.1 ⼀个业务增长系统的全局是什么样子的？
如果把业务系统看做一艘船的话：
战略模型就是“动态变化的航海图”，为整个业务指引方向。 管理系统是“仪表盘”，监控航向与船只状态 战术是船只的“动力引擎”与“效率系统”，支撑船只的航行。1.1.1 航海图：战略模型的作用，及对业务的影响
战略是选择方向，寻找一条实现目标最有效的路。
制定战略：对内要挖掘自身优势，对外要寻找市场缺口。
基于自身优势优势出发推进起来才能事半功倍，而市场是否有缺口则决定了这事能不能成。
梁宁老师在《增长思维30讲》中讲过“猎豹移动“出海的案例：
2012 年 7 月，傅盛第一次去美国。当时猎豹的状况是在国内市场对手过强，没有发展空间，而此时的美国还觉得做工具是苦活累活，不愿意做有着大量的市场缺口；
傅盛跑了Goole Play上所有关键词，发现：清理，杀毒，电池，系统这四个词出现频率最多，然后选择了cleaner（清理）这个需求做工具，找来3个人来做，几周后线上，上线第一天就有1.5W下载量，之后傅盛加大投入……2014 年5 月 猎豹移动在纽交所IPO。
猎豹的案例离我们实际工作可能会比较远，而且我们大部分时候也没有机会参与到一个产品或者一个企业的战略制定中，那么“战略“对我们有什么意义呢？
理解：只有充分的理解战略，在项目中我们才能更好的跟上级跟老板同频沟通； 反馈：战略只是方向，当外界环境变化时战略要跟着动态调整，在业务一线要及时反馈跟战略相关的信息，支撑上级和老板的决策。1.1.2 仪表盘：管理模型，及对战略模型&战术模型的影响
彼得德鲁克说：如果我们不能量化，就没办法管理。
而公司作为一个商业机构，业务的好坏最直接的量化反馈就是财务数据。
当然，考虑到不同商业模式的回报周期不同，除了财务数据之外我们还要看业务数据。
由于从业务数据中只能看到我们考虑范围内的问题，我们还需要通过用户研究了解我们在用户心智中的定位，是否与我们期望的一致。
管理在整个业务中起到的是仪表盘的作用，那么这个仪表盘怎么用呢？
对于可直接售卖产品我们主要关注财务数据（核心指标）
根据财务数据问题去分析业务数据，根据业务数据的定量分析得到的洞察去调整战术；
如定量分析无法得出有效的洞察，可通过用户访谈定性分析，了解问题的真实发生场景，再根据得到的洞察调整战术，同时检查一下战略方向是否需要做一些调整。（后面会详细写）
1.1.3 动力引擎：战术模型及高效运行的业务体系
战术中主要分三大模块：业务，支持，交付；
不同阶段不同平台的项目这些系统是不一样的，小公司或者初期项目除了业务核心部分自己做，在支持系统上更多是扁平化层级+SaaS&平台工具管理；而大公司或者成熟项目大部分有完善的支持系统。
在成熟的系统中熟悉系统+根据自己的需要提需求或者用成熟的SaaS就好，而在从0到1的阶段则要学会利用市场上的成熟系统快速的搭建项目，验证需求（后面会详细写）。
在战术中我们需要考虑的核心是：行动协同
用人话讲就是：在战术中我们设计的每一个动作对其他动作都是要有加成的，这就需要我们有系统去设计每一个动作，而不是孤立的去设计动作，设定目标。
如：我们做流量的时候需要考虑用户匹配度，这样对后面的转化和存留才是有加成的，我们做转化的时候要考虑用户体验，和更便捷的触达用户方式，这样后面才可能有更多复购。
怎么制定战术呢？
在制定战术的时候要考虑4个关键要素：目标，打法，资源，激励。
目标：战术中的目标是具体的，可衡量的（符合smart原则）
订目标是为了对战术中动作产生的效果有一个预期，但并不能排斥变化，尤其是在项目初期没有参考数据的情况下；不能为了预估的更加精确踌躇不前，应该追求在成本可控的情况下小步快跑快速迭代。
打法：持久战还是闪电战？小步快跑还是深耕All in……
打法是在目标制定后结合“自身优势”和“市场缺口”制定的；具体要根据不同的市场生命周期和业务模式决定：如做C端业务决策链条短，可采用小步快跑的方式去做；而做B端业务无论是服务还是工具，决策链条都比较长，回款周期长，在最初就要慎重决策，决定做就要做好深耕下去的准备。
资源：不同的打法配不同的资源
不同的打法需要配置不同的资源，如要缩短一个项目的工期又不能降低质量，那么就要增加资源投入；如果要做SaaS就至少要做好半年之内没有盈利的准备。
激励：只有目标没有激励，激励的大小
有目标就要有对应的激励，否则完成和完不成没有什么区别，那项目成员积极性也不会太高。
1.2 如何通过公开渠道挖掘产品的战略与战术？
知己知彼，百战不殆。市场竞争是动态的，只有对自己对竞争对手都足够了解我们才能在竞争中游刃有余，这需要我们有基本的信息获取能力。
在项目中获取竞品信息的需求一般有两种场景：
监控竞品功能迭代，营销活动……（后面会详细写） 针对一个主题去挖掘，制定对应的策略1.2.1 需要挖掘哪些信息？
企业的增长系统如同一座悬浮在海上的冰山，我们在海面上能看到的只是非常小的一角。
但企业作为参与市场竞争的组织又与“冰山”不同，因为它要把自己的核心价值传递给用户，传递给市场；所以它露出的那“冰山一角”也携带着最具有价值的信息。
最基本的是业务，信息，我们可以问自己一些相关模块的典型问题，梳理需要挖掘的信息。
1.2.2 怎么挖掘这些信息？
叮当平时分析的时候，如果有明确的目的一般会直接使用相关的工具去找；如果没有明确的目的，会先看一些这个行业的行业报告或者券商公司发布的分析报告，然后再有针对性的找自己需要的信息
如：进入一个新的行业需要进行全面的了解会先看行业报告，找几款这个领域TOP的产品去体验&研究，了解这行业的商业模式，用户群体，业务模式……
1.3 关于3周规划中每周重点和可能遇到的问题
一个决策质量高不高，其实就是发散和收敛做的质量高不高。
在我们搭建业务的时候也是如此，发散阶段如果获取的信息不够全面，决策是有漏洞的，有些漏洞可能就是致命的，在搭建业务的规划中我也是按照：发散-收敛-执行 去规划的。
以上的节奏是理想状态，但我们新接手一个项目的时候Leader，老板，或者甲方总是希望我们进度更快一些，能够快速上手，快速做出效果……
他们的期望是正常的，但大部分时候“快”与项目的成功并非正相关，他们的着急大部分时候是因为他们没有看到足够多的细节&工作量。
如：叮当之前在郑州工作的时候发现，一些做传统行业的老板思维中：互联网=程序员，做一个产品却不招产品经理，直接招几个技术去做，做完后发现很多BUG，然后吐槽这些人技术能力不行，而实际情况是这些人技术并没有多大问题，只是他们不熟悉业务，也没有严谨的评审测试流程，实际开发出来的产品很多情况都没有考虑到，无法满足老板的预期。
作为这个岗位的胜任者，我们要知道做这些事情大概需要花费多少时间，什么时候节奏应该慢，什么时候节奏可以快一些，合理的管理他们的期望。
预估时间：如果是换工作进入一个完全不熟悉的环境的话前2周的事情是无法省略的，但具体需要的时间要看公司的规划和业务的复杂程度了，经过第2周的规划，列出待办事项清单，自己负责的自己可以评估，一些涉及到协作的找协作放评估，但一定要留一些弹性时间，应对突发状态。 什么时候应该慢：当进入一个陌生领域，或者一个项目的初期，业务系统的很多部分自己还不熟悉的时候，应该慢一些稳一些，先去学习这个领域别人踩过的路，向先行者请教，避免去踩一些没有价值的坑（别人已经踩过很多遍了，自己再去花钱花精力踩一遍）。 什么时候可以快：在这个项目中有经验非常丰富的大佬，可以hold住一切的突发状况；或者进入一个全新的领域完全没有可借鉴的经验，自己就是先行者，需要小步快跑快速积累经验。2. 第1周：熟悉团队，了解业务
熟悉环境是推进项目的基本条件，特别是对组织规则，协作者，用户群体的了解。
2.1 如何快速熟悉团队？
先熟悉团队才能更加高效的了解业务信息（知道自己需要的信息从哪里获取）。
一般在入职加入团队之后Leader都会带着熟悉一遍公司的组织架构，和自己在业务中需要经常对接的人，但是如果团队的人太多的话很难短时间记住每个人的，这就需要我们提前做一些准备，更好的熟悉团队（或者可以叫“互相熟悉”）。
这里叮当总结了3个小技巧：
如果团队比较大的话可以用思维导图梳理下架构。
2.2 加入新的团队需要熟悉哪些流程？
一般公司都会有新人培训，会简单的介绍公司的文化，制度，福利……，但除了这些我们还需要熟悉公司的其他的流程为后面规划项目&推进项目做准备，核心主要有3大模块：人力，财务，业务。
了解人力相关流程一是为了解招聘相关，为后面业务跑起来之后扩大团队做准备，二是要了解公司的绩效评定规则，和自己需要背的指标，在目标上与上级达成一致。
而了解财务流程和业务流程是为了更好的规划&推进项目，以免考虑不周。
在大厂待过的小伙伴对财务相关的流程体验应该比较深刻，采购和报销都有很长的流程，如果不把这部分时间计算到项目中，后面项目延期卡壳几乎是必然的事情。
很多小伙伴可能觉得这些流程没有必要，但这些流程既然存在自然有合理性，比如采购时需要供应商提供相关的资质证书，需要签合同；再比如一些营销活动上线前需要经过法务评审。
对于小公司可能不需要考虑太多，而对于有一定体量的公司，每一个环节的失误都可能照成巨大的损失。
在规划中我们需要提前考虑到这些因素。
可以通过提前请教走过这些流程的同事了解这些流程的具体步骤和一些环节需要提供的资料，尽可能的提高效率，如果没有现成的经验，就要尽可能多留一些时间，同时在做的时候记录相关的信息，方便团队复用。
如果我们做的是TOB的业务业务需要了解客户那边的流程，更好的给到合作方支持。
2.3 如何快速熟悉用户？
业务的核心是为产品连接用户，熟悉用户，理解需求是做好业务的基本功。
在最初的时候我们需要根据现有信息+调研信息初步假设一个用户画像，为后面寻找渠道&设计方案提供一个大致的方向，后面再根据实际业务进展中获得的信息&数据把用户画像做的更加精准，提高资源利用效率。
我们需要了解的主要是以下4个版块的信息：
其中前两类信息可以通过历史用户数据和以往的用户调研了解；后两类主要是通过业务中的数据监测和用户访谈了解。在最初了解这些信息的时候可能会有两种场景：
场景1：已有业务
对于已有业务可以先通过以下两种方式构建一个用户画像的假设，再通过第三方的行业报告+垂直社区的UGC信息+用户访谈交叉验证&调整用户画像的假设。
客服部门资料：答疑文档，近期信息处理记录…… 内部用户数据：各平台后台（公众号，抖音，客服号……），渠道投放数据，订单发货数据，付费用户数据
场景2：全新业务
对于全新的业务需要先去发散性的收集信息，再慢慢收敛边界针对性的调研分析，可以参考以下5个步骤：
看行业报告&业内分析：在最初我们需要对这个领域有一个整体的了解，可以先看看一些大数据公司出的行业报告，投行投资分析报告（微信小程序“报告查一查”里面这些内容很全面），业内人士的分析文章（微信“搜一搜”或者知乎搜索相关关键词） 逛垂直社区，收集用户故事：看行业分析报告和业内人士的分析我们得到的是一个理性的框架，但如果要更加深刻的了解用户的需求和场景，我们需要从去读一些真实的用户故事理解用户的情感（可通过百度搜索和应用商店搜索相关的社区论坛&APP） 扒竞品软文&投放素材：投放素材&软文是一款产品营销策略的精华，这在对用户有了框架性和感性的了解之后，我们可以扒一下竞品的投放素材和软文跟自己收集的用户信息交叉对比一下（信息流投放查看工具：广告查查，信息流雷达；软文：在相关平台搜索竞品品牌词） 整理行业爆款内容&用户评论：爆款内容之所以能够成为爆款很大程度是因为迎合了用户的需求，而用户评论可以在一定程度上反映用户的体验和未被满足的需求（爆款文章可以通过平台搜索+阅读量排序；用户评论可以通过一些爬虫工具爬取） 梳理问题做用户访谈：如果通过以上步骤收集完信息，分类&归纳后还是对用户有一些疑惑，可以潜入竞品社群伪装成用户或者找相关垂直社区的活跃用户做下访谈2.4 如何快速了解产品？
这里的”产品”不仅仅指直接销售的产品或者APP，还有外部内容生态的布局，微信生态内的私域流量池；商业价值产品线则是指不同用来商业变现的产品；而功能产品则是为了支撑整个体系的高效运转（工具产品和针对B端的SaaS其本身也是商业产品）。
以上模块在不同类的产品，不同规模的公司模块也会不同：
在产品的最早期验证需求阶段可能只有：可售卖产品+商城SaaS+渠道；或者工具产品+内容+渠道，我们在这个阶段不仅仅是在梳理产品，也是在梳理可以用的资源。
不同模块在梳理的时候关注的内容不一样：
内容矩阵：需要关注平台账号的粉丝量，用户画像，最近一个月内容阅读/播放量，评论量…… 私域转化：也需要关注粉丝量/好友量，用户画像，最近一个月内容阅读，评论量，但同时还需要关注商品的转化率，活动的参与率…… 商业产品：课程类需要关注课程的SKU，核心卖点，目标人群，流量课OR营收课，价格，是否有赠品，每期可服务人数……；实体类产品需要关注：SKU，核心卖点，目标人群，流量产品OR营收产品，价格，成本，使用限制；广告销售需要关注：广告位，曝光量，排期，价格……；会员权益需要关注：会员分级及权益，每个等级会员数量…… 功能产品：这个部分的梳理重点在于熟悉功能，及其限制，可以用思维导图从一级菜单往下梳理，熟悉功能，方便使用2.5 如何快速捋清业务？
在叮当的理解中：业务是供需双方达成交易的明确路径。
在这个过程中可能包括：怎么触达到用户？（渠道）怎么让用户产生兴趣？（广告）怎么让用户体验产品？（低门槛），怎么获得用户的信任&口碑？（超预期），怎么引导用户完成转化？（优惠，紧迫感……）……
既然是“路径”那肯定就有流程，所以在叮当看来，梳理业务就是梳理用户从接触到完成转化的全流程。
叮当一般喜欢用AARRR模型去梳理整个业务流程（一些早期的项目业务链条较短可能不会包含整个AARRR，需要根据需求灵活调整）：
叮当习惯用泳道图梳理业务，以上是一个在线教育产品业务流程（上图框架可参考，内容纯属虚构），叮当整个业务流程分成：拉新，激活/分享，转化，存留/服务四个阶段，分别对应用户从接触到转化的4个阶段，在对应的阶段加入流程及使用的工具，这样可以在一张图中就可以看清整个产品的业务链条。
3. 第2周：规划业务，搭建引擎
规划的底层逻辑是：通过控制“定量”撬动“变量”，然后再把“变量”变成“定量”。
定量：确定的，我们能够直接控制的；变量：我们无法直接控制，甚至没法间接控制的东西。
比如减肥这件事，我们无法直接控制体重，但是我们知道跟体重有强因果的事情，而且我们可以控制，假设我们的目标是C（体重减到xxKG减肥成功），那么我们可以通过控制A（少吃，多运动），从而实现B（体重下降），坚持一定的周期后完成C（减肥成功）。
所以我们在做规划的是需要特别注意，要确保这件事中绝大部分是“定量”（可控）。
完全不可控的事情是没法“规划”的，只能在风险可控的前提下通过测试获取信息。
如果我们想要优化一定要去慢慢增加“变量”，通过测试不断把新增的“变量”稳定下来。
3.1 如何找到业务的切入点？
在找业务切入点时也会有两种场景：已有业务，全新业务。
以下我会简单介绍一下在这两种场景中我一般会怎么找切入点，以及判断一个好的切入点的标准。
3.1.1 已有业务找切入点
已有业务找切入点，中间的“定量“会相对多一些，叮当一般习惯从战略-战术-执行，一层层往下捋，对标竞品和跨界的优秀解决方案查漏补缺；
战略定位：已有业务中战略层一般都是规划好的，在这种场景下我们只需要了解，具体可以通过体验产品，看产品的SKU，包装，向公司同事&Leader请教……
要确保了解战略之后我们能够回答以下几个问题：
我们自身的优势是什么？（内容，技术，产品，渠道……） 我们在抢占的市场缺口是什么？（用户群体，需求场景） 这个市场有哪些限制性因素需要解决？我们是怎么解决的？ 这个市场有哪些竞品，他们各自的优势是什么？满足用户需求的方式是什么？战术协同：在了解战术的之前我们首先要判断这个产品处于什么样的生命周期，什么样的阶段，再看对应阶段的战术，看战术之间是否协同，是否有缺失的模块。
我们判断阶段后可以对一下对应的模块看是否有缺失，同时看目前的战术之间是否时协同关系。如：裂变体系的搭建对用户转化的影响是正向的还是负向的？从用户进入哪个阶段开始推裂变？
战术执行：在执行层面主要看用户转化路径各个关键节点的转化率，找转化率较低的部分往下拆分更细的路径，找到问题关键点，看推广素材，分渠道分析,用户调研验证假设。
如某在线教育产品的用户转化路径是：流量—购买体验课—体验课社群转化大课，他们分析完整个路径的数据后发现在体验课转大课的环节转化率远远低于行业平均水准；
又拆分了5天社群转化每天的用户活跃数据和完课数据，发现用户在第三天完课数据急剧下降；
找到社群的整体运营节奏，发现第三天规划的节奏是“开始转化“，社群以课程转化内容为主；
于是到这里他们大概就有了一个假设，这群用户对课程价值的感知可能比较低。
跟负责渠道的小伙伴沟通后了解到这群用户主要是由朋友圈投放过来的，但由于定向范围比较大，并没有精准的用户画像。
通过目前的信息还不能验证自己的假设，接下来还需梳理问题框架做一下用户访谈。
通过调研他们了解到这期用户主要以三四线用户居多，对在我们的课程价值认知度低。
那么接下来就可以根据这些信息去做一些策略的调整，如：在课程前期多增加认知类内容&案例，权威专家&理论背书；把转化期从3天延长到7天……
以上就是已有业务找切入点的流程（案例内容源自真实案例），而当这些梳理完之后能找到的切入点可能不止一个，我们还需要把这些切入点根据需“需投入成本“和”预计产生效果“做一下评估，先把”投入低，效果高”的做掉。
以上是理想情况，真实工作场景中我们遇到的是需要背一定KPI的，所以还需要考虑以下两点：
考虑这个切入点是否是在自己负责的范围内，如果不是，先和Leader沟通目标再推进。 考虑其中哪些切入点更有利于KPI完成，以及需要的资源（有KPI就要有对应的资源配置）3.1.2 全新业务找切入点
全新的业务基本全是“变量”，结果极不可控，失败属于大概率事件；也正因如此我们需要一些策略去尽可能的提高成功率，最大化的学习经验，降低失败的损失。
全新的业务是一个验证假设的过程，由于这其中所有的东西我们都没法保证是确定的，那么我们只能假设：我们对这个业务的假设是正确的，而具体需要看执行结果去验证。如果我们在执行之后发现结果和我们的预期是一致的，那么这个业务模式也就成立。
跟已有业务的规划一样，规划全新的业务也是三大步骤：战略定位，战术协同，战术执行。
1）战略定位：对内找优势，对外找缺口
新业务找切入点就是一个找自身优势和外部市场缺口的“交集“的过程。
2019上半年叮当负责一款基于微信公众号接口开发的营销SaaS产品的从0到1。
根据《2018年自媒体行业白皮书》中的数据，截止到2017年年底全国新媒体从业者已经超过300W，活跃公众号350W，“涨粉”是一个很强的需求，但通过我们接触的营销工具服务商，发现他们的用户并不是很多，然后通过调研发现一部分用户是因为价格，一部分是只是知道这种工具，但并没有实际使用过，我们觉得这是一个市场缺口。
而且我们的团队一直深耕微信生态内的用户增长，无论是营销能力还是对微信生态的技术探索都处于行业前列，况且我们还有十几万的精准用户群，非常有优势。
2）战术协同：定义模式同时考虑风控和兜底，找参考坐标。
创新是一个：发现—联系—重组的过程，而探索一个全新业务的过程也是如此，它并不是凭空创造出来的，而是在现有模式基础上结合用户的需求场景，加入新元素。
不同的商业模式有着不同的逻辑和不同的核心问题。
如：教育行业核心要解决的是效果外化，保险行业核心要解决的是价值感知&认可，B端业务的的长决策链……
在定义模式的时候我们可以问自己典型问题：
群体：我们的业务面向的用户是C端还是B端？（考虑决策链） 用户：我们的用户群体有哪些特殊性？（考虑用户的特点） 行业：我们的业务属于哪个行业？（考虑行业的核心问题） 产品：我们的产品是否有边际成本？（考虑规模效益强弱） 盈利：我们的业务如何盈利？（盈利模式，回报周期）其他需要考虑的要素还有很多，但这些是最关键的，而我们下一步要做的也就是基于这些问题梳理自己的风控&兜底策略。
群体：面向的用户是B端，需要考虑回款周期，要有一定的现金流。 用户：用户群体以新媒体运营为主，需要考虑他们的工作习惯。 行业：业务属于工具类SaaS产品，需要考虑竞品功能&开发周期（B端对工具的需求大而全） 产品：服务成本。（最初我们以为可以通过把功能做到极简，就不需要太多服务，后来发现还有很高的客服服务成本的） 盈利：通过工具的销售。除了这些还需要考虑极端结果的影响，假设这个项目失败了，它对公司其他的业务会有影响吗？是正向的还是负面的？
当时叮当其实没有想到这个问题，直到完成从0到1，退出那个项目后才发现，无论那个项目结果如何都是要做的；因为当时我们的客户主要是B端客户，会有一部分偏传统的企业定制营销系统的需求，我们当时的技术团队还是以做C端的营销工具为主，没有做B端产品的经验，这些技术经验是必须要积累的。
以上梳理完到了执行层面，我们还要找一些“参考坐标”去借鉴。
毕加索说：拙工抄，巧工盗。
抄和盗的核心区别在于“抄”只取其表，不知其中核心逻辑，而要想“盗取”其中精髓，需三步：拆解—对标—自检。
3）战术执行：以MVP的模式，小步快跑快速迭代
在全新的项目中由于没有历史经验&数据的参考，在战术的执行阶段变化是最大的，结果不如预期是大概率事件，我们的步子迈的要小一些，方便及时调整。
在前期的适合先找最核心的需求，做出最核心的功能去找用户验证需求，再一步步去迭代，防止花很多精力做一些没有价值的“伪需求”
叮当最开始做产品规划的时候通过竞品分析和用户调研先梳理出了核心的功能，后面又把其他功能按需求频次和工作量排序，尽可能每周可以上一个版本，可以获得及时的反馈去调整。
3.2 如何制定合理的业务目标？
业务目标可以分为长期目标和短期目标，长期目标是核心指标，是所有人都要关注的，而短期目标则根据阶段，根据岗位各有不同。
3.2.1 如何确定核心指标（长期目标）？
核心指标，也可以叫做“北极星”指标，整个指标将在很长的时间内像北极星一样指引业务的方向，而在制定之前我们首先要了解它的核心逻辑。
业务增长的核心是商业价值的增长，而商业价值来源于产品满足用户需求后获得的回报。
而这其中必然有一个核心的指标能够驱动产品价值的和用户需求不断处于一个正向循环，而这个指标在不同业务，不同产品中都可能是不一样的。
如之前做用户增长服务项目时我们关注的核心指标是：给客户业务指标带来的增长，这个指标的提高不仅仅可以带来更长期的合作，还会因为做出的爆款案例带来更多的客户。
衡量一个指标是不是北极星指标，对照以下几个问题自检一下：
能否反映用户从产品中获得核心价值？ 能否为产品达到长期商业目标奠定基础？ 能否反映用户活跃程度？ 指标变好，能否提示整个公司在往好的方向发展？ 是否简单直观，容易获得，可拆解？ 是否是先导指标，而非滞后指标？3.2.2 如何确定自己的阶段目标（短期目标）？
确定短期目标需要先看阶段，看角色。
在业务初期需求还未验证，业务模型还未稳定的时候，短期目标应该是把需求验证；
业务模型稳定；到了业务模型稳定之后，有了可参考的转化率数据，就可以根据资源制定确定的目标了。
除了阶段之外还需要看角色，在整个业务模型中承担不同的角色，指标也会不一样，权责一致，每个人只能为自己可控范围内的负责。
（极简版在线教育公司架构）
在这其中我们首先要了解自己是属于业务角色，支撑角色，还是交付角色（面向用户）：
支撑类的考核一般是跟响应度，效率相关的；
交付类的考核一般是质量和效率；
业务角色需要背指标具体的业务指标，但是需要关注那些是自己能够控制的，哪些是自己不能控制的，自己能背的指标一定是在自己的控制范围内的。
如负责渠道的小伙伴指标跟负责运营转化的指标肯定不一样（如果都背GMV的指标对越偏后端的越不公平，因为他们的受渠道的限制）
这种一般是负责整个业务链条的Leader背整体指标，其他小伙伴主要背拆分后的指标，同时用整体指标辅助考核（如：流量的质量……）
3.3 如何搭建一个靠谱的增长系统？
从“增长”这个词火起来之后，好像很多事情都可以加上“增长”，相信小伙伴们或多或少也听过“增长系统”，“增长引擎”“增长模型”……这些词。
3.3.1 增长系统，增长引擎与增长模型的区别是什么？
在了解如何搭建“增长系统“之前我们需要先了解这些概念：
如：还以在线教育产品举栗子，GMV是一个符合指标，它是由：流量*转化率*客单价*续费率 构成的，而这个业务中就至少有3个模型：流量获取模型，转化模型，续费模型；
如：流量获取模型由用户画像，渠道筛选，推广策略，渠道管理等一系列策略构成……
是不是感觉有点像搭积木~
3.3.2 增长岗与传统运营岗位划分，产品岗位有什么关系？
“增长”在商业的语境中一般都是指的业务的增长，而在商业语境下带“增长”的词汇一般也是从业务视角去出发的，而“岗位”这个词则是从执行的视角出发的。
假设：某成熟的平台电商产品想提高DAU，从业务角度出发这个需求应该属于用户存留与活跃的模块，对标下行业优秀的解决方案，发现可以通过“养成游戏”实现这个需求。
把做养成游戏这个需求拆解一下，切换到执行视角，发现做养成游戏需要产品经理去写文档&画原型，需要设计师设计页面&交互，需要技术通过代码把需求实现。
当我们作为一个业务的负责人的时候，就不能再从执行的角度去看业务了，我们更应该关注的是目标，从业务视角去看目标，配置资源，搭建团队。
3.3.3 如何搭建一个靠谱的增长引擎？
搭建增长引擎的前提条件：
“增长引擎”一般指业务部分，而业务增长的前提是，能够稳定的交付用户价值。否则业务增长越快带来的负面口碑越高。
只要把你困惑的问题写在奶茶的腰封上，在心中默念5遍，揭开茶盖，属于你的答案就会浮现在眼前。
2018年1月，河南盟网络技术有限公司推出“答案茶”凭借34条抖音视频快速获得获得35w粉丝，117W的点赞量，同年3月热度达到顶峰，几乎可以与喜茶相媲美；
但由于供应链和加盟管理的问题，很难做到规模化交付，很快消失在市场中。
SO，稳定交付是搭建增长引擎规模化增长的前提。
3.3.4 一个靠谱的增长引擎长啥样？
一个靠谱的增长引擎是在一定周期内稳定贡献商业价值的模型（营收/用户），而要达到稳定贡献商业价值，至少要有3个模块：流量获取模型，转化模型，复购模型。
流量获取模型通过渠道推广策略获取流量 转化模型负责流量的转化（工具类产品是激活） 复购模型负责复购提高营收（流量越来越贵，很多产品用流量产品引流阶段甚至是亏钱的，需要通过高频次的复购，或者转化高客单价产品分摊营销成本）3.3.5 裂变能成为增长引擎吗？
我们前面定义的“增长引擎”是，在一定周期内能稳定贡献商业价值的模型。
“稳定”就意味着它应该是一个“定量”可控制，可预估的量。
而裂变的特点在于它的多级传播，且每一级都是变量，都是没法控制，在没有结束之前你永远不知道它能传播多少级，以及每一级的用户会有多少回流到我们的流量池中。
裂变的核心是老用户带来新用户，虽然无法成为一个增长引擎，但是它是一个很好的增长引擎增幅器，在渠道稳定的前提下它可以通过一些玩法以较低的成本带来新用户。
是否可以尝试“新带新”在渠道投放阶段就开始裂变？
这个叮当之前试过，在用户对品牌毫无感知的阶段基本不会参加活动。
在用户购买过“体验品”之后裂变可以获取用户，但是获取的用户质量比“老带新”的用户质量差十倍。把购买过体验产品的用户做为启动量裂变，最终转化正式产品的转化率是，只有购买过正式产品用户转化率的10%
3.3.6 流量，转化，复购先做哪一个？
根据不同的情况：
1）流量成本低，甚至0成本的情况下，先搞流量，再考虑模式
遇到机会：新平台扶持，获取其他搞流量的方式（成本低，时间窗口短），先搞流量，同时搞产品想办法把流量盘活。
2）正常流量成本，先把转化（甚至存留和复购）跑通然后再开始搞渠道
不同渠道的成本不一样，我们做的时候要先跑通转化，转化率做的越高，可选择的渠道就越多。
如：教育行业信息流9.9元体验课获客成本300+，这样算如果社群转化率做不到25%以上，ARPPU值做不到2800以上，这个渠道的ROI是很难跑正的~
3.4 增长的不同阶段需要哪些准备？
每一个产品的增长大致都会有4个阶段：需求验证，增长放量，精细化运营，新业务孵化。
3.4.1 需求验证阶段：
在这些在需求验证阶段除了打磨产品的交付之外，最重要的就是搭建整体的运营系统了。
整个系统最核心的是：流程和库，这两部分。
流程的搭建是为了固化在这个阶段探索中获得的有价值的部分，提高运营的效率。 库的搭建则是为了避免重复造轮子，把探索变成一个可积累的事情。其中主要有6种库：
素材库：素材库主要存放用户，产品相关的素材如：用户好评，用户反馈，用户痛点……用于后期推广物料的制作和产品的迭代规划。 数据库：这里的数据库主要存储用户相关，业务，竞品相关的数据，为业务的决策做支撑。 资料库：资料库主要是跟产品相关的专业内容，主要用于用户答疑，产品文案的支撑，新人了解产品的培训（如：少儿英语在线教育产品，的设计理念，背后关于儿童语言学习的理论支撑） 模板库：一些常用的物料（海报，详情页……），业务常用文档（合同，汇报模板……），可以做成模板避免重复造轮子，提高团队小伙伴的效率。 品控：品控是为了控制业务各个环节的下限，提高各环节的工作质量，具体形式如：VI手册&设计规范（统一设计风格）；评审&测试流程（提高决策质量）；各环节自检清单（提高执行质量）…… 工具库：工具库是为了提高业务的整体效率而搭建的，把流程中能够自动化的就自动化提高“搬砖”效率（如：自动回复，快捷回复，爬虫，批处理工具……）在增长的每个阶段，除了关注当前阶段的目标之外还要考虑下一阶段的事情，而以上流程&和库的搭建就是为“增长放量阶段”做准备，把内容，SOP，都准备好，到了放量阶段直接加人，加钱就OK。
3.4.2 增长放量阶段：
如果在需求验证阶段都准备的很好，那么在放量阶段需要重点考虑的就是怎么招人，以及怎么让新人快速上手业务。（具体见章节：4.1）
3.4.3 精细化运营阶段：
到精细化运营阶段，产品已经有了一定的用户 规模，在大规划的用户体量下，每个小环节的转化率优化都能带来不小的数据提升；在这个阶段我们主要通过用户的不同需求，或者用户的价值对用户进行分层分类的运营，提高用户价值，通过文案，页面配色，按钮样式……优化转化率，提高整体数据。
3.4.4 拓展业务阶段：
到了业务拓展的阶段，原业务基本也到了成熟期，甚至衰退期了，即便再怎么优化也很难带来业务的增长了；这时我们就要结合我们自身的优势考虑是否要拓展业务类型获取更多类型的用户，或者挖掘业务深度，占领更多的用户场景，提高产品价值。
如：1995年成立的亚马逊最初是在线上卖纸质书的，后来基于用户需求、投资仓储提升配送速度、布局数字化出版抢占内容高地，推出Kindle引发数字阅读革命，布局线下书店，进行线上线下一体化运作。
接着基于电商平台能力，业务横向拓展至图书、3C、母婴、服饰等领域，以及相继推出亚马逊开发平台、AWS云计算服务、Prime会员服务等纵深业务板块，通过多条业务产业链的“纵深价值”挖掘和“横向平台能力”的建设，打造了一张庞大的价值网，实现24年增长2500倍的指数级增长。
3.5 如何规划项目的推进节奏？
传统的项目推进方式会有两种，一种是串行的逻辑，一个模块好了之后才开始另一个模块（也叫瀑布流）；另一种是并行的逻辑，多个模块同时进行（也叫敏捷型）。
两种节奏各有利弊，具体需要根据场景选择。
假设：我们要做一个分销活动，需要在一周内开发完工具，准备好物料，并且上线
按照传统瀑布流的推进方式的话可能需要：运营先写方案，然后给产品提需求，产品再去梳理需求，画原型写文档，然后再叫上设计和技术，测试一起评审，评审通过后设计开始设计UI和活动页面，设计完成后开发开始编码，开发完成后测试开始测试，最后一起验收，但按这样的流程起码需要2周时间。
这时我们就可以采用敏捷的模式去做：
在前期先把最重要的20%给确定好，后面的能并行的就并行，实在不能并行的就串行推进，同时把自己的时间留出一些弹性，随时响应各个模块的问题。
4. 第3周：搭建业务，管理进度
在第三阶段要做的事情主要是，团队的搭建与管理，工具系统的搭建，项目进度的管理。
4.1 一个业务早期如何搭建团队？
4.1.1 选择：在业务发展的不同阶段需要什么样的人？
在了解我们需要什么样的人之前我们要需要先了解一个人的能力主要是由什么构成的，业务的不同发展阶段具有什么样的特点。
我会把能力从上到下分为四层：认知，底层能力，技能，经验。
越下层的能力使用频次越高，但下层的能力会受上层能力的限制，且越下层的能力生命周期越短。
【名词解释】
认知：认知是个体对客观世界的的信息加工活动，知道：为什么？是什么？怎么做？ 经验：是技能和在技能使用过程中获得的信息&体验（如：怎么用PPT画插画？包含：技能PPT的使用和经验用PPT画画） 概念：是人把所感知事物的共同本质抽象出来，加以概括，是思维体系中最基本的单位（如：熵就是一个概念，即从客观上，事物从有序走向混乱是必然的，而我们做的很多效率系统，管理都是在对抗“熵”） 信息处理：指信息的输入（搜索，挖掘，阅读，理解……），分析（定性，定量……），输出（写作，表达，，行动……）能力 技能：运用某一专业领域内的知识，技术，方法的能力；如：要做产品经理最基本的你得知道怎么画原型。 新工具&新环境：工具是指完成某个事情所需的器具，或者促成某一事物的手段；而新工具就是在新的环境发展出来的满足需要的工具（如：大到一门新的编程语言，小到能够完成某一需求的一个脚本&模板……） 应用场景数量&质量：“场景”具体化一下就是：何事，何人，何时，何地，何因；数量是指这些不同场景的数量，质量是指这些场景的规模（如：数据分析，处理1W条数据和处理100W条数据质量是不一样的；分析电商数据和分析社交数据的场景是不一样的）
在上面我梳理了4个模块的能力：认知、底层能力、技能、经验。
这几个模块的能力在任何阶段都需要，只是在不同阶段的优先级不同。
在需求验证阶段方向不确定，会经常变换，经验很难积累，底层能力和认知更为重要。
到了增长放量和精细化运营阶段，需要抢占市场，同时降低试错成本，那么技能和经验就会更加重要（可以降低试错成本）。
我们在了解人的能力层次之后，再根据业务阶段的特点和需求，按动机，个性，通用，专业能力梳理之后基本可以得到以下的一个岗位能力模型。
更加具体的就结合自己所做业务的行业特点，去写JD就OK了。
小技巧：看一个人的能力，最直接的可以看这个人的作品（项目，文章……），作品是这个人在这个领域中：认知，习惯，技能，经验……的集合。
4.1.2 渠道：怎么找这样的人？需要多少人？
怎么找这样的人？
优秀的互联网人都有一个特点，就是喜欢混线上的社区&社群，有较强的好奇心和表达欲，所以基于这些特点，我们可以从以下三种渠道去找：
垂直社群：如圈内一些产品&运营&技术大佬的社群（先找一下大佬们的公众号，或者买本大佬写的书，然后通过公众号&书找交流群） 垂直社区：人人都是产品经理，运营派……（很多作者都会留自己联系方式的，可以根据自己的需求找对应的文章，然后通过文章勾搭作者，或者勾搭作者的小伙伴） 圈内朋友内推：这种会更加靠谱一些，但前提的我们先梳理清楚需求，知道自己想要什么样的人在零一裂变的时候小伙伴们大部分都是因为了解鉴锋才加入的，比如叮当加入之前就已经加了项目部小伙伴差不多一半人的微信，已经做了好久的网友了……
以上几种方式可以结合起来使用，如果是一些高级的岗位也可以尝试一下专门做一类用户群体的猎头渠道。
需要多少人？
具体需要的人数需要根据业务不同阶段的工作量确定：
需求验证：需求验证阶段由于没有可量化的价值参考一般是尽可能追求“质量”下的基本岗位配置（如：运营岗，如果前提不追求速度的话可能只有1个内容运营，1个用户运营，做运营的无论哪个方向基本都会做一些活动，且前期流量不太大，活动运营也很难发挥出自己的价值） 验证以后：而需求验证之后有了稳定的数据模型，基本就可以计算出增加一个人能够增加多快业务扩张的速度，人效是多少？具体根据业务增长的速度增加就好。4.1.3 问题：早期加入的人在后期怎么发展呢？
看了上面部分的小伙伴可能会有一个疑问：既然业务前期和后期对人的需求是不一样的，那前期加入的人怎么办呢？
这可能很多2年以上工作经验的小伙伴都有遇到过的，这基本是我们在职业生涯种遇到的第一个岔路口，这个路口有3条路：
4.2 如何利用成熟的工具快速搭建增长系统？
在增长系统中主要有两大系统：流程系统，工具系统；流程承担的是把控业务质量的角色，而工具系统则是流程系统的载体，承担着提高整体效率的作用。
4.2.1 流程系统：管控质量
流程系统的核心有7步：收集信息—信息归档—规划方案—实施方案—测试自检—监控效果—反馈&迭代；每一步都有互相增强的效果，同时有每一步有一个结构化归档的操作，让知识变得可积累为业务赋能，加上迭代优化的闭环，可最大程度提高业务质量。
4.2.2 工具系统：管控效率
工具系统是基于流程选择的，以下这些工具是叮当常用的，由于篇幅所限，具体功能就不展开了，具体可以在模板文档中查看。
以上工具系统适合“需求验证”阶段的业务或作为“增长放量”阶段的补充，由于国内的互联网环境复杂性和SaaS成熟度，完全用工具还是无法支撑大体量的流量和精细化运营阶段的需求的。
需求验证阶段：最重要的是保证质量前提下的快速和低成本，工具完全可以满足 增长放量阶段：就会有一些定制化的需求，这些工具很难直接满足，这个阶段可以通过对这些工具接口的二次开发+自己系统MVP的开发满足需求。 精细化运营阶段：这个阶段除了一些非常成熟且影响不大的（如：调用第三方的编辑器模块……），其他基本都要做到自有系统中，这样才能更方便做测试，精细化运营管理。以下是叮当在做一款在线教育产品时搭建过的业务系统，可以参考下:
4.3 在业务的不同阶段如何做好管理？
4.3.1 筹备期：进度管理，素材库搭建
在项目的筹备阶段核心“管理”的核心是管理进度，在保证质量的前提下确保可以按时上线
在管理进度中叮当主要通过：协作工具，日志&复盘这两个个工具去管理。
协作工具：
叮当习惯在写方案的同时梳理“待办清单”并且把待办事项按模块归类，之后再看哪些需要串行，哪些可以并行，并结合协作小伙伴的排期整理到甘特图和项目看板中，具体可以用Excel或Teambition等项目管理软件实现。
项目管理工具有很多，具体使用什么工具还要看团队的习惯和团队的规模，一切以简单高效为核心。
日志与复盘：
虽然我们在业务前期做了充足的规划和准备，但世界总是另有安排，我们会在项目中遇到各种突发事件，或者规划之外的问题，如果处理不好就很可能延期，这时我们就需要一些快速反应的机制。
把一个业务拆分成不同阶段，每个阶段再拆分到日，周，在这个过程中快速记录和同步问题，以便及时解决和处理，且这些记录在后期梳理经验做SOP时是最好的素材。
叮当毕业后待过的两家公司都有写周报的机制，个人和自己带的小伙伴会写日志，并且做阶段性复盘（这篇文章就算我2年职业生涯的项目复盘）
注意：推行这些机制的前提是自己先做到，否则很难推行下去的
素材库搭建：
这里搭建的素材库主要是营销推广素材和运营转化素材，具体可能包含：用户案例，用户需求&画像，产品包装，产品素材……对于外部的素材可以通过竞品挖掘和用户调研获取，内部的素材可通过归类整理结构化，方便取用。
4.3.2 上线后：数据监控，竞品监控
数据监控：
数据监控的前提是有做数据埋点，能够获取到数据，数据主要分3部分：渠道数据（可通过UTM参数做渠道标识）；前端用户行为数据（可通过数据工具埋点：神策，GIO，腾讯统计……）；后端数据一般在数据库中，可通过一些数据表工具查看（如：easyreport）。
在数据监控方面，成熟的业务一般都有自己的BI系统，但BI系统更多关注的是全局的数据（对整个组织的） 。
一些细分的业务，或者是在业务的早期，数据类型变动比较大，还是以手动记录+在线表格工具统计监控比较方便。
叮当习惯用石墨表格整理&监控数据，表格的设计主要分4部分：
注释：注明维度中每个数据口径的定义，每个复合数据的计算公式（如：转化率） 维度与日期：横轴维度是用户转化路径中的关键节点数据&转化率，纵轴是日期，后期每天根据日期更新数据。 汇总：分阶段，分类型汇总（如：除了整体数据，叮当还需要了解每个月的汇总数据和已经转化的体验课订单数据，于是叮当就用SUM求和函数根据自己的汇总需求把对应的数据框进来） 核心指标：如GMV，ROI……通过公式写进去，放在最容易看到的地方，当每日的数据更新后这些核心数据也会随之变化（1个表中不宜放太多维度的数据，那样更新起来很麻烦，可建立多个表存储数据，同时建立一个总表汇总关键数据）竞品监控
竞品监控的核心目的是为了及时了解竞品策略，做出应对方案，叮当一般会用小号关注竞品的公众号，加入竞品的社群，添加竞品客服号，每天刷两遍看竞品推送的信息。
同时建立“增长案例库”培养团队关注市场，关注竞品的习惯。
4.4 如何做好团队管理&成员培养？
一般在一个组织内团队一般会分两种，一种是非项目制团队，一种是项目制团队，不同团队的管理方式也不一样。
4.4.1 非项目制团队
大部分公司都是非项目制团队，这种团队内是以部门为单位的，部门一般按岗位划分，会有上下级的关系，需要向下管理，培养新人。
对于新人培养我一般会比较关注“目标”与“能力”这两个维度，去分类，针对不同类型的小伙伴采用不同的管理&培养方式。
目标：对于长短期目标的清晰度（如：自己规划的职业路径，分几个阶段，在不同阶段需要获得的能力，达到的里程碑） 能力：做一件事的方法，技能，经验，效率……（如：写一篇软文）
用“目标”和“能力”这两个维度画一个四象限图，大致会有4种类型：
能力目标都很强：这种最省心，确定好核心目标之后尽可能给TA支持，在过程中只关注关键节点的内容和数据就OK。 目标强能力弱：需要帮助TA尽快的把能力补上，给知识体系，给教程，给攻略（前提是TA的底层能力和认知还OK） 目标弱能力强：需要帮助TA规划更长期的目标，这样才能激发TA的工作热情与动力 目标弱能力弱：这可能暂时不是我们需要的人。
关于成长规划方面可以参考叮当之前写过的“个人成长地图”系列文章；技能和攻略叮当在从来没有停止学习和收集。
如果有需要可以在“小叮当运营笔记”后台留言，需求比较大的话我考虑整理一下给小伙伴们。
4.4.2 项目制团队
项目制的团队跟非项目制团队的不同点是，项目制团队是以项目为单位的，成员大部分都是不同岗位的，作为这种项目的负责人，最大的问题就是沟通&协作，因为“有效沟通”的前提是你们的认知在一个频道上。
在这种场景下就需要我们不仅仅在自己的模块非常专业，还要对整个项目各个模块的工作有一个基础的认知，理解这个岗位的思维方式，工作流，需求的实现过程与原理，甚至可以学一些高频低门槛的专业技能（如：设计图改文案，画原型……），提高项目的推进速度。
5. 一些业务中的常见问题和做项目的基本原则
5.1 业务中的常见问题
5.1.1 沟通问题
如何跟上级&老板同频沟通？
关于与上级同频沟通也会有2个场景，一种是面对在自己负责的这个模块有一定专业认知的上级，一种是在这个模块没有专业认知的上级。
1）对于专业的上级
确定好自己需要关注的指标和层级，理解上级的意图，做好自己责任范围的事情的落地，并及时反馈信息支持决策。
2）对于非本专业的上级
加入前看老板预期是否合理？
如：那种动不动就要求0成本获取xx万高质量用户的，打扰了
加入后确定共同的语言体系，名词背后的含义，深层需求，各自的理念
如：“私域流量”有人理解的是做渠道拉新，有人理解的是做复购转化。
如何高效地与其他部门协作？
高效协作的前提是确定共同目标+互相理解+高效沟通
共同目标：在目标上达成共识，确保在沟通时双方的立场是一致的 互相理解：通过了解对方的工作流，指标，了解对方关注的价值，顾虑的地方 高效沟通：站在对方的视角考虑，及时同步信息，并基于反馈如：以前做产品时每次跟设计师协作，叮当都会用石墨创建一个文档，需求列出1234，并且标注优先级，加上待办格式，设计师改一个勾掉一个，基本不会遗漏需求
5.1.2 限制性问题解决
怎么排项目中的事件优先级？
长期规划：看其中的限制性因素，看哪些是可以并行的，哪些是可以串行的，同时起码留出1.2倍的弹性时间。优先处理串行中靠前的（前面确定了后面才能开工） 短期规划：看是否需要协作，是否可控，优先处理需要协作的，不可控的，先把需要协作的安排好，把不可控的通过多次确定边界变成可控的。项目中的一些限制性问题处理思路：
定义问题：这个问题属于哪个领域的？紧急不紧急，重要不重要？ 拆解问题：解决这个问题的关键要素有哪些？ 找参考对象：有哪些成功解决这个问题的案例？如：如做活动需要多个公众号分流分散风险，但一个企业资质只能申请2个认证账号（重要）；
于是叮当梳理了公众号认证注册的流程，发现核心在于“企业资质”（关键要素）；
叮当又去找那些注册了很多个公众号的产品，看他们是怎么注册的，然后发现风变编程，用户主体是不同的；（案例）
那么问题慢慢更加明确了，变成了：如何快速注册更多主体？
找注册过公司主体的朋友了解了一下，发现在阿里云上，如果不需要刻公章的话9.9就可以注册一个主体，营业执照包邮到家。
5.2 做项目的2个基本原则
聚焦：抓大放小
无论是一个组织还是个人，在任何时间，任何阶段资源都是有限的（现金流，时间），不可能把所有部分都做到完美，而应该根据动作与目标的“相关性”和“协同性”去排优先级，抓主要矛盾，不浪费资源。
如：我们要确定一个活动做不做，一个功能开不开发，就可以基于现阶段目标的“相关性”和“协同性“去做评估。
产品化：流程+库
通过把一些成熟的模块流程化，收集优秀案例，搭建对应的模板&库，不重复造轮子，是提高项目质量&效率最有效的办法。同时还可以把一些高频，可标准化的模块用工具或者技术，自动化完成，解放双手，降低人力成本。（具体实施可参考：4.2如何利用成熟的工具快速搭建增长系统？）
写在最后
以上所有的框架是一个相对理想的过程，但实际中我们遇到的往往是，我们需要短时间做出成绩，先去证明自己，然后才能推动更多的事情。
信任的建立是从一点一滴开始的，人都需要及时反馈。
叮当第1份工作是从负责举办公司年会之后才有更多机会去尝试的，后面做项目也是做出了一些数据不错的项目之后才有更多的项目机会的。
作者：小叮当，深耕用户增长领域的增长汪；公众号：小叮当运营笔记，欢迎交流
本文由 @小叮当 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
