“大学生社区”项目复盘总结

“大学生社区”项目复盘总结

这一篇复盘一下“大学生社区”这个项目。

项目背景

2017年发生了这么几件事儿,一个是大学生裸贷新闻不断,经过一系列整顿后,非正规军被清除出象牙塔;另一个就是数据显示,花呗成为了大学生提前消费的主要信贷产品,对于信用卡而言是一个潜在威胁。2017年底信用卡中心大学生流量经营项目组成立,项目组背负着探索大学生经营方式,储备潜在客户的历史使命。

前期团队经过大量的头脑风暴、用户调研访谈,使用微信群和小程序进行了一段时间的MVP验证,在2018年的秋季开学季前,定下了“大学生社区”这么一个方向。也许看官您对前后两段话的逻辑关系有点茫然,定方向这件事情,找个时间专门写一写。

项目历程

yaktalk就是在这样的背景下诞生的,产品第一版的slogan是“分享我的大学生活”,我们希望建立一个大学生专属的社区,大家在社区中分享自己的生活百态,聊聊自己学校的八卦,和有趣的人成为朋友。整个产品的历程,基本上是沿着社区向社交发展的。

近40人的团队有来自各部门的同事,也有从虎扑、京东挖来的专家,大多数同学其实都没有社区社交产品的经验,大家在两年的时间里共同成长,共同进步。因为一些客观原因,项目在今年年初关闭了,这也算是我真正意义上参与过的从0到1的项目,更因为项目在金融体系下运作,这也给了这个项目一份独特的意义。

回顾这两年的经历,做了很多牛逼的事儿,也做了一些现在回头看也许是错误的决策,为了给以后的工作长长记性,从一个全程经历每件事情的核心成员的角度,进行复盘与总结。

这里先把产品几个关键的版本说明贴一下:

2018年8月30日 - 1.0.0版本
信息流
动态发布
评论互动
个人主页
通知

2018年11月21日 - 1.1.0版本
搜索
推荐好友

2018年11月28日 - 1.2.0版本
圈子

2019年1月25日 - 1.3.2版本
校园身份认证
图片水印

2019年3月2日 - 1.4.0版本
首页改版

2019年3月12日 - 1.5.0版本
私信

2019年4月27日 - 1.5.7版本
任务中心

2019年5月26日 - 1.6.0版本
附近动态

2019年5月31日 - 1.6.1版本
发现身边

2019年7月29日 - 1.7.2版本
讨论

2019年8月31日 - 2.0.0版本
全新学校主页
全新个人主页

2019年11月3日 - 2.1.2版本
每周CP

从功能的发展路线来看,我们可以看到两条线,一条是前期围绕着社区的,针对内容生产者和消费者的功能完善;另一条是中期围绕着社交的,在私信功能推出之后,设计了很多社交导向的功能,来促进用户之间的互动行为。

我们一直定义这款产品是一个社区产品,社区内容、用户互动的数据一直是我们的指标项。大学生分享自己的生活,和同校、同乡、同好的人产生共情/共鸣,进而互动、产生社交关联。但我觉得发展到1.5.0具有私信版本这个功能之后,这款产品已经不再是一款社区产品了。对于一款社区产品来说,社区的认同感应该会激励更多公开内容的生产,而私信功能上线后,我们发现用户对于私聊的诉求一下子得到了释放,这也从一个侧面体现了很多用户使用产品的需求就是交友。而后相关辅助社交功能带来的数据甜头,已经彻底把这款产品转变成大学生社交产品了。

回过头复盘下来,我觉得有这么几个问题:

问题一、yaktalk并没有解决用户的刚需

即使是一个以闲逛为主的社区产品,也是解决了用户的某方面需求的。

老生常谈,所谓刚需,对应的就是用户打开App的原始动力。百度解决了用户搜索的刚需,滴滴解决了用户出行的刚需,抖音解决了用户打发碎片化时间的刚需,知乎解决了用户对于了解知识的刚需……刚需是内因,在产品的行为是表现。

反观yaktalk,我们的愿景是把全国所有的大学生都聚集在这里,分享自己的校园生活,结交各种各样的朋友。

所以这样一个大学生社区解决了用户什么刚需?分享自己的校园生活是需求吗,不是,我可以在QQ空间分享、我可以在微信朋友圈分享、我可以在学校内部的论坛分享,为什么要来到这样应该社区分享?结交朋友是需求吗,也不是,社交是一个行为,我可以通过线上线下各种方式结交朋友,为什么一定要来到这里认识人?

行为背后的情绪才是需求,有的人是想网恋,有的人是想找到同好,有的人是想了解大学攻略,有的人是想找到直系学长要考经,有的人是因为失恋了找一个用户比较少的地方当做树洞。

大学生是属性标签,社区是形态,如果在一开始就定位准了一个核心诉求,我想产品的发展路径会明确很多。

问题二、社区的初期应该是少数人的狂欢

一个社区初期是什么样的?翻一翻成功者的经历,知乎“从最开始的注册用户来看,创业者、工程师和互联网从业者是知乎早期的主要用户。因为创业者的问题最多,从产品研发、招聘、法律、行业趋势等等。创业者需要的知识跨度特别强,既真实又活跃。”

小红书初期以境外购物为切入,“用户开始分享和交流其用真金白银‘砸’出来的境外购物心得,包括每个商品的详细信息,如品牌、包装、价格、购买地点和使用心得等。”
换句话说,社区的初期应该是少数人的狂欢。圈定了特定的领域、人群,社区是自带话题的存在,运营人员只需要丢下去一颗种子,自然就会发芽。从内容上看,内容的方向相对统一,可以沉淀某一领域的优质内容;从传播上看,这样的社区就像是定点爆破,可以“引爆”一群人,形成口碑;从运营上看,可以较少地介入,简单带带话题讨论,就很可以形成社区的讨论氛围。这也意味着从数据上看,早期的社区具有很可观的互动和留存数据。

yaktalk的1.0.0版本slogan是“分享我的大学生活”,内容定调在了大学生的生活百态,可以是大学城周边的美食探店、可以是每日穿搭、可以是军训轶事,总而言之,并没有对内容的方向做特别严格的限定。社区的启动方式,内容创作者方面,我们通过微博、小红书、知乎等社区平台招募了很多各个方向的校园红人,涉及的领域有摄影、手帐、美食、写字等等等等;内容消费者方面,我们通过开学季的校园路演、校园大使推广、社团入驻等偏线下的方式,获取了近1万名普通用户。

从数据上看,我们似乎也满足社区的2/8定律,20%的头部用户产生了80%的动态;产品的次日留存也还行,大概有30%左右;也有一定的互动表现,点赞、评论之类。这种数据给我一种波澜不惊、老夫老妻的感觉,感觉已经有很多用户,已经运营了很长时间,各方面都很稳定的感觉,却唯独并没有一种“狂欢”的感觉:大家踊跃发布内容、彼此聊得火热、自己玩得很high甚至根本不需要运营过度介入。

回头看,大学生社区如果定义成一个内容社区的话,初期应该是某一维度、领域、内容的细分。哪怕是一个综合社区,早期也不可能全领域全方向全面开花。大学生社区的细分可以是“大学生出国备考交流”、“大学生兼职信息”、“大学生求职经验分享”,先让社区在小部分人中运转起来,积累内容、形成气氛,再逐渐扩大范围。

问题三、核心功能来得晚了一些

我们直到1.5.0版本(距离第一个版本近9个月)才推出了私信这个功能。

其实在很早的时候,大概第一年10月的时候,我们从内容审核后台看到一些用户在注册后,就在很多动态下面留微信或者要微信,起初我们定义这种行为是一种骚扰,因为在没有互动基础的情况下的交友,就很不单纯,所以我们审核同学会屏蔽这些内容。

后来我们发现,也有一些同学,真的聊得来,在一条动态的评论区里面互动了很多条之后,会互换微信,然后约定加完好友后把这条评论删掉。发现了这样的现象后,我们才突然认识到私信的重要性,于是在盘算着推出这个功能。这件事情在产品团队内部也有争议,反对者主要持两个观点:一个是说,社区产品中,不一定需要私信功能,如果是一个强调基于内容互动的社区,用户的互动行为中私信不是重点;另一个原因就是说,私信对于当前的社区而言,只是将评论区互换微信的行为改在私聊中进行,并没有给社区带来什么收益。

首先,对于社交产品而言,私信的意义毋庸置疑。对于社区而言,如果是以干货内容为主的社区,比方说CSDN技术论坛、人人都是产品经理这样的社区,用户之间的关系偏弱,私信的存在不一定那么重要。另一方面,这些社区的内容创作者,以经验分享为主、观点讨论为辅,使用频率相对较低,私信没有得到及时得处理反而会影响对方的使用体验。

但对于大学生社区而言,私信就是一项必备的核心功能了。在这里,内容消费并不是根本诉求,用户连接才是更重要的使命——因为同好、同乡、同学等标签而产生潜在的社交关系。私信,是用户关系表达的重要方式之一。

私信功能上线后,数据还是挺好看的。我们发现了大量用户行为路径导向私信,比方说动态->头像->个人主页->私信,再比方说推荐好友->头像->个人主页->私信,有些新用户可能从没发过一条动态,但却产生了私聊的互动行为。从另一个侧面来说,私信反映了大学生群体对于交友的强烈诉求,这也促进了产品的重要转型。

如果早一点推出私信功能,也许我们在内容这件事情的纠结会少一些,也许我们向社交方向转变的进程会更快一些。

问题四、拍脑袋的后果是拍大腿

当我们不知道迭代什么的时候,我们在社区里面寻找用户的痛点。我们发现,有少数用户把yaktalk当成了树洞,正是因为里面的同学她并不认识,她在社区里面讲一些自己的悄悄话。

受此启发,我们规划了一个“树洞”功能,一个只在晚上10点开启的匿名空间,用户在里面可以发动态而不暴露身份,在第二天空间将自动销毁。

我们希望用户可以在树洞里讲一些羞羞的、负面的、情绪化的内容,并因此而互动。功能上线后,我们每天运营一个树洞话题,在“树洞”空间中进行引导。

这种一厢情愿的功能,数据表现并不好,树洞并没有发酵成我们希望的样子。这里面有产品设计的原因,当时给这个功能的入口比较深,主要是通过推送的方式进行触达。但我觉得更主要的问题是,这个功能并没有经过完整的用户调研与分析,是为少数人量身定做的拍脑袋功能。

回过头来看,其实应该做一次MVP,拉一部分用户在QQ匿名群里面玩起来,看看大家在树洞里面都聊些什么,有什么转化成产品功能的点。而不是简单论证后就开始设计功能,平心而论这个功能对当时的技术框架还影响蛮大的。

问题五、数据焦虑下的头脑风暴应当审慎而收敛

当发现数据出现了预期之外的下滑或者波动时,我们团队内部很喜欢做的一件事是头脑风暴。头脑风暴的内容大致氛围两部分,一部分是归因,一部分是求解。

在归因这一Part没什么毛病,大家谁还不是个喷子,能把问题看得很通透,有的点也说得很准。但是在求解这个环节,我们经常发散得过于严重,明明是讨论“如何进一步提高话题的互动”,却会引申到“做话题这件事情有意义吗”这种又大又空又怀疑人生的问题上,进而提出一个新的功能,来弥补之前的设计缺陷。

这种针对具体问题的头脑风暴,应当审慎而收敛,主持人必须时刻保持清醒,一旦苗头不对就立即纠偏。

问题六、文档撰写不规范

这个问题其实是在写复盘的时候发现的。以产品PRD文档为例,其实在产品推进的过程中,每个功能的设计背后都有当下的判断和逻辑,要么是基于数据分析、要么是基于需求调研、要么就是拍脑袋。

在PRD的撰写上,我们基本上有原型图、UML、数据埋点需求等偏执行的内容,但开篇却没有把背景和出发点。这就导致了在复盘功能的时候,无法准确追溯到当时的全貌,有个功能不明白当时为啥要做,有的功能在回顾的时候觉得当时逻辑并不通顺。

郑重提醒自己,以后的每一份PRD文档上都记录当时的背景和逻辑,不管逻辑正确与否,方便在回顾时理解当时功能设计的主客观原因。

我的感想

yaktalk是我第一个完整参与过的从0到1的项目,这个项目公司给我们很大的空间,让我们可以尝试很多可能性,这在以前我是完全不敢想的。

团队的小伙伴都非常专业,在整个项目过程中学到了很多,也成长了很多。都说创业是痛苦的,这种内部创业尤其痛苦,每一步都没有前人走过,我们基本上都是摸着石头过河。

虽然因为种种原因,最后项目关闭了,但我不后悔。

感谢公司能给我们这次机会尝试,提供丰厚的资源。

感谢每一位团队小伙伴,无论是合作过的,没合作过的。

感谢社区里的每一位用户,谢谢你们曾来过。

路还很长,加油。

  0

评论

📧 邮箱: 留下邮箱,别人回复后会收到通知喔
😉 头像: 自动同步邮箱对应的「Gravatar」头像
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×