3.1 产品经理入门指南
枯叶
正如所有的行业一样，产品经理也会经历三个阶段的成长，这将会是我们从入门到独挡一面的里程终点，同时也是从专业角色上升至管理角色的重要起点。
产品助理→产品经理→产品负责人
2018年，产品经理的竞争将会越来越激烈，这个行业已经经历了十多年的发展，作为行业的从业人员，我们需要更专业化的技能认知，更清晰的阶段认知。
一、产品经理不是天生的
请你忽略网络中，关于产品经理的片面观念，这其中包括有想法就能做产品经理等等。
“我是否适合做产品经理”“我是否不适合做产品经理”，这两个问题将会是产品入门的拦路虎，会给我们产生很大的伤害，尤其表现在我们的信念上，忽略他们吧。
10年前，我们无法准确定义产品经理是做什么的，10年后，已经有一些模糊的概念了；再过10年，也许我们会引来更清晰的认知，甚至开设大学课程和专业。
Tips：产品经理是一个专业角色，天赋有用，但却不是最重要的；实际上，我尚未遇到将自己的成功或失败归根于天赋的产品经理。
我们没有办法尝试告诉一位尚未接触编程语言的朋友，“很遗憾，你不适合做程序员，”又或者说：“天啦，你真是最有潜力的程序员，”毕竟，他尚未经过学习。
作为产品经理也是一样的：即使已经在产品经理的岗位上，没有经历过相应的学习，那你的过失，更多的是由于“知识”的不足，而不是“天赋”不足。
与程序员不一样的地方在于：产品经理目前所处的环境并不像编程行业那么成熟，只是近年才出现产品经理的分享浪潮；而遗憾的是，我们必须经历更长的时间，才能将零散的知识整理成体系。
这给现在的我们提供了更高的要求：忘记“挫败感”吧，因为这是我们必须经受的考验。
二、产品助理
本文提到的角色均为产品经理的成长阶段，不是具体的岗位。其实有很多朋友在产品经理的岗位上，做着产品助理的事情。
作为我们迈入这个行业的第一个阶段，并没有大家所认知的那般困难。
网络中盛传的“低门槛”与相应的各种“技能分享”，共同组成了一个“悖论”，这是一个思维误区。我们需要清醒的认知到：作为产品助理而言，应该做什么。
大部分的技能是在产品助理往上成长时，所需要补充的知识面积，而非成为产品助理的硬性要求。在这样一个特殊阶段，最核心的目标是“打基础”，而不是“拍脑袋”。
1.职责
助理的主要职责有三个：撰写需求文档，设计原型文件，收集资料。在许多团队里，真正能起到推动项目效率的，是产品助理，就像“齿轮”一样，转动的越快，整体效率越高，质量越高。
Tips：效率是一个变量名词，这就表示产品助理的职责存在可量化的系数，具备大小和差距。
让我感到非常遗憾的事情是：大多数产品助理将自己定义成了“培训生”，理所应当地接受“任务少”“不被重视”等现象。
产品助理是一个正规的职场角色，即便是工作环境并没有为这个角色量身定制工作内容，我们也要有自己的觉悟。
依照目前互联网团队的成熟及协作方式而言，优秀的产品助理足以提高整个项目组40%的工作效率。
这并不是一个随意提及的比例，实际上在我亲自参与的项目里，这个比例会提高到60%。根本原因在于这样的情况：
Tips：由于时间，精力分配的问题，产品经理和产品负责人会将精力更多的投入到思考和底层设计里，在二八原则里，80%的产品内容，会由助理分担完成。
偶尔，我也会做一些产品入门培训，而且会重点培训产品助理；毕竟我们所处的环境不一样了，现在随便找个人，都能对互联网说一二三；于是，我更关心大家如何做。
这是我个人的一个观点：没有认真经历助理环节的产品经理们，也许会是未来被淘汰的第一批产品经理。
2.成长：用需求文档建立功能认知
成长取决于我们所做的事情，以及做的数量和频率。
我们已经清楚产品助理的三个主要职责，相应地，我们在做这三件事情时，就会收获成长。
比如：当用户或者客户告诉我们一个“需要”时，我们总不能扮演传话筒的角色，将“需要”传达给开发——我们在这个过程中承担了翻译的任务。
案例：
●用户：我想上传我自己拍摄的照片，这样别人就更容易关注到我（用户需要）
●产品需求：图片处理，图片上传，相册，图片列表，图片详情，评论，删除，举报，点赞。
这需要我们自身对功能有一定的认知，能够将一些口语化的“需要”翻译成功能化的“需求”。
需求文档在我们成长过程中，会持续地将我们曾经或者正在实现的功能变成文字记忆，储备在我们的头脑和意识态里。
Tips：最好的存储办法是设计一个自己的“功能需求库”，不仅仅是工作中的需求，闲暇时间也可以将我们平时使用的产品进行分析，并封存到我们的“功能需求库”里。这些都是未来我们做某产品时，宝贵的材料。也是我们职业发展的一条快车道。
你能想象100个功能认知与1000个功能认知的差距吗？这大概就是产品新人和产品老司机的差异。
3.成长：用原型图建立设计认知
原型图的重点并不在于输出的图形结果，而在于设计的过程。
我不太建议大家去模仿其他产品绘制原型，实际上，我禁止我的学生模仿其他产品绘制原型。
原型图是一种表达介质，可以用axure、sketch甚至手绘都可以，这非常的简单，以至于在模仿的过程中，没有任何价值产生。
在设计原型图时，我们需要经历这样几个步骤：
●构造画板（有边间的空间）
●优先绘制稳定度较高的板块（比如标题栏，底部菜单栏）
●剩余空间再进行变化度较高的板块设计（空间划分）
●往往一个板块有非常多的参数，我们需要判断参数的价值（参数选择）
案例：
实际上，这个过程对我影响非常大，你知道我现在写文章的顺序吗？
1.约定字数，通常在2500字左右（有边界的空间）
2.先确定“导读”和“总结”所需要的字数（标题栏，底部菜单栏）
3.设计文章内容的结构（空间划分）
4.设计小标题（参数选择）
Tips：作为产品而言，空间并没有那么庞大，只是我们习惯性的将其视为无限可能，一个页面所能承载的内容非常的有限。能否驾驭这个小小的空间，取决于设计原型图的过程，给我们带来的成长。
我们必然会在这个过程中学会空间感，布局，产品模块，还有并不是所有参数都是一样的效用——也不是参数越多越好，这会让我们学会选择，初步接触产品经理的“判断意识”。
4.成长：收集资料可以触碰到产品的精髓
我曾多次对朋友提及我所理解的产品的精髓，甚至也是创业者的精髓。
“信息提取及大量信息加工的能力”
产品的设计并不是空穴来风的，而是信息处理后的一种结果；越往后面发展，我们所需要捕捉的信息量就越大，对我们并发信息处理的能力要求就越高。
就产品负责人而言，需要承担产品舵手的职责，同时也要肩负产品生死的考验，我们的任何一个决策，都有可能成为产品死亡的诱因——当然，也极有可能成为产品提升的决定性因素。
毫无疑问，现在的环境，产品已经泛滥成灾了，这表示“撞大运”的机会越来越少，更多的是凭借精打细算的思考，以及媲美计算机运算能力的预测。
阿基米德曾说：“给我一个支点，我能撬起地球”。对于产品经理而言，这句话的含义等同于“给我足够的信息，我就能计算出下一个风口，做出一款爆款产品”。
实际上，这样的描述并没有错误。可如何获取足够的信息，以及如何对大量信息进行并发处理是对我们能力的考验。
助理阶段在收集资料时，便是在逐渐建立起“找材料”的习惯，而对资料的汇总汇报的过程，便是在建立“材料处理”的意识。
Tips：这并不是“调研”——尽管未来会发展成“调研”，但目前而言，我们要做的是极尽我们所能，将能找的方法，能找的渠道都尝试一遍，并且不断的尝试新方法，新渠道去获得指定材料。
同时，不要做资料的搬运工，逐渐尝试对这些资料进行处理——要知道，你的leader或者你的导师，可能会使用和你的相同的材料进行分析；他分析出来的情报，便是你需要吸收的知识。
二、产品经理
相对于产品助理而言，较为成熟的功能库，以及熟练的撰写文档和设计原型的技巧，是产品经理们的典型特征。
功能库便是在助理阶段积累下来的认知，这是我们的财富，而且他还会一直随着我们的经验阅历的增加而变得更丰富。
除了这些典型特征，还会出现更多的技能进入到我们的工作中。比如对时间的预估，对进度的把控。
估时并不是研发独有的能力，实际上，在成熟的产品经理里，不乏对时间有精确控制力的朋友。原因在于：每一次和研发沟通的过程中，每一次的迭代版本或者项目中，我们都能收集到研发反馈的信息。
只要对这些信息敏感，便不难对功能实现成本做预测，这就好比我们做了很多次注册登录，再次做的时候，就能评估出研发时间和风险点，而不需要再询问研发同事。
1.职责
这个阶段的产品经理有三个主要职责：定义每个页面存在的意义，追求子目标，设计底层需求。我们在设计产品时所绘制的任何一个页面原型，都有其存在的意义，而且这些意义是不相同的。
Tips：设计方法本身没有问题，任何一种“方法”都曾经或者正在被其他人所使用；然而，相同的思路，放在不同的地方就产生了“对”和“错”的概念。
比如：
●列表页存在的意义是更高的跳转率，在这层含义之下，我们需要寻找更容易诱导用户点击进入资讯详情的方法。
●主页存在的意义是更高的关注率，我们希望用户通过阅读一个人的主页，更容易产生关注他、认识他的冲动，这决定了如何设计这个主页，也决定了通过何种维度来判断主页设计的是否“正确”。
●还会有一些页面，在不同的产品环境下遵从于不同的意义，就像我们的文章详情页，某些产品会更多的提高用户分享率，有些产品则会提倡更多的评论率。
这就需要负责该板块的产品经理，明确定义一个页面存在的意义，并在设计过程中遵从该意义。
这也滋生了产品经理的第二个职责：追寻子目标。
并不是所有功能都会为产品的新增，用户的活跃买单，个人资料就是很好的案例。我们不能说新增低，用户活跃低是因为产品的个人资料做的不好，但也不能认为个人资料页没有影响。
每一个页面都会有自身的数据衡量维度，跳转率是我们常见的一个数据指标，除此之外，还有停留时间，完成率。
搜索追寻的数据指标又与个人资料不同。
我发现很多产品经理，如果不独立负责一个产品，就变得不知道该做什么，这是错误的。即使不负责一个独立产品，我们也会有各自负责的某一个板块，也有我们这个板块存在的意义以及他所应该追求的子目标。
Tips：底层需求是指不可视的需求，我们在助理阶段积累了大量的功能库，但很多都是可以被看见的，也就是由前端驱动的功能。
一个产品的强壮度，往往并不在于前端功能，而在于后端功能和底层功能；需要我们了解数据流动，以及每一个环节对应的细化需求点。
随着我们对产品的掌握力度，我们的需求挖掘对象会逐渐的从左向右转移，对于产品经理而言，后端对应的底层需求是需要我们操刀完成的，原因在于这部分需求并不能通过我们的视觉来分析和拆解。
Tips：常见的底层需求包括推荐系统的推荐规则，匹配逻辑，大数据的应用，还有我们的搜索逻辑，微信的推荐通讯录好友的功能，你知道他是通过哪些需求点实现的吗？
2.成长
在产品经理阶段，我们会开始为数据负责并且通过对某个模块的意义赋予，形成个人的价值观——这是非常重要的一个里程碑，我们终将会进入产品经理的下一个阶段，也终将会为一个产品独立负责。
届时，我们将赋予其意义的，不是某个模块，而是一个产品存在的意义——为用户创造的价值；我们要分析的数据，也不再是某个页面的子目标，而是更深一层的全局分析以及价值分析。
三、产品负责人
请允许我简要描述这部分的内容，这个阶段实际上是一个转折点，也是一个转型阶段；除了专业能力的增加以外，我们还需要扩充团队管理，项目管理相应的技能。
产品价值观、产品结构、团队管理，是产品负责人必备的三个基础能力。
作为一款产品的实际负责人，我们需要承担起舵手的责任，我们需要更多时间来思考：这款产品究竟应该为用户创造何种价值，提供何种服务。
Tips：这是很艰难的减法过程，我们面临太多的可能，太多的诱惑，似乎这样做可以，那样做也可以。
再也没有其他人能帮你做这个决定了，而且我们还要帮更多的人来做这个决定。
十个字的slogan非常短，往往需要一个月乃至更长的时间去思考，我们很多的想法，很多的概念都会在这段时间里增加，减少，融合，最终沉淀为短短的一句话，并赋予给这款产品，从此，这句话就成了某产品的价值观。
产品没有结束和完成的概念，除非这款产品进入了死亡阶段。
QQ音乐迭代了11年，目前任然在迭代过程中。长时间的迭代，堆积的功能就会成为产品的负担，就如同人们身体的病痛，许多都是积累而来。
