如何自學數據產品經理？

01-05

想走入數據產品經理的領域，但是現在不知道怎麼入手去學習這方面的知識，希望得到大家的指點！！
目前還沒有基礎，也沒有人指導怎麼去學，希望多多指點！！！

數據產品經理是啥？

數據產品經理是負責數據產品的產品經理（好拗口，但就是醬）

數據產品：淘寶指數，百度指數，生意參謀，雙十一大屏，支付寶風控系統等
產品經理：這個不用我解釋吧，知乎一堆回答

那Okay，都說實踐重要，為啥要自學呢？

實踐當然最重要，但實踐前記得多儲備理論，尤其是基礎能力，否則實踐了也不會總結，那麼從實踐中收穫起來就慢了，所以這是自學的基本作用。

那如何自學？

這麼大個問題一定是要拆解了才能回答，就像數據分析一定要拿維度細分，下鑽才能慢慢有洞察。

按數據+產品+經理來拆解：

數據：數據分析，SQL，數據倉庫入門，數據挖掘入門
產品：商業分析，產品設計，產品運營
經理：溝通，項目管理

按硬實力+軟實力來拆解：

技術（硬實力）：數據技術（SQL，數據倉庫入門），數據挖掘入門
業務（軟實力）：商業知識，產品知識，分析能力，溝通能力等等

我擦，那麼多東西，學完了都過了找工作的時間了！

別急，做產品都按優先順序來，自學當然也是，根據個人時間安排吧，缺啥補啥或揚長避短，這兩種策略你可以自由選擇。我個人的見解：

按數據+產品+經理來拆解：

P0（打基礎，有底子）：商業分析（不懂商業就是白瞎），數據分析，SQL（必備）
P1（上戰場）：溝通（需求的輸入，合作的開始），產品設計（要做產品了），數據倉庫（要理解開發）
P2（獲得影響力，養產品）：產品運營
P3（找到工作前不用太著急）：數據挖掘入門（理解演算法同學），項目管理

這些都是概念，每個概念下如何自學呢？

明天得上班，我想洗洗睡了，如果對你有用，我後面繼續更吧。

ps，我也只是個剛本科畢業加入阿里做了6個月的數據產品經理，一點拙見，獻醜了。上面每一項其實知乎上都有不少答案，肯定回答得比我好。

難得在知乎上冒個泡，那就搬到我的微信公號（youerrener) 里去好了：）

為什麼那麼多人都喜歡方法論呢，難道方法論可以快速成長？哎，這個空手套白狼的世界。

我搬來大家自己看看。

寫在公司看的。

————————————————————————————————————————

本文檔主要用戶新數據產品經理對數據產品認識，以及招聘標準。

宗旨：深耕數據，賦能業務

數據產品經理一般可以演化成三個方向的產品經理：

數據平台產品經理（偏平台技術）

平台技術對於數據的認知大於對產品本身的認識，更加強調技術的重要性。

數據商業化產品經理（偏商業廣告變現）

商業化產品對業務和數據商業模式的理解大於數據本身，更加強調數據變現的敏感性。

數據策略產品經理（偏推薦演算法）

數據策略產品偏業務理解和技術演算法應用。

數據分析產品經理（偏報表和分析工具）

數據分析產品偏數據可視化，對於分析師出身的數據分析產品特別有優勢。

——————————————————————————————————

如需轉載請私信我。

po上一張自己總結的圖。

工具+知識，不過話說自學不靠譜吧，所有數據分析都是有目的的，只能說自學工具和一種思路，但是一定要實踐工作來檢驗的！

我是如何跟進產品落地？|需求跟進中出現的3大問題詳解

產品經理中打醬油的節點

最近負責的產品模塊進入開發周期，需求評審、產品設計過一段落，是時候歇一口氣的周期。往往很多產品經理在這個時候，最常用的是要麼在有任務或需求指標下，不快不慢的進入下一個需求；要麼是在下一個版本時間、或需求沒明確的時候，沒有事情的等待產品上線；不得不說這個周期，我認為是評判一個產品經理是否負責的PM。

有沒有跟進時間計劃、有沒有跟進產品節點、有沒有全局考慮全在這裡體現

我在工作中，會用甘特圖或PROJECT去把控產品的開發負責人、開發周期、工作描述，其中如果遇到大版本迭代，參與人數或變動比較頻繁的話，我會多採用PROJECT去管理項目的情況。

由上圖，我們可以清清楚楚的看到每一個階段會有哪些任務，每個任務會消耗的時間或精力。

這個就是時間計劃，當然根據你公司的分工情況；有時候項目經理會進行把控時間節點，並沒有一個產品經理的時間點的意識。

但作為一個產品經理來說，隨時隨地的知曉自己需求的進度，並且能夠及時檢驗，是對產品負責的一個態度；並且在需求評審落地過程中，如果是大的需求，可能會遺忘一些產品邏輯或細節欄位。

這個是我會出現的一個情況，但我不知道正在閱讀的你是否會出現以上情況，來一個投票看看大家的情況吧！

在這裡注意的是，在使用PROJECT工具中，需要注意各個項目任務的前後流程、人員關係，清楚知道時間節點或有評估時間節點。

不然你隨便做一個時間節點，可能開發的周期更長，那麼這個項目周期的管理能夠實際運用的意義就沒有了。

剛剛前面說過，有的團隊可能會是以項目經理或者BOSS直接去跟進需求進度，時刻CEHCK當時的產品是否符合預期或滿足其需求。

這裡我們拋開上面的情況不說，PM跟進需求通過以上的節點去了解現在的進度。比如一個APP中的某個功能，到了周五交貨時間（開發說給你測試包），那麼產品就可以去驗收，看看現在是否滿足其需求。

這個過程是頻繁、交際較多的，以下就是常見的開發分工情況

那麼一個完整的產品需求完成是離不開以上幾個工作職責的開發人員，不然你只可能去看看UI，沒有數據的產品；要麼就是有數據，但是不能按照需求中的演算法或規則去顯示。

比如FEED流的重力演算法，是否可用按照需求中的演算法，這個需要PM人員進行相關測試，但是如果服務端沒有做處理；那麼可能數據就是按開發人默認的順序去執行。

因此，產品經理跟進中，跟進第一部分說的時間節點；去跟進當前的開發需求完成情況，當然根據我的經驗中，很多過程會出現以下情況

在我工作的團隊中，經常會出現或數據端跟不上前端的速度，前端需要苦逼的等著介面的到來，這其實無疑是木桶效應。我認為團隊中，應該儘可能的去避免這種情況的出現。

木桶效應的原理是：影響裝水的量最終是木桶中最短的那個木板。

這裡我們把裝水的量比作是開發的進度，因此開發人員中如果有一個部門或某個職責的工作影響了進度，就會導致整個模塊的開發推遲。這也是為什麼一個好的項目經理或好的產品經理能夠迅速去把控相應的問題，爭取將團隊的木桶效應最小化、、開發資源利用最大化。

因為每個團隊的項目管理、團隊大小不同，其每個團隊反饋問題或同步問題的方式或流程也不同。

在創業公司，或許開發就坐PM旁邊，任何問題或情況都能馬上知曉。但在一定規模的團隊或企業中，往往開發人員對一些需求出現了問題，沒有進行處理或未完成，PM根據時間節點才能進行追蹤到相應環節出現問題的人或部門。

這也是我目前跟進中最頻繁的工作，移動端出現的問題是因為服務端，那麼就去跟進服務端；服務端做了，但移動端卻沒有顯示，那麼就去跟進移動端。

保證需求能夠順利的發包，最終按時上線。

最終這一部分，說一說最近工作中最常出現的情況，也有可能是在閱讀的你工作中出現比較多的情況。

需求開發過程中，往往會出現一些需求評審沒有出現的問題或技術沒辦法估計的問題。

好的情況是，這個需求經過評審得到開發人員的認可，可以去做，但是需要推遲；壞的情況是，開發人員根本不認可，不做！

當然，PM總會說：「砍我可以，別砍需求啊！這個需求評審的時候你不說，現在這個節骨眼給我說」

但是這個的的確確是執行與會議的區別，每個產品經理都心知肚明。好的產品經理能夠在評審中找到關鍵的難點進行詳細評審，新人產品往往就會一篇蓋全，不知道最大的坑確實在開發過程中。

首先，在工作中產品經理是對產品負責的第一責任人，如果你都不對你的產品負責，不想辦法去把產品往好的做；而是以完成任務的心態，上一個需求能上多少就上多少，那這個產品最終能為你帶來多少的價值，我們可想而知。

在遇到上面的情況，我們首先需要可以從下面幾部分去分析或爭辯：

從以上4個部分來爭取需求的開發資源，比如一個用戶量只有幾十萬的用戶產品；每天產生的用戶UGC就十多條，那麼是否有必要增加舉報功能？

雖然說舉報功能對於產品尤其是UGC是很好的一個過濾機制，是能夠增加產品的豐富。

但每天就10多條，現在的產品重點應該是引導用戶去產生UGC，十多條的量人工在後台可以進行刪除監控就足夠，是不是在當前的用戶基數或產品量情況下，可以不用去考慮過濾情況？

此，產品經理需要學會捨棄，用需求池之前有說過垂直社交與需求文檔思考的相關管理辦法。

我看到很多產品經理為了說服開發去做自己的需求，有時候是為了不讓自己打臉。畢竟就算一個很小的需求，產品人員也是經過調研或者思考，作為產品設計中，每個人都希望自己的需求能夠儘可能的完整。

好啦，這周的分享就到這裡！關於深圳線下分享會現在還在社群組織中，歡迎有時間參加分享會的朋友加入我們社群，獲取相關活動信息。

我們8月中旬會開始門票預售，這個門票並不是為了去盈利，之前就說過，門票的支出用於分享會的運轉或PMTALK組織的運轉。我們設置一個門檻，也是防止一些打廣告的朋友來現場搗亂。

以下是我的拙見：

簡言之--三足鼎立，缺一不可。

一，數據思維

OK，這塊很容易理解。

作為一個數據類的產品經理，是需要具有數據思維的。

為什麼？

請想像以下場景：

一名數據挖掘工程師經過艱苦卓絕的奮鬥，將時間序列模型的預測精度控制在98%。一周後演算法需要上線，而產品經理設計的產品是將預測變數添加為100個。

Excuse me?!?!

So，數據思維是什麼，又是如何獲得的呢？

1.1 數據思維是什麼

1.2 如何獲得數據思維

推薦書籍：《大數據時代》《刪除》（或許你已經讀了，也或許你真的懂了）

二，設計產品的能力

三，其他（通用）軟技能

都是通用的軟技能，此處不加贅述。

1.1 溝通表達能力

相信我，這是個超級加分項。但這裡的溝通表達能力並不一定代表特能聊（自來熟）。

1.2 文案寫作能力

寫一篇高效的產品文檔。相信我，開發哥哥會愛你更多的。

此處強推《完全寫作指南》。

1.3 自我迭代能力

如何使自己的產品適應口味多變的客戶，如何使自己能夠不斷地提高自我認知?

請參見產品經理流行的金句：「小步迭代，快速奔跑」

推薦書籍：（?????）呵呵，凡是可以使你認知廣度得以拓展、深度得以深化的知識，咱們都不要拒絕了吧。

改日再更

我也補這部分技能樹。

1，理解運營相關的數據，這個問題不大，有比較成熟的經驗，後續多留意相關的維度和觀點，問題應該不大;

2，技術方面，可分為數據獲取，數據整理和數據顯示，這部分問題較多，

先說數據獲取，sql是基本工具，但也需要比較清楚資料庫的關係。

如果嵌入了統計工具，還需要介面把數據導入。

再說，數據整理。

最後是數據展示，通過web頁面或者定期郵件，push出來。

這部分有相關的可視化工具，導入數據配置，應該就OK了。

這幾面，sql查詢和python，相對於我，是最難的。

目前自學中，有機會可以多交流。