从工程师到产品经理——转变（2）

image
本系列第一篇文章从工程师到产品经理——转变（1）,以程序员眼中的产品经理为切入点，讲述了一名工程师成为产品经理必需经历的转变——态度转变。接下来我想和大家分享我在工作中的另一个转变——思考问题方式的转变（思维模式）。

点与面

把一个项目的某个版本看作面，那么每个具体的功能模块就是点。工程师负责确定这个点需要多深入；产品经理则负责确定这个面有多大。这看似简单的道理，作为一名有研发背景的产品经理并不容易理解。

初做研发工程师时和一位资深且优秀的产品经理深度合作开发一款Android应用，那个时候刚走出校门不久，能亲历一个项目的整个开发周期是一件极其幸运的事情。因为基本功扎实且对写代码充满了热情，这个基本由我独立开发的项目在初期进行的非常顺利，在不断解决各种问题的过程中我的技术水平得到了很大提升，同时工程师的成就感每天也都能得到满足。

随着对技术理解的不断深入，处理某些需求的时候我不再是简单的实现功能而是会提出一些我的理解，比如“当前的交互方式在某种情况下会出现问题”、“这个需求非常影响性能，我们能不能换个其他方式”或者“我觉的这个地方需要加个动画来完成过度”、“Android4.4有了个新特性，我们来支持一下吧”。当时作为一个对技术充满激情的工程师，把代码质量以及程序性能看的极其重要，每天花大量时间学习新技术，恨不得把所有新学会的东西都应用到项目中。曾经我是一名研发工程师，非常感谢这位前辈的满足了我作为一个工程师的那种对技术的追求；现在我是一名移动端产品经理，回想当时他每天针对我提出的种种问题给出的回答，以及站在整个项目的角度来思考问题的方式，都对之后工作产生了深远的帮助，在此向您给予我的帮助和启发表达我最诚挚的感谢。

因为习惯了从某个具体的点去深入思考，有研发背景的产品经理往往更容易把自己局限在一个狭窄的范围内思考、行动。最直观的表现就是当项目进度受阻时，不是立即分析受阻的原因是需求阐述不明导致、流程设计本身有问题导致还是技术问题导致，不是立即查看受阻的是哪个具体模块，不是去查看当前整体进度以及评估受阻部分的优先级，而是亲自参与工程师的讨论，甚至亲自参与开发，这是作为一个产品经理很严重的错误。

作为一个产品经理既要渗透到项目的每个部分又不能凡事亲力亲为，与处理具体的点相比宏观的面更重要，保证团队整体前进是最重要的事情。

现象与本质

乔布斯曾表示“消费者并不知道自己需要什么，直到我们拿出自己的产品，他们就发现，这是我要的东西”。对于这句话有很多种解读，就我个人而言，我把它理解为——需求（本质）和解决需求的方法（现象）的关系。比如有用户说“我想要个机器人，当我晚上躺下的时候帮我关闭桌上的台灯”（现象），面对这个用户需求，有的产品经理会设计一个可编程且带有自动寻路功能的机器人来完成每天晚上关灯这个操作（自身有研发背景且依仗着公司拥有雄厚的研发实力，往往容易出现这种情况）；有的产品经理会设计一个安装在台灯上的机器人用来控制台灯的开关（没有站在用户角度深入思考问题，仅仅想要解决表面问题）；有的产品经理会告诉用户你需要的是一个Wifi插座，当你想要关灯的时候控制插座切断台灯电源即可，根本不需要一个机器人；站在用户的角度上，用户需要的实际是一个在不离开床的情况下可以完成关闭/打开台灯操作的工具(现象)，由于认知的关系，用户潜意识中认为应该是某种机器人来负责完成这个操作。问题的核心是——用户想要在某种情况下控制台灯的开、闭（本质），这就是所谓的“如果你问你的顾客需要什么，他们会说需要一辆更快的马车”。作为一个产品经理要从用户的角度出发去挖掘用户真正的需求，而不是迎合用户的思维去解决表层问题。在开发阶段，频繁的需求更改根源就在于对用户需求的理解不足，沉迷于“解决需求的方法”而不是定位用户核心诉求。

关于成就感

工程师很容易获得成就感——“解决了当前项目中的性能瓶颈”、“修复其他工程师无法解决的bug”、“开源一套质量较高的基础类库”，“实现了某个dribbble上的酷炫动画”等。以上这些都可以让工程师的成就感获得极大的满足，这种满足同时推动着工程师向更遥远的目标进发。初为产品经理时，我认为成就感的满足来自团队以及项目的反馈——“新上线的版本更受欢迎”、“工程师顺利完成了核心模块”、“被同事称为完美逻辑生物”，“做一件事而让团队士气高涨”等；当我对“产品经理”这个职位有了更深入的理解后，我发现一名产品经理的成就感来自——“让正确的事情相继发生”。

“让正确的事情相继发生”，诠释了一个产品经理的全部职责，确保每个决定都是方向正确的，确保整体逻辑正确，对“轻重缓急”有清醒的认识。如果起点和方向错了，就只能在错误的路上越走越远，正如产品经理圈子流传的一句话——“成功是团队的成功，失败是产品经理的失败”，这份责任感和使命感推动着产品经理向更遥远的目标进发。

关于鄙视

“文人相轻，自古而然”，似乎产品经理和产品经理之间也存在这个现象，大部分产品经理互相评判对方的产品时总是倾向于从交互体验、UI细节入手（现象）——“你们的app有点卡”、“你看这里的icon不是一边大”、“你看那个app可以这样点赞”、“你看那个app可以不点击确认按钮完成验证”。作为一个产品经理会经常遇到这样的场景，你要对这些问题进行记录，然后与现有问题列表进行比对评估新发现问题的优先级，确保头脑的清醒，不要被细枝末节的问题所干扰；没有任何一款app的成功是因为其创造了某种交互或者把UI做到了极致，一款产品的成功一定是因为其确实解决了某个用户群体的某些实际问题（本质）。在学会接受善意的“鄙视”的同时，也要防止自己进入同样的思维，尤其是在分析竞品时，不要停留在因为发现了对方的bug而沾沾自喜，也不要因为发现了自己某个细节优于对方而轻视对手，要时刻提醒自己抛开细节找到真正的差异。

最后如果产品经理间注定会相轻的话——你不能把这个世界，让给你所鄙视的人，请让正确的事情相继发生。