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

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

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

“一句话需求”也许大家多多少少都碰到过,通常就是老板/上司的一句话:“我想在产品上做一个XX功能,你来负责吧”,至于为什么要做?做了能给用户带来什么好处?怎么做?等这些问题,都需要产品经理自己来消化,自己说服自己。

我所接触过的需求源

在我的工作经历中,所负责与设计过的产品功能,其需求来源大可分为以下三类:

  1. 产品经理/总监,结合产品定位与用户价值,自己所构想的产品需求。
  2. 其他部门所提出的需求,如运营部、运维部、财务部等。
  3. 老板或决策管理层,提出的需求。

对于1和2这类需求,大部分都是有明确且较详细的“说明”的,产品经理在思考“为什么要做?”和“怎么做?”这一过程是相对较短的,自己的需求肯定比谁都想的透彻,其他部门的需求,也肯定会有人来告诉你需求的描述。

对于第3种类型的需求,前不久刚好做过这类“一句话需求”,稍微复盘了一下,分享给大家。

准备工作

接到任务的时候,确确实实就是一句话“我们打算在产品上实现XXX功能,你来负责”,之后直到上线,都没有再和老总沟通过关于“XXX功能”的事情。

然后我对即将要展开的工作,做了如下梳理:

对于程序员来讲,改一个Bug所花的时间,80%在用来找原因,20%的时间才是敲代码。

对于产品经理来讲,可能做一个功能所花的时间中,验证功能可行性所耗费的时间绝对不低于50%,其中包括对产品/用户价值、产品方向、实现方式、技术难度、业务匹配等的验证,所以很多老PM们都建议新人们,别纠结于用Axure做交互,做效果,前面没想好,做再炫酷的动效都等于零!

了解什么是XXX功能

  1. 公司为什么想做这个功能?
  2. 做了能满足用户/平台的什么需求?
  3. 能为用户/平台解决什么问题?

这是我首先展开思考的三个问题,为什么要这样做呢? 因为在开始做之前,至少我要把自己说服,只有在我开始对这件事情感兴趣以后,主观能动性大于行政命令而产生的被动做事状态,才能把它做好。

其次,在思考的过程中,也许能发现老总没注意到的问题,如风险或更好的替代方案。

最后,是最基本的行为准则,作为产品经理,对自己所负责的产品与功能,应该要做到在全公司,“没有第二个人比自己更了解”的这种状态与信心才行,无论谁来问你,需要你回答关于你负责的内容,你都能讲的面面俱到,否则被问到哑口无言,那给人的感觉就是不专业,不负责,没想好。

设计方案

看似是一个步骤,但在这个阶段耗时是最多的,可以再细分为如下步骤:

1.确定功能范围

首先我要考虑的是,这个功能的使用范围是怎样的,抽象一点讲就是从深度与宽度两个层面考虑。

拿“我想做一个聊天功能”举例,从“单对单”的聊天到“多对多”的聊天,从“文字聊天”到“语音、视频”聊天…

同时还需要考虑到技术难度,开发周期,功能价值等因素,综合来决定这个功能的开发范围。

2.选取第三方服务商

这个步骤,并非所有功能都会有的,只是恰好本次功能需要使用第三方平台。

因为行业的特殊性,导致在我们这个细分领域下的第三方平台,都处于刚起步的状态,有些公司甚至连开发文档都没写好,就大胆的在官网上表示“我们已经可以提供技术支持了!”这类含义的内容。

因此需要详细且深入的沟通,对接,以验证对方是否有能力支持我们的产品,以及双方的系统,是否能成功对接。如果市面上都没有合适的服务商,来提供技术支持,那么这种非人为可改变的环境下,就不能开发公司希望的“XXX功能”。

3.验证方案可行性

把以上做的事情,汇总为一份文档后,初步形成一个“功能概念”文档,在这里我的做法是,分别去找与该功能有联系的部门,人员,一个接一个的沟通,有问题就立即修改,没问题就换下一位,直到所有人员都私下过了一遍方案后,那么就可以召集这些人以及老板,一起来开需求评审会了。

在会议上,我会描述本次方案的内容,因为在开会前,已经分别找了关键人沟通,因此在需求评审会的时候,杂音会很少或几乎没有。因此开会的目的,实质上就是告诉大家,我们在某个版本,会正式启动这一块功能的开发,产品部会做什么,研发部需要准备什么,运营部需要准备什么…等等。

之前所做的,所有的工作的目的,都是为了低成本的试错,这点很重要,只有明确、有价值、能实现的东西,才能让公司调动资源投入。

产品设计

1.思维导图

我使用思维导图的目的,通常是记录设计中的注意事项,包括某些逻辑、规则、方法的记录,这个其实是因人而异,通常会画一个产品信息架构吐,但对于我来讲,这些内容全在脑子里,而如果真的记不住的话,还是输出一个产品信息架构图好一些。

2.流程图

产品流程图应该是设计过程中,最重要的一个环节。

产品如果是一棵树的话,那么流程图就是主干,线框图、原型图只能算是丰富主干树枝树叶。

如果一张图不能当前功能的业务逻辑,那就使用两张图,三张图,对于流程不复杂的不需要更多商议的功能,我通产选择直接在Axure搭配页面迁移图就做了,也能表现出功能流程。

3.线框图

现在很多人把“线框图”与“原型图”的含义弄得有些混淆,我自己的定义是,前者为“低保证原型图”,后者为“高保真原型图”,高保真原型图更多的目的在于,演示给客户、投资人、老板..看,因为这些用户希望看到一个最贴近产品的结果。

而我个人倾向于,对于演示给开发人员看,低保真的线框图就完全足够了,只要开发人员能最快理解产品经理的意思就达到目的,且线框图输出速度快,试错成本低。

一句话就能让开发人员明白的事情,就完全没必要画1个小时去画出来。

线框图

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

 

本文由 @Palowlto 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自PEXELS,基于CC0协议

欢迎打赏支持原创
4人打赏
评论
有话不说憋着难受
  1. 虽然还没有入PM坑,但是很有启发……提示一下哦,产品设计第1点,思维导图中有错字哦,“通常会画一个产品信息架构吐”这里,第2点,流程图中“我通产选择”~我不是故意挑错,只是希望楼主的这篇优秀的文章能更完美~

    回复
    1. 哈哈,谢谢,确实是我的疏忽 :mrgreen:

      回复
    2. 是我该说谢谢,看了之后很有启发

      回复
  2. 脑图用来展现什么样的东西?可否举例或者推荐下呢?还有脑图用啥软件呢

    回复
    1. 你可以搜索“百度脑图”,Xmind,用了就知道有什么用了。

      回复
  3. 楼主写的很好,涨姿势了哈哈 :mrgreen:

    回复
    1. 谢谢 :mrgreen:

      回复
  4. 大部分时候,想办法说服老板不做才是正确的

    回复
    1. 因公司而异,我所表达的是一个执行的过程

      回复
  5. 老板经常会提出拍脑门的提案,很多细节都需要产品经理想清楚,所以还是应该问清楚老板的需求,沟通清楚了再做效率才高。毕竟有的时候老板提的可能会让整个功能重做或一直修改,对开发来说成本太高了~

    回复
    1. 所以需要prd评审和原型评审。

      回复
    2. 我就遇到一个问题,评审时开发或者老板都觉得没什么太大问题,都开始做了,就发现要调整。你有遇到过这样的情况吗?

      回复
    3. 人艰不拆。。。

      回复
    4. :idea: 这个很现实。。。

      回复
    5. 当然有遇到过,但是,除了零时出现的公司政策、业务、战略发展变化而影响产品,其余情况都属于范围不大的微调。

      回复
    6. 恩,我是尽量是微调,以最小的代价来做~ 特别害怕大调整,修改成本也太高了

      回复
  6. 对于老板抛过来的需求,我的理解是我们需要站在老板的角度去评估产品机会。判断产品机会,需要从产品本身和市场情况、自身情况来看是否可行。评估完后,你最为产品经理也认可老板的这个需求以后,就可以全身心的发挥自己的能力去设计产品功能逻辑流程,然后和各个相关部门验证产品相关功能。

    回复
    1. 说得好

      回复
  7. 写的还是蛮真实的 但是你好歹要多和老板去确定下原型评审的时候 不然 黑锅背死

    回复
    1. 我有写到prd评审和原型评审

      回复
  8. 攒!,老板“一句话需求”的这个问题很接地气,感谢分享经验!

    回复
    1. 啦啦啦

      回复
    2. 啦啦啦

      回复
    3. 谢谢,共勉!

      回复