打造初创公司产品业务平衡

在2017年5月14日的 2017厦门互联网技术社区大会 做了关于初创公司产品业务平衡的演讲。

背景

Product-market fit 是硅谷著名投资人 Marc Andreessen 提出来的一个概念。对于互联网初创公司来说,用户需求一直在变,技术一直在更新,往往很难在一开始把握住真正的市场需求。如果产品跑得比市场还快,很容易陷入一种“产品技术的自high”,虽然功能做得很漂亮很完美,但却没有市场价值。反之,如果产品迭代跟不上市场的需求,往往很容易被竞争对手超越或者用户抛弃。

PMF 概念理解起来很容易,但真正做到不容易。作为管理者的我们,如何拿捏产品每一步的形态和需求,围绕 PMF 不断前进呢?总结起来分为以下四个方面:

确定目标

每个公司、团队和个人都有自己的目标。从公司角度来说,必须抓住和围绕最核心的目标来推进。可以观测和收集的数据很多,但最核心的目标其实永远只有一个,称为北极星指标 North Star Metric。不同指标总会有好有坏,所以一旦太多太散,人会很容易会陷入一种乐观的自我麻痹:“这个月虽然目标ABC降了,但DEF涨了嘛,挺好的”。抓住公司最核心的目标并且不断总结很重要。

确定了长期的战略目标之后,要围绕着它制定每个阶段的小目标。这里特别想分享的一点是,大家都说现在是移动互联网的下半场,线上增长放缓或者停止,互联网成为各行各业的基础设施。所以很多互联网人开始投入到线上线下结合的项目中来,比如我们T社。如果你是互联网背景的人,除了思考产品的目标之外,还需要将产品目标结合到公司的核心业务目标中来,才不会出现产品目标和市场目标脱节的情况。

产品演化

确定了目标之后,终于可以撸起袖子干了。然而,小公司资源、人力不够,如何和大公司竞争呢?另一方面,市场和用户需求一直在变,怎么样可以切入到用户的痛点去做大做深呢?了解过精益创业的朋友应该听过 MVP 的概念。比如我们做一个功能的时候,最开始可以避免大而全,而是通过一个个足够小的产品功能去验证和摸索用户的真实需求。这是非常困难的一个过程,因为没有人能代表用户的真实需求,甚至用户自己。如果产品功能过于完美,会影响上线时间,但产品功能过于简陋又会造成口碑下降和用户流失。如何把握这个度是摆在每个产品决策者面前的重大考验。

Talk is cheap,接下来我们看几个T社产品迭代中的例子。这是我们第一版本的编辑器,由一个人在一个月不到的时间内开发完成。从UI的层面看,这是一个非常简陋甚至丑陋的页面。然而在创业的最初期,我们的订单更多是在微信里传图和下单,沟通成本高而且效率非常低。这个功能的上线很好地解决了下单者和供应链沟通的问题。

当我们开始面对更多C端用户的时候,我们优化了原有的编辑器版本,进行了更合理地排版设计,提供了更多功能和选择:

优化不会停止,我们又针对编辑器做了很多细化的功能,比如展示图案具体的厘米数、更多素材库、展示预估价格等等:

而对于移动端,因为初期来平台设计的用户主要是众筹的发起者或者团体订购的用户。相对来说他们对设计的要求会比较高,所以我们用以下方式引导他们来PC端完成设计和发布。今年我们上线了一件起订的功能,开放给更多C端用户,于是开发了移动端的编辑器。第一版本的移动端编辑器也没有做很多图案缩放、拖拽的复杂功能,而是提供简单的位置模板来验证和收集用户反馈,仅仅开发了不到两周:

我们再来看看后台的订单管理。最开始一版的订单管理长成这样:

后来我们有了自己的供应链,需要对供应链的每个环节进行更细致地分工管理。于是我们根据需求开发了一个简单的供应链生产管理看板:

很快地,我们的供应链无论从产能、场地面积、人员上都成倍地增长,原有的后台管理已经无法支撑起庞大的业务需求。这时候我们选择了第三方的专业ERP公司为我们供应链量身定制了一套ERP解决方案。虽然说之前的后台之后就停止使用,看似浪费了开发资源。然而在业务还没验证的初期,我们用最低成本地手段支撑了业务的发展,而这个过程中的经验和积累,也帮助我们缩短了新ERP的调研和实施时间。

初创公司如何和大公司竞争打出自己的优势?把每个功能和需求做到60分的产品一定是没有任何优势的。相反,就算其他功能简单一些,但有一个点能做到90分、100分甚至120分,才可以真正差异化和抢占用户的心智阶梯。比如我们最开始围绕T恤的定制,无论印花工艺、服装版型、面料都做了深度的挖掘和开发。在拥有这一优势和口碑之后,我们拓展了更多不同的品类,比如手机壳、抱枕、钥匙扣等,成为了一个更全面的定制平台。

技术演化

和产品一样,技术架构在不同时期也有着不同的目标。作为公司技术架构的决策者,你需要很清楚每个阶段的实际场景,抛开实用场景谈技术本身的应用是没有意义的。初期可能为了快速验证,可以速度优先,用一些轻量框架;中期对已经发现核心功能,可以做深做精;后期规模进一步扩大,需要更加分布式的架构。

还是来说T社的例子,最开始在只有一名开发(兼产品和UI)的情况下,我选择了一个自己熟悉全栈的框架 Ruby On Rails 来进行开发,快速做出原型积累了第一批种子用户。

随着公司的发展,我们发现一个问题,前台的产品我们每周会进行迭代,但后台管理很多时候需要可以及时发布。为了减少版本发布带来的影响,我们做了前台应用和后台管理的分离,前台产品每周迭代,后台产品可以随时部署,互不影响。

之后我们招募了更多产品开发的小伙伴。我们发现,前端和后端在一个产品需求上的沟通里耦合非常严重,经常需要互相沟通和互相依赖。另一方面,因为快速开发的需要,一些架构层面的设计没有深度地思考,导致功能的延展性没有特别好。这时候我们引入了一个前后端分离的架构,在每次需求开发的最开始,后端和前端需要一起思考接口的设计,输出文档,这样等于强制加入了一步思考架构的环节。确认好接口之后,前后端再同时进行开发:前端使用mock数据,后端提供接口。关于T社前后端分离的实践,可以查看 这篇文章

随着业务的扩张,我们需要持续开发更多大功能,这时候厦门本地 Ruby On Rails 工程师不足的问题成为了阻碍业务发展的瓶颈。为了解决这个问题,我们开始使用 Java 这门厦门本地人才储备更充足的语言搭建了一套新的后端接口。新的 Java 接口和原有 Ruby 接口以一种类似微服务的架构同时跑起来。而前端除了负责网页、后台,也开始研究小程序的开发。这样就进行了更加清晰的架构拆分:前端全权负责所有展示层面的功能,后端围绕业务和逻辑进行接口的设计,从而更好地复用。

敏捷迭代

理解了产品、技术的演化,那么如何保证每个阶段的产品开发都能顺利进行呢?我们通过敏捷迭代的方式,以周为单位进行跨团队规划,确定了以下的产品原型、UI设计、开发流程,并且定期总结:

团队管理

当然,人不是机器,再合理和完美的制度都会有变化的时候,特别在公司规模比较小的时候。那么如何保证不同团队之间的协作更加顺利呢?我觉得最重要的一点是让所有人理解当前的目标。一般产品经理对于目标会更理解,而只有设计、开发也都理解了目标,才会更好地在工作中找到激情和成就感。另外,团建也非常重要,有助于竖立一个信任的跨团队关系。创业公司里的每个人更像是一支部队或者球队里的战友们,需要的是互相支撑和cover,也只有这样,在总结的时候,大家才能从解决问题的角度而不是互相指责。

对于团队内部管理,我们有幸招聘到了一位非常资深的HRD来规划。每位员工都有一个完善的成长规划和晋升机制。当然,除了外在的激励,内在的驱动力也很重要:需要真正认可公司的目标和愿景。

反馈收集

功能上线之后,我们可以通过很多现有的工具来收集用户的反馈。感谢互联网时代,现在很多轮子不需要我们自己造了。

一些大公司会用灰度发布和A/B测试的方法验证用户需求。而对于创业公司来说,用户数不多的时候未必需要这样,反而可以通过一些现有的例子里进行借鉴和学习。比如做一个下单模块,就可以参考淘宝、京东、一号店等,因为大公司已经做了很多深度地分析和验证来做这些功能。要善于利用“巨人的肩膀”。

总结

最后,再总结一下为了实现 PMF 的以上四步:

分享一句很喜欢的话,对于很多产品经理、工程师、设计师来说,大家很喜欢也很享受追求完美的过程。然而对于初创公司来说,时间和速度是最重要的事儿,那么就不可避免地需要有所取舍,一定要抓大放小。

注:keynote中图片部分来源于网络,截图中展示的T社数据皆为测试环境的假数据