我当产品经理的那点事儿 -20151101早读课

本网站用的阿里云ECS,推荐大家用。自己搞个学习研究也不错

<

section contentScore=”13184″>从去年9月开始入行做移动端产品以来,经历了三款产品。这一年中,我也由一名初出茅庐的菜鸟,蜕变为一名正式的产品经理。本来做总结应该是经常的事情,但因为自己懒惰,一直拖了整整一年才开始写一篇像样的总结。其实,在这一年当中,经常会有许多收获和感悟,总觉得如果下笔的话,绝对是长篇大论、滔滔不绝。但是没想到,刚提笔就发现根本无从下手。是写产品设计的心得呢?还是写用户体验的感悟?还是项目管理的经验?总觉得知识很多,却零零散散,缺乏一条主线将之串起来。索性,因为我经历过一个产品的诞生,就从产品之始讲起。
 

产品之始

一个产品是怎样诞生的呢?

可能是BOSS在厕所飞翔时,灵感涌现;可能是CEO出于战略目的,觉得公司需要做一款产品来满足商业需求;也可能是产品经理觉得市场上某个需求没有被满足,哭天喊地地求老板答应让他做。

不管产品出于什么样的目的诞生,但一款产品要想获得市场的认可,那就必须是基于一个需求而做出的解决方案。需求覆盖的用户群越大、被满足的意愿越强烈、出现的频率越高、市场上竞争对手越少,那么基于这个需求做出的产品,就越容易获得成功。

而我们产品的起源是老板基于资本市场的情况,提出要做一款以语音为核心玩法的社交APP。我们对此,做了一个简单的分析。

1
首先,移动互联网早期以文字为主的平台级产品无疑是QQ了,而相对高一纬度的便是以语音录播为核心的荔枝FM,再高一纬度是以图片为主的 instagram;美拍作为近几年比较火的短视频应用,主要是以视频录播的方式做社交;维度再往上的语音直播和视频直播几乎是没有平台级的产品。

语音直播相较于视频直播,对用户的门槛较低,流量成本也相对小,再加上语音直播能弥补语音录播互动性不足的问题。所以,公司决定做语音直播的APP是比较合适的。这款产品的定位就是:以语音直播为核心玩法的社交APP。而产品的目标就是开发出更加好玩、好用的功能;运营的目标便是增加类型更丰富的内容。至于 定位的目标用户,则很简单,就是现在的年轻人。

到这里为止,基本上一个产品的核心便诞生了,而以后所有的结构、功能、交互、视觉全部是围绕 这个核心展开的。从现在开始,就是产品经理发挥巨大作用的时候。我们要将一个抽象的需求产品化、功能化,并且将之实现。我想这是产品经理的核心价值所在, 也是大多数产品经理一直在做的事情。

 

产品设计

一款新的产品应该怎样去设计?

最简单的方法无疑是看竞品。毕 竟天下产品一大抄嘛。有很多人鄙视抄袭竞品功能这一行为,但我其实并不反感。汽车轮子是圆形的,不管你再怎么发明,也绝对不会创新出一个方形的轮子。你只能在轮子的大小,花纹,材质上做文章。有时候不是说后人非得抄袭前人,而是前人走的路是最合适的,后人不得不走同样的道路。

但是,有时候会看到一些产品经理用手机打开竞品页面,在电脑用Axure照着画。这种方式无疑是比较无脑的方法。其实,他并不是不思考,他也思考,有些竞品上的功能,他思考后觉得没用的就会去掉,有用的就会留下,遇到自己需要添加按钮的情况,就找合适的位置添加。这种设计方式无疑是极其快捷省力的,但也绝对是容易出问 题。长期以这种方式进行产品设计,很难进行产品上的创新。

在《用户的体验要素》一书中,系统地区分了一款产品的每个阶段,这种区分方式已经被大多数产品经理认可。

2
前面在“产品之始”的时候,已经确定了战略层。那下面应该根据战略层的目标,确定“范围层”中,做哪些功能,产品中要填充哪些内容?

在确定一个APP要做哪些内容时,思考顺序是至关重要的。首先,你要时刻将产品的核心印在脑中,带着战略目标思考。设计一项功能时要先想,我们的APP是否 需要这样一个功能。比如,做一款社交类语音直播APP,那语音直播该以哪种形式呢?是类似广播电台那种主持人讲,普通用户听呢?还是所有人都可以当主持人,随时随地都能进行语音直播?毫无疑问,肯定是选后者,因为我们的目标是做社交,是想让人和人之间产生关系,而不是类似秀场的主播和粉丝关系。

每思考好一条,就将之写在Excel中,尽量写明你的思考过程和结论,而这时先不做优先级排序,只写需求的重要性。在思考完所有自己能想到的需求后,再去打开竞品,查看对方的功能,看看自己刚才是否有漏掉的,从而补充丰富自己的需求池。没错,刚才的步骤就建立了一个早起最简单的需求池。

3
需求池建立好以后,就可以开始最早期的产品规划了。产品的第一版规划通常都是尤为重要的,而我建议在产品第一版一定要简洁、简洁、再简洁,只做最最核心的功能。比如我们做社交类语音APP,那我们就只做最重要的两部分:私聊和群聊(群聊可以语音直播)。从需求池中,将满足用户私聊功能的配套需求取出来,再将群聊配套的需求取出来,组成一套完成的流程,必须保证所有环节都是打通的,绝对不能出现死循环。

这里要注意,从需求池中取出来的需求,未必是最重要的,但一定要是配套存在的。 比如要满足基本的私聊需求:那么就要有用户查找功能,每个用户都有ID或者昵称可供搜索;在用户资料页面要有加好友的按钮;用户能从某个地方看到好友请求,并进行操作;成功加为好友后,要有相应的列表展示;如果我想删除好友,也要有相应的按钮。这些零零碎碎的需求,组成了一个完整的功能体系:私聊。如果 少了任何一环,都会产生问题。

在筛选出第一版本将要开发的功能后,就需要单独找到技术负责人,沟通实现的成本。如果不能实现或者实现时间太长的需求,则要考虑用其他方式处理。当第一版的所有需求都已筛选完毕,下面就开始产出产品需求文档和产品原型了。

 

产品需求文档

写纯word需求文档,绝对是产品岗位最苦逼的事情,不仅自己写的捉急,而且花费大量时间,更重要的是开发、美工、运营等部门,根本懒得看你文档。有时候宁愿QQ问一句,也懒得逐字逐句去读文档。

其实,现在很多产品经理已经发现了这个问题,解决方式就是用原型加标注的形式来产出需求文档。这样会更加直观方便,大大地提升了工作效率。下面展示一下我自 己设计的产品需求文档。我的产品需求文档里涵盖了很多东西,如果细说的话,恐怕需要另一篇文章来详细讲述。在这里我只简单说几点重要的地方。
4
修订历史,是一个文档必不可少的内容,不管前期你把问题考虑的多么周全,总会有没想到的地方。而有修订历史记录能保证每次修改后,所有内容都有记录,供所有人观看。

 

5
版本说明,是介绍每个版本所有的需求内容,点击查看按钮,可直接跳转到原型页面。技术负责人可以根据此表来分配工作内容,开发和测试也可以从这里整体了解版本内容。

 

6
思维导图模块下的内容,都是关于产品的一些图表,比如产品结构图、信息结构图、流程图等内容,我都是通过其他软件制作后,导入图片到Axure。

 

7
这里重点说一下线框原型。我为什么习惯用线框原型呢?因为高保真画腻了?因为画高保真太累?因为线框图漂亮?好吧,确实也有部分原因是线框图很漂亮,而且非 常耐看。但更主要的原因是,线框图不会有太多的视觉元素来干扰我对产品的架构设计,我可以清晰地看到产品的骨架和布局。UI在对着线框图设计的时候不会被 产品经理捉急的配色而影响,而且线框图省时省力,不用耗费太多时间。

在线框原型的基础上,我还在两侧做了功能的标注,任何涉及到此页面的功能点,我都可以写在两侧,并指向页面触发或展示的位置。这种最直观的方式,很方便开发查看功能需求。

 

沟通协调

当产品需求文档搞定以后,剩余的工作,大多都是沟通协调了。这一环节,是产品经理软能力的最大体现。沟通绝对能称得上一门大学问,善于沟通协调的产品经理, 可以大大提高团队的工作效率。我其实不是一个善于沟通的人,在第一款产品的开发过程中,我几乎天天和开发吵架,记住不是撕逼,而是拍桌子瞪眼,就差动手 了。这些经历在我现在回想起来,都觉得是难能可贵的经验。是的,我并没有后悔,反而很感激当时的冲动与坚持。产品经理从来都不是一个老好人的角色,把善良用在工作当中是极其不明智的选择。我认为的产品经理,就应该像张小龙、乔布斯一样,态度强势,能拍板,有决断。一个性格软弱的人,也许可以成为一名优秀的交互设计师,但绝对成不了一个优秀的产品经理。

不管是你让开发改需求,还是让设计改图片,或是拒绝领导的建议,这些都是得罪人的活。不可能每个人都和圣母一样,理解产品经理的良苦用心。当其他部门在质疑产品经理时,产品经理如果hold不住,那么以后不论做什么,大家都会对你产生不信任的感觉。

我看过很多讲解沟通协调的文章,但几乎没有任何一个方法,可以真正解决实际问题。沟通协调是需要常年累月,经验积累的。但这不是说,随着时间增长,你的能力也随之增长。而是你有目的针对性的去解决当前问题。我对沟通这方面,最大感悟就是:不要怂,遇到什么事千万也不要怂。不能别人捅你一下,你缩一步,再捅你 一下,你再缩一下。别人搞你,你就要强烈地fuck回去。我非常不赞同网上流行的跪舔其他部门,以恳求的方式来协调工作。

产品经理要有自己的腔调。

 

我大致给产品经理分了三种类型:

第一种——摇摆型

大多数新人产品经理都是这个类型,刚入行,什么都不懂,一会听这个的,一会听那个的,很难有自己主见。

程序猿:这个需求不好做。

产品汪:好吧,那先不做了。

运营:这个功能必须做,哪怕多费点时间。

产品汪:程序哥哥,运营说这个功能他们很需要,得做。

程序猿:你刚才不是说不做吗?你是不是产品经理啊,能不能有点主见啊,运营说做你就做?

产品汪:(羞愧的无地自容…)好吧,我再去找运营说说…

我觉得对一个新人来说,遇到上述情况,都是很正常的,关键是发现问题以后,怎么解决?一个产品经理必须要有自己的坚持,有时候哪怕明知是错的,也要硬着头皮往下走。

只因为:你是产品经理!

第二种——防御型

程序猿:产品,你这个需求不好搞啊,因为程序实现上:@#¥%……%

产品经理:不行啊,这个需求很重要:*&……%¥#%,必须得做,想想办法吧。

运营:产品,我们有个很重要的需求,做了以后能大大提高我们工作效率。

产品经理:(丫的,明明就是你们自己想偷懒,却要让用户多一步操作)这个需求我好好想想,需要的话,会放到版本规划里面。(有很多脑洞大开的需求,只要拖一段时间,提需求的人就忘了)

防御型产品经理其实已经登堂入室了,基本可以很顺畅地解决问题,什么该做什么不该做,都有自己的主张。但距离优秀的产品经理,还有一步之遥。

第三种——进攻型

进攻型产品经理:运营,你们这个需求有问题:&(&¥#¥……,还有这个:&&¥(%,还有这个:&%¥,不过这个需求很好,可以做。

运营:等等,这个需求我们很需要啊…

进攻型产品经理:这个问题:*&……%¥%,我们产品部经过讨论了,暂时不做,以后再说,现在不讨论。

运营:……

进攻型产品经理:这是什么东西,这么多BUG,怎么搞的,能不能干了?

程序猿:这个问题是这样的:&*%¥…

进攻型产品经理:你不用解释这个,我不懂开发,我只想知道,这个问题你什么时候可以解决?

程序猿:这个问题很复杂…

进攻型产品经理:我知道很复杂,但是咱们赚钱就是解决问题的,不是来发现问题吐槽的,&……%¥*(灌一些心灵鸡汤)反正你给个时间吧!

程序猿:….

在我看来,进攻型产品经理,才能正在的成为一个leader,是可以带领团队打仗的角色,是打造优质产品的前提条件。

最好的防守就是进攻。

 

结尾

在开发过程中,只要做好了沟通协调,基本上可以把上线时的问题减少到最小。然而产品上线之后,并不是结束,而是另一个开始。产品经理又要开始收集需求,整理需求,设计原型,开会扯皮,沟通协调,上线测试。

这是一个无限的循环,入产品经理这行,就意味着,这将是你以后的人生常态。但请记住一点,千万别失去对产品的热情,别丧失对细节的敏感。保持一颗求知好学的心,一步一个脚印,总会登上产品经理之巅。

<img src=”http://

未经允许不得转载:演道网 » 我当产品经理的那点事儿 -20151101早读课

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册