你以为的协作，只是拉个群发周报
很多公司对增长团队协作的理解，还停留在“把不同部门的人拉进同一个群，每周开一次进度会”的层面。
别搞虚的，先把责任边界钉死
扯来扯去的甩锅局，本质上都是责任边界没钉死。 之前接触过一家做企业服务的团队，之前每次做免费转付费的活动，都要闹一次矛盾：运营说自己负责邀约用户，已经把人拉进活动群了，转化率低是因为付费页的吸引力不够；产品说付费页已经改了三版，转化率低是因为运营邀约的都是低意向用户，根本没有付费意愿。 后来他们改了规则，每次增长项目启动前，先定一个专属的结果负责人，这个人要扛整个项目的最终指标，不是那种只负责催进度的项目经理，是真的要对结果负责的人。然后所有子任务，都要在启动会上说清楚交付物、交付时间，还有交付物的合格标准：比如运营要在活动前7天，把符合要求的分层用户名单同步给产品，不能随便拉个全量用户列表就交差；产品要在活动前3天，把所有付费页的版本调整完给数据组；数据组要在活动上线后，按约定的频率同步各渠道的转化数据，出异常第一时间通知所有人。
小团队的协作，别学大厂搞复杂流程
特别离谱的是，很多十几人甚至几人的小团队，非要照搬大厂的增长协作流程。 什么OKR要对齐三遍，什么改个文案要走三个评审，什么所有的沟通都要发邮件抄送相关人。本来半天就能做完的事，光走流程就要花3天，等所有审批走完，热点都凉透了。 小团队的协作核心是快，根本不需要搞那么多虚头巴脑的东西。每天早上10分钟站会，每个人只说三件事：昨天我交付了什么，今天我要做什么，我需要谁配合什么。所有的规则、交付物、遇到的问题，都放在一个共享文档里，所有人随时能改，随时能看，不用翻聊天记录找历史消息。 还有个特别容易踩的坑：不要搞“垂直汇报”的割裂。比如增长团队的运营，本来是向增长负责人汇报，结果还要听原来的运营总监的指令，两边的要求不一样，夹在中间的人根本没法干活。要么就把人彻底划到增长团队，统一向增长负责人汇报，要么就明确两边的指令优先级，别让一线的人夹在中间当夹心饼干。最后说个容易被忽略的细节
很多公司的协作机制，都是老板坐在办公室里拍脑袋定的，从来没问过一线干活的人怎么想。 比如你定了每周一要开2小时的复盘会，但是一线的运营周日晚上刚投完一波大流量，周一早上要盯一上午的数据，根本没时间准备复盘的材料，那这个会开了也是白开，大家都是对着PPT念套话，根本说不出真问题。 好的协作机制，从来不是一成不变的。小团队本来就是要快速迭代的，今天试了这个流程不行，明天就改，不用等什么季度复盘。每个月抽1个小时，跟增长团队的普通成员聊一聊，问问他们现在的协作流程哪里不顺，哪里可以简化，比你坐在办公室里定一堆没用的规矩有用得多。 其实说到底，增长团队的协作机制，从来不是写在员工手册里的漂亮话。 它是能让干活的人少扯闲篇，少背锅，能一门心思扑在把增长做上去上的规矩。你要是现在还在为团队甩锅、上线慢、转化掉的事发愁，不如先把你拉的那个几百人的增长群翻一翻，看看上次出问题的时候，到底是谁没交东西。作者|商讯
排版|商讯
审核|乐乐