导读
由于环境原因，我们接触到的产品经理似乎总是“特别的”，以至于这个问题困扰了许多人。
产品经理到底是什么，我现在做的事情，真的是产品经理要做的事情吗？
产品经理的工作
本文所提及的观念，为我个人的心得分享，不具备标准性质，但具备参考性质。
谈到产品经理的工作，“杂，乱”，是最常听到的定义，包括我本人也在许多场合提到了产品经理的工作内容很杂。
这有两个原因，其一，我们并没有掌握这些看上去杂乱任务背后的共性，其二，我们懒惰，相比长篇大论的陈诉以及费尽心思的沉淀，就只需要一个字概述——"杂"。（我便是后者，惭愧 ，嘿嘿）
用杂乱来定义产品经理的工作内容，就如同用写代码来定义开发， 用画图来定义设计师一样，只是一种自嘲的回应，并不是真正的定义。
我简单的将我个人对这个角色的定义分享一下，并不代表所有的产品经理，但也代表我所认识，所接触过的大部分产品经理，分析样本在100人以上。
这是一个工作的循环，一共是7个环节，分别是接受任务，分析，设计产品，交付产物，跟进进度，验收发布，结果分析。
我们来简单讲讲每个阶段的工作性质。
接受任务
这里提到的接受任务，原则上是产品经理一系列工作的起点，这些任务便是我们的需求。
正式工作环境里，我们的需求大部分通过任务性质被下发给我们的，这一点即便是产品负责人，产品总监也不例外，区别只是我们的任务不一样而已。
以产品总监为例，我们会接受到要启动某个新产品的任务，而这个任务或者是由企业上层决定，或者是由战略决定，或者是由市场决定。
其本质上更多的是任务，而不是想做什么就做什么。
我们来看看几种典型的任务：
●我们增加一个打赏功能吧
●我们增加一种消息样式
●我们做个转发，怎么样
●现在直播很适合我们公司的方向，你来操刀，设计一个直播系统吧
●积分等级体系能有效的增加用户的活性，来一发
●我们有教育资源，想找一位产品经理来做一款教育类app
当然，除了上级的直接要求以外，我们通过对市场，对用户的了解，也能发现一些问题，发现一些机会，而这部分内容，也同样是任务性质的，只是我们自己扮演者任务分配的角色。
冬日的某天，小雪，A和B两人相约去某地开会，准备打个出租车前往，两人在雪地等了许久，都没有出租车经过。
此时，A抱怨道，要是有一款APP ，能让我点一下就能叫到车就太好了（任务下发）。
B思考了一下，觉得这是一个很好的想法，于是回应道，咱们自己做一个（任务接受）。
于是 ，有了 UBER。
于我个人而言，我其实很排斥“想法”，更多的是喜欢以“任务”的概念来驱动项目，想法过于偶然了，具备十足的不确定性，同时又过于廉价，谁没有几个想法呢？而任务却不一样，具备一定要达成的潜意识，我们接受任务或者下发任务时，都持有必须完成的心理。
分析
分析是一个大类的环节，这样的称呼大概会让你感到迷惑，我们先来看看分析阶段都包含了哪些事情。
市场调研，用户调研，需求调研，技术调研，数据分析，kano模型，马斯洛需求层次，用户画像等等。
在分析阶段，我们运用各种各样的方法来完成对任务的分析，是的，我们所知道的许多看似很高端的名词，大概都是在分析阶段的某种方法论。
产品经理是个强思考的角色，这里的强思考主要就体现在分析阶段。
分析阶段在任务接受之后，我们分析的目的是如何去达成任务。
分析的目的 在于寻找达成目的的方法，而不是去寻找拒绝任务的理由。
很多时候，我们在分析时会有错误的思路，我们会下意识的去寻找能够帮我们拒绝执行任务的理由，这是一种潜意识，是我们需要克服的困难。
我深刻的知晓许多任务，在我们接受时，就已经存在不可执行性，从一开始就注定了失败的，但很遗憾，我们对此无能为力。
就像是士兵一样，服从是军人的天职，达成任务便是我们产品经理的天职，尽管他多么的离谱。
要知道，许多伟大的事情，都是在不可能完成的情况下被完成了。
产品经理接受的任务，极具挑战性质，80%以上的任务都是属于不可能完成的任务。
我们的角色，本就是将不可能变为可能，将可能变为现实。
所以，你还在排斥任务吗？或者你是否做好心理准备， 迎接一个又一个的不可能完成的任务。
再来说到具体的各种方法论，如同我们刚才列举的许多方法一样，其目的都是为了帮助我们分析。
我们已然清楚分析的目的是什么了，那如何分析便是这些方法论发挥作用的时候了。
这些方法论并不神秘，只是包装过于华丽了，我们简单列举几种分析方法吧。
●市场调研
我们在获取需求时，最先做的就是市场调研，简单的来讲，就是去分析任务所对应的目标市场，具备什么样的特点，需要什么样的服务。
需要注意的是，此处调研对象是“市场”，比如出行市场，IT市场。
●用户调研
任何一个产品都是被某人所使用的，我们借助市场调研明确自己要做什么服务以后，就需要做用户调研了。
用户调研的落脚点在于某人，正确的讲，应该是某类性的群体。
●技术调研
技术调研是在有一定想法以后，我们找上开发人员，简单评估一下技术的实现成本，如果某个idea的实现成本过高，我们可能就要重新想想方案了，许多产品经理在设计产品时，会忽略技术实现难度及成本，这是不可取的。
在应用层面，大部分的需求都是不需要强行攻关的，比如我们要实现支付功能，但并不是一定要自己开发一套支付系统以及安全系统，直接接入第三方就好啦。
当然资金量很大时，我们的收益足够平衡我们的成本时，就很有必要自己开发了。
●kano模型
kano模型是作为划分需求优先级的方法被创造出来的。
需求总是很多的，但前人经过研究，提取出了需求的共性，并总结成了需求的五个类型。
使用这个方法，我们可以很轻易的判断某个需求属于何种类型，再借助该类型需求的价值以及效应，最终来判断出某个需求的优先级和重要性。
设计产品
产品是被精心设计出来的，这是我所遵循的产品观念，在我体验一款新产品时，我会尝试站在对方的角色，来思考。
如果是我来做，我会如何设计呢？
当我们结束了分析阶段后，我们会根据自己掌握的信息，根据自己分析所总结出来的信息，来设计产品。
我们所使用的每一个参数，都是精心设计的，不仅仅是参数，一句提示文案，也是可以被精心设计的。
只是我发现许多产品落地很差，这点在设计上可以充分体现出来。
与分析阶段相同，设计产品也有诸多的方法，并且经常被我们使用到，只是很多时候，我们并不曾注意到。
设计产品的方法：结构设计， 业务设计， 流程设计， 原型设计，情感设计，MVP设计原理等。
产品经理行业，由于外界盛传的0门槛或者门槛低，导致许多朋友尚未准备好，就进入到这个行业，再加上目前尚未出现通用的技能体系，在实际工作中，许多leader ，许多产品老人，都尚未将自己的经验沉淀，最终的结果，是比兴奋更为巨大的迷茫。
迷茫：
从心底里想要学习，并认真的热爱这个行业，但却连自己应该学什么，都感到疑惑。
看不清当下，也看不清未来。
自己现在能力到底怎么样算好还是算差，又或者是一般。
下一步，我应该学些什么，如何才能变得更好？
其实没有那么复杂，这个行业远比我们想象的还要接近事物的本质，你所欠缺的只是应用的技能，以及对技能的熟练度。
在产品设计阶段，我们的差距更多的体现在思考面积的强弱上，我们掌握的设计方法越多，便越能设计出好的产品。
最合适的就是最好的。
在创业团队里，产品经理可能不会决定项目的成功，但却极大的决定了项目的死亡。
若产品经理没有掌握MVP设计原理，以及产品结构设计，极有可能在1.0版本花费太多的时间，并给未来的产品迭代遗留许多问题。
这将极大的增加创业团队的时间负担，创业而言，每一个小时都是极为珍贵的资源，可以想象，浪费一个月等同于将整个团队置于死亡边缘。
而一次版本迭代，若牵扯到了结构重构，几乎是必然超过一个月的时间耗损的。
在不同的时间，不同的阶段，不同的环境里，我们需要使用不同的设计方法，这就需要我们不断的充实自己，不断的学习。
设计方法之间是不存在正确或者错误的， 这完全取决于我们是否在合适的地方，用了合适的方法。
因此，我们无需因为自己设计出来的产品被排斥，被冷淡，而动摇自身的信念，也无需为了失败而感到沮丧。
我们所欠缺的，其实只是方法，那便学习方法就好了，不需要漫无目的的学习。
这些方法并不在已有的产品相关书籍里，而是在于传统行业的金科定律里，相对历史悠久的传统行业，互联网作为一个行业而言，显得无比稚嫩。
现在大家所认识的kano模型，金字塔原理，马斯洛需求层次，没有任何一个方法论是属于这个行业原创的，均是来自于对前人知识的学习以及再应用。
要知道，早在互联网之前，人们就已经设计出了许多精美的”产品“，我们其实早已掌握了产品设计的”精髓“，我们也早已接触了数之不尽的”产品“。
一段文字，一本书，一部电影，一场真人游戏，乃至我们所使用的碗筷，衣物，都是被作为”产品“被设计出来的。
因此， 你，无需感到畏惧，也无需感到迷茫。
未完待续。。。
已经有3500多字了，现在还有4个环节没有写，分别是交付产物，跟进进度，验收发布，结果分析全部写完大概接近万字长文了吧。
考虑到大家的阅读时间不宜过长，决定将这篇文章分成两篇来写。
