《高可用架构·中国初创故事(第3期)》一会会:一个产品经理的创业方法论

简介:

本节书摘来异步社区《高可用架构·中国初创故事(第3期)》一书中的第1章,作者: 高可用架构, 更多章节内容可以访问云栖社区“异步社区”公众号查看。

会会:一个产品经理的创业方法论

高可用架构·中国初创故事(第3期)

q3

会会的融资过程很传奇,李翔昊拿到经纬王华东的天使投资时,刚开始产品研发,甚至连公司注册都没有完成。一个尚处于设想中的产品可以获得知名VC的投资,李翔昊在职业社交领域多年积累的经验和思考起到了关键的作用。创业之前,李翔昊在人人、大街有多年产品设计和项目管理经验。作为曾经的企业管理者,现在站在创业者的角度,他对管理方式,开发节奏,产品设计有哪些思考和见解呢?

拒绝数字的诱惑,耐心打磨产品
今天的中国互联网,用户推广是一件成本很高的事,有统计称一款早期产品的真实注册用户成本接近10元每人。在如此高成本的压力下,“会会”却设置了严格的审核机制,为了追求高质量的用户体验,在审核注册用户的资料时会把将一半已经注册的用户过滤掉。在谈到竞争压力问题(数据要好看)时,李翔昊说:“团队内部也会有这样的意见,比如把用户注册的门槛降低一些,用户量上去了,这样也好去融资。这个过程中要尽量说服团队,用各种方法去佐证自己是对的,一起耐心地去做。”

做产品不能追求表面数字,李翔昊以社交场景中的例子来说明,“social graph(社交图谱)的产品设计常以用户关注数量的增长作为主要目标,为了追求好友数的增加,一些产品在设计上甚至会误导用户关注没有兴趣的人。结果就出现了这样的现象:好友越来越多,但是活跃度越来越低。思考背后的深层次原因,以增加好友数为核心的产品设计忽略了本质的东西,即关注的增长是不是能有效地提高互动。无效好友的增加,长远来说导致信息有效性越来越差,感兴趣的内容命中率越来越低。因此好的产品需要对业务有实际的理解”。

在大家都在拼命抢山头的时候,李翔昊坚持打磨一款基于真实职业社交关系的“慢”产品。尽管他承认自己也经常感到焦虑,但接受媒体采访时,他表示:“这可能会耗费比较多的时间和精力,但是一旦建立,成效将是巨大的。”投资人对李翔昊的支持和理解,是让他最感动的。“华东(经纬投资人)对社交产品很有研究,他一直跟我说,早期你不要迫于压力,太看重注册用户数,而更应关注用户真实使用时的口碑。”

作者最后引用李翔昊在朋友圈里的话:“‘但凡移植美国互联网的中国产品,都会走到南橘北枳的境地,中国职业社交现在的玩法还是太粗暴,市场验证的周期也不会这么短’,一名关注这个行业的投资人表示,在这个跑道上,耐得住寂寞最重要。”

有分歧可以从长计议,关键是分清大小问题
如今 “会会”上各种邀约、沙龙活动相当活跃,并已推广至上海、成都、广州等多个城市。每周还会推出一个重量级的沙龙活动:从蓝驰创投的下午茶,到“桔子娱乐”创始人、前“时尚芭莎”CEO唐宜青的老板请吃饭活动,保持了高水平的运营。“会会”上线时间并不长,但产品功能相当丰富,包括邀约发布、查看、报名,私信、群聊、通知等,已经实现相对完整的产品逻辑,整个使用流程也相当流畅。

一个初创的团队在不长的时间怎样做到兼顾研发和运营?相对多的创业公司选择了996的方式。但李翔昊表示自己并不急于求成,尤其要避免决策的专制,反而经常花很多时间和团队沟通。他说:“如果一个问题暂时说不通,就慢一点,不要强求立刻达成共识。可以多沟通几次。关键是区分是大问题还是小问题。小问题上慢一点对节奏不会有太大影响。而大问题应该是早就认真思考和团队充分讨论过,等到执行时已经成熟不会有太大分歧了。”

对于如何激励团队,李翔昊的看法是,能够调动员工的积极性,比小事情上争对错更重要。他说:“小事情上我也挺容易被说服的,让团队自发地去想问题,哪怕出了一些小错,也可以很快被纠正。即使是在创业后我更关注结果,也会这样去思考问题。大部分人是逃避责任,或者懒得去思考。如果真的有人提强烈反对意见,那恰恰是应该更好地去调整自己或者反思的时候。”

创始人说
产生做“会会”这个产品的想法时,我还在大街网。去大街也是因为我有做职业社交的情结,国内也没有其他做得好的公司。大街里面有一些比较熟的人,上一个参与的创业项目做不下去了,就去了大街。

我是一直在思考职业社交的切入点、突破点。从经验看来,招聘是很难积累社交关系的。那会儿已经有脉脉了,就是这么个路子,我感觉不对。

今年2月份的时候,发现了一个新上线的App叫“请吃饭”。3月份的时候,又在想新的idea,又看到了“请吃饭”,心想就深度体验一下吧。后来还真约到了一个妹子,见面过程不说了,总之因为约到的人不太对,感觉不是很好。但突然觉得这个模式挺有意思的。陌生人,直接见面聊,可以选离得近方便的报名参加,少了很多磨叽的环节。男人们肯定主动,姑娘们呢,也顺便蹭饭什么的。后来和同事闲扯聊天,说这个关系可以用到招聘上来啊。主动的是招聘方(=男人),请够档次的候选人(=美女)吃个饭,其实挺好的。大家不是都愁找不到好人么?熟悉中高端招聘业务的应该知道,对于候选人来说,都不会投简历,也不太会直接去接受面试。一般大牛,都是朋友推荐介绍给招人的老板,先吃个饭喝个咖啡认识认识,看看合不合适,再谈其他。很多时候,心想,不为求职,多认识个老板交个朋友也好。对于求贤若渴的老板来说,认识个大牛,有机会游说也就行了,至少还能交流下业务什么的。

可惜的是,这个主意,当时在公司内部,虽然被很多同事认可,却并未获得老板的支持,内心各种怨念。同时,“老板请吃饭”的念头挥之不去,觉得依靠这个直接约的点子去做职业社交或者高端招聘,其实是个很好的点,甚至比做异性交友、约炮更好。

当然,即便“请吃饭”那个App,从一个产品人的角度看有很大提升空间,而且异性交友起用户量更容易,我也从来没想过抄一个“请吃饭”的念头。一来不喜欢做全版抄袭跟风的事,二来确实对做异性社交产品没太大兴趣。

于是心里萌生了自己创业去做这个点子的想法。

后来和认识的做投资的朋友聊了聊想法,他也忽悠我出去创业就做这个。

4月份,打定主意出去自己干了!一边做调研验证自己的想法,一边准备组织团队,一边把产品框架原型做了。


q2

不过3~4月份这段时间,随着对产品思考的深入,我决定抛弃“老板请吃饭”这个概念,坚决不做招聘这个业务;而是在这个基础之上做“吃饭聊聊”这个概念的职业社交产品,也就是后来的“会会”。

话说“会会”这个名字,也是我花了2个多月的时间琢磨才想好。发现没有重名、工商注册可行,最后才决定的——并快速申请注册好了商标知识产权。

5月份,团队的小伙伴基本确定。找到了之前的同事,她在开自己的设计工作室,就把第一套UI外包了。

然后我开始准备找钱。这个时候压力还是很大的。因为团队的小伙伴基本上都被你忽悠动了,决心辞职了。如果没投资我的积蓄很难养得起团队,不能让他们和你喝西北风啊。

见了大概十来个投资经理/合伙人,有几个谈了第二轮,基本有些眉目。

6月中旬的时候,团队的小伙伴们都辞职出来,基本凑齐了人能做出iOS产品。更重要的是,这个时候,投资终于谈妥了。感谢投资人在我还只有一个idea一个简陋得不行的BP的时候,就给予了我信任,给我一笔天使投资。

第一版UI设计也完成了,开干!嗯,那会儿还没有LOGO,用了一个很丑图标占位,囧。


q1

7月份的时候,偶然拉到一个远在深圳的小伙伴回京和我做Android版本,以及另一个随之而来的小伙伴——只是他俩都算是新手。后台开发差不多可用了,iOS有了雏型。

8月份,借了1个Android工程师,和新到岗的2个小伙伴一起开发。

9月份,iOS和Android都已经有了demo。然后从9月~10月,陆陆续续找了一些朋友当小白鼠,让他们使用提供各种反馈意见。我们接着改进产品。10月16日,第一个版本通过App Store审核。但因为我觉得产品还不够好,所以没有对外发布,接着改进。

产品的设计,不能只考虑功能,还得照顾到运营。尤其是社交产品,必须要有足够的用户,才能产生吸引力和价值。所以一直到11月份,配合运营的规划,还做了一些产品的功能和后台的东西。为产品添加引导广告位;另外,我们的报名可以分享到微信,而且可以不用下载App,在微信里就能完成报名。一方面便于产品里的邀约扩散传播,另外也增加了用户价值。

直到11月22日,我们觉得能拿出去见人的iOS版本通过审核,在23日周日才对外公布。

到现在,已经有数万注册用户,几千人在会会上约到了合适的同行结识为朋友,其中有不少甚至成为了创业的合伙人。

到现在,很多想创业的朋友一直觉得好奇,到底是什么让你会对这么一个初听“荒诞”的点子充满信心,能下定决心出来创业的呢?我想说,可能还是做产品经理的时候,比较正确的做事方法论,让我有了较好的基础。

其实在有了这个产品idea之后,一直到刚开始创业做产品的很长一段时间里,我做了非常多的用户调研工作。在职业社交的用户群体当中,我做过近百人的用户访谈。具体到“会会”这个产品的概念上,我结合微博约饭局的假设使用场景,打电话聊过将近40人,做过较为充分的互动问答,调研出的结果表示出可行,我才敢拉上认识多年的伙伴,出来创业。

之后为了做运营推广,我们还做了两百多人参与的调查问卷……而到现在,产品除了考虑新的功能迭代之外,最重要的工作是从各种渠道搜集用户对于产品(以及同类产品)的反馈。

相关文章
|
11月前
|
安全 架构师
【企业架构】什么是 TOGAF? 企业架构方法论
【企业架构】什么是 TOGAF? 企业架构方法论
|
机器学习/深度学习 SQL 存储
实时特征计算平台架构方法论和实践
在机器学习从开发到上线的闭环中,实时特征计算是其中的重要一环,用于完成数据的实时特征加工。由于其高时效性需求,数据科学家完成特征脚本离线开发以后,往往还需要工程化团队通过大量的优化才能完成上线。另一方面,由于存在离线开发和工程化上线两个流程,线上线下计算一致性验证成为一个必要步骤,并且会耗费大量的时间和人力。
903 0
实时特征计算平台架构方法论和实践
|
5月前
|
设计模式 SQL 安全
淘东电商项目(67) -互联网安全架构设计(方法论)
淘东电商项目(67) -互联网安全架构设计(方法论)
36 0
|
7月前
|
机器学习/深度学习 前端开发 TensorFlow
|
7月前
|
架构师 数据可视化 测试技术
架构设计方法论和思维
架构设计方法论和思维
|
7月前
|
存储 架构师
企业级业务架构设计:方法论与实践 学习笔记
最近在项目中涉及到这一领域,也借着这个契机做一次对企业级业务架构设计的深入学习。
385 0
|
10月前
|
运维 架构师 数据可视化
架构设计方法论
架构设计方法论
264 0
|
Cloud Native
《云原生时代的架构方法论_ALPD技术实践-张刚》电子版地址
《云原生时代的架构方法论_ALPD技术实践-张刚》PDF
127 0
《云原生时代的架构方法论_ALPD技术实践-张刚》电子版地址
|
存储 缓存 负载均衡
RPC架构设计方法论(完结)
通过一种宏观的视角设计一种灵活的可扩展的RPC架构 分块介绍服务发现、健康监测、路由策略、负载均衡、异常重试的解决方案 如何优雅的启动和关闭RPC服务,以及如何通过熔断限流及业务分组来增强架构的鲁棒能力
RPC架构设计方法论(完结)
|
存储 Cloud Native 架构师
大咖说·图书分享|数字化转型架构:方法论与云原生实践
在数字化转型过程中,如何做好企业架构规划?本期内容,阿里巴巴架构师王思轩博士将携新书《数字化转型架构:方法论与云原生实践》展开分享。
461 0
大咖说·图书分享|数字化转型架构:方法论与云原生实践