人人都是产品经理——iamsujie

写给门外晃悠的同学：想做产品经理，如何入行？那么，转行会碰到的第一个问题又是什么？

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

有感而发。

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

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

他们可以帮产品很多。

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

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

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

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

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

iamsujie的各种二维码

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

这事儿给了我启发。

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

美国宪法

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

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

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

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

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

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

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

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

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

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

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

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

iamsujie的各种二维码

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

KANO模型

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

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

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

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

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

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

iamsujie的各种二维码

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

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

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

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

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

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

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

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

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

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

iamsujie的各种二维码