前言：

SOP（Standard Operation Procedure），即标准作业程序，是指将某一事件的标准操作步骤和要求以统一的格式描述出来，用来指导和规范日常的工作。SOP的精髓，就是将细节进行量化。

互联网行业随着上下半场、PC和移动、古典和区块链等概念和趋势的洗礼，岗位的分工和职责也越来越清晰和严肃。尤其是产品和运营，这种过年回家时不知道怎么给亲戚解释自己工作内容的岗位，也在长久的摸索和钻研下有了更精确的划分，一些玄学慢慢落地成科学，灵感和运气被复盘后变得有章可循有规可依。

在笔者的理解中，产品经理的SOP可以理解成脱离于行业的更底层的方法论，同时具备可迁移能力。

现实世界里，80%的产品狗可能没有灵气或者缺少机会，远远达不到改变世界的程度，在日复一日的撕逼和真实身份是乙方的项目里重复体力劳动；SOP的价值在于，让产品经理真正成为产品经理，就算不能轰轰烈烈，也要达到兢兢业业。

关于产品经理的各种方法论早已被翻来覆去写的无数遍，看起来都很有道理，但是未必适合当前阶段的自己。你走过的路看过的书遇过的人，决定了你成为什么样的人。你撕过的逼踩过的雷填过的坑，决定了你成为一个什么样的产品经理。是否产生同感和共鸣，往往是认知差距决定的。

干货之所以难懂，是因为信息密度高，每一个简短的词汇背后，都有大量的背景和案例来解释，导致阅读时经常被新概念打断，无法跟着作者的思路前进。笔者将尝试拆解问题至适合的颗粒度，剖析更底层的逻辑；大家在看其他方法论的时候也可以尝试将其拆解剖析，会发现只是从不同的角度用不同的描述表达了类似的意思；这样就不会因为信息爆炸导致迷茫，可以根据自身情况有侧重的选择学习和使用；从而实现方法论的串联，构建更完善的信息框架。

一、为什么一开始写定位

万物皆产品，万物皆有定位；选择比努力重要。做任何事情都要先明确目标，有了目标，才能跳出被潜移默化的常识操作路径，从更丰富的视角思考问题。找到定位，定位推出目标，目标明确指标，一些动作都是为了达成目标而服务、指标回归效果、根据效果明确新的目标，多个单位周期内的闭环逐个衔接，形成进化。

这与产品经理的自我成长、产品规划、产品分析、需求分析等都有着千丝万缕的联系。

让正确的事持续发生，首先就是要找到定位，知道什么是正确的事。

二、我能不能做产品经理？

小的时候纠结上北大还是上清华，最后只能在自己的分数范围内选择；面试时造火箭入职后拧螺丝。虽然现实不尽如人意，个人的想法和选择在结果面前看起来并无卵用，但是这不是放弃思考的理由，很多时候的真相是思考的还不够多不够深入，思考影响的因素没有在促成结果的多个因素中真正形成影响。事实上，那些重视思考善于思考的人，拥有的选择越来越多。

这个问题实际是要确认，我在团队中的定位与产品经理岗位的定位是否重合？这个问题可以初步拆解成

产品经理这个岗位，一直被调侃为想从事互联网，又不会P图不会敲代码的人的选择。在看到“同理心、对产品感兴趣、逻辑思维、责任感、沟通能力”时，都会觉得自己很合适，而自我的认知拿到实际工作中进行验证时，又会存在自我认知与团队要求的认知存在差异的情况。

“适不适合”和“岗位职责”的关键差异在于时间节点：入门前和入门后

分析需求时，能不能做到穷举场景进一步挖掘需求，构建完善的用户画像考虑到对所有用户群体的影响，进行准确的业务调研考虑到业务流程中的所有角色并排序体验权重。结合用户调研、行业调研、竞品分析等等的硬实力才能决定所谓同理心的天赋能够在项目中兑现。

如何算对产品感兴趣？只是陷入用户激励套路中的沉迷，还是有意识的尝试各类产品，带着目的去使用得出自己独立思考的结论。

怎么定义良好的沟通能力？宣讲需求时不是要华丽的遣词造句勾勒美好图景，为团队洗脑画饼实现说服；而是要通过客观的描述，让大家充分理解表达内容，引导大家从更多维度发表意见从而辨别出需求的真实价值。

产品经理是一个上下限差异极大的群体，科技公司的大佬们往往都有一个产品经理的身份，而刚刚入门的产品经理，往往写着生搬硬套的产品分析，在老板和客户的要求下做执行输出具体的功能需求。做的事情相对琐碎，而产出的结果受整个项目流程甚至产业链条各个环节的影响，指标难以量化。招聘JD中的描述宏观抽象，甚至很多企业都没有想清楚需要一个什么样的人。

年轻的产品经理们，往往憧憬着大佬们的丰功伟绩，受困于实际环境的压力逼迫。

在这巨大的落差中更加深刻的感受到专业的重要性，对行业愈加敬畏，激发自我驱动的成长动力；而不是一味的抱怨老板不懂产品，公司资源不够。

在需求发布后，及时找到提出人进行新一轮的调研验证，阶段性的效果回归，在各个渠道收集用户/客户反馈归纳问题。

跨部门合作时起到积极推动作用，职责模糊的区域在条件允许时主动承担，链接各个部门使配合更加流畅。

开发过程中对于需求的问题积极响应给出解答，在线上验证无误后再下班。

这才是真·责任心

所以，什么样的人适合产品经理这个问题的答案真的不重要，因为在实操之前，得不到真实的答案。就算你真的具备这些天赋，也需要结合刻意练习+经验积累的硬实力来在项目中兑现。

三.产品经理职责＆需要具备哪些能力

公司对于产品经理的定位可以用一句话概括：解决问题的人

所有产品相关的问题，都需要产品经理直接或间接的解决。

（1）用户体验5要素维度

战略层

战略层的目标是定义产品，明确用户需求，明确产品的定位和目标。产品经理会随着能力和等级的提升，越来越多的参与到这部分的工作。

需要产品经理可以独立完成的部分

产品定位：为哪些人解决什么问题

市场分析：有没有机会，机会大不大

竞品分析：能否抢占机会，哪些可以学习哪些需要规避

用户调研：需求是否真实，解决方案是否可行，商业模式是否可持续

龙头产品的平台越做越大，覆盖面越来越广。实现差异化和构建壁垒的主要方式就是通过长期有效的运营策略培养用户习惯夯实品牌定位，通过聚合资源形成一定范围内的垄断。因此笔者在这里不再过多赘述战略规划、行业分析之类验证周期较长验证路径复杂的产品能力。

主要方法论：

SWOT分析

PEST分析

波士顿BCG矩阵

用户画像

用户故事地图

马斯洛需求层次

KANO模型

范围层

范围层的目标是定义产品边界和升级节奏；不仅需要产品经理有清晰的产品规划，更要有通过良好的沟通传达出专业性观点的能力，面对不合理需求敢于说不的抗压能力和勇气。

要站在全局的视角长远的看待问题，在不同的节点，搞清楚谁才是真正的用户

多边平台、多角色利益冲突时如何权衡

在供应链或甲乙双方合作中，面对强势方的不合理需求如何处理

需要产品经理可以独立完成的部分

需求分析：需求筛选、需求透视、需求排序。

版本规划：理解业务的主次、了解用户对多个痛点的迫切程度、权衡出每个时间节点最适合做的事情

大家感受很深的是”老板今天想做个微信，明天又想做淘宝“这种很不靠谱的想法；在范围层这种问题同样存在甚至更加严重。选对了行业，却因为实现过程中的判断失误导致损失，比一开始选错了行业更加令人痛心和惋惜。对于范围层的不合理需求要更加敏感更加坚守态度。同时，也要持续关注战略层面的信息，灵活调整规划方向。

主要方法论：

MVP

产品生命周期

冷启动

优先级

结构层

结构层是将想法落地成一个功能需求的衔接，在这个阶段要将解决方案翻译成具体的产品设计；将线下的操作路径映射到线上。

需要产品经理可以独立完成的部分

产品架构：产品的骨骼、抽象描述产品的业务系统逻辑

信息架构：信息的组织和展示方式

功能架构：功能模块层级和层级关系

业务流程：某个任务目前的解决方案（多为线下），有哪些人参与，做了哪些动作，有哪些业务规则判断

产品流程：某个任务在产品中执行产品提供的优化解决方案，，有哪些人参与，做了哪些动作，有哪些产品规则判断；有哪些功能模块参与、模块之间如何关联、数据如何流转

主要方法论：

产品层级结构：用户层、功能层、数据层

实体联系：直接关联、间接关联、对应关联

对应关系：一对一、一对多、多对多

信息架构模型：层级结构、自然结构、线性结构、矩阵结构

框架层

在框架层，将产品设计具象成功能模块，清晰的规划到具体的页面上。

这里要注意【页面】和【界面】的称呼与表达习惯没有关系，是要清晰认知它们之前的区别。

【页面（Pages）】是具象的物理存在，每个页面有独立地址或URI。【界面（Interface）】是一个抽象概念，用户界面是系统与用户之间的”接口“。

比如【订单详情页】是一个页面，【订单详情页>待支付】是一个界面。在做产品设计输出需求文档时，应该以【界面】为单位，这样可以最大化的细化用户任务颗粒度，充分考虑清楚需求内容，方便团队其他成员更清晰的理解需求评估工作量；也更方便复用和统一形式，降低设计开发成本和用户学习成本。

需要产品经理可以独立完成的部分

功能流程：某个子任务在产品中的具体操作流程，有哪些人参与，做了哪些动作，有哪些产品规则判断；有哪些功能模块参与、模块之间如何关联、数据如何流转；有哪些异常流程、提醒

PRD：原型设计、需求撰写

交互设计：用户与产品的互动方式

主要方法论：

A/Btest

可用性测试

交互规范：iOS、Android、H5、小程序

尼尔森可用性原则

格式塔原则

费茨法则、希克法则

7±2，奥卡姆剃刀

（关于7±2原则，有另一种说法是根据最近20年的调查结果表明，人类的短时记忆为4个单位左右）

借鉴竞品的产品设计是比较常用的方式，甚至很多时候在需求评审时，会有人直接说”把你抄的竞品拿过来看看“。借鉴靠谱的竞品是一种可行的方式，它至少确保了两个方面：

竞品团队经过思考得出了使用现在这种方案的结论

这种方案已经投入市场经过了用户的检验

但是对于想借鉴的你来说，思考过后拿来借鉴和直接拿来借鉴，虽然结果相同但是完全是两回事。

是否适合：你的产品和竞品面向的用户群体是否存在差异，竞品公司和你的公司存在哪些优劣差异，你看到的方案可能是只有竞品能做或竞品存在限制妥协后的结果。

市场反馈：你是否收集到的足够的用户反馈，是否以用户的身份体验过并独立思考

表现层

感知设计（嗅觉、味觉、触觉、听觉、视觉），在软件产品中，绝大部分时间我们聊的都是视觉设计。

在表现层，确定产品的信息元素如何分布排列，如何通过视觉呈现，以确保清晰的传达信息和夯实品牌形象。

这部分工作通常是由UI设计师产出设计稿，而优秀的产品经理会在绘制原型时，就将信息的层级和主次通过字体大小、粗细、颜色（灰度）等方式直观的展示出来，方便UI设计师理解并沿用。

主要方法论：

各个生态设计规范

亲密性

对比

重复

对其

色彩心理

色彩三要素：色相、明度、饱和度

同类色、邻近色、互补色、对比色、类似色

冷暖色

产品经理通常要参与设计稿的评审，审美是一个很主观的事情，产品经理不仅需要判断”好不好看“，还要知道为什么得出这样的判断。商业设计，目的是解决问题，要跳出自身的审美偏好，清楚要解决的问题。

要考虑信息传达是否清晰、设计风格是否符合产品定位和品牌形象、目标用户能否接受这种风格、是否适合用户的使用场景。

（2）工作流程和细致划分

所谓产品经理的软实力都是在一个个实际的项目中摸爬滚打真情实感积累而来的。

而上面说到的产品经理面对着理想与现实的巨大落差，其实是因为没有对自己所在的岗位进行更细颗粒度的划分、认知、定位；盲目的提高了预期。

下篇文章从工作流程和更多维度细致划分的角度聊聊产品经理的个人定位。