今日では、興味深いトピックです
プログラマとプロダクトマネージャの闘争、基本的に擬似需要があります
私は2つの点を投げます：
ごみ1、現在の国内のインターネットのトレンドでは、非プログラマよりも90％以上の元プロダクトマネージャー
2、どんなにどこ、とプログラマは最高の初心者で、中間プロダクトマネージャー候補
ジェットが、実際に見ていません
これらのビューについては、次の引数
まず、プロダクトマネージャーは一切ありません調べるには、正常に個人の能力やプラットフォーム資本成功祝福の違いは？
私はプロダクトマネージャーの肖像画を言った、我々は非常に精通している必要があります：
私は、私はこの新しいインターネット製品の設計ツールの刃を知っている、と私は特に、通常は他の誰かのアプリケーションを熟考のように、私は新しいもので、特に興味を持っています、私はマッピングを気になり、切断された計画は、私がAxureを使用する方法を知って、文書を書きます私はデジタル製品を愛し、私はフルーツの粉、I.午前 。。
はい、あなたは彼が主流のプロダクトマネージャーであることを認識しているが、あなたは気付いていないです。
あなたはまだ「ジャンク」であってもよいです
ここだゴミは軽蔑的な用語ではないが、目的の文は、チームやプロジェクト内の人は、彼が他の人を交換した場合、まだシームレスに動作時間を切り替えることができます
それから彼は、最新のゴミ分類規則上海によると、「資源ごみ」である必要があり、他のチームはまだプロダクトマネージャーをし続けることができます
しかし、なぜ、時には優位のまだ完全な意味、人気の世界が見たプロダクトマネジャーの多くは、私は独自の美学を持って、私はそれのように、特に成功した製品の外観を扱い？
彼は把握していないので、プラットフォームや個々の能力の値の差を
中国のインターネットとソフトウェア業界は楽しいですし、高品質な製品のこの波の下で技術革新によって駆動され、業界や資本の動向は、出現し続けるが、また、作成された人気のある仕事を：プロダクトマネージャー、および一般的な錯覚： 「これらのプロダクトマネージャーは、多くの高品質の製品を作成します。」
しかし、実際には：
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波で除去したが、実際にはそこにあるだけでなく、企業の負担。
今の事業を覚ますために持っているこれらの製品マネージャを閉じてください、良いプログラマに昇給をプログラマを養成するための努力を増加させてください！彼らは良いプロダクトマネージャーに成長しましょう！
