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

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

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

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

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

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

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

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

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

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

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

你这个产品解决别人什么问题?
谁会用?
他为什么会用?
他是一个强需求还是弱需求?
他是强拉动还是弱拉动?
他给用户创造什么价值?

时刻提醒自己回答这六个问题,保持清醒的头脑,才能做好产品。

这篇本应在半年前完成的文章,拖到现在才完成,实在是惭愧。

 

————————————-拖延症重度患者的分割线————————————————-

 

财迷微博是鄙人在东财做得时间最长、倾注心血最多、也是最完整的一个产品。从提出构思到立项、产品设计、上线、运营、改版,前后经历了近两年的时间。期间经历了无数的波折、问题和障碍,有些通过自己的思考获得了解决,有些也由于种种原因而没法挽回。整个过程中,学到很多,也收获很多经验和教训。是以为记。

 

萌芽

 

09年的6月,当时我刚刚成为一个开始被Twitter的魅力所吸引的用户,快速丰富的信息流,前所未见的信息扩散传播形式令我兴奋不已,同时也陷入了沉思:这么简单而又空前成功的一个产品,为什么在我国却没法风靡起来呢?彼时新浪微博尚未上线,而饭否等先行者运作了几年也一直不温不火。从表面上看,是因为信息监管的原因,微博这种形式对内容很难控制,由此带来的政治风险极大,因此我判断做综合类的微博在我国特殊的国情下很难做大(当然,浪博后来的发展大大出乎了我的意料,这是后话)。但如果把微博应用到财经这个垂直领域,倒不失为一条蹊径,理由有三:

 

1.专注在财经证券这个行业,内容更加专业,也规避了政治风险。
2.当时新浪博客访问量排名前五的有四个是股票博客,并且都是做解盘直播的。证明用户需求量是很大的,而微博这种产品形态用来做直播,比博客要方便得多,不仅利于发布,更加利于跟踪,是个绝佳的替代产品。
3.从东财原有的王牌产品——股吧来看,散户对于个股信息的关注度很高,因为这是直接关系到自身利益的。但股吧中鱼龙混杂,垃圾信息过多。同时,他们对于各路民间高手的言论也是趋之若鹜,希望高手能够给自己指点迷津。但股吧只能对话题聚合,缺乏对用户关系的梳理。微博则正好能够提供互补的功能,并且“关注”这种单向的弱关系链尤其适合股民这样的群体:高手一呼百应,满足虚荣心名利心,也不用和陌生网友建立好友关系;而散户则可以关注在话题中随机出现的高手们,从此就可实时收到高手们最新的解盘点评,不必再费心从一大堆的垃圾贴中再去筛选有价值的信息。阅读质量也可获得成倍的提高。

 

基于以上几点主要的理由,我向公司提出了做财经微博的想法。但由于种种原因,项目被束之高阁。

 

一个月后,证星的赶牛微博上线。当时我心里一沉,心想不好,被竞争对手抢了先机;但同时也有几分欣喜,因为自己的想法获得了别人的赞同。

 

又过了半个月,新浪微博闪亮登场,从此一骑绝尘。

 

插几句题外话,浪博的成功,我认为是满足了天时地利人和的:天时——彼时恰逢国内严打社区,饭否嘀咕叽歪等一众先行者被有关部门关停,新浪没了对手;而同时,智能手机和3G网络的逐渐普及也推动了微博这个为移动终端而生的应用迅速发展。地利——微博两大核心媒体属性和名人效应,恰恰是新浪的强项,新浪以1.0的模式强推这个2.0的产品,充分实现了扬长避短。人和——不得不佩服新浪的执行力,倾全网之力强推微博,把深厚的内容运营功底发挥到极致,牢牢抓住了最有话语权的用户群体,从而就控制了更为大量的围观群众。从产品的角度讲,浪博并不比腾讯强,但其对用户内容需求的把握和运营能力则远超腾讯,这就是为什么两家市场份额差距如此之大的重要原因。

 

开工

回到财迷。在浪博运营半年之后,公司才正式立项做微博。当时全公司我估计知道微博是什么东西的人,不超过五个。于是开始构思、做设计。中间经历无数纠结和苦思,没有人协助,也没有人指点哪怕是质疑,完全就靠我自己去构建整个产品。那一个月从早到晚就沉浸在无尽的思索之中,甚至有过半夜睡到中途朦胧中想到一个feature赶紧爬起来用手机记录下的情况。确实是充满了激情。

 

设计、开发的过程不再赘述,由于立项之初的定位是“跟随策略”的产品,所以上头也并不是很重视,我也因此获得了空前的自主权。第一版的财迷做出来,和东财的产品风格迥异,走的是简洁路线,除了基本的信息流、关系链以外,没有做太多加法。

 

充满意外的上线

上线以后,各路领导们的意见突然纷至沓来,整个产品运营和改进计划被全盘打乱,加上技术架构设计得不合理,在铺开推广两周以后迅速遇到瓶颈,导致连续出现崩溃的情况。无奈之下只好撤了推广,开始漫长的重构。

 

这个阶段获得的收获和教训:

1.不同的产品阶段,要采取相对应的产品策略。过早或过迟都不适宜,甚至会起到反效果。

这里举两个例子,都是在设计阶段自鸣得意以为领先于浪博的功能,结果上线后效果很差:

一个是类似于Twitter中的list功能,可以对关注的人进行分组,也可以不关注人而是直接关注别人的分组。

我的想法:这个功能对于关注数过多的用户来说,可以方便的管理自己的关注对象,减少信息过载带来的困扰。而对于新用户来说,也可以通过关注别人的分组来迅速扩展自己的信息来源,更快上手。

现实却是:绝大部分的用户并不会使用此功能,觉得上手难度太大理解不了。而且绝大多数用户的关注数并不多,还没有达到需要分组梳理信息的地步。

第二个例子是转发:我把Twitter式的Retweet和浪博式的转发做了一个结合,当用户点击转发时会出现如下图的操作层:

若用户不添加评论直接转发,则自动按Retweet的形式转发,保留原作者的格式,只显示此微博被多少人转过。

若用户添加评论后转发,则按照浪博的形式转发。

我得意于此设计的地方在于:一沿用官方Retweet的方式能够有效降低信息冗余,避免热门微博反复出现带来的信息噪声;而是兼容了民间转发需要加入自己评论的需求,并且比市面上所有的客户端操作都省了一步,无需用户去判断改用哪种转发形式,只需自己决定是否加评论转发即可,判断的逻辑由后台完成了。

但残酷的现实是:用户会迷惑于同样的转发为何会产生不同的表现形式,更严重的是,由于Retweet形式的存在,使得早期本来就缺内容的情况下更显得微博数量稀少人气不足,用户上来没东西可看,恶性循环。

上面两个例子都是在不合时宜的产品阶段采取了不正确的产品策略所导致的不好效果。这两个功能都适用于用户基数较大、用户成熟度较高的阶段推出。Twitter也不是一上线就有这些功能的,而是在产品发展到足够庞大时,顺应大部分用户的需求推出的。包括浪博也是,前期根本没有分组,到上线半年后才开放。而Twitter更是在发展了四年之后才上线的官方Retweet功能。我自作聪明的把这俩功能做了小改进后在产品初级阶段就推出,而用户积累量和对信息梳理的需求还远没有达到那个点,所以效果自然好不了。

 

2.微博的产品形态并不复杂,但想要做好,尤其是在中国这样一个用户水平普遍偏低的国情下,必须在运营上狠下功夫。

前文也提到,浪博的成功,最关键的一点就在于运营的成功:不管是内容的运营还是关系链的建立和强化,各种手段都用到了极致。

而这一点我做得不够好,下手不够狠,而且受制于技术瓶颈,很多手段也不能再用。产品上线前三个月的黄金时间没抓住,后续再挽回就难了。

 

3.定位有偏差

最初结合东财既有产品的气质和人群,我决定还是延续草根路线,因为名人牌是浪博的强项,咱打不过他们。

但对于新用户比例极大的财迷来说,没有名人,新用户上来不知道该关注谁,也就没有信息源,直接导致上手困难,流失率很高。

为了解决这个问题,我一开始就设计了导入部分东财博客里直播解盘做得不错的博主,默认推荐给新用户;在注册完成后引导进行关注股票的操作,并打通了自选股账户数据,直接导入为关注的股票,通过推荐有共同关注股票的人来拓展新用户的信息源。

但这么做还是不够。一是名博有限,且知名度也有限,若是由名博主动去邀请粉丝来加入,短时间内效果很不错,但持续性不强,而且影响范围也有局限;二是有相同自选股的人很多,但发言的很少,所以虽然有关注,但依然缺信息源。

综上,在微博这种产品的初级阶段,名人效应是必不可少的手段。在用户量进入良性上升通道以后,才有可能转入草根路线。

 

4.产品规划和领导意见的不一致带来的灾难

早期产品无人问津,我天马行空恣意发挥,但上线后领导们的突然重视并且领导间意见的不一致直接导致了上线后的失控。所以,充分的向上沟通是非常有必要的。BOSS们可以不知道自己想要的是什么,但我作为产品负责人,必须清晰的把自己想实现的产品还原给BOSS看,把核心的要点提炼出来,至少在大方向上不能有大的分歧,否则后续绝对是灾难。

 

——————————————–重构分割线————————————————-

重构经历了漫长的讨论阶段,多方意见始终不统一,最后由大老板出面,拍板定了方向:和股吧整合,导入股吧内容。依旧走草根路线,弱化“人”的关系,股票就是我们的名人,用户关心的只是手上的个股,所以关注个股加入主时间线并成为重要组成部分。

我曾极力反对此方案,多次试图说服领导,但人微言轻,也没法和大老板直接沟通。多方领导最后都同意了按大老板的想法,至此尘埃落定。

这次重构被当做2011年的“公司战略级项目”来做,但我心知肚明,这一改,将万劫不复。

微博的本质就是利用人的关系链,对信息进行梳理和传播的工具。它的革命性就在与没有了传统媒体的把关人来控制哪些信息可以为大众所接收,而是完全靠人们的群体判断自发的对信息进行筛选、过滤和放大,并且对于人群和信息的选择主动权在浏览者自己手上。

而股吧的做法是以话题为核心对信息进行的聚合,虽然也有人群对内容的筛选,但这个人群是不可控的,这也是为什么股吧的内容质量参差不齐广告泛滥的原因。

把微博和股吧整合,表面上看是利用股吧的内容充实了微博,但实质上则是把财迷变成了一个单纯的RSS订阅器而已,信息量大,但无用。

财迷就像是我的亲儿子,由我一手打造,却被整容得面目全非。这是个失败的产品,但从失败中获取的经验,弥足珍贵。

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

 

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

 

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

凡事都要讲究方法,工作亦如是。
最近的几大败笔:
1.什么事都揽在自己身上,结果什么事都做得不咋的。
2.对于领导交代的事,没有第一时间完成。还是按照自己的思路在做。
3.事情做了不少,汇报做得不多。因此虽然实际上每天忙得不可开交,但在领导看来,我还挺游手好闲。

得到的几点经验教训:

1.要善于分配工作。该利用团队帮助的时候,还是要合理利用。虽然有些事情交待给别人做,可能确实没有自己做的效果来得满意,但是一个人终归不可能做好所有的事情,因此越早把活分配出去,对自己越有利。在执行的过程中再保持沟通和交流,把自己的目的和要求传达清楚,在不断的磨合下,效率只会越来越高。

2.领导交待的事要置于最高优先级。因为领导通常都是唯结果论,在什么时间完成了哪些事情是他们想要看到的,至于过程多么曲折他们并不需要了解。因此,一定要让领导感觉到你很重视他安排的工作,而不能按自己的思路去做。领导认为重要的事,一定比你认为重要的事更加重要。不要轻易试图去修正领导的优先级安排。

3.“做了什么固然重要,但让别人知道你做了什么更重要。”换位思考一下,当自己给别人安排工作,别人只顾自己闷头干,做完了也不汇报,你会认为他把工作做得很好吗?产品设计的“易用性”原则中,很重要的一条就是要注意“反馈”。用户执行操作后要有成功或失败的提示反馈,这样用户才能知道程序是否响应了刚刚的操作,否则就会误认为程序死掉了或出错了。同样的,领导也需要你不断的向他反馈你的工作进展和成果,以此来评判你的工作成绩。没有反馈,就无法了解你的工作状态。

4.用户体验分析的方法也适用于日常工作中,把领导、同事都当成你的用户,多从他们的角度出发去思考问题,就会更好的改进自己的工作方式方法。加强沟通,多了解对方的真实需求,有的放矢,才能取得更好的工作成果。

通行证,作为一个网站的基础服务,其目的有三: 1.帐号管理(注册帐号、编辑资料、找回密码) 2.身份认证,单点登录,一个账号全站通用。 3.用户数据中心,保存用户在网站各不同应用中的数据及资料。同时为各不同平台的应用提供数据调用接口。 这次做通行证系统的升级,主要也就是为了完善以上三点。另外还有一点目的就是优化注册表单——在精简表单项的同时,将操作和错误提示语修改得更为清晰明确。目前已经取得了阶段性的成果,不过依然有很多地方有待改进。

收获:

建立了跨平台的统一身份认证机制,新增了两种注册登录方式,为获得真实的用户数据打下了一个基础。同时,也完善了找回密码的机制,为提高账户的安全性做好了准备。

心得:

对于用户来说,通行证只是一个非常简单的应用,界面上应该越简单越好,不需要用户进行过多的思考和选择即可直接开始使用。至于复杂的逻辑判断,则放在后台进行处理。

教训:

1.跨平台、跨频道的项目合作,需要更多的、及时的沟通,每一步的进展都需要知会相关人员,否则极易产生卡壳事件,影响整体进度。

2.对于基础性的服务,必须要走在前面,否则会成为新开发应用的瓶颈。这次几个项目并行,就因为通行证没有升级完成,导致其他几个项目进度都受到严重影响。(当然,这也有历史遗留问题的原因。)

几个有意思的问题:

1.关于字段的命名,应尽量避免出现相近的名词。例如登录名、名字、用户名等就最好不要同时使用,否则用户很容易混淆。之前我的设计是把邮箱、手机、用户名这三个可用于登录的字段统一称为“登录名”,用户在这一文本框中输入任意一个已设置过的邮箱、手机或用户名均可进行登录。而同时还有一个“名字”字段(相当于昵称),后来在实践中发现,不少人把这个“名字”和“登录名”弄混了,结果就是死活登录不上。针对这个情况,我把“登录名”的名称改为了“帐号”,并在注册时强化了提示语,这样改过以后,就没有再出现混淆的情况。

2.关于表单的设计,之前也在Twitter上说过,当相邻两个页面的表单非常相像时,光凭文字来区分是不够的,还需要通过样式、色彩、图标等的变化来体现其区别,否则一眼看上去很容易会误认为是同一个页面。网速快的话,甚至会以为页面没有跳转。因为文字是最不显眼的区别。当看到一个网页的时候,首先关注的是整体形象,然后才会看到细节。这就好比“一起来找碴”的游戏,大家都知道要分辨姑娘手上戴的是手链还是手表是很费劲的,但如果一个是帅哥一个是美女那就很容易的区分了。


3.关于找回密码。 对于整个用户群来说,除了登录以外,“找回密码”大概是使用最频繁的一个服务了。老版的通行证仅有“回答密保问题后发送邮件”找回这一种方式,并且邮箱信息还都是没有校验过的,很多用户甚至并不填写邮箱。因此老用户常常是压根无法找回密码。

针对这一现状,我做了几点改进:一、新增邮箱和手机注册,新注册的邮箱和手机必须通过了校验才能正常登录。而校验过的邮箱和手机即可认为是真实有效的信息,由此建立了用户——账户——邮箱/手机之间的关联,这样就确保了用户能够通过真实的信息来找回密码。二、对于老用户,在登录后的页面给出提示,建议他们为了保障账户的安全,尽快去填写和绑定邮箱。三、提供了邮箱、手机、密保问题三种方式来找回密码,分别对应了三种不同注册方式的用户类型。

不过在实践中又发现了问题:最初的设计是直接给出三个选项:邮箱找回、手机找回和密保问题找回,用户选择其中一种,直接输入对应的邮箱名、手机号或用户名。此时用户名注册的用户若选择邮箱找回方式,直接输入一个邮箱,则会发现无法找回,因为老的邮箱并未通过验证。而有一部分用户是确实不记得自己的用户名,只记得填过邮箱,同理也有只记得填过手机的用户,这种情况该怎么办呢?

解决的办法其实也很简单:把流程修改一下,第一步不是让用户选择找回方式,而是输入账号。首先确定用户想要找回的是哪个帐号,然后根据帐号去检索其已设定的密保措施,自动进行相应的找回流程。若已绑定邮箱则自动发送密码重设邮件,若已绑定手机则自动发送手机验证码,若已设定密保问题则自动显示该问题。假如用户三种都设置了呢?那就全列出来,任其选择一种。这样做的好处是在大部分情况下可以减少用户思考“我应该选择哪种找回方式?”的过程,另一方面后台在进行匹配的时候也更加精准,可以直接对应到账号,而不像前一版的设计,需要去对未知是否已验证的信息字段进行判断。

有待优化的几点:

1.关于邮箱绑定的流程

目前是需要先填写邮箱信息,保存后,方能进行绑定。对于用户来说,两步操作有点费解。还得想办法精简。

2.关于账户安全的提示

目前仅有用户中心首页有一句提示语,而对于某些频道页登录后直接跳转回原页面的,安全提示就看不见。还需要增加一些有效又不扰民的提示语。

3.对于安全性

这次的升级,不仅是为了提高易用性,也是为了改善安全性。但这两点总是存在矛盾的,有时候为了安全性,就必须牺牲一部分易用性。如何平衡这两点,在保证安全的基础上尽量提高易用性,这是个值得深入研究的课题。