1樓：半半
從產品經理成長的路徑來說，要學習的知識很多，分如下幾個部分。
1、工具篇
做個產品經理得會畫原型吧，應該要懂得怎麼把想法與需求轉化成技術、開發懂的語言。
那麼產品常用的工具得熟練，包括：Axure RP、Visio、Xmind、PPT、Word、藍湖、jira，這些都是必須要熟練的。
NPDP產品經理國際資格認證報考資格免費評估+學習/備考資料免費領取
2、溝通篇
乙個專案開發的過程中，產品經理需要和運營、前端開發、後端開發、測試、市場等多個部門多位同學溝通，怎麼推動專案按時間節點完成呢？
這就需要溝通的藝術，產品經理需要懂得怎麼跟人打交道，內部外部的，包括使用者。
比如產品研究過程中很重要的一部分就是使用者研究，使用者訪談調研，怎麼提問，怎麼讓使用者把使用產品過程中的問題表達出來，這些都是需要溝通藝術的。
3、高階篇
這部分是最難的
理解人群的需求，針對性制定合理產品策略。
理解行業的情況，理解公司在產業中所處的位置和競爭形態，團隊就這麼多人，功能要那麼多，先做什麼後做什麼，做了之後可能帶來的反應是什麼。
同理心，資料分析的能力都是必須的。
2樓：石溪
我毛遂自薦乙個為非計算機專業朋友打造的學習python和資料分析的專欄：
給妹子講python
醬油哥：給妹子講python第二季-資料分析基本工具（序）
這可能是乙個與眾不同的專欄：
1.日漫外表，美劇情節，學習成了追劇。
我們做這個專欄首先思考的是如何留住讀者，要讀者走進教室？通過精心設計專欄，我們把想要介紹的內容打造成環環相扣的美劇形式：每一季講述乙個大的主題，季中每一集的內容環環相扣，前後幾集一般又構成了乙個完整的專題。
2.作者引導，妹子陪讀，打消許多乏味。3.鋪墊台階，思考目的，知道路在何方。
其實我們每乙個人花時間學習，都對乙個問題非常重視：那就是學了有什麼用？學了後，下一步再往哪走。
對於python而言，學習他只是起點，而不是終點；只是工具，而不是目的。第一季講完python後，我們會以python為工具，和大家一起繼續探索實用而有意思的主題
3樓：Kevin
產品經理中打醬油的節點
最近負責的產品模組進入開發周期，需求評審、產品設計過一段落，是時候歇一口氣的週期。往往很多產品經理在這個時候，最常用的是要麼在有任務或需求指標下，不快不慢的進入下乙個需求；要麼是在下乙個版本時間、或需求沒明確的時候，沒有事情的等待產品上線；不得不說這個週期，我認為是評判乙個產品經理是否負責的PM。
有沒有跟進時間計畫、有沒有跟進產品節點、有沒有全域性考慮全在這裡體現
我在工作中，會用甘特圖或PROJECT去把控產品的開發負責人、開發周期、工作描述，其中如果遇到大版本迭代，參與人數或變動比較頻繁的話，我會多採用PROJECT去管理專案的情況。
由上圖，我們可以清清楚楚的看到每乙個階段會有哪些任務，每個任務會消耗的時間或精力。
這個就是時間計畫，當然根據你公司的分工情況；有時候專案經理會進行把控時間節點，並沒有乙個產品經理的時間點的意識。
但作為乙個產品經理來說，隨時隨地的知曉自己需求的進度，並且能夠及時檢驗，是對產品負責的乙個態度；並且在需求評審落地過程中，如果是大的需求，可能會遺忘一些產品邏輯或細節字段。
在這裡注意的是，在使用PROJECT工具中，需要注意各個專案任務的前後流程、人員關係，清楚知道時間節點或有評估時間節點。
不然你隨便做乙個時間節點，可能開發的週期更長，那麼這個專案週期的管理能夠實際運用的意義就沒有了。
剛剛前面說過，有的團隊可能會是以專案經理或者BOSS直接去跟進需求進度，時刻CEHCK當時的產品是否符合預期或滿足其需求。
這個過程是頻繁、交際較多的，以下就是常見的開發分工情況
那麼乙個完整的產品需求完成是離不開以上幾個工作職責的開發人員，不然你只可能去看看UI，沒有資料的產品；要麼就是有資料，但是不能按照需求中的演算法或規則去顯示。
比如FEED流的重力演算法，是否可用按照需求中的演算法，這個需要PM人員進行相關測試，但是如果服務端沒有做處理；那麼可能資料就是按開發人預設的順序去執行。
因此，產品經理跟進中，跟進第一部分說的時間節點；去跟進當前的開發需求完成情況，當然根據我的經驗中，很多過程會出現以下情況
在我工作的團隊中，經常會出現或資料端跟不上前端的速度，前端需要苦逼的等著介面的到來，這其實無疑是木桶效應。我認為團隊中，應該盡可能的去避免這種情況的出現。
木桶效應的原理是：影響裝水的量最終是木桶中最短的那個木板。
這裡我們把裝水的量比作是開發的進度，因此開發人員中如果有乙個部門或某個職責的工作影響了進度，就會導致整個模組的開發推遲。這也是為什麼乙個好的專案經理或好的產品經理能夠迅速去把控相應的問題，爭取將團隊的木桶效應最小化、、開發資源利用最大化。
因為每個團隊的專案管理、團隊大小不同，其每個團隊反饋問題或同步問題的方式或流程也不同。
在創業公司，或許開發就坐PM旁邊，任何問題或情況都能馬上知曉。但在一定規模的團隊或企業中，往往開發人員對一些需求出現了問題，沒有進行處理或未完成，PM根據時間節點才能進行追蹤到相應環節出現問題的人或部門。
這也是我目前跟進中最頻繁的工作，移動端出現的問題是因為服務端，那麼就去跟進服務端；服務端做了，但移動端卻沒有顯示，那麼就去跟進移動端。
保證需求能夠順利的發包，最終按時上線。
最終這一部分，說一說最近工作中最常出現的情況，也有可能是在閱讀的你工作中出現比較多的情況。
需求開發過程中，往往會出現一些需求評審沒有出現的問題或技術沒辦法估計的問題。
好的情況是，這個需求經過評審得到開發人員的認可，可以去做，但是需要推遲；壞的情況是，開發人員根本不認可，不做！
當然，PM總會說：「砍我可以，別砍需求啊！這個需求評審的時候你不說，現在這個節骨眼給我說」
但是這個的的確確是執行與會議的區別，每個產品經理都心知肚明。好的產品經理能夠在評審中找到關鍵的難點進行詳細評審，新人產品往往就會一篇蓋全，不知道最大的坑確實在開發過程中。
首先，在工作中產品經理是對產品負責的第一責任人，如果你都不對你的產品負責，不想辦法去把產品往好的做；而是以完成任務的心態，上乙個需求能上多少就上多少，那這個產品最終能為你帶來多少的價值，我們可想而知。
在遇到上面的情況，我們首先需要可以從下面幾部分去分析或爭辯：
從以上4個部分來爭取需求的開發資源，比如乙個使用者量只有幾十萬的使用者產品；每天產生的使用者UGC就十多條，那麼是否有必要增加舉報功能？
雖然說舉報功能對於產品尤其是UGC是很好的乙個過濾機制，是能夠增加產品的豐富。
此，產品經理需要學會捨棄，用需求池之前有說過垂直社交與需求文件思考
的相關管理辦法。
我看到很多產品經理為了說服開發去做自己的需求，有時候是為了不讓自己打臉。畢竟就算乙個很小的需求，產品人員也是經過調研或者思考，作為產品設計中，每個人都希望自己的需求能夠盡可能的完整。
我們8月中旬會開始門票預售，這個門票並不是為了去盈利，之前就說過，門票的支出用於分享會的運轉或PMTALK組織的運轉。我們設定乙個門檻，也是防止一些打廣告的朋友來現場搗亂。
4樓：
我也補這部分技能樹。
1，理解運營相關的資料，這個問題不大，有比較成熟的經驗，後續多留意相關的維度和觀點，問題應該不大;
2，技術方面，可分為資料獲取，資料整理和資料顯示，這部分問題較多，先說資料獲取，sql是基本工具，但也需要比較清楚資料庫的關係。
如果嵌入了統計工具，還需要介面把資料匯入。
再說，資料整理。
最後是資料展示，通過web頁面或者定期郵件，push出來。
這部分有相關的視覺化工具，匯入資料配置，應該就OK了。
這幾面，sql查詢和python，相對於我，是最難的。
目前自學中，有機會可以多交流。
產品經理如何提高資料探勘和分析能力？
產品一哥 提高資料分析能力，你需要 對業務有深刻的理解 熟悉資料框架 對現有資料指標進行分析 勤於取數訓練 增加資料多樣性。產品一哥 萬字乾貨！0基礎如何拿到產品經理offer 0基礎如何拿到產品經理offer 資料分享 資料提取碼 z8nr 0基礎如何拿到產品經理offer 資料分享產品經理求職 ...
自學產品經理，需要掌握哪些東西？
Leeele 首先說一下自身背景，本人臨床醫生出生，後續轉到醫療裝置廠家 國內上市企業 外企做產品經理，行業經驗5年，目前又回到臨床。首先要確認，你所所的產品經理類別，是上游偏研發類，還是下游偏營銷。首先這兩個的共同點就是 跨部門溝通溝通在溝通，協調資源，調配人力。分別來說 上游研發類需要和研發部門...
產品經理如何學習資料庫以便進行資料分析？
北斗核潛艇 是的，廣東某些智障廠的管理也是想省一筆錢異想天開的直接excel運算元據記錄，然後內部管理結構和財務流程就跟吃了農村那種打鳥的銃彈一樣，財務倉務人事喜迎工廠倒閉 姜健 老婆PM，我DBA，不是我不教，是她太懶.另外，從乙個DBA的角度講，測試環境還好，生產環境讓乙個PM直接去查，哪怕沒有...