【产品分析】PiliPili弹幕复盘总结

本文分为项目背景、项目历程、问题总结和个人感想。其中个人以为干货集中在问题总结部分,如有阐述不清楚的地方,可以参考项目背景和项目历程。个人感想部分为自我陶醉的靡靡之音,仅供笑尔。

一、项目背景

PiliPili弹幕是一个图片弹幕社交App,2014年11月9日在一次hackthon比赛中诞生。比赛之前我们五个应届生(两个PM,一个android客户端开发,一个web前端开发,一个服务端开发)画好了原型图,申请好服务器,进行了简单的开发,然后在两天一夜中完成了发布正方形图片、浏览图片、评论图片的功能并发布给内测用户,至于用户系统、推送、分享等辅助功能完全抛弃。虽然还不全面,但是第一版确实有点精益创业的感觉,把握核心功能,剔除非核心功能。可能由于这个原因,PiliPili获得机会立项,继续做下去。

从得知立项开始,我们就认识到从能力、经验、资源等各个角度来讲,PiliPil项目失败的可能性远大于成功的可能性,尽管如此,我们还是凭借着年轻的劲头义无返顾地去做了。虽然这样说,在项目进行过程中我的心态就产生了微妙的变化,或多或少地忘记过立项时候的初衷。

二、项目历程

2014.11.9 立项,共五名成员(两个PM,一个android客户端开发,一个web前端开发,一个服务端开发),其实还有外援android开发同学,承担了不小的工作量。项目中期一名PM离开团队,团队剩下四个人,PM、服务端开发、android开发、web前端开发。

2014.12.1发布0.2.5

服务端同学和web前端开发同学退出,新的服务端同学和web前端开发同学加入,项目交接,重写服务端。

客户端查缺补漏,修改大量bug,完善产品基本页面。

增加腾讯信鸽推送。

增加友盟社会化分享。

增加友盟数据统计。

2014.12.11发布0.3.0

完整的用户系统,手机号登录。

增加引导页。

优化界面。

用web实现的个人主页。

修复海量bug。

2014.12.19发布0.3.4

完整的消息中心(之前的消息几乎是乱显示的)。

修复海量bug。

优化界面。

大重构。

增加友盟自定义事件统计。

2014.12.29发布0.5.0

增加点赞功能。

新的个人主页。

把图片列表放在应用的第一屏。(★次留显著提升)

一些重构工作,修复大量bug。

优化界面。

2015.1.4发布0.5.5

修复点赞的一系列bug。

增加弹幕出现动画。

优化详情页。

增加举报、删除评论和删除图片的功能。

App的名字从PiliPili改为PiliPili弹幕。

2015.1.5发布0.5.6

修复bug。

2015.1.8发布0.5.13

增加发布长图的功能。

增加排行榜功能,用web实现。(★用户发布内容的积极性大幅度提高)

发布图片的时候可以选择频道。

2015.1.20发布0.6.0

消息中心里面区分消息来自于我的图片还是我参与的图片。

图片描述里面能够插入链接。

提升了稳定性。

点击底部按钮,能够返回顶部并且刷新。

一些细节和文案的调整。

增加群聊功能。(☆使用环信服务,次留大幅度提高,但是崩溃数目也大幅提高。)

2015.1.21发布0.6.1

修复群聊相关的bug。

2015.1.29发布0.6.3

增加QQ和新浪微博的第三方登录。

增加群聊免打扰功能。

2015.2.3发布0.6.4

增加弹幕发语音的功能。

2015.2.28发布0.7.1

增加关注和粉丝系统。

查看已关注好友发布的图片。

发现页改为web实现,运营内容后台可控。

2015.3.10发布0.7.2

允许用户下载原始图片。(能下张壁纸也是好的)

图片列表显示无压缩图片。

2015.3.13发布0.7.3

增加私聊功能,但是入口隐藏很深

2015.3.20发布0.8.0

增加小电影滤镜,可以将图片处理成小电影、新闻联播、动物世界、今日说法、KTV风格。

2015.3.30发布0.8.1

拿掉手机注册入口,只保留第三方登录和手机号登录。(负担不起短信费了)

从项目开始,PiliPili面临的最大问题就是留存率,无论是次日留存率还是7日留存率一直是非常低的水平。这个问题直到项目冻结,都没有得到显著解决。

三、问题总结

1.PiliPili没有解决刚需

PiliPili作为图片社交应用,核心功能是在图片上直接评论的弹幕,无论形势如何,它实际上是对评论区的微创新。而图片社区的形式,和传统论坛别无二致。无论我们采用何种内容组织形式(例如频道和话题),还是什么样的用户关系(关注和粉丝抑或互相加好友),传统的论坛都囊括。

问题就在这里,以上只是形式上的微创新,而没有真正解决用户刚需。所谓刚需,应该是目标用户在日常生活中频繁遇到、并且可以持续下去的需求。比如花瓣网、昵图网等图片站,解决的就是设计师群体寻找图片的需求,这个需求是频繁可持续的。所以从图片角度而言,我们并没有解决刚需。

再说社交。在我总结来,社交不是个需求,社交背后的东西才是需求。我通过社交解决了刚需,那么社交就是强需求,我通过社交没有解决什么刚需,社交就是伪需求。除此之外,还要考虑这个地方的社交有没有可替代性。比如脉脉,脉脉上的社交是微信、QQ等一众巨头无法替代的,而它也确实解决了和职业相关的需求,所以脉脉称得上是一个解决了刚需的产品。

反观,PiliPili只是希望一群对弹幕感兴趣的人聚集在一起分享相同的爱好,然后成为朋友。其一,对弹幕感兴趣的前提是弹幕依附的内容有价值;其二,没有强运营工作,用户分享的内容质量非常低;其三,这种分享很容易就被微信、qq空间取代。我甚至有种想法,任何能够分享到朋友圈、分享到QQ空间的应用都不具备纯正的社交。

总而言之,PiliPili弹幕不是一个解决刚需的应用。

2.容易被蒙蔽的用户访谈

在PiliPili项目中,我们与用户做了大量的沟通。我几乎一对一访谈了QQ群里面的每一个用户。同时,友盟后台反馈、市场评价也是一一记录。但是在这个过程中,很容易被用户访谈蒙蔽。

用户访谈有个前提:只有对你的东西有好感的应用才会接受访谈,不喜欢你的东西的用户会直接用脚投票。

我们通过后台,获取到一些安装后马上流失掉的用户的联系方式,通过各种途径沟通之后,发现收效甚微——他们本来就对这个东西无感,更提不出太多有价值的意见。

但是我感触最深的是另外一点。

PiliPili弹幕的形式可以说是新奇的,从同一时期大批量的竞品身上也能看出。在图片上直接评论的方式有一种侵犯性,对评论者而言,比传统评论方式更爽更好玩。正是因为这种“好玩”,导致直到今天,PiliPili仍有不少新注册用户仍然会说这是一个有意思的应用。但是“好玩”本身称不上一个刚需,或者说可替代的解决方案实在太多了。所以等到过上几天,那些觉得好玩的用户就会对PiliPili失去兴趣,转而离开。

我们发现太多用户称赞了我们,但是并没有及时感知到他们的默默离开。我们以为流失的只是那些对我们不感兴趣的用户。这种情况极大地影响了我们的判断力,一直到项目快要结束的时候,我们才想到认真思考图片弹幕的形式到底是不是一种刚需。

3.对早期用户的犹疑不决、锱铢必较

刚开始一个月,PiliPili的日活也就100左右。那个时候我们升级版本,为了兼容旧版本花费了很大的工作量。现在看来实际上是完全不必要的。

其一,如果不是刻意积累的,那些尝鲜的早期用户本来就留不下来。

其二,我们可以积累的种子用户,就算升级之后有兼容性问题,我们手动给他一个新包也就解决了问题。

4.过于看重美观性和体验

看我们的更新记录,在界面优化上耗费了太多的时间。其实我们改到现在,虽然和最早期的demo界面相比有了一些提升,但是客观评价一下真的聊胜于无。

其一,界面美观本来就是一个主观性的问题,除非视觉系产品,在不是特别影响操作便捷性的情况下,产品早期界面丑一点无足轻重。

其二,在没有UI设计的时候,PM把太多工作陷入表层的美观性和交互层面的工作里,而不是思考产品使用场景、目标人群、解决的需求等问题,是极大的浪费。

另外,为了保证体验,我们很多地方都是android native实现的。其实不涉及输入和复杂交互的页面,特别是用于展示和作为入口的页面,完全可以用web实现,甚至用web实现要优于native实现。

用web实现的缺点是会损失一定的体验流畅性,但是优点是随时更改随时上线,并且后台完全可控。

比如PiliPili的排行榜和内容推荐页,全部由web实现,任何推荐内容,后台作出修改,所有用户马上就能接受。对于开展运营工作来说非常方便。但是我们真正知道该这样做的时候已经错过了最好的时机,PiliPili那个时候已经积重难返。

不过话说回来,我觉得在产品易用性上应该做到极致,但是易用性包括易于理解、易于操作,并不等同于美观性和使用体验。当然我们在易用性上也做的不好。

总结下来,天下产品一大抄可能是一种很简便的解决方案,存在即合理。早期我们经常陷入细节部分的争论,现在看来,细节部分服从行业大多数的惯例几乎就好了。

5.没有考虑到用户量不同的情况

PiliPili的设计完全是在用户量较小的情况下实验并进行设计的。所以在中期用户量急剧增大的时候,各种问题突然显现出来。例如我们意识到要增加运营工作了,但是突然发现没有太多可以操作的运营空间。而等到我们适合运营的web推荐内容页上线之后,已经错过了最佳时机。

对于社交产品或者社区而言,用户量不同完全就是不同的产品。早期用户量小的时候,也要考虑到用户量大了以后各方面的情况。

6.数据分析停留在表面

虽然我在学校所学专业和数据分析有所联系,毕设也是做得相关课题。但是真正在日常运用过程中还是不经意间踩到很多坑,甚至很多坑是毕设导师提醒过我的。

举例来说,在PiliPili中期,我们发现一个情况:

PiliPili有个QQ群,所有加过QQ群的种子用户全都留存下来了,并且他们每天在PiliPili上产生了大量的优质内容。同时PiliPili有一个微信群,但是由于运营不力,里面几乎没人说话,微信群里的种子用户全都流失了。在综合其他一些数据,我得出的结论是图片社交X群聊,应该是一个可取的方向。

于是我们加了环信,加了群聊,后面又加了私聊,在短时间内次留的确提升了5%左右。

但是现在分析,次留提升,最大的可能性是由于加入了群聊以后,用户收到推送的频率变高了,打开应用的可能性也变大了。

随之而来的就是各种问题,最大的问题是在开发人数不够的时候接入IM,导致应用稳定性降低,崩溃数特别大。虽然我们的开发很优秀,但是这活的确不是一个人就能干的。紧随其后的问题是用户量增大的时候,垃圾信息扰民严重,卸载量急剧上升。没有群聊的时候,anti-spam主要靠手动删,但是接入了第三方的服务,这招不好使了。社区氛围一片混乱。

7.各种一厢情愿的小问题

做产品要从小白用户角度思考,这一点我们在产品早期做的很不好,不仅产品设计上有太多一厢情愿的地方,就拿一点来说,PiliPili这个名字就取的很不好。

其一,仅仅凭借口头复述,正确输入PiliPili的概率就不高。

其二,就算在应用市场里输入了PiliPili,很多市场往往会自动跳到“霹雳”这个词。

其三,更何况绝大多数人根本不知道PiliPili。

四、个人感想

PiliPili弹幕是我第一个完全负责,并且从无到有,从有到跪的产品。这个项目算是公司交学费,让我们从失败中获得教训的宝贵课程。其实最早立项的时候我们也知道失败的可能性更大一点,但是随着项目的进行,随着越来越固执地想让PiliPili继续下去,心态也发生了一些变化,变得很不淡定,也出了一些烂需求(比如群聊)。自己的锅自己认。

但是就我个人而言,这个过程中还是收获了很多东西,特别是早期产品从规划到推广的各个步骤,基本都亲自走了一遍,也总结了一些经验。

在做PiliPili的过程中受到各方面的帮助,公司提供了宝贵的推广资源,各方面的前辈和朋友提供了很多意见和帮助,感谢他们。

感谢在PiliPili各个时期参与开发和推广的朋友们,你们也是PiliPili的缔造者。

也感谢这个过程中看不上我们、对我们提出质疑、以及离开我们的人。

感谢所有用户,感谢到现在还不放弃PiliPili、一直在反馈意见的朋友,真心对不起。

PiliPili立项第二天,我们就得知一个几乎一摸一样的竞品——槽厂的诞生。后来又陆续出现好多形式相似的竞品,槽流、时光、blabla等,如果宽泛一点,次元、TUTU、疯贴、彩社都算。我对竞品们的心情非常多变,刚开始的时候几乎切齿,觉得自己想出来的主意被人拿去了。(实际上大家应该都是独立开发的,很多竞品比我们早开发,只是我们不知道而已)曾经跟一个年长的朋友说过竞品的事,朋友笑曰:“我看世人皆傻逼,世人待我应如是。”不禁捧腹。现在看到有一些竞品已经跪了,有一些还在苦苦坚持,别管怎么样,感谢他们陪PiliPili一起在这个领域探索,向他们致敬。希望他们中有人能找到从单纯的图片社交转化为解决刚需的路径,一炮而红。

最后,特别感谢几位从头到尾一起走下来的兄弟,总感觉自己的烂需求坑了大家,个中感慨,溢于言表。虽然PiliPili被冻结了,并不意味着就死绝了。另外,就算产品跪了,团队还在。

另外,我们的开发是最牛逼的开发。【这句话因为太重要,所以单独一段】


继续加油。

你可能感兴趣的:(【产品分析】PiliPili弹幕复盘总结)