我是如何把“老板的一句话”变成产品功能的？

                                                当老板提出了“一句话需求”时，作为PM的你是否懵逼过？面对这样的需求该如何下手呢？

“一句话需求”也许大家多多少少都碰到过，通常就是老板/上司的一句话：“我想在产品上做一个XX功能，你来负责吧”，至于为什么要做？做了能给用户带来什么好处？怎么做？等这些问题，都需要产品经理自己来消化，自己说服自己。
我所接触过的需求源
在我的工作经历中，所负责与设计过的产品功能，其需求来源大可分为以下三类：
[ol]

产品经理/总监，结合产品定位与用户价值，自己所构想的产品需求。

其他部门所提出的需求，如运营部、运维部、财务部等。

老板或决策管理层，提出的需求。
[/ol]
对于1和2这类需求，大部分都是有明确且较详细的“说明”的，产品经理在思考“为什么要做？”和“怎么做？”这一过程是相对较短的，自己的需求肯定比谁都想的透彻，其他部门的需求，也肯定会有人来告诉你需求的描述。
对于第3种类型的需求，前不久刚好做过这类“一句话需求”，稍微复盘了一下，分享给大家。
准备工作
接到任务的时候，确确实实就是一句话“我们打算在产品上实现XXX功能，你来负责”，之后直到上线，都没有再和老总沟通过关于“XXX功能”的事情。
然后我对即将要展开的工作，做了如下梳理：

对于程序员来讲，改一个Bug所花的时间，80%在用来找原因，20%的时间才是敲代码。
对于产品经理来讲，可能做一个功能所花的时间中，验证功能可行性所耗费的时间绝对不低于50%，其中包括对产品/用户价值、产品方向、实现方式、技术难度、业务匹配等的验证，所以很多老PM们都建议新人们，别纠结于用Axure做交互，做效果，前面没想好，做再炫酷的动效都等于零！
了解什么是XXX功能
[ol]

公司为什么想做这个功能？

做了能满足用户/平台的什么需求？

能为用户/平台解决什么问题？
[/ol]
这是我首先展开思考的三个问题，为什么要这样做呢？ 因为在开始做之前，至少我要把自己说服，只有在我开始对这件事情感兴趣以后，主观能动性大于行政命令而产生的被动做事状态，才能把它做好。
其次，在思考的过程中，也许能发现老总没注意到的问题，如风险或更好的替代方案。
最后，是最基本的行为准则，作为产品经理，对自己所负责的产品与功能，应该要做到在全公司，“没有第二个人比自己更了解”的这种状态与信心才行，无论谁来问你，需要你回答关于你负责的内容，你都能讲的面面俱到，否则被问到哑口无言，那给人的感觉就是不专业，不负责，没想好。
设计方案
看似是一个步骤，但在这个阶段耗时是最多的，可以再细分为如下步骤：
1.确定功能范围
首先我要考虑的是，这个功能的使用范围是怎样的，抽象一点讲就是从深度与宽度两个层面考虑。
拿“我想做一个聊天功能”举例，从“单对单”的聊天到“多对多”的聊天，从“文字聊天”到“语音、视频”聊天…
同时还需要考虑到技术难度，开发周期，功能价值等因素，综合来决定这个功能的开发范围。
2.选取第三方服务商
这个步骤，并非所有功能都会有的，只是恰好本次功能需要使用第三方平台。
因为行业的特殊性，导致在我们这个细分领域下的第三方平台，都处于刚起步的状态，有些公司甚至连开发文档都没写好，就大胆的在官网上表示“我们已经可以提供技术支持了！”这类含义的内容。
因此需要详细且深入的沟通，对接，以验证对方是否有能力支持我们的产品，以及双方的系统，是否能成功对接。如果市面上都没有合适的服务商，来提供技术支持，那么这种非人为可改变的环境下，就不能开发公司希望的“XXX功能”。
3.验证方案可行性
把以上做的事情，汇总为一份文档后，初步形成一个“功能概念”文档，在这里我的做法是，分别去找与该功能有联系的部门，人员，一个接一个的沟通，有问题就立即修改，没问题就换下一位，直到所有人员都私下过了一遍方案后，那么就可以召集这些人以及老板，一起来开需求评审会了。
在会议上，我会描述本次方案的内容，因为在开会前，已经分别找了关键人沟通，因此在需求评审会的时候，杂音会很少或几乎没有。因此开会的目的，实质上就是告诉大家，我们在某个版本，会正式启动这一块功能的开发，产品部会做什么，研发部需要准备什么，运营部需要准备什么…等等。
之前所做的，所有的工作的目的，都是为了低成本的试错，这点很重要，只有明确、有价值、能实现的东西，才能让公司调动资源投入。
产品设计
1.思维导图
我使用思维导图的目的，通常是记录设计中的注意事项，包括某些逻辑、规则、方法的记录，这个其实是因人而异，通常会画一个产品信息架构吐，但对于我来讲，这些内容全在脑子里，而如果真的记不住的话，还是输出一个产品信息架构图好一些。
2.流程图
产品流程图应该是设计过程中，最重要的一个环节。
产品如果是一棵树的话，那么流程图就是主干，线框图、原型图只能算是丰富主干树枝树叶。
如果一张图不能当前功能的业务逻辑，那就使用两张图，三张图，对于流程不复杂的不需要更多商议的功能，我通产选择直接在Axure搭配页面迁移图就做了，也能表现出功能流程。
3.线框图
现在很多人把“线框图”与“原型图”的含义弄得有些混淆，我自己的定义是，前者为“低保证原型图”，后者为“高保真原型图”，高保真原型图更多的目的在于，演示给客户、投资人、老板..看，因为这些用户希望看到一个最贴近产品的结果。
而我个人倾向于，对于演示给开发人员看，低保真的线框图就完全足够了，只要开发人员能最快理解产品经理的意思就达到目的，且线框图输出速度快，试错成本低。
一句话就能让开发人员明白的事情，就完全没必要画1个小时去画出来。

线框图
以上，就是在我遇到“一句话需求”时的做事流程，以及处理方式，抛砖引玉，分享给大家。