区别于产品经理，“产品功能经理”往往是指刚入行的新人，他们所在的职位正在做的事情一般是完成上级领导传达的一个个功能指令，而不会独立地负责某一模块。

背景介绍

什么是产品功能经理？区别于大家理想中的PM，刚入行的同学往往只是产品功能经理。不会独立承担一个模块，大部分需求都来自于自己leader直接传递，加个页面？改下交互？增加个字段？

这种模式试用于各个大小公司，PM都是从一个个功能成长起来的，脱离功能层面去理解需求才能快速从功能进阶为模块。

虽然和大家理想中调研市场，引领大家开创一个全新业务的工作有点区别，但是如何做好一个功能经理也是需要大家不断总结的。下面从整个业务流程简单概述下如何从一个新人过度为一个合格的PM：

一、理解需求

逆向推倒，从用户需求到用户目标

需求来源也许只有leader的一句话，也许只是一封邮件，甚至可能只是一条qq消息。但是往往话越少，需要做的也就更多。

首先得明确需求和目标绝对不是一码事。

需求的正常描述语句是：我需要增加/修改某个功能/页面；例子，领导给你说，小王，把我的桌子收拾一下。

目标的描述语句是：我希望获得某种收益；例子，领导告诉你，小王，我希望能够及时找到自己想要的文件。

区别在哪里？做需求，你只用把桌子的东西摆整齐，笔记本和文件摆在一起，桌子擦一遍就可以了；实现目标，你需要把每种文件分类，草稿纸堆一边，合同堆一遍，笔记本又得堆一遍。

领导只有一句话，我怎么才能知道目标呢？逆向推到，从结论到原因，从现象到本质。一个功能一般只有一个目标，一个目标可以对应多个功能，这也是敏捷开发中强调的用户故事。

《用户体验要素》对需求划分了五层，大多数人只会在框架层和表现层思考问题。拿到需求就想着该怎么设计交互，这个按钮放在哪里，那个表单应该怎么排列。越表层的东西越应该放在最后去思考，拔高自己的层次。思考用户为什么会有这样的需求，学会思考，多多在生活中尝试这样的逆向思考，为什么火车站的餐饮口味都非常一般？为什么现在的大学生都要自学编程？透过现象看到本质是你从功能经理到PM的第一步。

回溯需求，场景化功能

理解用户真正的使用目标后还是需要回溯到需求，从需求适用的场景去思考如何设计一个完备的功能。

为什么需要落实到某一个具体的场景？最大的好处是带入用户的体验感，其次是遍历所有的可能性，避免设计方案有所遗漏。

需求是用户目标的落地方案，一个目标一定可以通过多个需求来满足，如何选择最优的体验以及在资源有限的情况下选择效益最高的功能是PM最核心的技能。

如何场景化？

根据《交互设计精髓4》的介绍，应该是用户调研。从市场调研到persona的建立，是场景化的前提。很遗憾的是，大多数功能经理以及产品经理都很很少有机会去做一次专业的用户调研。

那么，比较折中的方案就是自己去使用产品或则在产品没交付前去试用原型。当然，人都难以避免会带入主观性，所以得及时刹车，避免过度设计和满足不存在的需求。

市面上有一套比较成熟的方案，5W2H法可以协助我们及时矫正。

场景化本身并不是一件多困难的事情，但是大多数产品往往会习惯性忽视这一步，这也是为什么我们的PRD会经常被开发挑战的原因。

不能落实到用户具体的使用场景就会出现设计遗漏，举一个经典的例子，某个导航类的app一个核心流程就是帮助用户换乘地铁，app此时会在界面上标识换乘地铁的终点站，只有带入用户场景才知道，在匆忙换乘的期间，你第一眼看到的一定是下一站的几个大字。

如何快速让你知道换乘地铁的方向？Where？When？两个核心指标可以快速带入用户的场景。

二、方案设计

不急于页面设计

新人产品最大的误区就是以为产品的职责就是交互，提供一个可用的界面给用户。这样的设计思路弊端实在太多，基于此类思想的设计方案往往灵活性不够，也不能满足用户的真实目标，最终的结果往往是推到从来。

下面着重介绍新人往往会忽略的两点：
（1）优先梳理流程

理解客户的需求后，第一步应该是梳理业务流程，把整个方案形成闭环，从trigger到action，以及各种失败的异常情况都应该包含在整个流程中。

流程过于复杂时可以逐层细化，从用户目标逐层拆解到产品功能，需要注意的是顶层到底层一定是一对多的关系。

梳理流程时需要根据实际需求选择流程图还是泳道图，一般来说当整个交互过程设计到多个用户角色时用泳道图更为合适，也方便开发同学理解业务之间的耦合关系。

注意流程图的撰写规范，圆角的矩形表示状态，平角的矩形表示动作，菱形表示判断，以及更为多线框的矩形表示子流程。

如何画一幅完美的流程图？

1. 首先明确用户的输入和期待的输出，将中间的交互过程想象成一个黑匣子，只关心用户最初始的操作和期待最终的结果。用注册这个功能举例，用户最初始的操作就是请求注册，期待最终的结果就是注册成功获得账号。那么在流程图这个阶段，表单有哪些字段，对应的交互策略是不重要的，只用假设现在你的表单一定的完美的交互形态就行。
2. 将中间流程拆分。这个时候就需要将流程细化到每一个步骤，最理想的状态每一个步骤都对应后端的一个接口调用。还是以注册功能为例，提交表单就是一个步骤，如果使用注册账号就显得有些含糊不清了，因为对于后台而言，提交表单和生成User是两件事情。
3. 补充子流程。这个时候就是展现你产品功力的时候了，对于异常事件的遍历是给开发同学最好的帮助，网上有很多现成的功能自查表，当然流程图不用细致到交互层面，总结出主干以及支线的流程就可以了

（2）建立数据字典

为什么需要数据字典？这个问题其实和网上争论很久的产品经理需不需要懂技术有很大的关联性。我的观点是，产品经理是一定需要懂技术的，当然不需要像开发同学那样能写实现的代码，但是逻辑层面的数据流转，PM是必须要懂的，至少在开发同学设计库表时能够参与进来，从业务发展的角度上给予一定帮助。

为什么产品要提前建立数据字典？看起来和产品没有多大关系的事情，其实是我们PM的核心能力。无论是优化现有功能还是新增一个功能，对于背后涉及的字段我们必须提前想清楚。

1. 从业务层面去理解数据字典。产品的每一个功能都不是孤立的，我们在构想数据字典时得提前考虑功能之间的耦合关系，这样我们才能定义好每个功能的输入以及输出。产品不会是表单设计的最终决定人，但一定是表单框架的直接影响人。以评论这个功能为例，我们在设计页面时得提前列出所有的信息元素，评论人，评论时间，品论内容，评价分值……其实这些信息元素就是后台的数据字典了。
2. 从界面的角度去理解数据字典。比如注册功能的表单，我们得提前列出所有涉及以及新增的字段，反复推敲哪些字段是必须的，哪些是可以省略的，哪些是作为选填的。产品的职责就是简化流程，对于表单类的产品就是减少客户需要输入的表单，能自动填写的一定不用客户去填，能有Suggestion提示的，一定要提示客户自动补全。那么这些填充以及补全的字段，我们都得提前想清楚。

三、建立反馈

1. 建立数据指标

版本上线不代表就已经交付成功了，产品方案设计完的第一件事就是建立数据指标。对于新人产品往往会存在以下几个误区：

1）数据不重要

大多数新人产品在刚踏入工作的时候，对于一个版本迭代其实没有太大的监控意识。版本Review可能更多是对Bug的回溯，不会主动去看线上数据的好坏。

对于所有的PM而言，没有数据监控的迭代就是蒙眼狂奔，累功能的结果就是大多数功能都没客户使用。所以即使是产品功能经理也得有数据监控的意识。

2）虚假繁荣指标

刚开始分析数据的时候容易找不对门路，建立监控指标的时候往往只看到自己想看到的。比如我们去看数据的变化效果时，往往会忽略其他因素带来的影响。这类例子也实在太多，比如一个广告推荐位带来的数据上涨不能反馈功能优化的结果，短期的上涨无法告诉你这个迭代我们做对了。

3）指标过多

有了一定入坑经历后，我们往往会特别慎重起来，监控一个功能会把所有能用的数据都查一遍，这样的结果就是有涨有跌，最后还是拿不准该干什么。这个时候一定要记得，一个产品在不同的阶段一定只有一个唯一的关键指标，所有的迭代效果都以这一个指标为准。比如你看注册功能，最终的标准就是转化率，表单填写比率只是一项辅助指标，只有当你分析具体原因的时候才需要拆解更多的指标观察。

2. 上线分析

结合指标和功能，分析数据指标产生差别的原因。所有的指标都是可以量化的，也就是说迭代的效果一定是好与不好，没有其他的情况。先根据唯一的指标明确本次迭代的最终效果，然后再提出假设，逐层拆解指标去验证假设。

3. 迭代计划

达到了预期目标，可以总结产品经验应用到其他功能。

没有达到预期目标，需要深究用户实际行为和预期行为产生差异的原因。为下一次的迭代做好理论支撑。

最后

产品功能经理是我们成为真正PM的第一步，也许目前你还不是一个业务模块的负责人，但是做好一个功能的PM也是值得我们深挖的事情。

本文由 @One 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议