没有太多系统思考，工作之余零散记录一些闪过的思绪，记录与此，说是提点别人，其实更是为了鞭策自己。

1. 产品经理的想与做

怎么看一个产品经理的能力?

在我个人感受而言，会从两个维度去看，想和做。

越高的Level越会看其思考能力，思考的层次也要从战术、到战略，从推广到营销，从产品到品牌，从单个产品线，到业务，到了我厂P8及以上的产品经理，实际上，个人动手去写PRD，个人去跟进项目落地的机会就很少了，更多真的是运筹帷幄，决胜千里的能力。产品形态也趋向于从有形到无形，营销战略、品牌调性、甚至公司间的合作……都是产品经理可能要考虑的范畴，而调动的资源也不只是围绕产品的开发、测试、设计了，还有市场、BD、PR、运营……诸多角色……真的是很大一盘棋。

而更入门的产品经理，则更被看重的是快速的执行落地。因为分解到你头上的，可能已经是某个功能模块，某个小产品，你已经没有太多空间去思考产品的意义，而是要把既定的目标给完成。做功能点的梳理，做具体的产品设计，排出周密的计划，协调各方资源按计划如期完成。

而成长中的产品经理(包括我在内)，想和做都是要同时并重发展提升。

想什么呢?

需求的发现、需求的评估和分析

解决方案设计和评估

如何把以上的过程和结果呈现出来，让大家都明白

第三点非常重要。可能你也很辛苦地做了前两步，最后得到了你认为最合适的解决方案，然后产品设计方案也出来了，PRD文档也写完了，可是就是受不住大家的各种层面的“逼问”，产品经理要拿出最终的结果，但是过程中的思路也要一脉相承并能够应对各种疑问。

然后这过程，一定要做到阶段性的产出，不能耽于思考。这其中就是：

如何把大图拆分成模块

如何取舍眼前与长远的重点价值(比如下个季度你只做一件事的做什么?只做三件事做什么以及为什么)

如何把计划排到季度，拆到周

如何识别关键角色并沟通到位

如何快速开工并拿到结果

阿里巴巴有句老话，送给大家“我们为过程鼓掌，但是我们为结果买单”。

这个想、做的过程，三大意识非常重要，而意识的培养是贯穿了一个产品经理的日常工作的。

目标意识：即使发封邮件，也存在邮件的目标，是否能够有效达到?

成本意识：要思考产品能够帮助减少用户的操作成本，也要想办法做四两拨千斤的产品设计，减少开发成本，日常工作中，是否能够减少大家的沟通和理解成本?

客户意识：不要说”我要”，任何功能都是为特定的角色设计的，他要想吗?他会用吗?

2. 如果需求和解决方案你都分不清，就别做产品经理了

老生长谈的一句话，可是为何我们现实生活中总还是会犯这个基础的错误?

某天路过自己团队产品经理和需求方沟通的一个小桌子，侧耳倾听了几句，发现双方陷入争执，于是忍不住参与进去，发现原来双方正在纠结于是把一个任务管理功能中的优先级作为筛选条件还是排序条件……于是忍不住问产品经理了，需求方的需求是什么?是筛选?还是排序?还是什么?需求方的需求是让他能够从非常多的任务中把自己最需要关注的任务给找出来，或者再深一层，需求方的需求是能够让他一目了然知道现在最需要做的是什么。

而给出优先级字段也好，还是把优先级字段作为筛选条件、排序条件也好，都是解决方案层的东西。

不要过来给我投诉说：需求方的需求不合理，不靠谱，出现这种情况，大部分是因为我们还是停留在解决方案层面。

很多时候，需求方会直接提一个解决方案，认为就是他的需求。这种情况下，产品经理也无需苛责需求方。比如，你去蛋糕房里买蛋糕，也是倾向于说：喂，给我拿那个草莓蛋糕(这是解决方案)。而不会说：你好，我女儿要过5岁生日，我女儿很喜欢吃草莓，我让让她的生日很开心，你觉得有什么可以帮我的吗?这就有点太傻帽了。虽然一个去买蛋糕的顾客内在的需求可能是“让女儿的生日很甜蜜很开心”，或者是“让我的喜欢浪漫气息的老婆结婚5周年快乐”，但是能够简单表达出来的或许就是他认为最合理的解决方案。

需求沟通也是一样的。

一个需求方来说：我要想数据直接导出，不要每次下载都走审批。他不会表达成：我每周都要写周报，而我的周报需要好几张报表的数据整合，所以我需要导出数据在电脑上用Excel加工，但是因为每次下载都需要审批，不但麻烦我，也麻烦我的审批人，有什么办法能够降低我做周报的成本吗?

如果需求方描述成“有什么办法能够降低我的做周报的成本吗?而且据我所知，和我一样需要导出多张报表数据做本地加工做周报的小伙伴都是这样的痛苦，希望你们能够想想办法”，你可能会发现解决方案未必只有“导出”一种，比如长远来讲，你可以提供在线编辑器，小伙伴把需要做周报的数据都存在一个自己的数据环境里，在其中做加工，编辑，然后分享周报地址出去即可，或者去了解需求方周报汇报的对象看数据的需求，把其需求也做成在线可直接查询的报表……或者……

需求方可以随意表达需求，即使说的是解决方案，也不是他不专业，而是解决方案就在他的口头边。而作为产品经理，最关键的就是：

多问几个为什么，把解决方案背后的真正的“需求”给挖掘出来

场景验证，看看这个需求方的需求是否具备一定的通用性，个性化的需求和通用的需求有不同的解决方案

畅想解决方案，从中选择最合适的

解决方案与需求方进行沟通、与开发进行沟通，敲定

记住：没有什么需求是不合理的，只是解决方案够不够合适。

3. 做理想方案，做二手准备

有时我们面向开发提需求的时候，一开始会想，恩，很难做或者他们肯定不愿意做，所以直接在体验上打个折扣。给出一个妥协后的方案。

但是开发有时眼界比我们高啊，人家在你们看电视逛街听音乐的时候，还在不断在互联网上浏览新兴的科技，新兴的网站，对各种交互模式比PD都要清楚，他们有时觉得你的方案不靠谱啊。所以就会觉得体验不好啊，为何不做更好的?

作为产品经理，一定要让自己眼界更高一些，而不是亦步亦趋，给他们提出一些想法是你的事，他们能不能实现是他们的压力。但是你又做好了妥协的准备，岂不是更好?

我觉得大家都有必要多去体验下别的产品，别一门心思盯着自己的产品看。毕竟都是那么年轻的人，要持续追求进步和学习啊。

如果你觉得交互设计是交互设计师的事情，用户体验是用户体验部门的事情，那么请问，你是否找到了自己独特的作为产品经理的价值?如果连产品系统逻辑、功能描述也不专业的话，那么交互设计师是否也可以做现在我们做的事情呢?

我希望大家多多体验下好的交互设计模式，以后设计产品才会游刃有余，平时也会用花瓣网采集好的设计模式，也分享给各位：http://huaban.com/boards/3979518/

4. 万物皆产品

既然很多人都看过苏杰的《人人都是产品经理》，那么是否也有意识觉得一切都是产品呢?

我们刚发布了一个产品，短期呢还存在一些体验不好的地方，但是我们内部对它做了一个调性的定义：要做有爱的数据平台。为什么要做“有爱”，而不是“专业”，“严谨”，”洞察”，自然是和用户群的特征以及需求脱不开干系的，这里就不具体说了。

但是围绕“有爱”，我们如何做呢?

平台要摆脱传统的数据平台那么老古板的面孔，以及密密麻麻的指标数据，以及高深但是看不懂的图表，即使这些是必须的，我们也必须加入其他的有爱的元素。

有爱，方能让用户包容一些小小的瑕疵，方能让我们大家都参与进来共同建设，然后因为共同建设而更加凝聚爱意。除了要求产品上的一些注意事项外，我还要求，是否能够把需求梳理评估的过程，变成每周定期的会议，可以邀请需求方、开发一起对需求池中新增的需求进行讨论、决策和排期。产品经理认为没问题。

我就说那么对这个会议进行一个包装吧。产品经理不是很理解为何连一个会议也需要包装，是否太重于形式了?

因为在我看来，短期能够让人感觉到有爱的，产品的改变节奏却太慢了，而主动联结用户节奏上更快。而一个会议，也是一个产品。如果不把它当成一个产品来说，它就只是一个会议，它可能连个名字都没有，或者只是会叫做某某产品需求评审会。而且它可能也没有相应的机制设计(比如：频率、参与形式、激励形式、目标)。

同样是开会，如果当成产品做又会怎么样呢?

我们会想它的目标，它面向谁?它要解决什么问题?它能够产生的价值是什么?它运作的场景以及期望的产出，进而会想它如何能够提升大家参与性?如何加强它的用户认知?进而就会想它是否需要一个名字，需要一个口号?然后会想到如何把它卖出去!让它产生我们赋予它的价值。

5. 没有借口?

做产品经理是很苦逼的。因为这个职业的定位天然决定了“没有借口”。

一个优秀的产品经理，就是能够敏感地发现问题。

而且就是要比别人更早发现，而且不能以该问题为借口。

因为另一个职责就是不断地为各种问题开发解决方案。

那么就等于说一个产品经理的问题只能有三种形态：

未发现的(既然没发现，自然就没问题咯)

有解决方案的(既然已有解决方案，那么就快点执行咯)

还没解决方案的(既然还没解决方案，问题明确了，就成功了一大半，那么就快点去想解决方案啊)

反正，就是认为产品经理就是问题分析及解决专家，所以，产品经理是最没有立场去“抱怨”的。

怎么样，觉得压力大吗?