本文作者余晟，来自其微信公众号“余晟以为”，原文题目为《谈谈产品经理》
丁香园的产品总监二爷，俨然是当下的热门人物。他有一句名言“产品经理最重要的能力，是让正确的事情相继发生”，已经被反复引用过了。前段时间我和二爷聊过产品经理的话题，启发不少。所以今天，我也想凑热闹谈谈产品经理。
产品经理俨然是当下相当热门，又相当招人恨的职位。热门的原因，一方面是大家崇拜“神一样的产品经理”，另一方面是产品经理似乎基本没有门槛和背景知识的要求；招人恨，则主要是招开发的记恨，觉得很多产品经理纯粹是瞎搞，浪费自己的工作——有个做开发的朋友从某以产品经理文化出名的大公司离职时，我问他“你想找个什么样的工作？”，他说“别的无所谓，公司产品经理少就行”。
那么，产品经理到底要干什么呢？
首先可以确定的是，产品经理的工作绝对不只是“用Axure画原型”。
以Axure为代表的一系列工具，确实大大方便了软件开发的过程。以前的软件必须等到开发完成，用户才能看到真正的样子，不幸“用户一旦看到软件的样子，他们的想法就变了”。现在依靠这些工具，原型不但惟妙惟肖，连基本的交互都可以模拟出来。这样，大家可以先对着原型确认需求，之后严格对照原型来开发，原型看得见摸得着也不会变，确实节省了很多时间。
但是如果把原型和产品等同起来，那就大错特错了。因为产品背后有连贯的逻辑，原型背后没有连贯的逻辑。
比如某个产品，用户可以通过邮箱、手机、微信来注册，产品经理兢兢业业把每种注册方式的原型都做好了，也实现了。过了不久，业务需要能够准确触达用户，激发用户互动。这时候才发现用邮箱注册的用户根本无法有效触达，尽管各个功能都做了、界面都画了，业务逻辑却是跑不通的。
用户注册和有效触达两个功能之间距离遥远，真正使用的时候用户自己可能都记不起来，只能靠运行的系统逻辑来约束。不幸的是，单个的原型背后并没有一贯的逻辑。这就是考验产品经理的时候，不但要画原型让其他人理解，还必须在脑海里构造出这些原型背后的逻辑，这种逻辑还必须保证在多个产品、多个版本之间稳定不走样。如果没有这种逻辑，产品经理很容易退化为功能堆积员，这些功能还经常打架。很多人会说“产品意识”，指的就是产品经理能在目标用户、目标场景、产品定位等等“看不见”但重要的方面保持清晰和连贯的逻辑。
理解了这一点，也就容易理解为什么很多人说产品经理要有技术背景了。
我国现有的教育体制和课程安排，很难保证学生的逻辑思维能力。比如最常见的一些课程明明是满嘴胡话，学生却很难分辨，即便知道不对也说不出所以然来。不过，有技术背景的人在这方面独具优势，因为程序和系统都是严格按照逻辑来思考的，会强迫人的思维变得有逻辑。按照上面的论述，产品经理不能只画界面，还需要很强的逻辑思维能力。所以，有技术背景对产品经理来说是非常重要的。
另一方面，技术在现代越来越重要，产品的应用场景很可能是受到技术强烈影响的，如果产品经理不懂技术，能够想象的空间就非常有限，或者会与现实发生很大的偏差。比如热门的移动互联网，相当多的产品经理并不清楚移动互联网和PC互联网的差别究竟在哪里，仍然停留在“大屏小屏”等等直观层面，不知道移动设备装备了哪些传感器、不同网络的典型传输速度、网络传输和本地计算的电量消耗比例、不同设备的推送方式和触达比率…… 基于这样的认知，就算原型再漂亮，也很难做出好的产品。
技术背景对产品经理的价值还不止于此，有技术背景的产品经理和开发打起交道来更有优势，因此更容易保证交付结果的质量。按照新晋网红、硅谷程序媛朱赟（公众号：嘀嗒嘀嗒）的说法，相比硅谷的公司，国内的产品经理权力要大得多，工程师的话语权因此也要要小得多。这种分工或许是国内的通行惯例，伴随而来的就是工程师内心的怨念。产品经理画原型虽然辛苦，但工作量其实远远小于实际开发，所以没有技术背景的产品经理往往很难估量开发的工作量，以及开发中可能的难点。如果产品经理只是简单关心功能的数量，就很容易和工程师闹崩，最终结果就是开发的质量低下。这也是软件开发的神奇之处：三个月做出来的系统和三个礼拜做出来的系统，初看上去功能没有差别，内部的质量差别只有工程师才懂，等到这些问题爆发出来，往往为时已晚。
即便产品经理有技术背景，和开发有不错的沟通，我也建议产品经理不要直接管项目进度——这个观点也得到了二爷的赞同。如果让产品经理管项目进度，开发人员很容易认为“你又要发号施令又要催我快点做”，潜意识里就有抵触的心理。
一个可行的解决办法是设立专门的项目管理人员（PMO），他们以“第三方”的角色参与到项目中，调和产品与开发之间的矛盾，协调内外部资源，沟通各种信息，这样监督起项目进度来也显得合情合理，至少不会让开发觉得形单影只，纯粹是被欺负的对象。设立专职PMO的另一个好处是，PMO内部的沟通能有效跨项目协调公共资源，在资源不够时保证重点项目得到重点照顾。
最后讲讲产品经理和运营的关系。现在很多的系统开发虽然做的是互联网的业务，骨子里的模型还是传统软件开发的瀑布模型。产品经理负责定义产品，开发负责实现，交到运营手里已经是不容更改的成品了，运营要完成任务，手段和资源是相当有限的。
对互联网时代的产品开发来说，这套模型本身是有问题的。互联网的重大价值就是加速信息流动，一切都处在高速的变化和发展之中。因此，以精益创业为代表的一系列学说，都主张先做最小可行产品（MVP），根据用户的反馈不断调整、打磨、验证，最终找到可行的出路。这时候，产品经理就不再位于绝对的上游，运营也不再位于绝对的下游。整个产品的开发周期是由无数个迭代累积而成，产品和运营在某种程度上已经合为一体：在产品定义阶段就应当考虑到运营指标和运营手段，真正的运营数据必须反馈给产品作为调整的参考。
在这种情况下，优秀的产品经理要考虑的就不只是静态的产品，还必须考虑产品的整个生命周期；就不能只陶醉于对自己设计的欣赏，而必须有清醒的头脑来解读数据，宽广的心胸来直面现实的挑战，缜密的心思来找出问题的原因。最终，才可能诞生成功的产品。
当然，有人会说：那乔布斯呢？确实，乔布斯做了iPhone之后，许多人都梦想成为乔布斯，迷信自己能苦心孤诣闭关修炼，最终拿出横扫天下的产品——以及随之而来的，一言九鼎不容置疑的权力。乔布斯当然是这种方式的成功案例。但是，这种方式的成功几率有多大呢？有几个人有乔布斯的天赋，而且经历过那么多磨难呢？历数伟大的产品，又有多少是通过乔布斯那种方式成功的呢？如果这些问题搞不清楚，多半是认识问题的基本能力有问题，这样的人还是不要当产品经理了，至少能让开发少受点祸害。