程序员是最好的产品经理 - 初码

今天来说个有意思的话题

程序员和产品经理的斗争，从根本上就是个伪需求

我抛出两个观点：

1、在当前国内互联网大势下，9成以上非程序员出身的产品经理都是垃圾

2、无论在什么地方，什么时候，程序员都是最好的初级、中级产品经理人选

不是找喷，而是事实

下面论证一下以上观点

一、产品经理有没有搞清个人能力成功和平台资本加持成功之间的区别？

我说一个产品经理的画像，大家应该相当熟悉了：

我会写文档，知道怎么切图、我会用Axure，我会思维导图，我知道墨刀这种新互联网产品设计工具，我平时特别喜欢琢磨别人的应用，我对新鲜事物特别感兴趣，我热爱数码产品，我是果粉，我。。。

是的，你已经意识到自己是一个主流的产品经理了，但是你还没有意识到的是：

你可能还是一个“垃圾”

这里的垃圾不是贬义词，而是一种客观的陈述，如果一个人在团队和项目中，把他替换成其他人，依然可以无缝切换运转的时候

那么他，根据上海最新的垃圾分类规则，应该是一个“可回收垃圾”，到别的团队依然可以继续做产品经理

但为什么很多产品经理有时候依然优越感十足，一副见过流行世面，一副我有独特审美，一副我经手的产品特别成功的模样呢？

因为他并没有搞清楚平台价值和个人能力区别

我国的互联网和软件行业是有趣的，在趋势和和资本推动下产业不断革新，在这浪潮之下，优质的产品不断涌现，也造就了一个热门的岗位：产品经理，和一个普遍的幻觉：“这些产品经理创造出了无数的优质产品”。

但事实上：

1、用户是可以量化购买的，主流资本和平台所研发出的产品，时至今日为止，下意识的运营想法和成功套路依然是买用户和导流量。
2、资本是有能力去承受产品设计的反复试错甚至失败的，而这类失败，其实占比相当之大，只是在BAT成功产品的光环下，大家都忽视了这些海量的失败的产品过程。
3、除了用户和流量之外，产品力驱动的产品成功有没有？有！但产品力的成功，绝大多数并不依靠所谓的精致界面和用户体验，而是依靠了业务逻辑的创新，无论Web也好、App也好、微信也好，最终产品形态只是伟大业务逻辑创新的落地载体罢了。

有的产品经理会很郁闷：“我会切图，我会画原型图，这不就是我的职业素养吗，拿着一份工资，做着一件事情，这也要被你喷？”

是的，当你看明白刚才所说三点时，你会发现，相当多的产品经理没有任何真实价值，垃圾程序员好歹还能贡献可80%稳定运行的代码，但垃圾产品经理除了随意被替代外，甚至还会做出无数的负设计来拖累项目。

所以，什么才是产品的本质？真正的产品经理是怎样的呢？

这里把产品经理分成两种：“决定性的产品经理”和“执行性的产品经理”

前者代表着真正的产品力，而后者承载着落地顺畅度。

举个简单的例子，淘宝网有个产品经理提出来，我们需要做个直通车的业务场景，凭空造出一个商家竞争和让流量变现的业务，我们还要做个卖家服务市场，让商家的信息通过开放平台给第三方开发者做授权的二次开发，从而形成数据赋能，顺带收取应用分润费用。看到没，这叫平地起浪，属于决定性的产品设计，一下子奠定了阿里电商生态的运营套路、盈利模式和长远发展的利润基石。

很明显的，这种人已经超越了产品本身，走到了业务架构师的层面，这里不在我们讨论的范围内，我们要说的，是普遍的产品经理，也就是执行性的产品经理。

既然你是执行的角色，那么，根本不需要你所谓的产品优越感，也不需要你所谓的好看气质，需要的是：↓

二、通畅不出错，高效少花钱，内外兼修，这才是最好的产品经理

产品设计绝非大部分自以为是的产品经理所以为的“精致UI、用户体验、头脑风暴、创新创造等”这套人文逻辑。

事实上，产品设计，是一门严谨的科学

优质的产品设计：

对外：产品界面元素清晰、流程逻辑清楚，每个功能模块均有完整准确的闭环。

对内：业务所对应的数据模型有全面设计、有解耦考虑、有扩展能力，产品业务逻辑所对应的程序逻辑顺畅平和、不交错复杂。

所以，基于这样的判定标准：↓

三、非程序员出身的产品经理，不具备由内而外的设计能力，也不具备对垃圾程序员的掌控力

想要探寻产品设计最关键最难的地方是什么，最简单办法就是看失败的地方是什么？

说一些典型的失败场景：

• 产品仓促deadline之后，每天都在修补BUG，用了1个月开发上线，竟然不知不觉又花了3个月来修复BUG增加系统稳定性。
• 产品需要升级适应新的市场需求，比如原先的桌面产品需要支持微信登录，还要支持所扫码的微信号可以随时更换，这样帮助推广公司旗下多个公众号，产品经理只知道看别人这样实现了，自己也不知道背后是怎么做的，经过和开发团队沟通，开发团队调研了很久才弄明白怎么处理，这时候发现原来的整套账户体系问题很大，设计的逻辑也不对，需要耗费很大人力代价和时间来重构和重新开发。
• 按照产品设计说明书发布上线了，但是每天都会发现功能缺失，今天这个细节没有，明天运营组那边想要的管理功能不支持，后天用户投诉了找不到XX入口，最后发现这个当时的设计说明书得全部重写，再次设计。

其实已经再明显不过了，不懂技术和开发的产品人员，在产品设计上仅能浮于表面，无法进行深度设计和闭环设计，在团队协作上也无法基于原理和逻辑做出深度决策。

最可怕的是：这样的产品经理，对大量存在的、技术不扎实的、喜欢敷衍了事的程序员，不具备识别能力、预警能力和准确的管理定性定量能力，从而让产品经历看似成功的上线到最后的无限内耗慢性死亡，不夸张的说，这是目前9成以上产品设计的现状。

无数案例已经证明，在产品设计领域，准确的逻辑理性修养要远胜于艺术直觉修养。而且：

逻辑修养的养成过程，是完全可复制的

四、程序员的产品经理修养的养成，是具备天然优势的

• 程序员学习过数据结构和数据库原理，知道业务如何转换到最优的数据模型
• 程序员经历过各种项目知道产品端和开发端的交互逻辑和步骤
• 程序员接触各个业务部门，长期耳濡目染业务，还要根据业务设计技术，是事实上的业务精通者
• 程序员和项目经理的接触是平滑的，对项目质量的理念有更加数据化逻辑化的思考和理解

做好任何事都没有捷径，优秀产品经理的成长也需要大量的逻辑训练和项目训练，而程序员的成长过程正是最佳训练路径！

经过对程序员如此的分析和认识，那么当程序员来担任产品经理的时候，再遇到类似上面提到的账户登录问题，他会

• 1、仔细认真的阅读微信开发平台和微信开放平台的文档，并自己做了几个Demo测试了一下。
• 2、了解到可以通过在开放平台添加网站应用实现扫码登录，也可以利用公众号里面的服务号的带参数二维码的临时参数二维码实现扫码登录，自我评估公司的需求更适合使用服务号参数扫码体系。并自我思考了一下如何构建一个多服务号的管理机制和技术交互机制。
• 3、也去了解了一下公司原来的账户体系的数据表结构，根据开放平台能获取到的字段和获取逻辑，思考了一下用户表体系的改造思路。
• 4、根据他综合调研的结果，给出了一套最优方案，并对比市场上其他的方案，召集老板和项目组成员开了碰头会，并直接给出自己的方案和理由逻辑。
• 5、经过给其他程序员的业务逻辑和代码逻辑的讲解，制定了准确的改造开发计划，最后顺利的如期完成了改造。

再举个例子，比如公司要上马一个新项目，预算有限，但是老板又希望移动端、微信端都有，还希望有个独立的App，不懂技术的产品经理只知道在这个时候调研同业在不同端怎么做设计怎么做样子的，他只会思考别人是不是把几个端的样子和流程做统一了，再深入一点也只能思考到别人家在不同端的账户体系是怎么构建的，仅此而已，剩下的他只能问开发人员讨论并且不停的追踪开发进度。但是作为一个程序员产品经理，就可以站在不同的维度，站在更加技术和逻辑的角度去思考这个问题，这个机智的程序员会快速调研到某套开发框架，支持MVVM模式的VUE全平台互通编译，一次开发，多平台部署，甚至App端也能够做到以H5 Hybird App方式完成无需XCode开发环境的IOS部署，如此种种，这个程序员的方案，必然比一个正常的产品经理带领出来的方案，要节省5-10倍以上的时间和人力。

看到没有，这才是产品经理该有的本来面貌，只是长期以来

国内的互联网高速浪潮，掩盖了一批又一批低能或者无用的产品经理的真相

五、程序员介入并主导产品设计是大势所趋，不懂技术的产品经理将逐渐消失

正如这一波DevOps浪潮一样，当复杂的业务变化、云服务的产业升级、开发模式和方法不断出新等客观社会大势推着你前进的时候，开发与运维就不得不融合，并且这个时候更讲逻辑的开发团队，将会从开发时开始，主导自动化运维的整个过程。

产品设计也是如此，每开除一个无效的产品经理，把多出来的工资交给有天赋的愿意学习的程序员，那么项目和产品就多增加一份扎实度和可靠度。

在不远的将来，产品设计端和开发端将会越来越融合和耦合在一起，最佳的产品界面和流程设计，一定与数据模型的设计和扩展同步进行，而对产品设计的评审，也由资深程序员和项目经理来评定。

最最垃圾的产品经理是什么？就是那些享受着平台流量红利，躺着也能进来用户，特别爱推崇自己特立独行的设计理念和技巧，反复折腾着公司资源，最后产品看似成功了，其实和他真的毫无关系的“高级产品经理”，这种人，不仅存在，而且数量巨大，混迹在BAT浪潮中，从1个岗位跳槽到另一个岗位，工资不断上涨，看似指点江山游刃有余，实则毫无作用，企业累赘。

请开除这些产品经理吧，已经清醒过来的企业，请加大对程序员的培养力度，给优秀的程序员涨工资！让他们成长为优秀的产品经理！