【1024】种子用户是迭代的必要条件

2014年4月14日

周末,听到一个故事,有一家公司的一个新产品,在内部迭代了6次,据说,每一次发布,大家一看不满意,然后就改一版,如是6次(当然,故事的部分情节是我编的)。

有感而发。

这不叫迭代,迭代的概念和“种子用户”是连在一起的,自己内部改改改,那只能叫没想清楚就动手了。我们看看种子用户是怎么辅助迭代的吧。

他们是一群,受你要解决的那个问题困扰最深的人,从产品概念的验证开始,到需求采集阶段,就需要找到并维护好与这群人的关系。

他们可以帮产品很多。

第一,   愿意配合,因为他们困扰很深,所以有人来帮助解决,自然很高兴。如果你的产品找不到几个很愿意尝试、积极配合的人,那只能说,你的产品概念有问题了,并没有解决某些人的痛点。

第二,   可以提供很多有价值的信息,俗话说,久病成良医,他们一定已经在自己尝试解决这个问题了,去了解他们现在是怎么做的,让他们谈谈对新产品的想法,你一定能收获很多,所以,种子用户也叫“用户顾问”。

第三,   可以忍受缺陷,种子用户们虽然很想解决问题,但,作为用户,还是会因为资源的缺乏,有想法但没能做出很好的解决方案,这时候,有一个方案了,他们是可以忍受缺陷的,而这种不完美的产品,才是真正的迭代产物,在你的功能列表里筛选出MVP(最小可行产品),做出来,推给种子用户们。

第四,   可以成为义务推销员,如果他们爽了,他们一定会帮你宣传,所以,在选择时,能找到某些细分领域的意见领袖是很重要的。

因为这批用户的高价值,所以,一开始,尽量不要收费,这是小钱。我们看到越来越多的行业都在充分利用“种子用户”,他们叫“内测、封测”等,并且把这个过程的营销作用给尽量放大,比如做手机的小米、做牛腩的雕爷……

iamsujie的各种二维码

iamsujie的各种二维码

【4026】产品原则就是产品的宪法

2014年4月8日

最近听了几段罗辑思维的脱口秀,其中一段讲美国建国初期,几位老大们昏天暗地开了4个月的会,制定美国宪法的故事,这个宪法,nb就nb在短短几百个字,用了200多年,只添加了一些修正案。

这事儿给了我启发。

国家需要宪法,而国家也可以看作一个产品,那么,产品的宪法是什么?翻开《启示录》,我知道了,就是产品原则

美国宪法

首先,我们要简单说下为什么要有产品原则这个东西,美国宪法的序言说——

我们合众国人民(文图的We the People就是全文的前三个词),为建立更完善的联盟,树立正义,保障国内安宁,提供共同防务,促进公共福利,并使我们自己和后代得享自由的幸福,特为美利坚合众国制定本宪法。

 

然后,要确定产品的价值观。

总结起来,美国宪法的价值观就是七条——人民主权、共和制、联邦制、三权分立、制约与均衡、有限政府、个人权利。举例第七条,就是说“个人有言论自由和新闻自由等”。

对于你的产品,比如说就是“小组是成员们的私人领地,管理员尽量不要干涉(豆瓣)”、“每个人都可以在某时某刻成为别人的老师(知乎)”、“有激情有方法的人,做自己想做的事,效率会高于完成任务(阿里赛马)”等。

 

接着,是实现产品目标的方法论。

比如,产品团队是如何组成与分工的——“实行资产阶级性质的联邦制,肯定了以立法、行政、司法三权分立。规定立法权属于美国国会,并规定了国会的组成;行政权属于美国总统,以及规定总统产生的办法;司法权属于美国联邦最高法院,并规定最高法院的组成;各州的相互关系和义务。”

又如,如何做产品决策——“美国宪法明确了由选举产生的政府具有唯一的合法性。人民通过选举或者指定产生的政府官员和议员来行使权力。”

 

你的产品,还需要想清楚,目标用户是谁?有哪几种,他们的优先级如何排序?产品未来一段时间的目标是赚钱、还是烧钱获取更多用户?……

 

随着时间的变化,产品所处的市场环境、竞争对手、用户属性也会不断变化,所以,还必须要有一个产品原则的迭代优化机制。所以,美国宪法也提供了修正案提出和通过的程序,议员们也可以修改美国宪法和其他基本法律,甚至还可以重新起草新的宪法。

 

产品原则,是整个产品团队必须达成共识的东西,我们在工作中的大部分争吵,追根溯源,都是产品原则不一致,比如你认为卖家重要、他认为买家重要,你认为要拉新用户、他认为要先留老用户……

对产品原则,哦不,是美国宪法感兴趣的同学,可以看这里,确实是体会一个大产品架构设计的好案例。

iamsujie的各种二维码

iamsujie的各种二维码

【1023】KANO模型再理解

2014年4月2日

结合自己的理解,试着把KANO模型本地化翻译一下,希望对大家平时做产品的过程有用。

KANO模型

KANO模型

上图是原始模型,现在我改下说法,三条曲线从“功能”的角度去理解。

最下面一条曲线叫“基础(功能)”,没有的时候,用户对产品无法接受,有了,也不会夸奖你,用户会觉得这是理所应当的。所以,必须做,也叫“must have”,不管成本有多高都得做。在功能列表里,这种功能就不用参与pk了,比如手里的打电话、发短信,当然,也许多年以后不是了。

最上面的曲线叫“亮点(功能)”,没有的时候,用户也想不到,有了以后,用户会赞不绝口,wow,惊喜。比如手机的指纹识别,解决了安全(更多更复杂的密码、证书、外挂硬件等等)和方便这一对矛盾的需求。亮点功能的特性,使得我们在选择“做哪个”的时候有一个诀窍——挑选成本低的亮点功能去实现,比如苹果电脑的呼吸灯?不要费太大的功夫去做一个亮点——除非你在大公司的里的“研究中心、创新中心”。你认为的亮点到底能不能点亮用户,是要运气的,相比下面一种功能,它更像早期投资。

中间的叫“期望功能”,曲线比较平,也叫“nice to have”,这里体现出用户调研的局限性,如果我们简单的去问用户,只能获得“期望功能”,为什么,因为基础用户觉得你肯定有,不会提,而亮点根本想不到。那要让我们的产品更加丰满,怎么办?基础功能,我们说,要靠产品经理的领域知识来弥补,你是做手机的,就必须知道手机要能打电话;而亮点,就需要靠对用户需求、场景、人性的理解了,也就是我们经常所谓的“创造需求”,其实,你只是探究到了用户深层的需求,然后创造了一个解决方案。

基础功能只能消除不满,不能带来满意,亮点的重要性在于,有了,才有口碑传播的概念,没有亮点的产品,只会有人用,没有口碑。

一个功能的类别,随着时间会变,一般从亮点到期望到基本,比如手机的彩屏、和旋铃声,在十几年前还是亮点,今天已经没人再提。所谓饱暖思淫欲,由俭入奢易……这也是人类创新进步的源泉。

iamsujie的各种二维码

iamsujie的各种二维码

【0020】产品岗位细分的一些思考

2014年3月24日

前几天和朋友聊到做产品的几个环节,简化一下可以分为4步:产品规划、产品设计、产品开发、产品运营。正好可以对应比较常用的产品经理岗位细分:Product Architector——主要负责产品架构与规划;Product Designer——偏向需求分析与设计;Product Manager——做项目管理、团队管理的工作,需要对技术有深刻理解;Product Marketing——负责运营相关事项,市场、营销、推广等等。

一个人能做到4项都强最好,这样可以节省巨大的沟通、管理成本,但养成这样一个神,至少需要十几年,所以,在国外,我们常常看到的一些40岁左右的产品经理,那些确实是大包大揽的“真·产品经理”。

而国内这个行业、这个岗位,发展时间还很不够,这种人至少要5~10年才可能成批出现。

但,对于一个团队,这4项都要有人精通,所以,有意思的来了,我们闲扯起BAT三家,一个产品新人,通常都是从产品设计做起,因为这是最好“培训”的“产品经理”,但前路不同,各自有各自的解决方案,俗话说的好——百度的技术、阿里的运营、腾讯的产品,各位做产品的同学,不知有没有体会。

先说最熟悉的阿里,以淘宝为例。从产品设计做起,但因为淘宝的大框架是商业驱动的,所以具体的设计相对不重要,结果就是大家都觉得阿里的各种产品都比较“糙”,而公司里有话语权的,是运营,他们在做了产品运营之后,还会把持着产品规划,产品经理做着做着,就会向下游挤压,担负起项目管理、团队管理的工作,于是,我们可以听到大量的产品同学抱怨自己根本没时间去仔细琢磨产品,而是整天在pk、说服、找资源、催催催。曾几何时(2007年左右?),淘宝UED团队在业界的地位是超过腾讯CDC的,但在淘宝,UED也面临着类似的被商业、运营挤压的局面,以至于略感失落。这个模式,在移动应用上还能不能打开局面,是很大的未知。

再说腾讯,从产品设计做起,产品开发的事情研发同学很专业,基本把项目管理什么的全包了,而产品运营又比较弱,也就没了很多“业务方”,所以他们可以用心在产品设计上精雕细琢,但事情总有两面,扎得太深,离开腾讯的土壤就很不习惯。腾讯产品大多数是典型的用户产品,所以需要产品经理在设计上下狠功夫,于是,自然腾讯的产品经理离用户最近,其实他们是最懂一个个个体的,这个基因的优势在移动互联网的形势下是会放大的,移动的特性也是和C类用户强绑定。

额,腾讯和阿里对比比较强烈,百度不太了解就不说了,烂尾去吧。

 

产品设计是可以学的,而产品开发几乎只能在入行前几年打基础,从运营起步,我总觉得不扎实。最后,殊途同归,产品规划是比较好的终局出路。So 个人觉得最优路线是:

产品开发产品设计产品运营产品规划。

刚开始想这个问题,大家可以讨论。

iamsujie的各种二维码

iamsujie的各种二维码