作为一个产品经理如何补充技术知识？

作为一个入行差不多两年的产品，在功能上的修行已经越来越熟悉，但是在和技术对接以及很多涉及到技术比较深的问题还是会懵逼，不知道如何补充自己这方面的知识？

我是来劝退的，哈哈

首先，你要相信术业有专攻，而且有时候认怂也是一种解决事情的方法，如果你不是专心做技术研发，不要想著自己从哪里学点技术知识就能压制的住程序员，因为你业余时间必然学的没有别人精，而且没有实战过，半懂不懂的跟技术人员交流，会被碾压的更狠，在工作中，我即使懂，一般在技术方面有某个想法，在跟技术沟通的时候，也会先说一下，我可能不是太懂，所以是不成熟的想法，看看这样xxx行不行，防止自己被打脸；

其次, 你这个问题本质上是一个沟通的问题，你得了解技术的思维模型，然后使用一些沟通技巧；

技术人员是产品落地的执行人，是最后干活的人，需要考虑很多细节，就跟盖房子一样，每一块砖都得放正确房子才能安全，稳固，这个过程是很累人的，所以研发人员自嘲为「码农「还是很形象的；

在工作中你会发现这样一个规律，对于之前没有做过的需求，技术做完了总是会有很多bug，得经过几次迭代才能完善，而对于之前做过的需求，你再提类似的需求，技术往往做的又好又快，就是因为一个创新的需求，从开始开发到成熟，要有一个过程，每次都创新，技术会非常累，所以大多数技术人员倾向于复用过去的开发方案或经验，一般在接到需求后，他们优先考虑使用之前开发过的方案 , 如果用不了再考虑自己比较熟悉或擅长的方案，然后如果还是不行，再推荐你优化你简化产品需求，使用更简单的方式来实现，如果遇到比较坚持的产品经理，他们就会通过一些技术的难题来刁难你，这个时候你可能就得使用沟通的大杀器，撕逼或搬领导了，整个过程，技术的思维都是从我怎么能实现，怎么能更轻松的实现来考虑的；

再来看看产品经理，对于一个需求，产品经理是从用户需求，业务逻辑，市场竞争，用户体验，投入收益等角度来考虑问题的，产品经理思考的是不仅要能用，而且要好用，甚至超出预期，所以会经常提一些「超纲」的需求，必然会加重技术人员的工作负担，天然的会产生一些矛盾；

所以当他们给你拽专业的技术术语的时候，你就要有心理准备，可能是因为这样几个原因：

发泄心中不满，觉得你的需求超纲又不得不做
用你不懂的，让你知难而退
刷存在感（因为产品经理不懂技术，而且经常思维上有漏洞）
可能是真的涉及某项技术，在用他们的语言在跟你正常沟通

针对这种情况你可以用这些技巧跟他们沟通：

把自己的需求捋清楚，表达清楚，务必确认他们是否收到并且理解了你的需求；
不要跟他们讨论技术，不要跟他们讨论技术，不要跟他们讨论技术，即使你很懂，防止他们把你引向自己擅长的方向，然后再用自己丰富的经验打败你；
如果跟你讨论技术，要搞清楚和你需求之间的关联，不要把问题讨论变成知识讲堂，问题始终围绕在需求实现上来讨论，针对技术问题，遇到不懂的，首先认怂说自己不懂，然后问是什么，把问题抛给技术让给你解释，不管懂没有懂，然后回归解决问题的思路，问这个技术能否实现提的需求，多久实现，实现不了其它什么方式？

其次, 基于上面的观点，产品经理如果想补充技术知识，可以从这三个方面来展开：

像了解用户一样，研究技术人员的思维和内在需求，从而知道他们其实想需求什么；
了解一些常用的技术专业术语和产品实现上约定俗成的说法，相信你工作两年已经接触了不少，比如「bug」是啥意思，「H5」是啥意思，「前端」是啥，「客户端」是啥，「轮询」是啥等等，每个技术团队的使用偏好不一样，这些通过日常的产品评审，留心整理，日积月累就慢慢掌握了。
了解一些技术实现的「原理「，而不是去学怎么写代码，比如知道一个产品要实现，需要几个终端，需要哪些技术人员，一般各个端是怎么配合的，技术的实现也是需要先设计，然后再开发的等等，知道了原理，你就知道技术人员问某个问题背后的真实目的是什么，比如技术人员常常会问这个栏位要不要「写死「，如果你了解技术原理，你就会发现，他们其实是考虑你这个栏位后续可能会有修改的需求，为了不给自己后续工作造成麻烦，所以跟你沟通确认；关于这部分内容的学习，可以去看一些技术书籍，一般看前面原理部分的章节就可以了，另外还是要加强实战，多和技术人员沟通，不懂就问，任何一种方式都没有实战学习提高的快！

最后. 再说说产品经理的思维，产品经理的主要工作是从需求，业务，解决方案层面来考虑问题，在这个过程中重要的不是你能把这个过程中所有事情都了解，都做了，而是你怎么合理的协调统筹你手中的资源，把问题解决了，所以需要具备老板思维，自己不懂的，学会合作，相信自己的合作伙伴，并鼓励帮助他们做好它，如果没有这种想法，你会发现，自己可能除了补充技术知识，还得补充设计知识，测试知识等等，导致自己要学的越来越多，当然多学东西总是好的，我还是鼓励多学习，但是要知道自己工作的重点。

感谢邀请。

可以多看看实时的干货文章，其他技术领域的内容可以去了解，然后根据自身所知道的知识结合一下~

其实有很多优秀的技术或是产品开了自己的公众号平台，不定时更新，因为这个是实时的，比书籍更有时效性，符合当下情况，所以可以找找看看，而且各个领域的都有。

产品经理在工作中，经常会和技术去沟通，当你在和技术沟通的过程中，不懂技术可以问，这样你也能学到很多东西

多提问，及时总结。

产品经理和开发工程师是经常接触的，在输出产品原型的过程，遇到自己没把握的问题，可以多跟开发工程师们沟通。但不要在他们集中精神敲代码的时候去打断他们，如果不是紧急的问题，可以在中午吃饭等闲时时间再问。

可能很多人会碍于面子，认为问问题会降低自己的level。但每个岗位都有自己擅长的领域，请教工程师技术层面的问题，你才可以让自己设计具有更高的可行性，在需求评审会议上才能更顺利通过方案。如果已经觉得设计有问题，却不去问，一方面浪费自己的时间在设计一些会被驳回的东西，另一方面需求评审不过关，其实会很受打击。

问问题之前，一定要先自己思考，问完之后再及时总结，总结他们常用的术语。同时，了解他们回答问题的思想，也让自己慢慢有这种思想。

最后，现在也有挺多产品经理开始学习编程了，B站的课程很多，可以每天花个半小时看看，进行比较系统化的学习。不用学的非常透彻，除非想转行，学习一个思想就可以了。

首先，我觉得不用写代码，也不用看书，经验来自实践。

1.通过平时的交流沟通，了解你经手的需求的实现原理。做到针对一个产品需求或 bug，你大概看一眼，要知道这个是客户端问题，还是服务端问题。

2.了解资料库相关知识，要到自己公司的资料库表结构，结合业务理解学习。

3.如果工作中会遇到，多看看第三方的技术文档，大概了解对方的实现原理。

有个公众号「给产品经理讲技术」可以关注看看，深入浅出的讲了很多常用的技术，应该会对你有帮助。

最后，作为产品要了解的不是技术语言的执行细节，而是技术的思维模式，学会从技术的角度拆解需求，慢慢得就会有一种融会贯通的感觉，跟技术沟通起来也会比较得心应手，甚至有时候还能给技术提供些新思路。