刚步入产品经理这个行业的同学，是不是还对这个岗位的内容不大了解全面呢？下面这篇文章是笔者整理分享的一个产品经理工作流的相关内容，有需要的同学可以进来看看哦！
很多刚转产品经理的童鞋，大部分对产品工作都比较模糊，有些还会认为画原型，就是产品的主要工作了。
如果把产品的职业生涯比作马拉松，那么作为原型仔的你，可能才跑出了 500 多米。
这就想捧起奖杯领奖阿？先醒醒，哈哈~
作为过来人，我试着分享一个简单的产品经理工作流，帮你稍微避避坑。
按照它去做，不说成为乔布斯、张小龙，至少你也能写出媲美 3 年产品的 PRD 需求文档了。
产品经理的工作难度，就像淘宝的千人千面，可真是一言难尽。——好夕雷
有些搞个思维导图，画画原型，这也算是一个产品方案了，刚入门的产品小白千万别学这套。
你要做的是，首先建立起产品工作的初步认知，快速熟悉产品流程的各个环节。
以上是个人以前用到的产品工作流程，主要分为8大类：需求管理、产品规划、产品构思、UML分析、流程分析、产品设计、项目管理、其他内容等。
如果你只想输出产品方案，那么简化下这个工作流就行，大致为：接需求、懂业务、理流程、选方案、建模型、定状态、画原型、补交互。
学会把需求颗粒度拆为原子级，版本规划就像喝水那样简单、自然。——好夕雷
产品经理的需求，主要有老板、业务、合作方和用户等来源。
除此之外，如果你闲着没事，花点心思做做数据分析，或自行挖掘用户需求，这也是一种常见的需求来源。
很多产品做到 2~3年左右，都会遇到一个问题，“需求那么多，完全做不完，这种日子怎么熬到头阿？”
产品经理要想在职场中浑水摸鱼、到点下班。你需要了解需求的不同特性，分别是“需求有不同颗粒、需求有优先顺序、需求有高低价值”。
如何理解需求的高低价值？
产品经理的大坑之一，就是容易陷入业务的节奏，老是接完烂需求，就屁颠屁颠干活去了~
要想识别这种投产比极低的需求，你可以从“战略契合、市场潜力、商业价值、符合目标、覆盖人群、使用频率、研发成本”这几个维度，判断一个需求的价值高低。
那什么是高价值需求？据我以往的产品经验，真正高价值的需求可能只占 1%。
这能带来什么启示？二八法则同样适用于产品领域。
所以你需要花更多时间思考和决策，用 80% 精力找到那最重要的 20% 需求。
如何应对业务提出的低价值需求？一种做法是，将需求泛化为系统能力，进而满足未来更多的需求组合。——好夕雷
产品日常工作中，承接的大部分需求，都会和业务强相关。
作为不懂业务的产品，又要设计出让用户、老板、业务方用得爽的产品方案，那么短时间学习、掌握业务规则，就成了必备能力。
懂业务没有捷径，你只能一遍遍拉着同事开会、确认业务细节。
我这个人有个缺点，就是记性太差啦，所以我会把学到的业务知识，沉淀成业务规则文档，方便自己回溯、复盘。
产品的一个比较重要的输出物是流程图，它主要分为“业务流程、功能流程、页面流程”。
产品要做的是，在上述不同的维度中，进行相关流程的系统梳理。
产品要学会去平衡，功能之上价值的千人千面。——好夕雷
搞定了“接需求、懂业务、理流程”后，接下来就要针对需求，进行方案选择了。
不同的方案，相应的”市场潜力、商业价值、覆盖人群、能力要求、研发成本“也不同。
日常的产品工作中，我们往往会输出各种产品方案，我总结了主要有以下四种：
在这个过程，你需要根据实际情况，平衡各方利益，并找出一条 ROI 最高的产品方案。
数据建模是对真实世界的关系模拟，仅有一种最优解。——好夕雷
什么是建模型？
建模型，主要指的是使用 UML 类图来呈现系统中，不同对象、对象之间的关系。
理想情况下，你所设计的数据模型，应该尽量和现实世界保持一致。
产品可以在此基础上进行场景匹配，甚至功能延伸。
然而产品小白进行方案设计时，往往没有概念，甚至忽略数据建模，造成方案与需求严重不匹配。
这种错误，常见于1~2年的产品小白。如果缺陷方案一旦落地，等待你的将是重构，甚至业务方的声讨。
如何理解这句话？举个例子你就明白了。
我们日常在淘宝、京东购物下单时，一般链路都是“选商品、购物车、去下单、支付款、等发货、拆快递”。
现在问题来了，刚说的整个购物流程，你能识别出几个对象，以及它们之间的关系吗？
区别一个产品是否入门了，可以用它作为面试题，原型仔是不会考虑这么多的（是我！说多了那都是泪阿）。
假如产品一个不小心、偷个懒、脑子发热了，原型只画了一个订单一个商品。然后又那么巧，后端摸鱼走神了，你猜会发生什么？
喜闻乐见的 BUG 出现了，购物车买 10 个商品下单后，TMD 居然给我生成了 10个订单，你说气不气？
有人说 ，根本不可能有这么离谱的事情发生！那一个订单的快递包裹怎么发、订单评价是基于订单还是商品，订单和售后是什么关系呢？
说实话，你让一个做过电商的产品经理，都不一定答得出来。
假设你会数据建模，这题简直秒解。
没做过电商你总上过淘宝吧，稍微联想下实际情况，答案不就出来啦！
定状态指的是 UML 中的状态图。
状态图，描述了一个对象在周期内，相关状态及其变更条件的过程。例如一个电商订单从待付款到已付款的变化。
在这个工作流程中，你需要搞懂相关功能的“不同状态定义、状态变更条件、以及对应的状态功能”，并输出成对应的状态图。
当你做好了“数据建模、状态图绘制”后，接下来只要按照这些内容，画相关的功能原型、撰写规则就 OK 啦~
不少产品小白在问我，不懂画原型咋搞嘛？
我反手花 5 分钟，就给你现编一个，快速掌握原型的 4 步法：掌握工具、熟悉组件、使用模板、组装原型。
不同用途的界面，由特定的组件组成，掌握了基本套路，1 天整 10 个界面真的算慢啦~
要想让原型动起来，可千万别忘了交互。
交互一般可分为动态交互和静态交互。
一些产品进行交互设计时，会习惯使用动态交互，这样可能看起来更酷炫。
沟通的本质，是减少信息差。——好夕雷
如果使用动态交互，一个稍微复杂的交互效果，做的人效率低不说，查阅的开发同事，要重复点击多少次，才能完全理解其中的逻辑，换我也崩溃~
所以，使开发一目了然、快速抓住交互重点才是文档的核心，那么静态交互在这种情况，就成了最优解。
九、总结
对于刚转行产品的童鞋来说，要知道产品经理的工作不是只有原型，工作越往后原型的占比越低。
如何才能输出一个不错的产品方案？
可以按照这个产品工作流去做：接需求、懂业务、理流程、选方案、建模型、定状态、画原型、补交互。
你学会了吗？
本文由 @好夕雷 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。