在产品设计中,产品策略的运用是很考验功力的一件事。针对不同的用户、产品的不同发展阶段、不同的地域、不同的硬件环境,都要采取不同的产品策略去应对。

新手很容易犯的一个错误,就是不管三七二十一,把功能往上堆,也不管这个功能有没有人用,就觉得功能越多越好。实际上真的是这样好吗?

举个例子:Twitter在2005年成立,最开始只有一个简单的功能,就是Tweet。没有转发,没有回复,没有评论,没有收藏。一切都是随着用户的不断增长,在用户真实使用过程中不断的研究反馈,根据用户的实用习惯,才逐步推出了Reply和Favorite功能。至于转发,更是到了2009年的新版中才得以出现,而且采用的是精心设计后的Retweet——同样的内容,不管你follow的人Retweet多少遍,你都只会看到一次。这和新浪微博的转发相比有天壤之别,非常有效的降低了信息冗余,尤其在热门事件爆发的时候,可以非常好的避免你被同一条热门推刷个一百遍;同时又很好的突出了原推的作者。

那么设想一下:这个功能如果在Twitter刚上线的时候就推出,会怎么样?结论是:时机不对,采用这样的产品策略将无法充分体现其优势。

上面提到过,Retweet的两大优点是一突出原作者,二降低信息冗余。假如在Twitter上线初期就推出,那时的用户群体并不够大,活跃度也比较有限,当时的产品策略应该是百花齐放让尽可能多的用户发出尽可能多的声音,而一旦采用Retweet,第一发声的人少了,转推的人会多(毕竟所有社区的通病都是20%的人创造80%的内容,其余大多数是潜水党);第二Retweet不创造新的信息,使得整个社区的内容产量少了,活跃度就显得并不高。因此,Retweet在Twitter初期推出就不是一个合适的产品策略。

(好吧,哥做财迷的时候就饭了这样的错误这种事我会随便乱说吗……)

对于社区类的产品来说,通常都会分为萌芽、井喷、平稳、没落这几个时期。那么在不同的时期就需要有针对性的去采取相应的产品策略,才能推动社区更好的发展。

萌芽期——这个阶段社区的目标是积累核心用户,沉淀高质量的内容,创造优秀的社区氛围。那么此时的产品策略就应该围绕这些方面去展开,例如邀请制确保种子用户的质量,编辑介入帮助塑造内容并选择精华置顶,针对目标群体展开主题鲜明的讨论,让种子用户多发言并能够产生观点的碰撞等等。

井喷期——这个阶段社区的目标是求增长。那么此时的产品策略就应该围绕如何吸引新用户、增加发帖回帖量等方面去展开,例如附件回复可见(我知道这点很遭人唾弃但却是有效)、首页精华内容聚合、帖子分享引流、回帖可顶并高亮顶得多的回帖、增加第三方登录方式降低注册门槛等等。

平稳期——这个阶段社区的目标是保持稳定,不出乱子。那么此时的产品策略就要围绕净化社区内容、保住核心用户不流失等方面去展开,例如防灌水机制、广告关键字屏蔽机制、注册防机器人机制、人工删除恶意发帖机制、防挖坟机制、小黑屋机制等等。

没落期——这个阶段社区的目标就是挽回颓势求再发展或转型。那么此时的产品策略就应该围绕积极拥抱第三方、寻找新的增长点去站看,例如接入大的开放平台、内容共建、开辟新的频道等等。

本周和技术的几次讨论,让我认识到一个问题:过去我们经常会过多的考虑了最坏的情况,而导致在开发的过程中采取了相对中庸或者保守的做法,但却偏离了产品的初衷。这样是不对的。例如因为广告贴的过多,而延迟微博的展示,或是因为可能的网络不稳定,而采用更加复杂的流程来确保畅通。最坏的情况,是小概率事件,而因为小概率事件发生的可能性而更改产品方案的正确路线,是不可取的。今后我们应该更坚持主要的、核心的需求和功能,不能过多的被负面因素所困扰,要把握好这个平衡的度。

 

就好比从上海去北京路途遥远,本来打算坐飞机去,但技术说飞机太贵,我们还是坐火车去吧,这是可以接受的。但如果说飞机太贵,我们去南京吧,这就偏离方向了,是不可取的。

 

产品的核心需求永远要保证满足,解决的办法有多种,不管怎么变,只能变方法,而不能变方向。性能是必须要考虑的重要因素,但是性能问题不能成为产品改进的阻力。