作為一個產品經理如何補充技術知識？

作為一個入行差不多兩年的產品，在功能上的修行已經越來越熟悉，但是在和技術對接以及很多涉及到技術比較深的問題還是會懵逼，不知道如何補充自己這方面的知識？

我是來勸退的，哈哈

首先，你要相信術業有專攻，而且有時候認慫也是一種解決事情的方法，如果你不是專心做技術研發，不要想著自己從哪裡學點技術知識就能壓制的住程序員，因為你業餘時間必然學的沒有別人精，而且沒有實戰過，半懂不懂的跟技術人員交流，會被碾壓的更狠，在工作中，我即使懂，一般在技術方面有某個想法，在跟技術溝通的時候，也會先說一下，我可能不是太懂，所以是不成熟的想法，看看這樣xxx行不行，防止自己被打臉；

其次, 你這個問題本質上是一個溝通的問題，你得了解技術的思維模型，然後使用一些溝通技巧；

技術人員是產品落地的執行人，是最後幹活的人，需要考慮很多細節，就跟蓋房子一樣，每一塊磚都得放正確房子才能安全，穩固，這個過程是很累人的，所以研發人員自嘲為「碼農「還是很形象的；

在工作中你會發現這樣一個規律，對於之前沒有做過的需求，技術做完了總是會有很多bug，得經過幾次迭代才能完善，而對於之前做過的需求，你再提類似的需求，技術往往做的又好又快，就是因為一個創新的需求，從開始開發到成熟，要有一個過程，每次都創新，技術會非常累，所以大多數技術人員傾向於復用過去的開發方案或經驗，一般在接到需求後，他們優先考慮使用之前開發過的方案 , 如果用不了再考慮自己比較熟悉或擅長的方案，然後如果還是不行，再推薦你優化你簡化產品需求，使用更簡單的方式來實現，如果遇到比較堅持的產品經理，他們就會通過一些技術的難題來刁難你，這個時候你可能就得使用溝通的大殺器，撕逼或搬領導了，整個過程，技術的思維都是從我怎麼能實現，怎麼能更輕鬆的實現來考慮的；

再來看看產品經理，對於一個需求，產品經理是從用戶需求，業務邏輯，市場競爭，用戶體驗，投入收益等角度來考慮問題的，產品經理思考的是不僅要能用，而且要好用，甚至超出預期，所以會經常提一些「超綱」的需求，必然會加重技術人員的工作負擔，天然的會產生一些矛盾；

所以當他們給你拽專業的技術術語的時候，你就要有心理準備，可能是因為這樣幾個原因：

發泄心中不滿，覺得你的需求超綱又不得不做
用你不懂的，讓你知難而退
刷存在感（因為產品經理不懂技術，而且經常思維上有漏洞）
可能是真的涉及某項技術，在用他們的語言在跟你正常溝通

針對這種情況你可以用這些技巧跟他們溝通：

把自己的需求捋清楚，表達清楚，務必確認他們是否收到並且理解了你的需求；
不要跟他們討論技術，不要跟他們討論技術，不要跟他們討論技術，即使你很懂，防止他們把你引向自己擅長的方向，然後再用自己豐富的經驗打敗你；
如果跟你討論技術，要搞清楚和你需求之間的關聯，不要把問題討論變成知識講堂，問題始終圍繞在需求實現上來討論，針對技術問題，遇到不懂的，首先認慫說自己不懂，然後問是什麼，把問題拋給技術讓給你解釋，不管懂沒有懂，然後回歸解決問題的思路，問這個技術能否實現提的需求，多久實現，實現不了其它什麼方式？

其次, 基於上面的觀點，產品經理如果想補充技術知識，可以從這三個方面來展開：

像瞭解用戶一樣，研究技術人員的思維和內在需求，從而知道他們其實想需求什麼；
瞭解一些常用的技術專業術語和產品實現上約定俗成的說法，相信你工作兩年已經接觸了不少，比如「bug」是啥意思，「H5」是啥意思，「前端」是啥，「客戶端」是啥，「輪詢」是啥等等，每個技術團隊的使用偏好不一樣，這些通過日常的產品評審，留心整理，日積月累就慢慢掌握了。
瞭解一些技術實現的「原理「，而不是去學怎麼寫代碼，比如知道一個產品要實現，需要幾個終端，需要哪些技術人員，一般各個端是怎麼配合的，技術的實現也是需要先設計，然後再開發的等等，知道了原理，你就知道技術人員問某個問題背後的真實目的是什麼，比如技術人員常常會問這個欄位要不要「寫死「，如果你瞭解技術原理，你就會發現，他們其實是考慮你這個欄位後續可能會有修改的需求，為了不給自己後續工作造成麻煩，所以跟你溝通確認；關於這部分內容的學習，可以去看一些技術書籍，一般看前面原理部分的章節就可以了，另外還是要加強實戰，多和技術人員溝通，不懂就問，任何一種方式都沒有實戰學習提高的快！

最後. 再說說產品經理的思維，產品經理的主要工作是從需求，業務，解決方案層面來考慮問題，在這個過程中重要的不是你能把這個過程中所有事情都瞭解，都做了，而是你怎麼合理的協調統籌你手中的資源，把問題解決了，所以需要具備老闆思維，自己不懂的，學會合作，相信自己的合作夥伴，並鼓勵幫助他們做好它，如果沒有這種想法，你會發現，自己可能除了補充技術知識，還得補充設計知識，測試知識等等，導致自己要學的越來越多，當然多學東西總是好的，我還是鼓勵多學習，但是要知道自己工作的重點。

感謝邀請。

可以多看看實時的乾貨文章，其他技術領域的內容可以去了解，然後根據自身所知道的知識結合一下~

其實有很多優秀的技術或是產品開了自己的公眾號平臺，不定時更新，因為這個是實時的，比書籍更有時效性，符合當下情況，所以可以找找看看，而且各個領域的都有。

產品經理在工作中，經常會和技術去溝通，當你在和技術溝通的過程中，不懂技術可以問，這樣你也能學到很多東西

多提問，及時總結。

產品經理和開發工程師是經常接觸的，在輸出產品原型的過程，遇到自己沒把握的問題，可以多跟開發工程師們溝通。但不要在他們集中精神敲代碼的時候去打斷他們，如果不是緊急的問題，可以在中午喫飯等閑時時間再問。

可能很多人會礙於面子，認為問問題會降低自己的level。但每個崗位都有自己擅長的領域，請教工程師技術層面的問題，你纔可以讓自己設計具有更高的可行性，在需求評審會議上才能更順利通過方案。如果已經覺得設計有問題，卻不去問，一方面浪費自己的時間在設計一些會被駁回的東西，另一方面需求評審不過關，其實會很受打擊。

問問題之前，一定要先自己思考，問完之後再及時總結，總結他們常用的術語。同時，瞭解他們回答問題的思想，也讓自己慢慢有這種思想。

最後，現在也有挺多產品經理開始學習編程了，B站的課程很多，可以每天花個半小時看看，進行比較系統化的學習。不用學的非常透徹，除非想轉行，學習一個思想就可以了。

首先，我覺得不用寫代碼，也不用看書，經驗來自實踐。

1.通過平時的交流溝通，瞭解你經手的需求的實現原理。做到針對一個產品需求或 bug，你大概看一眼，要知道這個是客戶端問題，還是服務端問題。

2.瞭解資料庫相關知識，要到自己公司的資料庫表結構，結合業務理解學習。

3.如果工作中會遇到，多看看第三方的技術文檔，大概瞭解對方的實現原理。

有個公眾號「給產品經理講技術」可以關注看看，深入淺出的講了很多常用的技術，應該會對你有幫助。

最後，作為產品要了解的不是技術語言的執行細節，而是技術的思維模式，學會從技術的角度拆解需求，慢慢得就會有一種融會貫通的感覺，跟技術溝通起來也會比較得心應手，甚至有時候還能給技術提供些新思路。