昨天我在自己另一个公众号写了一篇文章，说了一个有离职冲动的产品经理遇到的工作现状。
文章发出后，有好几个读者跟我留言说了自己类似的遭遇，可以感受到他们情绪中带着一丝无奈。
(相关资料图)
结合昨天的文章，这里我再展开多说几句，希望对非技术背景出身的产品经理有所帮助。
事情是这样的，昨天早上我收到一条留言，内容如下。
我感觉公司里的程序员都挺爱欺负不懂技术的产品经理，他们总是无理由拒绝需求，而且自己决定什么能做什么不做，我们很被动，有点想离职了。
看到这段内容后我回复了四个字，不要离职。
事后也了解到，他们公司是技术文化主导，产品经理更像是需求整理师和文档写作员，对于需求和产品方案的把控力非常弱。
之前公司里还有三个产品经理，现在走了两个只剩他自己了，每天工作起来非常费劲，离职冲动非常强烈。
尤其是在 PRD 评审会上，程序员对需求做不做有一票否决权，但凡觉得复杂点的方案他们就说做不了，或者打回来让产品经理重新想其他方案。
遇到不懂的技术问题，程序员也没耐心给他解释，留下一头雾水回来自己消化。
当然，并不是所有的程序员都这样，有很多技术小哥还是非常热心帮助这些技术小白的。
之后我也问了他一个问题，遇到这种情况的时候你们领导有干预过么？
他说，领导是技术出身的产品负责人，所以公司程序员都还是比较服他，有些方案在他的协调和解释下还是能顺利推进。
基于以上情况，其实问题就出在了他对于技术知识的空缺，以及无法从技术角度去评估产品需求和方案。
但是要我说吧，越是逆境，越有助于一个人的成长。
我说你即便是现在离职了，换一家公司也会遇到同样的问题，因为问题的核心不出在这家公司上，而在于他自己。
如果是这样的话，这样的离职就非常不具备性价比。
作为一个不懂技术的产品经理，这种知识上的空缺是可以通过后期学习补上的，而且也不是什么太难的事。
我一直说，产品经理不需要掌握技术能力，但要掌握技术思维。
思维和能力的区别，就是你知道怎么开车，但不需要你去造车。
大多数产品工作所涉及的技术知识都是有边界的，常用的无非也就是那一些。
如果是常规类业务产品或工具产品，所包含的技术领域无非就是前端、后端、数据库以及网络通信。
落地到一个具体功能上，大概的模型就是前端调用接口发起网络请求，将数据封装在 JSON 或者 XML 里传递给后端，后端处理完成后通过接口返回结果，涉及到数据存储的就调用数据库服务。
以上这个过程，可以通过下图概括出来。
进一步拆解，这里面涉及的技术知识点可能包括数据类型、API接口、JSON、URL、响应状态码、HTTP请求以及数据库处理等。
也就是说，要建立技术思维，就需要先理解这些技术知识点，然后触类旁通举一反三。
比如，前端和后端的联动就像一次笔友写信的过程，前端将信件内容（数据）写在信纸上（JSON），然后在信封上写上地址（URL）并交给邮局投递给后端，后端收到信后处理信件内容并回信。
很多人看过我的那本书，也因此具备了相对完整的技术思维，能够帮助到这么多产品经理我很高兴。
同时我也建议那些非技术背景出身的产品经理们，不要因为暂时的困难而退缩，不懂就学，不懂就问，克服当前的困难你就能走出困境。
因为这样的原因就离职只是一种逃离，因为问题并没有就此自动消失，它还在那里。
就像有的同学会因为不喜欢公司的一个同事或领导而离职一样，这样其实也不解决问题，因为你无法知道下一家公司是否还会遇到同样的人。
只有强大自己，持续学习，克服困境，我们才能收获成长。
最后，给自己打个广告。
我正在写一本面向非技术背景产品经理的新书，这里面的内容相对于之前那本更加完善，更加成体系化。
并且，不需要等到这本书出版上市你就可以看，而且是我边写你边看。你还能给这本书提建议，我可能会把你关心的内容写进去。
目前这个专栏已经更新到了第五章，进入后端技术的学习环节，后期还有区块链和 AI 相关的技术知识。
买断的读者在这本书更新完成后可以免费获得一本纸质书，而且首批买断的读者，你们的名字可能会出现在这本书最后。
话不多说，扫码上车。
推荐阅读：《这类坑，别踩》
·················唐韧出品·················
▲点击上方卡片进入发消息回复“w”，可加我个人微信
关注唐韧，用产品思维洞察现象背后的逻辑
安可时刻
今天上午给我合作的一家公司的产品团队做了一场小分享，内容也是关于如何掌握技术思维的。
从他们的反馈来看，平时工作中没少受程序员的欺负，看来大家的痛点普遍一样。
不过没关系，当你身怀绝技的时候，就没人能小看你了。
