经验之谈:初创公司如何实现规模化增长?

猿团 | 2016-01-13 14:38:52

本文的作者来自Intercom创业团队,他分享了在过去18个月中,规模化过程中的成系统的做法。所有初创公司都能够从中找到适合的内容。让我们一起看看别人家的公司是怎么正确实现规模化增长的?

文章略长,请做好准备:

创始人面临的新问题:在公司不断的发展阶段,公司团队能否做到及时的调整?规模化的同时如何能够保证竞争力不会被影响?

反面教材:单纯出于有效控制的目的而设立层级纷繁复杂的治理结构,盲目扩张招聘使得自己的文化越来越走形,僵化呆板的行政体系拖慢了整个公司前进的步伐。

那么问题来了,在这个过程中正确姿势应是什么呢? 

之前Spotify 在2013年分享了它的故事,除此之外似乎很少有公司站出来现身说法。也许是因为这个过程中肯定会有冲突与混乱,没有人会愿意把这些全部放到公众平台去说。

如今,我们Intercom团队在学习了无数抽象的概念,听取了各种顾问的指点之后,也走过了这个阶段,并且愿意将这一切拿出来分享。在过去的18个月中,我们在规模化的进程中学到了很多,如果分一下类的话就是四个板块:

1. 一套制定决策的原则 

2. 清楚的责任划分 

3. 简单、透明、且全面的路线图 

4. 目标设定文化

另外还要补充下面的几点内容:

1. 我们所分享的内容并不一定适用于每一家公司,它紧紧跟我们的文化相联系。作为创业者的你也应该有属于你自己的文化,于是决定了你所做的事情会和我们的会有些出入。

2. 我们的做法也绝对不是完美的,我们也在不断地完善修正,甚至于你在读到本篇文章的时候,我们还将把一些环节进行调整。

3. 整个方式只是对应,适用于我们当下的团队规模。当我们的团队远远没有这么多人的时候,那是另外的一套做法;当我们的团队人数再翻一倍的时候,做法又会不一样。

最后,我们真诚的希望读者能够从中找出属于自己规模化扩张之路。


1、我们自己拟定了一些原则,这些原则指引着每一个决策。

为了让产品团队得到成长,成员需要一套价值准则,以确保决策质量,也避免和我们团队的信念发生根本性的冲突。下面就是这些关键性准则:

小步子前进胜过大步子跳跃——快速、频繁的迭代更新是臻于完美的途径,我们需要打造运行速度最快、最小巧、最简洁的产品,要在其中迅速学习,调整,不断将产品推向更加符合市场的方向。我们确保每一次的更新都会给客户带来价值。团队成员相互督促,确保自己永远不会把时间浪费在不重要的事情上。

当我们在谈“开发”,我们在谈的其实是“周目标”和“日目标”。

我们深信Intercom捕捉到了一个市场先机,一个被所有人忽视的市场空白。但是我们也告诫自己不能沾沾自喜,现在要做的事情是和时间赛跑。我们把任务细化下去,从周目标再分解到日目标。每一个人在当天都知道今天要完成什么,他们今天所做的事情将对周目标,以及最后的产品终极发布带来怎样的影响。

面对面的协作大过一切——我们深信要让事情进展的更快,那么必须大家都必须共处一室,面对面地沟通交流,以及协作 。两个站在同一块白板跟前的人往往会碰撞,激发出更多的想法,这比远程工作等其他工作形式要来得有效果得多。远程工作确实也有它的优点,但是在论及决策的快速和有效性上面,它就不占据优势了。正是出于这个考虑,团队成员永远是在一个房间里并肩作战,我们的原则就是:一旦你有问题,扭过头来就可以看到你身边的同事。

软件开发一切从简——跟在白板上写写画画,贴一些便签纸相比,用软件来开发软件肯定要慢很多。我们的开发流程一切从简,利用最少的软件数量来把工作完成。如果你要开发一个产品涉及了Google Docs、Trello、Github、Basecamp、Asana、Asana、Slack、Dropbox、Confluence等一系列软件,那么肯定这其中哪里出问题了。

结果的重要性要大于计划——计划当然在产品开发中扮演很重要的角色,但是最后我们还是以结果为导向的。 真正优秀的团队能够随时消化新的信息,并且做出行动上的调整。他们在执行计划上面永远保持开放式的思路,随机应变,应时而动,其目的就是在不变的时间框架中达到预期的结果。

2、我们要求更加清楚的责任划分

我们是一个小团队,每一个人负责Intercom的一部分内容。这些人包括了一个产品经理(PM)、产品设计师、工程负责人、2名到4名产品工程师。有鉴于此,我们需要对每个人负责什么内容做到无比的清楚透明。最后,我们列了下面这个表单:

如果对某个亟待解决的问题分析不正确,那么这就是PM的责任。他要确保正确、合适的研发;

如果设计没有解决问题,那么这就是设计师的责任。他要确保能够理解研发和问题;

如果设计解决了问题,但是并不适用于Intercom,没有达到最满意的效果,那么这同样也是设计师的责任。他要确保他能充分领会我们的价值观、产品工作模式以及一些原则;

如果工程师没有按照设计师的设计开发出来产品,又或者延误了递交时间,那么这就是工程师的锅。他要确保充分理解现在正在解决的问题是什么以及相应的设计方案,在写代码之前做出合适、恰当的计划;

如果他开发出来的产品充满bug,支离破碎,那么这是产品经理的责任。他需要了解团队测试产品时的应用案例与情景;

如果团队花了太长时间在修复Bug,在每一张路线图上并没有带来价值,这也是工程负责人的责任。他要确保每一个项目都会给代码的整体质量带来提升;

如果我们都不明白这个软件是怎么服务用户的,那么这是产品经理的问题。他要落实产品开发成功与否的标准,是否成为用户的工具;

如果它没有解决问题,那么这同样是产品经理的问题,他要确保有一个产品提升计划;

产品开发团队自然会存在一些灰色区域,需要一些跨部门的协作才可以完成。这方面需要团队成员自行解决。而当分析各个板块花了多少宝贵时间来完成工作的时候,这个责任划分的界限就会非常清楚了;

三、我们执着于简单、透明的路线图

我们的路线图会告诉我们,在接下来几个月的时间里我们将开发的东西是什么,它一共有三个清楚的时间框架:

1、接下来4个星期到6个星期的工作计划安排的紧锣密鼓,并且会有具体的产品开发出来。

2、在接下来的几个月里,会有一个更加宏观的计划,简要叙述了目前项目所遇到的问题以及机遇;

3、在这几个月开外的时间里做出预测,更加松散的想法,与我们的愿景紧密契合。

我们有可能开发的东西会全部写在一个单子上,由产品经理负责管理,定期由团队进行审核。

我们的路线图能够产生是基于下面的三个基础:

1、我们所相信的。这个基础是自身判断,并不是调研后的结论。 它集中体现在团队领导层的一些共识以及预测上。这是我们所能预见的一些趋势以及我们头脑里盘旋已久的一些想法;

2、从客户那里获取到的定性评价,这些评价是通过下面的三个渠道汇集而来 :

(1)我们有专门的调研团队,会专门深入到客户征求他们的答案,产品经理也会跟客户展开沟通,我们的产品经理会使用自家产品 Intercom 来跟客户对话。

(2)还有一些不是主动获取,而是被动接收到的反馈。客户会主动地通过Intercom把自己的意见建议发送过来。一支名叫“Customer Sucess”的团队负责每周收集这样数千条反馈信息,并将它们分门别类。这些信息会经由产品经理审核,添加到我们计划在未来开发的功能清单中,有一些甚至会添加到路线图上。

(3)从销售谈话中获取的反馈。我们的销售团队会把很多记录分享给产品经理,于是产品经理就能够明白人们在选择应用产品时的门槛出现在什么地方。我们的路线图会在每个月被销售负责人和产品开发负责人进行审核,以确保曾经发现的障碍现在都被剔除掉了。

3.  基于我们目前的产品性能给出量化数据

量化数据的基础有两个:

* 在每一个小项目上拟定出来的成功评判标准

*  产品和团队级别成功指标

产品开发策略重心 ——目前我们有8个重心,囊括了我们所做的一切工作。为了让大家都知道这些重心,我们专门为每一个都准备了一块板子,挂在我们办公室的墙上。


每一块板子都会有一个题目,一个描述区域,上面写清楚我们为什么觉得这个角度是非常重要的,以及我们正在解决的问题以及我们所能够捕捉到的机会,并且还会有一些解释性概念。请注意下面的这个写着整合的板子其实已经过时了,我们现在已经完成了跟Stripe、Hipchat、Mailchimp、Slack、Zapier等产品的整合。

团队目标——每一个产品团队都会有一个目标,这是一个需要花几个月时间来实现的战略目标,每一个战略目标集合起来就形成了我们的产品目标。

战略目标之间会有一个“真空期”,在这个真空期里,产品经理会负责撰写一个名叫“Intermission”的报告(如上图所示),它就一页纸,非常清楚的指出目前我们正在解决的问题是什么,这个项目的范畴是什么,我们该如何评价这个项目的成功。这张纸上不会提到解决方案(解决方案出现在后续时间中)。这个Intermission的报告主要是让所有人都明白我们现在做的事情以及动机。

在Trello中的路线图——因为我们发布周期很短,步子前进的轻快细碎(更新周期最短是1天,最长是2个星期)。我们在同时有可能有5到6份Intermission 要撰写,有10个大小不一的项目正在研发。为了做到这一切是井然有序展开的, 我们使用Trello来组织这一切 。 所有在Trello中的内容都是由产品经理来管理。为每一次发布更新我们都会准备一张Trello卡片。如果某些功能表现不如人意,我们会在上面添加红色标签,以保证对任何不理想的工作成果持续跟踪。

在Trello中的Intermission卡片——Intermission报告会专门在Trello里面有一张卡片,卡片直接指向Intermission文档。它里面还包含了一张清单,确保我们没有遗漏任何事情。 清单只是为了提醒我们一些事,并不是待办工作 ,有些时候我们仅仅会因为知晓了就在清单上划勾,而不无需做任何实际工作。

在Trello里的更新卡——每一次发布更新都会在Trello里面有一张卡片,这张卡片会链接到任何支持性文档(用来解释产品)以及设计决策上面。每一个这样的卡片都含有一份清单,清单包含了5部分内容:设计、开发、QA、测试、最终发布。

还是跟上份清单一样,这个清单只是为了提醒,而不是指引实际工作任务。

四、目标设定文化

周目标与Hutsle工具——为了保证我们时刻目光不偏离,保证自己时刻在轨道上,周目标的设定对于每个产品团队来说都必不可少。这些目标是从我们的路线图衍生而来,其中包括了Bug排除、系统提升等让我们在未来进展更快速的工作内容。另外,我们还内部开发了一款名叫Hustle的工具,能够帮助我们持续追踪目标。它通过Trello API直接从路线图中拉取内容,通过Github API拉取Bug公开汇总。这一系列的做法都是为了保证各支团队都能设定好周目标,并且负起责任。


日目标以及白板——为了达到我们的周目标,团队里每一个人都会有日目标以及日目标之下的次级目标。这也意味着每一天都很重要。每一个产品团队都有一个白板,以便追踪日目标的完成情况。每天早上晨会时就会把白板上的内容完成。

每周进展汇报——每个星期五的下午五点,我们所有人都会齐聚餐厅,坐在一块大屏幕跟前,大家手边放着啤酒瓶,每一个团队都会派人上去向大家展示这个星期的工作成果。

这再一次体现了我们是在跟时间赛跑。我们所有的目标都被细化成为了具体实在的,具有可行性的小的工作内容。

此一时,彼一时:上面的流程已经变了

我们不断地改进产品开发流程。每一个星期我们都在学习新的东西,上面是我们截稿的时候所学到的内容,但我们不会停留在此处。这些宝贵经验是我们一点一点实践出来的,有的时候还是绕了弯路,付出一些代价才换回来的。

在一个快速成长的公司里去开发产品,应对环境,阶段的不同迅速做出调整,这确实是一个不小的挑战。我们希望你能够从我们的文章中学到一些东西。(出自/Medium、编译/创见花满楼)

  • 城市合伙人