产品经理的最大作用是将需求转化为产品或者功能，从需求到功能，会经历哪些过程？本文总结了从需求到功能的转化过程，希望对你进一步了解有所帮助。
“大部分的产品经理特别是数字化产品经理其核心价值就是如何去解决如何把需求转化为用户可使用、易使用、爱使用的并能够解决业务实际问题的功能或产品。”
产品经理最大的作用就是把需求转化为产品（由很多功能组成的系统，如果放在实物领域就是能够满足人们某些特定需求的载体），看了很多产品经理的工作方式，这10多年也和很多产品经理有合作过也了解他们的工作方式，发现从需求转化为产品其实是一件很麻烦、很难的事。
一般来说从需求到产品大概可分为这几个阶段：用户调研、市场分析、产品规划、需求收集、需求分析、代码开发测试、试运行、上线、迭代升级。
一般的产品经理很难负责所有的环节，只有是某一个产品的负责人才会对整个过程负责，大部分的产品经理都是在产品规划到代码开发测试 这部分环节开展工作，而这个阶段也是把需求转化为功能的关键阶段，解决的是做什么的问题。
在这个阶段之前都是处于规划、设计阶段，更多的是论证可行性，在这个阶段之后只是把已经确定的系统实现出来更多的是资源、时间、进度的问题，而只有这个阶段会决定用户使用你产品的体验会如何，产品功能是如何能够让用户获得价值的。
很多产品经理忽视了这个阶段最本质的价值输出，陷入了一种解决问题的天性中了，用户的需求即是他所面对的问题或者是体验很差，产品经理在扑捉到用户的需求后立即想的是如何去解决这个问题，缺少对真实诉求的分析，也缺少从系统设计的整体性层面去进行需求分析。
大部分的产品经理特别是数字化产品经理其核心价值就是如何去解决如何把需求转化为用户可使用、易使用、爱使用的并能够解决业务实际问题的功能或产品。
想要体现这个核心价值，产品经理不能成为用户的传话筒，一定要能够透过现象看到用户的真实诉求、底层需求，要看到情绪层面、价值层面的逻辑；也需要考虑系统整体架构的合理性，能够从业务、应用、数据、体验等不同维度去思考如何进行设计。
我举几个例子，看看大家在日常工作中有没有遇到啊。
故事一：有一次在评审活动类型的产品需求时，只看到了前台商城上面的页面，并没有对应活动配置的页面，问产品活动时间如何控制、活动价格如何控制、活动库存如何控制皆无法回答，和其讨论时来了一句用户只提了这些需求，产品不是业务的传话筒和原型设计人员，我们是产品经理，我们需要搞清楚产品功能上每个字段、每个交互后面的逻辑、含义。
故事二：在几年前，我们做过一个电商重构的项目，当时我负责商品、交易相关的功能模块，在设计商品模块时由于自己经验也有限，只能从过往比较粗浅的经验以及在网上找到的一些资料出发去进行功能设计。看到了一个完整的电商商品的功能结构-SPU+SKU的体系，当时把这个体系抄过来后还洋洋得意，感觉自己能够实现如此复杂的功能模块也是蛮厉害的，但上线之后发现很多问题，在电商的商品模型里面缺少供应链所需的业务逻辑，更多的是站在如何对商品进行售卖的角度出发，但商品的库存如何管理、采购环节需要什么关键信息、财务对商品又有一些什么需求并没有在模型中进行提现，导致后期在上线后各方使用商品数据时还是比较混乱、无序。
故事三：设计一个移动端代客下单的功能，在产品经理和用户进行详细的需求调研、分析后，设计的整体用户操作路径为：订单列表页-新增订单页-选择商品页-填写商品下单信息-回到新增页-循环以上步骤，只支持单个单个商品操作，在选择商品的页面提供了搜索框和筛选条件，支持按商品名称、编码、规格搜索，支持按品牌、规格以及其它属性进行筛选。从逻辑上面看这个功能设计的完全没有问题，但在上线后，却成为了员工们吐槽最多的功能。为什么呢？我们去调研了吐槽的实际使用人员，主要以下原因：
以上的一些故事，相信大家可能也有遇到过类似的情况，而这些都是一个产品经理不够成熟的表现，一个成熟的产品经理是能够具备良好的从需求转化成功能的能力，而不是简单的去实现功能。要做好这种转化工作需要产品经理具备一些专业的知识。
所有的系统功能都应该是为了业务落地的，业务在网络空间的一种映射，比如说：库存管理中有出入库单，对应的就是实际业务中的出入库操作；商品管理中有上下架功能，对应的其实就是现实业务中上下架商品的业务；在比如交易过程中有加入购物车、下单、支付等功能，其实也是对应我们现实购物场景中的实际操作。
我们要想做好需求转化为功能的过程，第一步就是能够对业务进行抽象建模，我们需要梳理清楚业务流程是从哪到哪，每一个环节涉及的角色、操作、处理逻辑有哪些，是怎么样的，也需要明白这个业务流程最终给哪些用户输出了什么样的价值。我们在做产品策划的过程中脑子里面时刻要记住系统是业务在网络空间的映射，脱离了业务流程、业务场景去设计功能都是闭门造车。
业务流程分析：
对业务进行梳理后，我们真正进入了需求分析的过程中，很多同学到这个阶段不知道如何去开展工作，只能简单的从需求中提炼一些表面的信息，直接去进行产品原型的设计，以为原型出来产品策划的工作就基本完成了，这是打错特错的，你这样做之后大部分的情况会陷入我们上面讲的三个故事一样的境地。
系统是业务在网络空间的映射，在网络空间中建设系统至少要在这几个维度上去进行设计：数据结构、代码逻辑、页面交互，当然还需要在物理环境、网络环境层面进行设计，但这些与产品的工作关联性不大。
软件系统说的简单点就是使用角色对系统进行输出，系统更具代码逻辑做出必要的反应，给出输出。
在前面业务分析的过程中我们梳理出来了角色、操作、处理逻辑以及每个节点的输入和输出，这些内容是我们做需求分析最核心的输入，我们需要把这种业务语言转换成软件语言，我们可以从这些内容中提炼出关键的名词、动词以及一些限定词汇，关键的名词往往是我们功能操作的主要对象，我们也可以称之为实体或对象，为了表达它们我们需要对这些概念进行定义，并通过主要的属性以及生命周期去把定义显性化，不同概念的差别也主要提现在了这些地方。
提炼出实体后，我们还需要去梳理各个实体之间的关系，能够明晰哪些实体的变化会对其它实体有影响，影响是什么。这部分的分析结论，不是一蹴而就的，也是需要反复推敲琢磨的。能够有类似以下的一些输出物：
实体模型：
状态机：
状态描述：
以上的过程我们更多是在数据结构层面进行梳理，在这个过程之后我们还需要对业务逻辑进行抽象分析，我们需要能够详细定义如何去获取或者接受输入信息，输入的信息有哪些内容，传输的方式是什么样的，频率如何，如果发生了极端情况我们如何处理。
然后我们需要对每个节点的业务逻辑进行分析，形成结构化的语言去进行描述，在系统中大部分的业务逻辑都是需要通过操作或者是系统自动的方式去触发它，而具体的操作也是我们去进行业务逻辑结构化描述的起始点，从这里开始我们逐步分析这个操作对哪些实体有影响，影响了实体的哪些属性的变化，这些影响是怎么样去生效的，在系统中业务逻辑说到底就是用户的操作对数据产生变化或者是能够对用户输出特定的一些信息的规则、步骤，我们在描述这些规则、步骤的时候一定要互相独立、完全穷尽，做到不遗漏、不重复。
最后我们还需要分析清楚当前的这个环节对后续那个流程节点或者是角色有影响，我们需要定义用何种方式去对影响他们，是通过实体属性的变化产生了影响，还是通过下游环节输入的形式，亦或者只是需要提醒或通知到某些角色即可。
通过以上几个环节，我们把产品功能设计中最为抽象的部分做完了，但在产品功能设计的工作中还有具象化的部分的工作，那就是如何把信息呈现并与用户产生互动，这两步的内容我们可以参考用户体验要素的模型中最上面三层：结构层、框架层和表现层。
此处不做过多的方法论的说明，需要的同学推荐可以去看一下《用户体验要素》这本书。输出物一般为功能结构图、用户使用路径图、产品原型、设计稿等。
更想说的是，交互、视觉、用户体验这些内容很多时候是被大部分的产品不太重视的，总认为逻辑正确、模式正确那产品一定会成功，但我想说的是大部分的用户他们不关心或者说首先关心的不是逻辑正确、模式正确，他们首先能够感受到的是交互、视觉、体验，好不好用、容不容易使用是他们首先能够感受到的，只有他对产品功能的印象是正面的他们才有可能继续使用或者是能够“友好”使用你的产品。
我们做产品设计时既要能够“从下往上看”（从数据-逻辑-应用-体验），也能够“从上往下看”以用户视角去看自己设计的产品。
以上是近期重新开始做具体产品设计工作的一些感悟、总结，也算是对自己这些年经历的不同产品阶段工作中可能遇到的一些问题以及如何去解决的一些思考，希望对在成长过程有相似困惑的产品经理有所帮助，也欢迎大家一起留言讨论。
专栏作家
不可分类者，微信公众号：数字化产品，人人都是产品经理专栏作家。专注于电商中台的产品设计，擅长产品规划及需求分析；热衷于研究中台、SaaS等领域的最新产品形态。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。