优秀的PM要有做事的态度

能够听进别人的逻辑和观点,并进而理性思考,是多么稀有而可贵的事情。

总会有这样的人,跟你讨论时沉浸在他营造的理想国,且不管其所讨论的事情,是否是他自己所擅长、所经历的。这种让人苦恼的现象,总不能简答归结为不聪明,不靠谱,不努力。毕竟甚至他已经在职场混迹多年,或甚至已经成为别人的导师或老大。而上一周来到公司的一位台湾作家,其知之为知之的态度和审慎,实在值得一众喷子学习。

zhihu上对于 就差一个写代码 这个问题的讨论中,一个人提到所谓“就差”的表述,其内在透露出一种对于 写代码 这个领域的不重视。还不能说是不尊重,但至少提问者显得有那么点儿不重视。就好像一个程序员对你说,就差一些做产品的,又或者就差一个做设计的。而这种不重视,又跟那种在一个不熟悉的领域想当然的勾画愿景和细节的人,异曲同工。殊不知,对于对方的领域和专业有内心的尊重或敬畏,便同样是对自己专业的认可。

可惜的是,人人都是产品经理,所以每一个人都不觉得做产品是一门多么纠结而高深的事情,至少在操作起来,觉得自己的需求想当然、逻辑无漏洞。这个时候,如果自己也没有能力和时间,来证明对方是拍脑袋的,那就只能由着对方指手画脚了。对方沉溺在自己营造的产品愿景当中,是一个无法听进别人的逻辑和观点,进而理性思考的人,那么看着对方往坑里跳,便是对产品的不负责;拉着对方硬不让跳,又被当成对一切说NO的无能PM;跟对方一起跳,是对自己和项目的不负责。三难。最后,便不得不挖空心思把大坑变小,小坑化了,然后继续承担里外不是人的骂名。

所以,碰到一个有逻辑思考、有胸怀倾听的人,多么可贵。而这种能够听取和理性思考的能力,便是最有效的学习能力了。毕竟,没有尊重,何谈学习。

为什么一个项目或工作环境,突然变得让各路神仙都如此热衷于帮PM拍脑袋,而且还时常的理直气壮。

之前的项目中,在处理大小需求、交互、设计及项目管理的决策中,每一次决策都是一次培养信任的机会。PM需要抓住每一次机会来证明自己和推进产品,最终能够理直气壮的对各路神仙提出“欢迎需求变更”的理念。面对的是靠谱的PM,每一次需求变更的提出,都将是一次产品上的再思考和进步,所以 欢迎 二字有其角度和道理。

而各路神仙争做PM,也是因为现在的PM团队已经逐步失去大家的信任。环境的改变,来自集体决策、集体合力。曾经各种靠谱的PM,在一个全新项目中失去聚集信任、形成合力的决策空间,一是 PM能力不足以使之成功;二是 产品方向本身走势向下;三是 整个团队没有集体价值观,各自拍马、邀功、为战。也不能说任何一方面因素能成为主要原因,每一个方面的因素,都可能成为滋生另一方面问题的温床。

久而久之,大家发现产品发展的不怎么样,KPI重压之下,先拼了命包住自己的饭碗。怎么保?是自己做的事情必须严苛的做好,不是自己负责的事情,责任推一推,然后多逼一下责任方。所以就会出现人人都是产品经理,人人都是设计师,人人都是交互,人人都是运营,人人都是市场的状况。而在这里面,把产品经理当成众矢之的,是可以大家一起喷,喷起来最能服众的。何乐而不为。

项目、时间与信任对于一个产品狗是多么可贵

一个产品的成长,靠谱的老大和项目缺一不可。老大可以抗住各方压力,不断为项目给出正确的空间和决策,让项目形成上升势头。而项目靠谱,也能让新产品狗,有学习和踩坑的空间。当然是要踩坑的,要犯错和折腾。而这空间,是要靠大方向正确、大势头给力的项目,给出空间的。产品狗要在这个过程中,快速成长起来,能够独当一面;是否能够快速成长,就看产品狗本身的学习能力了。幸运的话,PM可以在这个团队中建立起属于自己的能力权威和信任,为下一个项目蓄力。

反观一个糟糕的环境,是基本上没有空间给产品狗犯错的机会,因为大家需要严苛的KPI来换取空间和信任,而严苛的KPI之所以严苛,很多时候也是一个夕阳项目拿短期的量换取存在时间的手段而已。

如果你不能让猎人挑武器,又凭什么要求猎人拿你给的武器去打死老虎?

目前看到的大部分项目,多数来自于高层的意志。

产品经理的主要能力,也就演变成,如何将高层意志下的项目,神奇的化解为一个靠谱的产品方向,从而凝聚团队去拼一把。即使是这样,深入的洞悉高层意志,巧妙的转化成正常的项目,也是一件极其考验产品能力、极其有意思的事情。就怕你还在深入洞悉的时候,老板已经急不可耐的塞了一把刀给你,并且喊到,快去快去,把老虎给我抓回来!去了,死路一条;不去,死路一条;想换一个武器再去,大抵还是死路一条,而且会被喷成不听话,让你用刀你不用,活该,创新不足。是的,太着急了。

所以,能够听进别人的逻辑和观点,进而理性思考,是多么可贵的事情。无论面对多大的压力,多困难的局势,都能够保持冷静和理性,尊重事物的规律,尊重领域的专业,才是一个做事情的态度,无论你做的事情,是一个项目,还是一个企业。

 

【短】谈读书

养成读书的习惯,应该是从今年四、五月开始的吧。一方面后悔自己没有早一些博览群书,一方面庆幸自己从现在开始,知道阅读的意义。

现在的人,越来越难以集中精力完成某个事情。

关注点太多,信息爆炸,让我总是偶尔跳出当前要做的重要的事情。这好像是一种放松,但频繁发生总归不好。丧失集中精力的能力,怎么能专注的完成重要任务呢。找到一种保持专注的锻炼方式,例如钓鱼、读书、禅定,等等。就在此时此刻,我还要让耳机里响着音乐。

循着兴趣阅读,还是循着需要阅读。

回顾今年看过的书:洞见、精益创业、浪潮之巅、创新者的窘境、看见。真正享受过程而读完后少有沉淀的,就是一本文艺强调的书,柴静的《看见》。其他的,在阅读过程中,总是不会像读小说一样爽快,但总有值得笔记的收获。兼顾兴趣和需要,也是一种很有技巧的平衡吧,对于一个阅读的人来说。似乎除了《看见》,其他每一本书,我都感觉是值得再次阅读的。最近还在片段的时间里阅读季羡林对话集,这种泛兴趣,不能没有,也没必要太多。

书中的联系

最近看的书当中,创新者的窘境,用了3个月断断续续看完,这其中我搬了家,做了好多大一些的事情。但这本书的阅读过程,应该是我比较认真的完成的,有71次笔记,其中发现了其与精益创业、浪潮之巅中观点的微妙的联系。系统化的读书,能让知识结构形成体系,这个道理听别人都说过,自己从几本书中体会到的联系逻辑,或许就是知识体系构建过程中表现出来的现象。

就像健身一样,让读书成为习惯,那就不得不从读书中得到正反馈,要让自己喜欢上读书。否则,这种苦差事,不会坚持很久。

N叉树和人性光辉

昨天晚上,本胖子做了一个奇怪的梦,我梦见自己,和自己组里的另外两位射手座同事,一起被老板笑嘻嘻的成功开除。我想了一下,决定听着罗大佑的歌,总结一下近期产品心得,以表示对自己业务能力的鞭策,和对其他人业务能力的态度。

职位细分是必然趋势,也是入行门槛降低的直接原因。

刚开始,大家做网站的时候不太讲究视觉和排版,写代码的人搞个差不多,可视化就得了。那时候的工程师都是适合那个时代的小全才,自己写代码自己做交互自己做视觉。后来发现网站太大了,做不过来,得有专门的人帮忙做做前端,所以有了美工。再后来,人机交互更加复杂,面对的用户更加慵懒和白痴,不得不让可用性更加简单易用,就有了专门做交互设计的人。再再后来,发现一个事情被拆分成了设计、前端、编码、测试、运营、维护很多阶段,臃肿的环节导致效率和质量的下降,人员增多导致话语权的分散,产品方向乱七八糟,所以就有了项目管理和产品经理,甚至有了傻傻的用户研究专员这种职位。

现在,盯着36KR看一个月的人,就敢说自己是做产品经理的。盯着socialbeta看一个月的人就敢说自己是做运营的。盯着UCDC看一个月的人就敢说自己是做交互设计的。大家因为可以仅仅在自己这块领域瞎忽悠,而不必去担心其他环节的事情,所以也就对自己的专业技能和眼界降低了要求。一个做交互的不懂视觉和产品,一个做运营的不懂视觉和技术实现,一个做技术的不懂需求和视觉,结果大家配合起来,就是一群乱踢皮球的傻逼。一个问题,被踢过来踢过去,谁都自以为然,乱七八糟,累死了项目经理。

前段时间面试应届生,发现满嘴专业术语的学生比比皆是,真落实到逻辑、需求、设计上,整个人就很容易犯二。这很正常。大家认准一个职位,就在这个职位里混一混,进一个好公司容易,混出好产品,就看后期的潜力和造化了。

总—-分—-总,这也是必然趋势。

真正牛逼的产品,最终还是需要各个环节融会贯通的人参与其中。不要奢望仅仅技术牛逼,或者设计牛逼,或者运营牛逼,就能做成或升华一个产品。虽然一个产品被划分为很多环节,各个环节按照呆板的流程也可以配合起来,但其实任何靠谱的团队,关键环节的关键角色,必然是对其前/后相邻环节非常熟悉的人才。我对这类人才怀有敬畏之心,常年采取跪式服务,仅仅传达需求,绝不敢讲解需求。仅仅商议方案,绝不敢说明方案。但交给这类角色,从初稿到终稿,也就一两回合就搞定。

也就是说,一个越是流程细分、环节明确的项目,就越需要对各个环节了如指掌的通才,这类人是润滑整个项目前进的关键角色。对于这类角色的人选,产品经理自然首当其冲。

在做单纯的交互设计时,别只盯着当前界面的可用性。真正好的框架设计,可以通过框架的整体逻辑,让用户有效的降低学习成本。我最近在看一个兄弟团队的产品,一个触屏界面上的同一个位置的按钮,竟然会变化三次,而且三次的功能完全不同。单个界面来说,这个设计的可用性无与伦比,整体框架上却完全无逻辑可言,完全凌乱。如果你在动手设计之前,有能力把一个需求翻译成一个轻松而单纯的二叉树,然后再从简入繁,那你就算在单界面的易用性上没有建树,至少也是一个架构师。如果你做不到这一点,那就把姿态放低,听别人为你诉说一个更加全面的产品故事,而不是抓住自己那点可怜的逻辑不放。

在CODING的之前,如果你能扔掉自己在编码方面的多年所学,像一个傻用户一样,将一张张界面在脑海里串成一个完整的使用流程,那将会大量减少与PM之间的软磨硬泡,大量减少因为需求不明而导致的无谓的BUG。我对任何身怀编码技术的工程师都怀有敬畏之心,但如果面对的又是产品感强烈的工程师,总感觉他们总会是下一个mark,而不是坐在旁边听我指挥的同事。

无论如何,对前后环节要心怀敬畏的情况下多想一些。如果做不到,还不如转行。

谈一点实际的,做设计的时候,看的远一点。

面对产品上的问题,最可怕的回答莫过于“这是老板让我这么做的”。这是圣旨,我面对这种事情也不知怎么办,只懂得诚惶诚恐的侍奉主子。我肯定还不如别人,甚至可能直接拜拜。

除了以上这一点,其他时候,在动手设计前,应该看的远一些。我欣赏逻辑,这并不代表任何事情都需要带上逻辑的脚镣才执行。逻辑是一种内化的能力,如果你可以,不谈逻辑也罢。如果你不行,就套上逻辑的方法论再动手。

逻辑的手段,不仅仅是把一个事情搞清楚,更重要的是把一个事情搞简单,并且后者更加重要。二叉树是技术上简单但很少用到的逻辑结构,但在产品上,如果能让一个人机交互过程,通过单线无交叉的逻辑顺序组织起来,单纯从框架设计的角度,这一定是成功的。在这个基础上再去考虑单个界面的用户体验,才是一个做事情的顺序。

我最讨厌别人拿着一个狭窄的理由来驳斥一个全局的概念,而如果执拗不松手的抓住这种站不住脚的理论,才更加让人无奈。前段时间,吐槽其他大公司的环节明确、流程清楚,各个角色特别的各司其职,也正是因为这个原因。这种体制是用来混日子的,但却很难在产品方面胜出。

框架设计方面,目前阶段,我大概可以为自己总结这样几个原则:

1、拥有清晰的单线逻辑,即N叉树结构。

2、N叉树结构的任何单个叶子节点,与其他所有叶子节点,在需求和功能上不能有明显交叉,否则就需要合并或重新架构

3、在1和2的基础上,仅在必要的叶子节点之间做索引的交叉,以满足单界面的用户体验

4、每一个叶子节点所代表的功能,尽量用同一套视觉和交互表现。

如果以上几个原则做不到,这个产品需求再靠谱,设计上也是一个失败品。

有层次,并且每一个层次具备唯一性的交互流程,以及一致性的视觉传达,能够让使用者快速的完成学习过程,并形成记忆,这才是一个优秀的设计,通过整体的设计提升用户体验、降低学习成本。

以上几点能够做到的前提下,还需要好的单界面设计,才能让产品有性格,或极客,或简单,或华丽,这些不是逻辑原则能达到的,而是执行人本身的人性光辉的体现,而人性光辉,就只能靠斯巴达了。

 

到底是博客,还是社区?

一次针对轻博客发展方向的探讨,仅作记录。

到底是博客,还是社区?

其实,这个产品没有一个本质或者唯一的答案,不能将其百分之百栓死在一个定位上,所以,绝对是博客,或者绝对是社区,或者绝对是媒体,都不正确。同问,豆瓣是书影音工具还是社区?微博是媒体还是社区?大众点评是查询美食的工具,还是挖掘草根力量点评美食的社区?无论说是前者,还是后者,都不能绝对。

轻博客朝着社区做?还是照着博客做?其实可以换一个问法。

有些人,把它当纯粹的记录工具来用。有些人,把它当做官方信息发布,对外宣传这个链接。有些人,不仅当做博客,而且展示作品给其他人,与其他人互动交流。那么,我们考虑一下,以上几种用法,哪一种对我们更有价值?或者说,对产品更有贡献?

  1. 发布内容,自说自话,内容没有消费价值
  2. 发布符合产品气质的值得消费的内容
  3. 热衷于消费别人的优质内容,随着各种互动,建立站内关系

对这几种用法逐一分析:

  • 只有1,对产品仅限数据价值,可替代性强。
  • 只有2,对产品有数据价值及内容价值,可替代性强。
  • 1/2/3,对产品有数据价值、内容价值、关系价值,轻博客对其不仅是工具,而且是带有关系群体的社区。

当做社区用的人,是产品的early adopter,产品早期来说,这类人对我们更有价值。他们为产品创造内容,将产品中的用户连接起来,建立关系,并吸引周围更多人成为用户,帮助他们建立关系。

所以,我们不妨换一个问题,现阶段,我们为哪一类用户做产品?答案必然优先是1/2/3,为early adopter做产品,从而辐射到更大的人群。

哪一些人,对于当前的产品来说,是真正的early adopter?

机构或媒体是吗?不是,他们的功利性和距离感,让普通用户没有理由,因为他们的存在,而长期留在该产品。短期留在产品当然有可能,但短期,没有意义。

只顾自己宣传,没有社区关系和互动的牛博是吗?不是,他们虽然是个人,但其仍然带有功利性和距离感,将他们的阅读者或粉丝哄到自己的博客当中,短期可以,长期则无效。

只有那些真正在博客中建立关系、记录东西的内容产出者,才具备成为early adopter的必要条件,即1/2/3并存。

补充解释:

  1. 功利心重,不玩儿社区只发内容的牛人来到这里,吸引了10个人到来并关注他。
  2. 社区太小,仅仅10个人,不能满足这个高不成低不就的牛人,所以牛人离开,停止发布。
  3. 关注他的10个人,有5个是没有需求的脑残粉,果断离开。另外5个,虽然没了牛人,但依然有点儿需要这个产品,所以留下。
  4. 那么这个牛人发挥了5分的作用。

问题是,有多少牛人吸引的用户里,有高达50%的目标用户?

为什么,产品当前阶段,带有功利性,或者带有距离感,就不能成为early adopter?

功利性,在产品用户量不多的早期阶段是满足不了的,一方面功利性使得博主的经营方式不够贴近其他用户,另一方面社区内人太少,满足不了功利的目的。

距离感,是功利性催生出来的现象。距离感决定了此人在社区中无法建立双向关系,无法建立双向关系,就完全没有意义。

总结一下上面的结论:

  1. 将某个发展初期的轻博客产品绝对定位在某一个单一的方向上,都是不够严谨的。
  2. 现阶段,应该为“像社区一样使用轻博客的用户”做这个产品,即为early adopter做。
  3. 当前阶段,功利心重、无互动、仅发布的机构或个人,都不是我们的early adopter。
  4. 既然是用关系来吸引用户群,那么,这个产品必须优先为用户关系服务。危害用户关系的事情,暂时做不得。

无逻辑,不产品。

一切事情都有逻辑可循。我相信这句话。做出任何产品决策的基本依据,大概有两种,一是通过比较顺的逻辑思维,让自己信服决策的可靠性;二是凭感觉做决策。

那么,如果一个尊重逻辑的产品决策者,最好能够把产品需求和定位,用最严谨的逻辑解释的天衣无缝、无懈可击。如果一个全凭感觉的产品决策者,最好可以在产品里培养最有同理心的感觉。

如果时而逻辑方面想一想,时常感觉方面想一想,这个人多半是双子男?或者是个做市场的。某些产品的产品定位,从一出现开始到1年之后,都在反复变化,那么这个产品背后,多半是有这么一个人在把持。害人不浅。

但如果从逻辑和产品两者,2选其一的话,我宁愿选择后者。这样做的优点有很多,缺点也是有的。

凭感觉做事情?听起来太TMD可怕了。其实这种从感觉出发作出的决策,都是逻辑思维内化为感觉,而作出的。逻辑思维,是天生的因果关系的思维模式而已,在小时候学习数学证明题的时候,就已经内化到思维里面。我们在产品最前线破怕滚打的时候,不断的通过各种条件反射般的试错或反馈,让自己形成固化的思维,这种思维,大概就是所谓的产品感觉。

我们逐渐知道,什么样的措辞用户不喜欢、什么样的格调容易被理解和传播、什么样的信息表达形同虚设、什么样的交互模式最让用户吐槽,等等。这一切条件反射般的快速反馈,正是互联网产品的最大财富。一周之内,有可能出现无数个此类的反馈,让我们产生条件反射,内化成思维模式。这几乎是任何其他非互联网络产品,都做不到的事情。

当然,不同人接受这些反馈,接受速度和程度都有所不同,这是个人能力的差别。如果感觉到自己的接受程度太慢或太迟钝,还是去做公务员或传统媒体,更靠谱。

接着说,这种大量的信息反馈,或者叫做客户反馈、或者叫做市场反馈,就是对产品决策者孜孜不断的给养。用这些给养矫正自己的逻辑体系,再通过校正后的逻辑体系左右自己的产品感觉,再通过产品感觉确定决策,以期待下一次反馈和矫正,这大概就是一个产品往前推进的过程,也是一个PM成长的过程。我相信,就算在国内这个烂摊子,任何一个PM主导的成功产品,成功之路,一定是这种过程的稳定重复的过程。

那么那些失败的呢?这个过程的哪一步出现了差错?一定是PM矫正自己逻辑体系的依据中,掺杂了错误的反馈,这些反馈往往来自公司高官、KPI、市场环境的改变。你不听从正确的用户声音,却被其他不靠谱的声音左右了。SB了吧。

整体来说,最靠谱的产品决策,应该是最前线的产品执行者,通过长期摸爬滚打中获取的大量信息反馈所内化成的产品感觉来做出的。当然,这样就应该让所有KPI都压在这种人身上,谁决策谁负责。但更多的现实情况,往往与这种模式大相径庭。其实,就算大相径庭也无妨,必经本来大部分产品执行者也不靠谱,无论谁决策,都不影响产品失败的结果。可惜的是,少数靠谱的产品,往往也会被这话总情况扼杀。

所以,这种人,大部分都去创业了。

总结一下近期的产品心得

好久没有认真总结最近的产品心得了。积累了很多主题,都在高强度的工作节奏中磨没了。连书都不看的懒人,如果再不养成总结的习惯,就TMD的完蛋了,就变成垃圾产品的产品经理了。

完蛋问题1:慎用设计手段解决需求问题。

发现产品中出现的问题之后,产品经理的作用,最起码应该是把这些问题背后的需求发掘清楚,翻译给大家和自己。交互设计师的作用,则应该是根据需求层面对该问题的解释和衡量,提出对应的解决方案。但真实情况是什么样?有时候,项目紧张,没有条件和时间做完整的用户调研或测试,几个人一起拍脑袋决定,几个拍脑袋的人却都不靠谱。有时候,需求模棱两可,竞品分析一下其他几个产品的做法,然后东施效颦,几个被拿来分析的产品却都不靠谱。

这些都不可取。可取的是,要么,最终以百分之百的理由说服自己;要么以低成本、低耦合的方式进行快速试错。要清楚的跟进,不能糊里糊涂的上线。

这里有一种误区,千万别被看上去还行的设计方案蒙蔽了自己。若需求都没想清楚,再贴切的设计方案,也是一种陷阱,造成功能越做越做的陷阱之一。

完蛋问题2:别为少数用户浪费太多精力。

听到的用户声音,基本都是那部分很喜欢主动反馈问题的少数派。大致听一听就行了。让不可替代的技术资源,去解决大部分用户需要的功能。至于如何判断某些反馈是否是大需求,产品经理的能力问题。

完蛋问题3:别因为华而不实的功能而忘记核心体验

如果是一个邮箱,再NB的容量和网盘功能,也比不上邮箱收发速度。如果是一个相册,再NB的相册模板,也比不上图片上传速度。先把核心体验做到极致再说,别被竞品花里胡哨的辅助功能吓到。

完蛋问题4:数据有时候不是那么重要。

如果不是电商或千万级用户量的产品,就不能拿数据来左右自己和团队的产品动作。一个深谙需求的合格的产品经理,对一个发展初期、相对简单的产品,应该拥有基本的判断力,来自产品经验和对该领域的直观感觉。数据应该发挥应有的合适的作用。

完蛋问题5:别忽视技术骨干的产品建议。

虽然技术男看上去基本上都窝在自己的电脑前,浑浑噩噩的拍着代码。但靠谱的技术,最解产品背后的数据结构和实现逻辑。产品经理将需求翻译成功能、提交给开发之后,最有可能节省时间成本、降低实现风险的环节,是跟技术之间的讨论。讨论新功能如何融入现有逻辑、以后是否拓展新需求进去。经常有眼前一亮的技术建议,让功能更加富有逻辑美感、更加节省实现成本。

换句话说,懂更多的技术、培养技术思维,产品经理就更容易NB和靠谱。我特别享受这一过程,跟工程师讨论技术实现方式的过程。

完蛋问题6:运营驱动产品的本质

真正靠谱的产品动作,来自于最前线的用户需求。用户需求不是靠用户自己喊出来的,是要有人泡在用户里面去发现才行。产品经理就得干这活儿,去运营。一个脱离运营,只做功能的人,基本是还只是交互设计师。

恬不知耻的说,这活儿也只能由产品经理来干,纯粹的编辑、运营,也没办法从运营中抽取和翻译出靠谱的需求,乱七八糟的1.0媒体、门户类产品就是典型反例。

总的来说,产品经理又不是超人,不可能躲过这么多陷阱、克服这么多问题。所以一个产品组,几个默契的产品人一起把关,比较稳妥。

隐性KPI:对项目管理的合理追求

问题:在产品发展和项目推进过程中,如何追求项目管理的科学性和合理性,是恰当的?

下文中提到的所有项目管理观点,全部都以“利于产品发展”为最高优先级的大前提,其他利于团队团结、公司发展等细节都次之。(当然都是可以方向一致、相辅相成的,你懂的。)

在一个产品发展过程中,根据架构背景、项目背景、产品背景三个方面的因素,综合考虑当前项目管理的最后方案,才能保证“利于产品发展”的目标。三个背景缺一不可,少评估一个,就多一份风险,默默的埋藏在执行过程中,并且很难被再次发现。

将三个层面的背景梳理清楚,才有可能综合的判断问题根结,假设:

架构背景:

1、产品、运营、视觉三个方面的跨部门合作;
2、各个部门中的团队考核标准不同,晋升机制不同,团队氛围不同;

3、各个部门中团队,前期没有进行过磨合,并且供职于不同领域的产品;

项目背景:

1、产品上线初期的快速迭代优化状态;

2、竞争市场非常激烈;

产品背景:

1、社区产品,依据线上情况及需求变动,随时作出产品动作;

2、产品负责制,说白了,就是产品部门说了算,并对产品最终负责;

“架构背景”所导致的实际问题:

Q1:架构背景不同,导致:团队之间的思维模式及个人愿景不同(架构无法改变)
Q2:不同的思维模式及个人愿景,导致:合作过程中的细节及方向分歧
Q3:细节及方向分歧,导致:合作过程中的过度讨论及精力消耗,以及最终决策权的实施
Q4:在消耗精力的讨论过程中,反复由产品实施最终决策权,导致:产品负责制的外在表现更强,即产品强势

Q5:产品强势,导致:其他非产品团队成员的工作归属感减弱、工作挫折感增强

面对可怕的Q5,当其他非产品团队成员怨声载道的时候,如何很好的解决这个问题?这也是我们目前要做的选择。

PS:在架构背景不同的前提下,尝试统一思维模式,让不同团队的个人愿景与产品愿景一致。能做到吗?

答:当然可以用各种方式统一跨部门、跨地域团队的个人愿景与项目愿景,比如项目宣讲、团队洗脑。但要质疑的是,这种仅限于表层的苦口婆心,是否真正能够战胜不同的架构背景?在当前的产品背景和项目背景下,我认为不可能。此类产品及项目背景,决定了该项目属于创业项目(大公司也有无数个创业型项目),这种创业项目,不允许让项目核心成员把精力聚焦在团队默契培养和远景统一方面。

如很多同行所说,大公司里搞创业产品,困难比创业公司更大。就是这个原因吧。

产品初创期间,没有一个强有力的默契的大团队,就已经是危险的了。面对这种困难,选一条错路来与架构背景死磕,就更危险了。

下面看看各种解决方案的优劣:

针对Q5的解决方案1:

1、制定明确的需求确认过程,三方或N方共同确认,由产品方面组织,说服各方,正正规规的抹平分歧,降低产品强势的感觉;
2、制定明确的流程控制策略,明确各个环节的时间节点和责任人,并跟踪各节点,控制流程进度,拉平产品部门与其他部门的地位,克服产品部门的封闭感。

即,侧重法制。

方案1的风险:

风险1:对抗“产品强势”而做出的流程设计,导致:合作过程中的需求确认更加严谨、分歧讨论更加频繁、进度控制更加流程化,即“死板的需求、无谓的讨论、机械的流程”。

比如:需求管理无弹性,导致试错成本增大,让各方需求提出更加谨小慎微。为需求做减法,可不是以扼杀积极性为基础。
分歧讨论的频繁发生导致各参与成员逐渐形成逃避分歧的行为惯性,或者导致各个参与成员在无谓的细节中浪费大量时间。

进度控制流程化导致任务质量与时间节点之间的矛盾更加突出。

风险2:“死板的需求、无谓的讨论、机械的流程”,导致:各个团队之间的合作关系比较机械,即将合作过程中的社会规范变为市场规范。

比如:过去我可以跟其他团队成员,共同完成一个作品。现在,我是让其他团队成员为我的产品完成一个任务。

面对靠谱的合作人,我可以因为更高的质量,而放宽时间进度。现在,时间进度的死板与分歧讨论的挫折感,让我与他都开始不自觉的规避违背流程的事情发生。

最终,冰冷的市场规范与无谓的时间浪费,导致:迭代速度下降、产品决策效率降低,影响产品健康度

方案1的适用条件:

1、各方团队对产品或需求把握能力基本靠谱,即,具有说服他人或被他人说服的基本前提。
2、产品发展趋于稳定。稳定的市场份额、用户群、竞品情况,决定了产品已经不需要频繁的大动作,正常的优化速度已经保证产品可以正常存活

3、跨地域或跨部门的团队合作比较频繁

针对Q5的解决方案2:

1、在沟通过程中,产品团队与其他团队的核心人员建立社会规范,让产品与其他环节的重要角色成为好基友,
2、避开无法统一的思维模式和个人愿景,而尝试统一团队之间的近期目标,以保证近期步调基本一致
3、好基友之间在工作过程中产品细节与方向分歧,仍然实施产品负责制,但基友的关系保证了受挫方的感情基础不动摇。

即:侧重人制。

方案2的风险:

风险1:人制过程,需要实施者有更完整的“情感应对”经验,实施起来很复杂,需要潜移默化的搞之。

比如:甚至针对不同的合作角色,采取不同的沟通和协作方式,以保证充分发挥不同合作角色的最大效率和能力。这一点很困难,做不好的话,人制优势尽失。如,有的人适合情感激励,对同一个工作培养出统一的认同感和成就感;有的人适合流程化的合作方式,到时间就交活儿,少废话。

风险2:虽然保证了效率和速度,放弃的则是制度化的工作沉淀和规范,不适宜大规模的项目团队或产品。

比如:人制过程必然导致多数环节的责任人不明确,或由“人制实施方”单方面承担,因此要求关键角色能力过关且素质靠谱,以保证任务产出质量的潜在风险,在周边团队和项目进程的忍受范围之内,且速度最快。不然,周边团队必然怨声载道。

没有制度和流程,导致多数细节无法回溯和落实责任人,则要求无制度无流程的社会规范,发挥更大的作用。

方案2的适用条件:

1、产品需要快速迭代、扛得住激烈的竞争环境,从而要求项目团队效率及质量优先,其他方面次之。

2、产品团队规模较小,各环节间的沟通及配合复杂度在可控范围内。

产品KPI的介入时机和制定方式,对产品很有影响。而对项目流程的期许,也或许是一种隐性的KPI,需要谨慎为之。

总之,在复杂的架构背景下,根据项目和产品背景的优先发展,调节架构背景所导致的各个变量(考核不同、个人愿景不同、能力差异不同等等),才能确定“最利于产品发展”的最优路径。

如果在这一个评估过程中,少考虑了一层元素,就会在流程实施中埋进隐患。表面上,流程顺利了、产出物质量稳定了、时间节点控制更加严谨了,但却很容易为了“顺利、稳定、严谨”,而在过程中付出了更大的时间和精力代价。这些时间和精力代价从哪里来?从产品中来。搞定的是流程,伤害的是产品。并且,这种伤害,却比较容易在“顺利、稳定、严谨”的喝彩声和欣欣向荣当中,被忽视掉。

这些都是人性,总是容易犯的错误,不是说把控就能把控的。比如说,一个总是能够高调满足阶段性KPI的产品,绝对是一个有可能挂掉的产品。而在产品发展阶段,把项目流程搞的“顺利、稳定、严谨”这一个愿景,也很有可能是另一种隐性的KPI,如同PV/UV一样,默默的在工作过程中影响着执行人的思维,从而映射到产品发展本身。

所以,在解决问题的时候,一定不能只冲着问题表面去解决,仍然要综合“三大背景”,周全考虑,才能降低风险,解析出最优方法。

这就需要沉浸在执行细节中,研究细节,记录下细节中表现出的真正问题,对症下药,才最安全。

@劣松 URL:http://www.liesong.me/?p=421

避免过度设计:有所为有所不为

最近在产品的设计流程当中,融入了正儿八经的专职交互设计,反复体验着这种完整团队所带来的优缺点,虽流程完整,但细节困扰。其困扰之一,我感觉应该叫过度设计。
(呃,文章像大长今一样长~~看前做好心理准备吧。)

过度设计,一般是说技术开发中,对于逻辑复杂、技术先进的过度追求,导致了技术框架虽看似华丽却复杂难用。若说到产品功能及交互的过度设计,应该是“过度追求体验完美、需求满足”而导致的“实际体验下降 or 长期产品定位偏离 or 功能没人用”的悲惨结果。

为什么会导致过度设计?

原因1:一味追求体验

所谓大团队、多部门的互联网公司,在开发产品时,设计资源往往是产品部门无法把控的,一枚宝贵的设计师,往往曾经跟过很多产品,总是被派来派去,而不是长期跟进某一个产品。因此,再如何苦口婆心的为团队成员灌输市场情况、产品定位、项目目标,也不可能形成合作过程中的默契感。没有默契,就没有产品归属感,只有流程管控和死板的执行。

如此工作框架下的设计师,其首要目标很难与产品发展保持一致,而是要为自己的设计作品照想,要让这个产品中自己负责的设计部分,被他的主管认可、被主管的主管认可。这合情合理,天经地义。但是,他的主管,却与我们的产品很少有交集。这就是苦逼的开始。

在这个时候,设计师必然希望每一个设计细节都能考虑周全、设计完美,几乎希望摒除一切不好的设计,以在其老大面前证明自己的能力。但是,假如眼前这位设计师,没有眼观六路、耳听八方的强大能力和视野,则极有可能会被这种追求完美的设计思想所拖累,让一些设计细节走了样。

设计师挖空心思,拿出一份自认为近乎完美的作品,并苦口婆心说服所有人相信并执行,即使隐约感觉到不对,但乍看似乎完美无缺。推进到开发或上线测试阶段,真正的问题从走样的“完美设计”当中渗透出来,淋伤的则是产品计划,傻眼了。重新改、重新写代码、推迟发布。

这种过度设计,不止伤害团队和产品,还会浪费时间:

• 挖空心思的追求完美,比常规思路的设计,多耗时3天。
• 产品与设计师一起确认设计细节,在“非预想的设计细节”方面博弈一番,产品说“我没见到过这种设计”“开发和维护成本大,浪费时间啊”,设计说“这种体验确实是更好的”“那个竞品的模式真的很恶心”,多耗时1天,并且徒增设计师、产品的挫折感。
• 开发非系统默认的精致设计细节,多耗时3天。
1周,就这么浪费了。就是这样。

原因2:一味的满足需求

研究用户需求时很容易陷进去,然后被非理性所控制,假如自己没有足够的经验,而身边又没有靠谱的人提醒,就会有一堆本来不是需求的需求,成为开发任务,所以才有了后来滥大街的一句口号“产品减法”。最苦逼的是技术:“辛苦写好的代码,说减就减,TMD的当初都干嘛去了,一群SB!”我往往都随声附和,暗骂一声自己。。

以下两种常见的情况,会导致“过度满足用户需求”的问题:

一是对用户声音缺乏筛选。用户不是产品人员,其在使用产品时,提出的问题、表现出的困惑,一定是偏自我的感性意见。“我不认识这个按钮啥意思!”“我感觉全部展示出来才好看!”“这个功能特别不方便!”

二是对需求研究无法保持理性。“假如自己给自己评论会怎么样”“要告诉用户不能这样做啊,直接砍断不好吧”“用户想这样,然后在那样,然后在这样,就会出现困惑了呢!”“直接把入口铺出来,这样才最方便!”

总之,当在理解用户需求时,如果不能以一种正常、理性的心态推演使用场景,很容易被上面这种问题带到沟里,最终导致过度设计。(身边靠谱的产品人,多是理性起来不是人的射手座~~~呃)

功能以及交互上的过度设计,最终可以导致一系列后果:

1、浪费时间,延误甚至失去市场机会!
2、在过度设计的博弈中自我耗损,伤害士气!
3、过度设计的功能,看似华丽,却无人问津,白搞了!
4、最可怕的问题:过度设计的细节,导致错误引导,培养了错误的用户习惯,并且这一过程,不可逆!

第4个问题,有必要详细描述一下:

• 假如只是一个功能入口,入口A比入口B更加便捷,用户只会记住A,而忘记B。假如产品设计之初,希望用户在途径B时,享受更多的推荐或引导,那么B的这种作用就发挥不出来。而这个时候,再想删掉A,用户会骂死产品。若想修改A,则是动框架,耗费成本。

• 假如是一套用户使用流程,流程A比流程B更加舒适自然,但是如果没有考虑到A和B对于整个用户引导的差异,而草率的选择了A,那么这种用户引导的差异,或许会导致产品定位的偏离。(近期某款雷声很大的新产品,正是犯了此忌。)

如何减少过度设计的发生?只能对症下药。

不要一味的追求体验:

•  一是,让产品设计师更多的向产品靠拢,增加默契感,形成产品归属感,在做事情的时候便可以有效的规避不信任的细节争吵。

•  二是,改变不合理的“产品负责制和确认层级”机制,产品负责的归产品。这样才能在通篇考虑“市场、定位、时机、成本”的时候,做到相互信任和理解。只有让产品横空出世,整个产品组才能真正有所收获,而不只是通过一个设计作品来增强自己的满足感。实实在在的成功最重要。

面对需求,保持理性:

至于产品人,只能多犯错多磨练,让自己靠谱多一些。总之,在产品创意时不失感性,但在面对需求时应该保持理性。幸运的话,进入一个整体靠谱、左右权衡的经验团队,会让自己的成长方向更正确。


最后,奉上一张小图,偶见于某产品的动态首页~参不透。
总之,希望自己做到有所为,有所不为。
@劣松 文章地址:http://www.liesong.me/?p=344

产品管理:用机制降低风险

最近一直在跟的一些项目,过程中出现了一些反复,原因有很多。深入分析一下问题根结,希望以后能避免。

关键词:产品负责制、确认层级机制、产品脊梁、靠谱

问题:

1、项目初期,产品原则已经开会统一、皆大欢喜,但中期却在产品原则上出现分歧。甚至在产品面临上线时,还有人为该产品赋予新的定位。

2、产品设计环节中,在产品需求和定位已确认的情况下,纠结在“不符合需求、偏离定位”的设计细节,僵持不下、浪费时间、拖垮精力。

3、跨部门合作的项目,设计部门提交的工作结果,经常被他们自己的上层或左右推翻重来,即使对产品有利,却伤害整个项目,伤害自己人。

根据这些问题,需要问很多为什么。

为什么初期统一过产品原则,中期却出现原则上的分歧?“发起分歧者”所具备的必要条件是什么?

首先需要问公司:产品负责制,到底有没有明确和落实?其实,产品人员已经也应该,把对产品的长期责任,承担在自己身上。但是公司层面和总监层面如果没有强有力的确认产品负责制的归属,我们这种自我承担的产品负责制,永远不会在关键时刻发挥作用,而只会左顾右盼。

在产品负责制尚不明晰的情况下,即使团队核心成员开会确认了产品原则,也永远不会有一个强有力的角色把产品原则贯彻到每一个阶段,初期产品定位和产品原则的会议确认,是没有力度的,只是表面上的统一而已。

原因很简单,当一切顺风顺水、条条大路通罗马的时候,旅游团众大佬必然跟着美女导游就OK了。当路遇挫折时,导游就算熟悉路途中的险恶,也仍然不是无法把自己伪装成团队的菩萨,左右不了各位大佬的想法。(默契,可以克服这一问题。但在大公司的营盘里面,想培养一个默契而完整的项目团队,一般是可遇不可求的。但默契的产品小组还是有的。)

在以上这种情况下,发起分歧者有什么必要条件?一是长期跟进产品,了解最初的产品原则和定位;二是了解整个团队的工作重心和产品市场情况,而不是只熟悉自己所管部门的情况。可悲的是,熟悉了以上两点的人,往往不会做出不靠谱的决策,而去伤害整个项目。

既然已经确定了产品需求,为什么会出现“不符合需求、偏离定位”的设计细节?为什么会在这种问题上浪费时间?

这种问题出现非常正常,当设计人员没有做充足的竞品分析,也没有充分理解产品的情况下,总会在设计时出现偏差。只要产品人员说明需求和修改原因,说服设计人员回归需求即可。可怕的是“僵持不下”,设计人员坚持己见,认为设计细节是正确的、靠谱的、符合产品需求的,产品人员却无法认同。僵持不下时,应该搁置问题,继续推进项目,而不是在这种问题上纠结一个下午,还把各种用户调研、应用实例搬出来说理。

最终做决定时,如果依旧僵持不下,那么谁对产品长期负责,谁做决定。谁对产品长期负责?回归的上一个问题。

为什么“工作结果”可以推翻重来?谁赋予了提交者“提交的权利”,又是谁赋予了推翻者“推翻的权利”?

首先要问的问题是:是不是根本没有明确“确认层级”的工作流程,或者只是口头明确、表面默契而已?
比如一个设计稿,当然要由直接负责人A确认,没有问题了,再交到下一步去执行。那么这个负责人A需要评估:自己是否能够保证这一个确认结果是最后结果。如果不能保证,那么再提交上一层的负责人,让他确认。但如果上层负责人曾经授权了负责人A的确认权限,就不应该在A已经确认之后,轻率的推翻确认结果。

在这种确认过程中,应该在每一个项目实施之前明确“相应的设计工作,需要有相应的确认层级”,这一点至关重要!“确认层级”都不明晰的情况下,首先应该检讨的不是设计质量没有达到要求,而是为什么会出现这种流程上的漏洞,让不符合设计质量的东西推进到下一步骤。漏洞不堵住,就没有资格反复插手,这样既伤害团队,也拖垮自己。

相反,当指定了项目设计工作的确认层级之后,再出现提交设计稿不合格、推翻设计工作不符合流程的情况,就可以明确的质疑“提交的权利”和“推翻的权利”,是否符合“确认层级”的流程。这个时候,是能力问题的就调整确认层级或更换负责人、是流程问题的就贯彻流程,比大家互相装无辜更加务实。

最后感叹一下,产品经理是妥妥的炮灰,哪个环节出问题,都可以揭出产品规划和项目管理的漏洞和伤疤

一个产品项目,从立项、交互、视觉、开发、测试等各个阶段,总会因为各种问题而反复伤害。尤其是跨部门合作、多环节配合的流程,伤害问题发生的隐患比比皆是。这个过程期间,产品经理的职责,就是想尽办法,避免各种伤害的发生、避免各种伤害打击到核心成员、伤及团队重心。

可悲的是,在大部分环境下,卑微的产品人员不仅无法预估各种隐患问题,对于已经发生的伤害问题也没有足够的防备资源和职权。这个时候,产品经理,就是妥妥的炮灰,众口一铄,灰飞烟灭。最后,产品经理仍然必须站起来,拖着被各种问题所累的核心成员,继续把项目推进下去。

不知道这种情况,在其他公司是否常见。当没有固化的产品负责制和确认层级管理机制的时候,深埋问题的跨部门团队开发产品,然后暴露出一堆问题,一遍又一遍的伤害每一个产品。所以,这种公司总是出现一堆一堆的打折产品,承担着一堆又一堆不给力的数据和市场境况,最后担责到产品人员身上,该调走的调走、该跳槽的跳槽,再招进下一批未知轻重的欣欣向荣者,如此反复、以至无穷。

关键角色位置的靠谱牛人,是产品的脊梁

产品团队,碰到这种复杂的情况,唯一的救命稻草,就是产品各环节的关键位置,有靠谱的关键角色把持,然后这类关键角色需要保持持续的头脑清醒、精神集中,在任何阶段都能回溯最初的产品原则、评估当前的团队重心和高层要求,统一麾下执行者的行动,并说服高层。

从这个角度讲,没有那么多流程管理和部门配合的小团队产品和创业公司产品,要更加安全、更加靠谱。近期组里的一个小众产品,没有大资源投入、没有多部门合作、没有高层压力、没有战略意义,虽然选择了一条难路,但整个产品从设计到运营,让外人看来,显得张弛有度、节奏明确,这就是一个明显的例子。

只要人靠谱,做什么都是靠谱的。如果人本身不靠谱,在任何角色上,都会出问题。至于什么问题:细节不到位、文档及版本控制逻辑不清楚、决策前后矛盾、协调成员配合乏力、工作重心聚焦不正确、沟通不主动……比比皆是。

希望自己靠谱一点。
@劣松 文章链接:http://www.liesong.me/?p=334

不靠谱的互动驱动因素

现在,凡是稍微大一点的网站,一定有一张个人主页、一堆用户关系、一串动态信息流、一批用户推荐。用户累不累?从facebook和buzz开始,这种累的感觉,越积越多、比比皆是、避之不及,只能逆来顺受。

记得刚开始玩儿论坛的时候(印象最深的两个论坛:既生、天堂海,都关了),设置自己的头像、介绍、签名,重视的不得了,就像在选自己唯一的面具。现在,到一个社区,看见选择头像就烦,随便扔一张系统图片在上面;看见一堆用户推荐就恶心,对这些推荐出来的UGC几乎没有信任感。

问题出在哪里?当然无法一概而论,感性的说:
哎。大家都太同质化了,纷纷在一种模式下拼命。拼显性内容、概念定位、个性推荐、互动关系的激励和维护。

当整个市场竞争越来越激烈(尤其在中国…),大家的动作就变了形(马甲账号、无情感用户、过分的内容推荐,等等),变形的动作越积累越多,把页面搞的拥挤不堪(初进首页就给你一个双层导航,吓死个人),吓走了新用户、烦走了老用户。这个时候,一股“需求减法”的清风袭来,仍然也有积重难返的重症社区不为清风所动,要么变卖家产(myspace),要么半死不活(某社会、某某空间……你懂得)。

社区怎么了?
论坛概念太旧,爱玩儿的人越来越少。存活下来的论坛,不太会继续吸引大批90后在内的新用户,只能吃老本儿。泛泛而谈的综合论坛,有的可以撑得久一些,像天涯、猫扑,有的慢慢就挂了。侧重服务性的论坛或本地论坛,可以活的好一些,但有自己的瓶颈,瓶颈就是“服务领域本身”或“地区范围”之内。
博客压根儿就不适合做社区。当年国内博客向社区化转型的大潮中,撑得住并活下来的,只有门户,其他全死。就目前而言,传统博客,更没有社区化的必要,应该坚定工具化的决心。
社交网站,一旦没有吃准用户互动的最首要驱动因素,几乎是死路一条。考虑到这一点,社交网站其实是最难做的社区。一不小心,就会被用户行为欺骗、或被自己的愿景搞的一厢情愿。可悲的是,现在竞争最为惨烈的战场,正是社交网站。

切入正题:坚挺的互动驱动因素:(下面只说社交网站,不含论坛、博客等其他)
搜狐博客转型搜狐空间,多么**的行为。百度空间天天搞搭讪,多么**的行为。开心网竟然想借没有粘度的游戏社区搞微博模式的群组讨论(海贝),多么**的行为。网易梦幻人生还在线上,多么**的行为。(KAO,就你不**)
所以,俺窃以为,拥有坚挺的互动驱动因素,才是最有力的社交网站强心剂:
A 之一,是强人际关系。(包括间接关系在内的其他弱人际关系,皆因强关系而发挥作用。没有第一层强关系,其他都是浮云)
B 之二,是基于个人主观行为的强需求关系。很强很强的需求,比如:寂寞男和单身女、强的购买欲和个体买家。(为什么强调“个人主观行为”?:因为需求关系双方中,凡有一方是以团体为主,则不可能做社交)
C 之三,是仰望关系。我仰望JOBS,所以我乐意在“貌似”对等的互动关系基础上,围绕他展开互动。(切… 貌似对等,实际根本不可能对等,但刺激用户互动,足矣)
我小心翼翼的列出上面三项,绞尽脑汁想不出第四点了,也想不出三者全不依赖,而能成功扩张的社交网站。(真够小白的)

还有一个互动驱动因素:
D 但不一定是之四,基于优质内容的互动(无A/B/C,只有“优质”二字)。问题来了,因素D,这货到底行不行啊?
我感觉,几乎不行,尤其是在中国。优质内容当然算是互动驱动因素,但这一因素较A/B/C三个货,还不够强,而且极易受到其他因素的扰动:
1、“优质”本身就是一个主观判断。本身是一个仁者见仁的事情,就不要拿来坑用户了。退一步将,就算套用某一垂直领域内优质内容的公认标准,来判定优质内容。你能保证每一个用户心理都揣着这个标准?多数是靠编辑来搞定的吧。呵呵
2、“优质内容”撼动不了用户性格。人都是自私的、懒惰的、贪便宜的、虚伪的,尤其是在中国。这些不利于互动行为发生的用户本性,随随便便就可以战胜“优质内容”激励下的虚荣心和交流欲望。没有其他强因素(A/B/C)的助推,“优质内容”真的很无助。

可能还有其他扰动因素,但单纯考虑到这两点,我就很绝望了。国内,靠因素D起家的大社区,豆瓣应该算是一个擦边球的故事,优质内容建立在二部图兴趣关系的基础上,并且沉稳的养活了小组。除此之外,其他成功案例少之又少了。

为什么要谈“互动驱动因素”这个问题?
最近讨论到一个问题,tumblr到底是一个什么网站?如果算是一个社区,它是怎么活下来的?
无可否认,tumblr的互动关系已经纯熟,大量的reblog和like已经撑起了社区用户群的活跃度。相比于国内的同类网站,tumblr的优势有三:一是良好的互联网环境(你懂得),让用户可以安静正常的玩儿同一个产品;二是普遍外向热情的用户群,即比含蓄的国人更加热衷表达的老外;三是较易导入真实人际关系(FB和twitter为tumblr带来了巨大的流量和用户群)。

国内是啥环境?竞争恶劣、用户含蓄、真实人际关系不易搞(人人封点点哦~~)。所以,若希望国内同类产品像TUMBLR一样飞驰,真的很难。点点这个“高质量内容社区”,走这条路实属不易,但也没有其他路可选。前几天点点的JACK说“我们仍处于将人际关系与信息结合的初级阶段。这是一个巨大的机遇”,点点近期一系列拓展用户群的活动,也明显是针对真实人际关系。方向对,效果就难说了。况且,即使导入了真实人际关系,这种关系也要配合合适的内容运营一起发力,才能成功刺激互动。

说真的,大家都很忙,CPI如此给力,谋生太不易,哪有时间享受兴趣…

综上所唠,国内类tumblr产品,要结合国内大势,构思一下新规划,至少给自己留一条后路。不能继续拿一个“不靠谱的互动驱动因素”骗自己了。有了新规划,到时候可以对自己说:社区做不成,做一个某某某也是不错的嘛。

有了新规划,至少心安理得一些。做新产品,安全感也是很有必要的,哪怕是自我安慰。呵呵。
写到这里,思考一下A/B/C,下一篇文章续写新规划。

文章地址:http://www.liesong.me/?p=331       @劣松