【产品分析】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被冻结了，并不意味着就死绝了。另外，就算产品跪了，团队还在。

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

继续加油。