随着互联网的发展，产品经理的需求越发旺盛。而互联网产品经理没有对应大学专业。有幸进入大型互联网公司工作和学习的产品经理毕竟少数。多数产品经理都在经历着从草根到专业的转变过程。细数这几年，自己眼见新人曾经犯过的错误，值得深思与总结。
一、关于职能定位
许多产品经理刚入门的时候都是从简单的原型制造开始，更准确地说应该是临摹其他产品的相关页面。在这个过程中从界面上逐渐去辨别某一个产品功能的好与坏，美与丑。慢慢地就认为这些就是产品经理这份工作的everything了。他们的目光永远聚焦在产品的外衣，而对于产品内在的价值和意义思考不深，甚至完全忽略。这样的产品经理通常只能算一个不专业的交互设计师。
出现这种现象的原因主要是许多公司缺乏对产品经理的认知、判断、培养的能力。在不同公司，对产品团队的工作要求、重视程度差异较大。更直白点说，许多公司缺乏产品经理基因，压根就不知道招聘什么样的产品经理，不知道他们应该做什么事情。
回到主题，产品经理对自己的职能定位一定要深刻。高度要能俯视整体产品线，广度要能涉猎更多知识面，深度要能直入业务最本质。忽然想起林夕的歌词“在高处凝望世界流动”，Yes，这就是产品经理应有的视角！
二、关于需求管理
1、没有建立完整、客观的需求获取通道。需求往往来自运营部门、市场部门或老板的要求，产品经理沦为需求文档撰写者，把别人的想法写成文档，交付给技术团队。这样的产品经理则沦为传统软件开发的需求分析师。要建立完整、客观的需求获取通道产品经理必须“眼观六路，耳听八方”：定期收集外部用户对产品的评价和反馈；定期对竞争对手的产品动向进行分析和跟踪；定期从后台提取用户行为数据，分析用户行为，通过数据提供产品迭代的理论依据；
2、没有建立合理的需求考评机制。需求漫天飞，永远不知道哪些需求要做，哪些不做，哪些先做，哪些后做。产品经理要为产品建立需求池，打造需求管理体系。从需求获取、需求排序、需求分析、需求评审到需求设计、需求开发和需求变更都要有依据和操作规范。以此来确保整个产品研发方向的合理性，摸索出一个适合市场要求和团队研发实力的迭代节奏。比如迭代周期以及每次迭代研发团队能承受的工作量。
三、关于流程管理
流程管理是最容易刨出坑的地方。关于流程方面的问题通常有两种表现形式。一种是日常化工作没有形成明确的流程，造成团队工作混乱。比如关于需求变更流程，如果没有明确的流程，产品经理在发起需求变更的时候很容易出现信息传递不对等。团队应该事先规定清楚，影响程度不同的变更必须上报到哪一个层级。以此来控制需求变更的合理性。需求变更应该通知的范围，除了技术、测试还应该通知运营团队甚至老板。以什么样的形式表达需求变更？邮件形式还是需求文档？这些问题没有相关流程会造成很多团队间扯皮、推诿的现象。
另一种情况则是团队通过讨论通过艰难地制定出某一个流程，可是在执行阶段出现问题。团队缺乏执行力，缺乏对流程的培训机制，缺乏对流程的改进和迭代。一个流程正如一个产品，要深入人心需要不断试错，升级。因此对于研发团队中最核心最常见的流程，必须靠强大的执行力来支撑，最终在团队里形成一种良性的工作习惯。
四、关于市场调查
在需要听取到团队之外的声音之时，产品经理通常会想到通过市场调查的方式收集信息。如果产品经理本身对市场调查方面的工作不够精通，通常会犯这几类错：
1、调查目的不明确。每一次市场调研需要当做一个独立项目去完成，在项目立项之前，就已经有一个明确的方向和目的。比如针对产品的某个指标发起的一次调研。那么首先需要把这个指标细分成多个相对可量化的指标。在后续调查问卷的设计中，或者用户访谈问题的设计中都有明确的方向和逻辑。比如，要调查用户对某个产品用户体验的满意度。可以细分成界面美观程度、主要流程易用性、主要流程加载速度、还有一些软性能的满意度等等。
2、样本采集不科学。采样的准确性直接关系最终结果的准确度。在调研中有些问题则必须通过与用户面谈，有些问题则打死不能当面与用户沟通，必须通过在线问答的形式。比如满意度，当面去询问对产品的满意度，用户碍于面子给予的反馈通常会比实际想法不符。因此采用的时候要综合考虑采用的渠道、样本的数量才能得到相对客观的基础数据。
3、问卷设计不合理。俗话说上梁不正下梁歪，如果调研的目的和调研逻辑没梳理清楚，到了问卷设计步骤一定会凌乱。而问卷设计部合理最常见的有如下情况：问题与中心无关、问题描述太笼统、选项不完备、选项不互斥、问题带有强烈的诱导下等等。
五、关于跨团队沟通
产品经理在整个大团队中无疑应该充当”万金油“的角色。需要平衡不同团队的特性，在技术面前要积极推动需求的实施，在运营团队面前则要坚持合理的节奏和原则。沟通能力差的产品经理通常会沦为运营对付技术的工具，或者是技术对抗运营的牺牲品。产品经理不要在团队里”搞政治“，却必须能游刃于团队间，靠的是过硬的专业技能和人格魅力。
1、在技术面前强调需求的价值，让程序猿深刻认识到自己开发的功能为何而生。同时建议在需求设计阶段就邀请他们参与，多听取技术的意见，与程序猿建立浓厚的感（ji）情（qing）。
2、在运营面前强调需求合理性，运营通常给出的需求是没有站在整个产品规划上来思考的，多数属于”哪痛帖哪“”指哪打哪“这样的场景。更不会去考虑需求可行性，天马行空的需求漫天飞也是正常的。这些无处不在考验着你的沟通能力！
或许我们都经历过从草根到专业的过程。本文列举的问题也未必适用于所有人或团队。仍然希望对广大新入门的产品汪有所帮助。
