产品人的优秀不优秀

团队合作中，把所有期待都放在其他人身上着实有些……

应该有蛮多朋友都知道我前不久入职了一家新的公司，不过由于不同公司有不同的土壤和不同的企业文化，这家公司确实缺少很多「产品文化」，最常见的问题就是明明在公司序列上有专门的「产品研发部」，也有专门分开的「产品经理」，「产品助理」以及「需求分析师」，但由于各种各样杂七杂八的原因，我发现其实很多人都不太能够描述出「自己心中优秀的产品经理是什么样子」。

几乎所有从事产品经理行业的同行都知道产品经理身上必须要有「学习力」，「沟通交流能力」，「需求分析能力」，「逻辑思维能力」，「领导力」等各种各样的必备能力（如果你以往看我博客的话会发现我一直在强调这一点）。但其实如同每一个观众心中都有自己认为最厉害的哈姆雷特一样，不同人对于逐项能力的理解也层次不齐，因此我也针对各项能力，也基于自己心中对于「优秀产品经理」的理解，写了一个比较简单的人物小传，和大家进行分享。

由于是在尝试描述这样一个「优秀产品经理」应该是什么样的人，具备哪些属性，所以在下面的文章中我就没有把这些能力归纳成不同的「能力细项」了，李姐万岁！

– 优秀的产品经理具备讲故事（Storytelling）的能力， 也因此能够分得清目标和手段，在描述需求时能够脱离具体的界面方案，从沟通对象（用户）的视角说清楚期望的路径和想要达到的效果；

– 优秀的产品经理不会是需求的搬运工，需求从哪来、往哪打，产品经理应该比任何人都清楚，他们不应该用方案倒推目标，也不应该强行给 KPI 包装「使命」；

– 优秀的产品经理不会是考核绩效的执行者，他们身上应该散发出来一种与数据指标无关的使命感；

– 优秀的产品经理能够正确地看待「数据指标」和「产品目标」的关系，不会一味的把数据指标当目标，在产品上线后也能客观合理的利用数据指标验证目标是否达成；

– 优秀的产品经理会对自己的方案有信心，而不会盲目去做跟其他主流产品的方案「找不同」，然后推测些没缘由的理由用来「指点」自己的方案；

– 优秀的产品经理在和设计师沟通的时候，既能通过草稿描述出自己的设计审美，也能给设计师们留足发挥的空间，；

– 优秀的产品经理在和工程师对接的时候，方案的完成度高，能够预先考虑到一些技术实现的方法，而在工程师讨论障碍时也不扯皮、不甩锅给设计师。如果产品经理能够帮助或启发工程师实现共赢最好，实在不行方案也会该改就改，而不瞎给别人添麻烦；

– 优秀的产品经理能够从发散的产品方案中归纳出逻辑，帮助研发同学搭建出扩展性良好的产品架构；

– 优秀的产品经理不会当好好先生，在任何环节，有感觉不对的地方也不会假装看不到，而是能构建良好的讨论氛围再抛出问题，一起讨论直至解决。即使是遇到老板或者很少见的 BOSS，也会不卑不亢的保持有自己的坚持；

– 优秀的产品经理在跨部门沟通的时候能主动扛大梁，沟通中很明确自己要什么，不卑不亢，能让业务组的设计师、工程师感到安心；

– 优秀的产品经理在讨论氛围比较激烈的时候，会知道如何给其他人找台阶，也会在别人给出台阶时主动下来，而不是非要在言语上战胜其他人，或者在同事面前展现自己「很普通又很奇怪的优越感」；

– 优秀的产品经理能够以理服人，就事论事，而不总是搬出各种 leader 或者奇怪的规章制度企业压制其他人；

– 优秀的产品经理愿意且喜欢和大家分享各种好消息，会把老板的夸赞分享给大家，让团队中的每一个人都能找到自己的成就感；

匆匆写了几条，但心中感觉没有还有很多可以描述的东西。如果换一个角色，我们有一天不再是产品经理，而变成了其他和产品经理合作的售前，客服，销售，设计，研发等各个工种，我们又会如何回答「和产品经理合作是什么样的体验」这个问题呢？

坦白来说，一个糟糕的工作流程中其实就像一座围城，产品、设计、开发等各种角色都被困在里面，在这种时候我们就不应该光指望别人去解决问题，如果能够熟练掌握和不同段位的同事合作，其实也应该是一种职场人的职业技能吧。

我们熟悉的工作流无非就是「产品经理们规划出迭代方向，并以此设计出自己的需求，随后设计师再将这些需求转化成高保真的设计稿，最后交由研发进行开发和上线」，但倘若说实话，很多人虽然瞧不起那些流水化生产线上的工人，但自己又何尝因为不愿意去思考，而心甘情愿变成了需求的搬运工呢？

产品经理们拿着来自老板或客户的一句话需求，千思万想整理出一份自以为带有原型和逻辑流向就能满分的需求文档；设计师拿到需求文档后立马打开站酷或者 dribbble 这样的网站寻找灵感，并且打开 sketch 或者 photoshop 开始画美美的界面，把不同的控件摆放在一起就交差了事，再然后通过内部评审后，就能切图并且传到蓝湖上；研发拿到需求稿和设计图之后，要么发现逻辑不闭环的地方就一股脑回退给产品，要么就是在一旦遇到业务问题的时候就拉来产品开始开会，讨论怎么才能搞出来闭环，而那些大家都没有想清楚的东西，就留着等到用户变多有人提 issue，或者等到后面设计别的版本需求时，再随机塞入到不同的迭代计划里面去……

有的团队发现反正都有 antd 和 element 这种组件库，就真的把 UI 设计师定义为界面设计师了，但我觉得 UI/UX 的设计，重点是在于通过界面方案解决问题，重点在解决问题，而不在于界面本身。

在很久以前我写过一篇文章，讨论「设计师的创新和创造」，并且在文章中聊了聊我理解的设计师应该是什么样子的。但如果拿和产品经理合作这回事来说，我有时候就会觉得设计师的职责也不应该是把产品经理给出的「需求」做的更美更酷炫，而是应该去思考同样达到产品经理想实现的目标，是否有别的更好的方法，而在不同的方案权衡中，才能实现双方对于需求的真正了解和沟通。

但实际上，这些「流水线」之类的工作无非就是让我们更早的跳入深渊。为什么这条流水线中的每一个人不能发挥出足够的主观能动性，在意识到有不妥的时候，就去和产品沟通，帮助产品经理们去完善那些「原本不真切也不真实」的需求呢？

如果每一个人都觉得把期待放在别人的身上就能解决自己遇到的问题，那我想持有这种心态，最终的受害人真的只有自己，倘若我们愿意尝试靠自己的努力去补足他人的短板，那其实反而还能够让我们自己补齐短板。