我当产品经理的那点事儿

从去年9月开始入行做移动端产品以来，经历了三款产品。这一年中，我也由一名初出茅庐的菜鸟，蜕变为一名正式的产品经理。本来做总结应该是经常的事情，但因为自己懒惰，一直拖了整整一年才开始写一篇像样的总结。

其实，在这一年当中，经常会有许多收获和感悟，总觉得如果下笔的话，绝对是长篇大论、滔滔不绝。但是没想到，刚提笔就发现根本无从下手。是写产品设计的心得呢？还是写用户体验的感悟？还是项目管理的经验？总觉得知识很多，却零零散散，缺乏一条主线将之串起来。索性，因为我经历过一个产品的诞生，就从产品之始讲起。

产品之始

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

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

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

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

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

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

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

产品设计

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

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

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

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

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

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

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

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

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

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

产品需求文档

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

其实，现在很多产品经理已经发现了这个问题，解决方式就是用原型加标注的形式来产出需求文档。这样会更加直观方便，大大地提升了工作效率。下面展示一下我自己设计的产品需求文档。我的产品需求文档里涵盖了很多东西，如果细说的话，恐怕需要另一篇文章来详细讲述。在这里我只简单说几点重要的地方。

修订历史，是一个文档必不可少的内容，不管前期你把问题考虑的多么周全，总会有没想到的地方。而有修订历史记录能保证每次修改后，所有内容都有记录，供所有人观看。

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

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

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

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

沟通协调

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

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

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

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

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

第一种——摇摆型

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

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

产品汪：好吧，那先不做了。

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

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

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

产品汪：（羞愧的无地自容…）好吧，我再去找运营说说…

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

只因为：你是产品经理！

第二种——防御型

程序猿：产品，你这个需求不好搞啊，因为程序实现上：@#￥%……%

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

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

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

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

第三种——进攻型

进攻型产品经理：运营，你们这个需求有问题：&（&￥#￥……，还有这个：&&￥（%，还有这个：&%￥，不过这个需求很好，可以做。

运营：等等，这个需求我们很需要啊…

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

运营：……

进攻型产品经理：这是什么东西，这么多BUG，怎么搞的，能不能干了？

程序猿：这个问题是这样的：&*%￥…

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

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

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

程序猿：….

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

最好的防守就是进攻。

结尾

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

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

作者：臻龙