2年PM的忠告：这些坑，你们千万别踩！.docx

2年PM的忠告：这些坑，你们千万别踩！ PAGE 1 2年PM的忠告：这些坑，你们千万别踩！ 笔者在某云计算厂商做过两年半的对内产品的PM，期间也遇到了不少大大小小的坑。私以为做产品经理，一定要懂得总结，平时会有一些凌乱的想法，就借此机会整理出来，将在这段经历中遇到的坑总结分享给大家，希望也能够帮助到其他跟笔者一样境遇的产品经理。背景产品H为一款监控产品，从0到1在某云计算厂商内部中孵化。从笔者开始做这款产品到笔者离职，经历了两年半的时间。期间的工作除了对产品的调研、原型设计以及跟进开发测试外，还有很重要的一部分职责是内部推广。但是，在这款监控产品对内发布之前，各个业务部门并不是不用监控的，大多数业务部门搭建了自己的Zabbix等开源监控系统，更有一些体量大、业务相对复杂点的部门自己根据自身的业务开发了监控系统。所以，产品H从一开始所面临的压力就很大，因为对业务部门而言替换产品的成本很高。接下来，笔者想根据产品H演进的过程来讲一下遇到的坑，以及当时是怎么做的以及对于更好做法的思考。一、内部产品从0到1，该如何冷启动？做产品H的团队，架构师、研发、产品经理、测试等等都是初来这个公司的新人，公司招这么一批新人的目的也是因为我们这么大公司，不能老用别人家的监控产品吧。但现有的工具团队中，没有人懂该如何做好监控产品，所以从别的大厂挖了一些有相关经验的研发过来（笔者例外，之前没有运维或监控的经验，完全是新人一个）。面对前提背景中，各业务部门已经有在使用中的监控系统，产品H想要取代那些产品，实施的思路是这样的：先有简单的采集（服务器基础指标、端口监控指标、进程监控指标）和报警功能（如果读者对运维监控系统不太了解的话，那差不多可以比喻成业务方都在用5G手机了，然而我们开发出老年机希望他们来用），然后再给兄弟部门推广，并让兄弟部门给点使用建议给其他业务部门推广。首先，这个思路的第一步就出现了问题。如果想要通过产品本身的优势吸引到用户来使用，那第一步里做的事情明显远远不够，业务方们已经在用功能更加成熟的监控系统了，根本不屑于用这样的产品。如果是依靠政治手段进行推广，那一开始满足最基本的功能就想推广成功，很大程度上取决于产品经理的跨部门沟通能力。产品H面临的就是第二种情况。作为负责去推广这个V1.0产品H的产品经理，当年的我确实too young too simple，以为大领导都发话了，那大家一定会配合我的吧，很快就被现实打脸了——兄弟部门总是以还有别的事要忙为理由婉拒接入产品H（私底下更是直接骂这是什么傻X系统，根本没法用）。也因为这个挫败，领导给我的绩效评了一个0.95（基准线是1）。所以，我当时面临的情况大概就是自己的团队没有能力和时间提供更好的技术和产品，而兄弟部门也拒绝接入这shi一样的监控系统，上级领导也没有通过权力来帮助我的意思。最后，本来抱怨的我调整了自己的思路，既然兄弟部门已经烦我了，那我为什么不把他们烦到底呢？所以接下来的时间，我跟他们的沟通特别频繁，没事就往他们工位跑，一个上午可能就跑两三次，督促他们该做什么要做什么，并表达了这是我的任务希望大家帮帮忙配合一下（多亏我是女生）。有一次他们要去团建，我缠着两个运维非要他们解决十几台机器的监控部署问题后再走，他们的领导也是很无奈~所以，总结一下：如果你的内部产品V1.0版本不具备替换别的产品的硬实力，那作为产品经理的你就要发挥出你的软实力了。如果是妹子，就发挥好妹子的优势。女性的形象更加柔和，所以一般对方也很难直接拒绝。不要以为领导发话了，底下的人就会全力配合。在对方不怎么配合的情况下，频繁地去工位找他们沟通会有助于你的推进进度。体谅他人。表示你能体会到他们真的很忙，但是手头这件事也是非常重要的，不然领导也不会发话说要接入这款产品。适当施压。如果对方还是不断拿别的工作来搪塞，那就可以和他一起找他的领导，希望他的领导能够帮助协调这两件事情的优先级，并且给一个完成的时间点（能有个时间点，也好回去给自己的领导交差哇）。涉及到决策的事情需要用邮件等方式来记录，避免扯皮。二、没有UI/UE，靠产品经理和前端的审美怎么让产品优雅起来？对于内部产品，资源往往是给不足的，所以没有UI/UE也是必然的。相信大多数的产品经理虽然有不错的审美，但完全交给自己来设计视觉，会觉得该不知如何下手，好不容易找到个可以抄的UI设计，前端做出来的效果往往相差很多。一开始，我们团队认为这是内部使用的工具型产品，没有必要追求好看的外表，而更应该注重产品本身的作用，但很快就被现实打脸。业务方即用户，根本不会站在我们的角度去想，做的不好看不好用，就是产品有问题，管你是对内产品还是对外产品，我是用户我就是老大。后来，我们就