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