产品经理思维转变1

很多人问：产品拿到需求以后，先画原型还是先写PRD文档啊？我看产品最终就是写一份文档，我边写边想直接弄一份文档不就行了？

为什么这么做----目的
先画原型文档就出来了，先有文档原型胸有成竹是这样吗？

看到这个问题想到了自己以前刚刚转行，当初的自己帅气逼人，感觉意气风发脑子的想法多的无处释放，终于得到老板跟我亲切交流的机会：我们需要提高一下用户留存，研究一下有什么新玩法，搞个文档你们一块探讨一下。

老板亲自吩咐这是何等的荣耀自然不敢怠慢，憋了三天终于输出一份另我满意的文档，想法之新颖，功能之全面，我自己都差点给自己跪下磕头了，交给老板老板看了眉头一皱：你想法不少啊，A需求不是已经在做了吗？B需求跟现有的XX功能有什么不同，C功能是用户真实需求吗？别搞成电视机效应，以为有用结果没人用。扒拉扒拉一堆，当初让你提高留存率，你这文档里哪有提高留存的方案。

我脑袋一翁：什么留存？这老头真有意思我文档写的这么好你跟我提留存。

老板苦口婆心的说：小杨啊，你文档内容挺多，可读性也不错，但是你想想你写文档的目的是什么？我给你的要求是什么？你找出什么问题？最终解决方案是什么？你写的都不是我想要的。

从那以后我记住一个词：目的。

2、什么是产品原型？什么是产品需求文档？

言归正传，什么是产品原型什么又是产品需求文档？他们又是做什么的？

两者都是产品经理工作中的产出物，其作用完全不同。

我个人认为产品原型是在产品经理明确目的以后，通过需求调研和需求分析找出问题所在，并制定解决方案，将方案转化为具体的产品功能，而原型就是这一阶段的产物，是产品功能可视化的表现形式。

而PRD文档则是对产品从确定目的到最终完成原型的过程的整理和总结，以及对产品原型的详细描述，目的是让开发、设计、测试以及顶头上司了解你的设计方案，是产品的说明书，大家都按文档写的来，谁也别扯皮。

文档是产品经理的技能之一，因为文档就是产品经理对外交流的手段和产品经理的嘴并称：产品两大利器。文档写的差嘴来补，嘴笨文档补总之你的方案能不能落地就靠这两大武器了。因此产品需求文档是产品经理的最终产物，是产品开发的最终标准。

3、产品经理的日常

跑偏了，我想说的是产品经理的技能不只是写文档那么简单，产品需求文档决不是凭空产生的。写不重要的文档东西都是拍脑袋想出来的，总是跟人吵架，实际上是对产品经理工作的误区。

事实上产品经理工作的每一步都有具体产出。

（1）需求获取

有了目标，拿到任务以后就可以展开工作了，不管是哪种方式获取需求，竞品分析也好，用户调研也好，最终目的是想发掘是用户痛点找到问题，因此在这个阶段你需要整理出你找到的问题，也就是需求池。一份完成的需求池需要有需求来源，你的竞品分析报告用户调研报告也是重要组成部分。

（2）需求分析

从需求池中挖掘用户真正的痛点，用户想要一匹跑的快的马？他真的想要一匹马？不，他只是想要跑的快的交通工具。因此此时你应该从需求池中挖掘用户真正的需求，剔除伪需求，最终的分析结果就是一份需求列表，并标明优先级。

（3）产品结构设计

你已经有了众多需求，也做出了优先级的排序，此时要对软件功能结构有一个明确的划分，是主要功能放在第一层级还是次要功能放在第二层级。做完这些工作产品结构图就出来了。

（4）产品功能设计

有了产品结构图，产品的框架搭起来了。对产品具体功能的逻辑设计也要开始了，完成具体功能设计你的最终成果应该是一份产品功能流程图，让开发小伙伴知道你设计的功能操作流程和逻辑判断是怎么样的。

（5）原型设计

坚持到这一步，前期的需求获取把老板打发了，需求分析把用户解决了，产品设计把把开发打发了，要知道UI设计也是一块难啃的骨头，那帮小娘子也不好惹，所以你得搞一份产品界面的原型给她，让她们搞清楚你的界面是怎么打算怎么排版，画的越难看但是内容越完整越好，让那帮小娘子生气又挑不出什么毛病。最终一份原型图就出来了。

（6）交互设计

原型画完了，光能用干不行还得想好用易用用的舒服的问题，因此有些灵活的东西，比如人机交互，光靠图形说不清楚，因此在原型上要做出交互的结果和交互逻辑。

（7）产品需求文档

干完了所有的工作，自己忙个臭死，你以为你是功臣？别的小伙伴可不这么认为。

为了让这帮短见的家伙知道你在干什么，你干的结果是什么，因此把前面每一步得出的东西整理到一个文档里，一份产品需求文档就诞生了，剩下的工作就是带张嘴准备在评审阶段自吹自擂，吐沫横飞横飞的同时手撕他们这帮短见的家伙。

当然之后还有开发、测试、上线等工作要跟进，产品什么时候也不是闲人，工作也不仅仅是一份文档。

在工作的每一步都这样问自己：你的目的是什么。

因此原型是凭空产生的吗？文档需要专门去写吗？留给大家去讨论吧。