數據驅動，在團隊中很重要，那么該如何做呢？作者結合自己過去的經歷，總結了一些對數據驅動的思考以及自己接手這家公司數據驅動前段時間的復盤、如何找到數據驅動的人才、最終如何執行KPI指標。一起來看吧。

再講一篇團隊如何做數據驅動的經驗復盤，有些內容是因為上次沒有講到所以進行的補充，有些內容是我最近的咨詢又有了新的感觸和復盤。所以就有了這篇文章。

雖然我扮演的是咨詢建議的工作，但是假如您是在團隊內部，你有足夠的管理權力做組織數據驅動，那么您可以按照這個維度去思考。

本篇文章會分為三個部分。我對啟動數據驅動的思考，以及自己接手這家公司數據驅動前段時間的復盤。第二是如何找到數據驅動的人才，第三是最終如何執行KPI指標。我們會把組織分工和人員招募以及管理KPI，這三部分再細化的講一講。

因為上次有一些角度并沒有講到，這很重要，不然我也不至于再寫一篇文章。注意這不是重復，是一個新的角度。當然這些角度有些可以用在持續數據驅動中。

在這里也感謝一下snow和Vincent兩位老師給了我一個實踐的機會，不然就沒有后續的文章了。

也讓我理解了交易中信任對于交易可行度的影響。端午節看了naval寫的《納瓦爾寶典》里面提到了「構建者」和「第四種運氣」以及「責任與名聲」這是三觀點。我對它們影響深刻。

到了我現在的工作閱歷，我會有意識的抽離出來看待工作，畢竟一個人能力再強，還是需要依靠團隊來完成商業行為，所以我管這個叫做「做局」，或者叫「做勢」只要環境對了，環境孵化的業務會慢慢變好（前提是你在一個好的賽道里）我相信通過組織結構，權責激勵，以及工作流程等的優化，遠比個人上去蠻干要來的業務增長巨大。

當然這并不是說你只需要關注制定方向目標，調整組織結構，梳理工作這三個方向就足夠了，而是說你需要去考慮投入產出，考慮到哪些事情你可能需要下去抓一下，哪些事情則需要培養組織內的人才，哪些事情你通過調整組織結構就可以影響，不是說「構建者」你只需要做大的結構調整就可以了，這中間的權衡取舍，邊界確定，模型調整是需要實踐的。

或者說可能隨著我的工作深入，我會逐步總結方法論。目前我總計會有一個參考系來評判決策，它來自于產品經理的權衡體系。底層萬物歸于一。

所以從19年，我就有意向所謂的組織增長方向靠攏。系統讓業務增長。就是naval在《納瓦爾寶典》中提到的「構建者」，他認為能夠完成復雜系統交付的人更為稀缺。所以感謝snow和Vincent給了我親自操盤的機會，盡管可能他們沒有理解到我有多么感激。

順便說一下，有想咨詢組織增長的可以隨時聯系我，文章底部有我的微信號。

第二就是naval在書中提到的「第四種運氣」，即如果你在一個領域有了名氣，可以提供一項別人都無法提供的技能，那么就會有額外的好運氣找到你，他舉的例子是，你是潛水深度最深的潛水員，如果一個打撈機構發現了一個只能你下潛到的寶藏沉船，那么等于你也可以分到一杯羹，因為他們必須依靠你來打撈。

第三點就是信任，對于組織的變革，中間會有一些領導者暫時看不清的地方，但是snow和Vincent的愿意相信我，畢竟我和Vincent是3年多的朋友了，不至于為了這個事情，搞臭我自己的名聲，當然這也是我每次對外分享不會講重復內容的原因，要對得起聽眾?；氐秸}。

因為最近幫助這家公司啟動數據驅動，我自己也復盤之前的一個判斷不太準確的地方。這里面有組織的問題，也有我的問題。讓我重新審視了這三件事情。

一、啟動數據驅動的時機

我們什么時候啟動數據驅動這樣的工作流程的時機或者說啟動的條件，首先我們要清楚的是在哪里啟動。第一個是高頻的日常工作需要啟動，包括了需求實現流程，運營策略，市場投放策略等。第二個是規劃或者是年度的規劃等中低頻的工作，第三是每個員工的目標和自己的to do list這些也是需要數據驅動的。

下面我們說下啟動數據驅動的時機，如果你是以上的流程都已經有固化的流程且內容清晰，已經將這些內容都抽象為了模板，那么你就可以立即啟動數據驅動這件事兒。注意，為了同步流程固化和什么是一個標準的流程，我這里提供了一個版本供大家參考。

第二種情況是這些流程本身就沒有，或者做的并不是非常標準和清晰明了，那么第一件事兒先把流程走通，并且建立模板，讓大家先熟悉模板內容，以及模板的邏輯。

先以方向或者OKR去做牽引，先不要上數據量化，只做目標和OKR的牽引，說白了你先有目標和OKR定性，不對這些目標做定量，然后再逐步數據化。通常這種情況人員的能力模型當前是有些吃力的。上這么大的強度，又要搞流程和又要搞數據，團隊成員吃不消，那么就會抵觸。每次迭代只做一個目標，團隊也清晰。

總結一下，你如果需求實現流程有了，比如我提供的這種流程，有明確的需求評審，產品內審，等環節，可以做到固化和穩定運行的情況下，那么你就可以直接在流程上推行數據化了。如果沒有先做流程再逐步啟動數據驅動。

1. 產品實行數據化是基礎

首先互聯網公司的業務都是希望通過產品來實施或者逐漸自動化的，控制了產品部門的需求量化，就等于控制了接近半數業務的數據化驅動。其次是產品下游眾多，ROI非常高，他們涉及到產品部自己的產品設計，UI設計，研發和測試，控制了上游的需求，等于一下子提升了下游所有環節的效率?？刂菩枨髮崿F流程核心就是黃色的兩個框，需要控制需求評審和產品內部審核。

其次就是產品部開始審核需求，就可以要求業務方逐步的數據驅動化，當然這是一個逐漸磨合的過程，我知道很多公司的業務方都具備產品思維，也無法從產品角度來講一個需求，這時候就需要產品經理去介入，先去溝通需求，輔助業務方撰寫需求文檔。

所以無論是業務方還是產品經理寫需求文檔，這個環節肯定是不能少的，只不過是誰做的問題，考慮到能力模型一開始啟動這個環節可以先由產品來實施。這個環節的目的有如下幾個方面：

• 明確業務方的需求包括需求背景，用戶人群。
• 明確業務方需求的功能范圍。
• 明確業務方向達到的目標。

第一項為了讓產品經理理解why 或者說業務方的原始訴求， 其中用戶人群是不能不去分析的。這相當于我曾經講過的 segment ，分層行為，你的到底對哪個用戶群體做功。第二項為了劃定邊界，一個功能可以很大也可以很小，最后一個是和業務方達成目標，很多時候業務方不一定明確知道自己的目標。一旦目標明確了就知道是不是有商業價值或者用戶價值。

好的產品經理至少50%的時間應該花在問題發現和需求權衡上，我甚至覺得花80%的時間都不為過。另外20%~50%的精力花在需求實現上。

不好的產品經理80%的時間用在產品需求實現上，可能只有10%花在問題洞察發現和需求權衡上。

因為如果你無法權衡優先級，你要做的內容就會變得特別多，你就有特別多的事情來忙，來做產品設計，你忙，你的下游就都會忙起來，因為一個需求需要下游四個環節去實現。

那么長期團隊就會迷失在這種為了做而做的過程中，不能針對業務目標逐步釋放業務壓力，就會導致業務方和研發方矛盾加劇，業務方認為我現在需求這么多都忙不過來，研發方認為每次都要的很急，做了沒有結果。其實就是沒有把一個需求完整的按照流程去實施，一開始沒有講清楚對業務的影響，上線后沒有數據反饋。長期下去團隊就陷入到這種為了忙而忙的狀態。

正如俞軍老師所說，很多在知乎上問產品經理會不會被淘汰的都是那些只做需求實現的。對于產品來說需求實現是基本功，更難的其實是一個不可見的需求權衡。產品經理最難的是權衡模型。所以找到當前最重要（洞察）最緊急（權衡）才是需要練習了。但是大部分初創公司其實不太注重這塊。業務方也會說：權衡你妹??！趕緊做??！業務這么緊急！而事實上他們自己也不明確到底做到什么程度，到底這個需求對業務哪些方向有提升。

2. 流程的標準有助于管理

流程標準和數據驅動，有四大好處，第一個是數據驅動如圖業務同步的部分，通常公司都會省去，這其實是一個不能省去的環節，當然也不定要業務方來執行也可以來讓產品經理來做，就是一個功能上線了，他的結果怎么樣，有沒有后續的數據變化，這才是一個功能最終上線的閉環。

第二個好處有了這事情，你就能逐步緩解產研和業務方的矛盾，以及逐步提升產品和業務的影響力。因為好的結果會激勵產研團隊，明確他們的工作價值。

第三個好處是可以長期評估需求提出方的業務能力。這也就是說明了為什么需求文檔要細化到具體的需求提出人，我知道很多公司業務方是提不了需求的，或者他們會通過業務老大代提需求，但是這個需求靠譜不靠譜，最終是需求原來提出人的問題，因為需求的來源是需求提出人提出的。如果需求來源都標記業務方老大，就沒有辦法分析和評估長期他們需求提出能力。

All data in aggregate is crap ，segment or die———Google analytics Avinash Kaushik

所有加總數據都是沒有意義的，要么做拆分，還要么就結束。

第四個好處是只有所有的內容白盒化，才能極大地降低新人準入的門檻。新的產品準入后就可以接需求，他可以快速了解到需求的背景，人群，目標進而方便他權衡和設計等等。

3. 我對咨詢服務公司的復盤

最后就我咨詢這家公司我復盤自己的和對方的問題，如果你想把自己的公司數據驅動，也需要做這個check list。當然如果你是CEO，你也需要做這個check list，但是CEO主要職責也是要從怎么干想到讓誰干，然而不是我親自下場怎么干。

我主要的工作就是負責這家公司的組織架構和工作流程做到數據驅動，現在復盤一下之前工作循序上的混亂點。

公司背景部分：

• 公司的業務流程是怎么樣的。
• 公司的組織結構和人員分工是怎么樣的。
• 公司的產品結構是怎么樣的。
• 產品細節流程是怎么樣的，包括核心主要的用戶流程。
• 當前人員工作流程和協同工具是什么。

數據部分：

• 當前是否有已經將業務拆解為相關的指標。
• 流量來源統計追蹤是否已經完成。
• 整體上是否具備數據指標可以獲取的能力，哪些數據指標還是不具備的。
• 當前的數據情況是怎么樣的，后續如何迭代，是否有迭代流程。
• 各個部門同步數據流程和機制是什么樣的。

實施落地部分：

• 如果數據驅動需要組織中哪些人參與。
• 我和這些人如何配合，工作邊界在哪里。
• 當前的組織架構，人員角色支持不支持我去做。
• 當前的工作流程是否需要針對數據驅動優化。
• 組織驅動的實現路徑是怎樣的，大概要經歷幾個階段，每個階段的目標是什么。

如果你是個不懂業務的完全局外人，那么你開始做數據驅動至少需要從這幾個方向去思考，第一部分主要是公司背景，因為我們是把當前的公司做到一個可以數據驅動狀態，你可以抽象的看成從A點（出發點）到B點（最終點），那么了解當前現狀是很重要的。其次就是數據的驅動的部分，就是從數據獲取到分發到組織各個角色是怎么做的。如何去做。第三是實施落地。如何通過杠桿通過驅動幾個關鍵角色把任務鋪下去。

我在實踐中犯下的錯誤：

過分的樂觀估計了干系方的支持力度。

剛開始接手，直接進入到了第六步執行，就是直接拆解業務，把業務拆分成各個指標，當時想有了指標就可以做數據提取。在這個過程中，有產品經理來輔助講解業務流程和產品細節流程，全程都是口頭講述。我拆分完畢后發現三個問題。

第一個問題是這個數據看板沒人實現，因為研發數據人員忙著接需求，第二是由于我的角色是咨詢我也不知道找誰來確認是否是需求方需要的數據指標，第三個問題是很多公司的組織上沒有對應的職位。所以指標也不知道給誰看。

名不正則言不順，言不順則事難成。

我的核心定位還是咨詢，就是定方向和目標，找對應的人來做，以及把控他們做的流程和結果。整體上數據驅動一個系統的事情，需要從需求上游到產品都進行數據驅動，產品的下游主要是執行工作，數據驅動的不那么強。這就涉及到多個業務干系方。

一開始在梳理部門工作時候，一些基礎流程從ROI上來說還是由每個部門的負責人和我對接比較容易推進，但是由于我當時的頭銜沒有確定導致很難驅動他們做事情?；蛘咭恍┕镜牟块T內部由于快速發展，還沒有明確負責人導致這些和我對接的人也很難推動內部。

不知道如何通過提問獲取想要的內容，以及由于分工問題我也不知道找誰去問這些問題。

有一個問題就是我自己不知道如何把這些大的需要我了解的部分，如何快速拆分轉化為問題來對業務方提問。這顯然是一個技術活，而且我還需要讓對方的人員理解我要這些內容的目的是什么，和我讓他們這么做的目的和意義是什么，畢竟他們已經習慣了當前的工作方法。change ，改變習慣通常是非常難的。

過分樂觀評估組織與人員。

最開始的規劃是先逐步搭建數據獲取可視化體系，然后直接推進組織工作數據化，現在發現比較困難，摸底了產品部發現人員沒有目標理解和數據提取洞察能力，甚至需求流程還是比較粗放的。況且按照薪資來說產品相比較市場和運營是相對薪資較高的職位。

如果產品沒有目標驅動感，其他部門很難有目標驅動感。這就使得可能原來一步到位的流程要拆分為兩步，我們屬于沒有建立起工作流程的階段，先讓組織理解自己的事情和目標的關系，先做OKR引導，再逐步數據量化。

合作方的問題：

工作內容信息不支持數據驅動。

很遺憾我去的時候公司是沒有這種人能夠了解到全貌的業務，從工作分工上講也不應該是CEO來給我講，所以不了解組織結構和業務分工的背景，這會導致我變成了《魔獸爭霸》狀態，每走一步，才能看見后面的幾步，每次了解一些情況發現還有后續的情況。當然這樣也有對方的問題就是沒有很好的文檔沉淀。

對方的組織架構還不支持數據驅動。

從組織和角色上還偏向于傳統軟件開發公司，其次就是各個部門缺少負責人，當然我從推進上來說，效率上也不太可能我直接推動各個部門的人，所以需要完善組織結構，人員決策，以及負責人。

流程環境不支持數據驅動。

沒有一個數據支撐團隊可以持續的將業務方的數據提取需求轉化為數據看板。因為數據提取是一件系統的工程，所以他需要團隊長期賦能，當然你開始的時候可以頭疼醫頭腳疼醫腳，但是如果你是一個數據驅動的業務，早點考慮系統的數據搭建，持續的降低數據獲取成本總是好事情。

人員模型也不支持數據驅動。

目前摸底了一下產品部門，整體上還是以做事情為導向，就是為了做而做，還不具備說能說清做的事情對于業務和目標的影響。更不要說找各種影響進行數據化的量化分析。并且相關的工作流程還不標準。以及沒有這種意識，好在團隊中總會有一兩個人有這種意識，只要有意識的人能做出樣板來，模仿對于這些人是容易的，但是從0到1自己摸索是困難的。

二、如何培養團隊的數據思維

首先我覺得任何一家公司當前能招聘到的人才，就是當前能招聘到的最好的人才，我覺得當前服務的這家公司產品負責人打的比方是非常貼切的。

當前我們還沒有一個體系去持續賦能業務提供數據，缺少工作流程和一些組織角色。打個比方就是餐館沒有很好的炊具，高端的刀具，也沒有高端大廚習慣的烹飪流程等等。

這時候你找一個高端廚師來了，我們可以把一切的雇傭關系比作交易，這時候高端廚師來了他想獲得什么，一定是說鍛煉自己的專業廚藝，你讓他來了先買炊具和磨刀，這時候一旦餐廳垮了，他這些經驗是沒法在新公司用的，因為大的餐廳是提供良好的烹飪環境的，廚師只需要花精力做飯。

所以不要在特別小的時候找一些特別高端的人，無法匹配。因為他來了也發揮不出來，你在搭建烹飪環境，他要求好好鍛煉廚藝。讀者們不要拿蔡崇信來反駁我，況且咱們也不是馬云。正如我自我介紹說的那樣，以概率論來解釋這個世界，馬云是小概率事件。

第二是好的人才很容易被其他offer吸引走，我本人曾經在一家400人左右規模的公司工作，那個時候你招人也不好招，你發出去的offer，一線大廠一個offer人就被節流了。

我現在在大廠是一樣的，我始終想表達的就是一點，你招聘到的人就是你當前能招聘到的最好的人，大廠一樣有困擾，我們每次發offer都害怕阿里和騰訊以及字節跳動發offer，只有抖音，Tik Tok ，微信等產品他們不太害怕自己發出去的offer會沒有人接。

第三我當時在的互金公司工作的同事最后都找到了快手，攜程，京東，百度等工作，還有人做了O2O業務的產品總監。所以我現在的反思就是到底是這些人不行，還是公司不行， 同樣一批人為啥都去了更好的公司，證明他們是沒有問題的，可以培養成為大廠的骨干。

那么當時為啥領導對他們都不滿意呢，我認為還是公司不行，公司沒有培養人的環境，人只要過了某個閾值以后，其實很大程度上能力受到公司環境的影響。當然人的基本素質要突破一個閾值。

總結一下企業招聘人員不要妄圖招聘到一個特別厲害的人，從交易的角度上來說這種人你得支付遠高于市場價才能來，你支付多個30%，考慮到項目失敗風險等隱性成本，他是不會來的。你只有讓業務走到下個層級，獲得下個層級的影響力，你就可以招聘到下個層級可以吸收的人才。

這讓我想起松下幸之助的一句話，松下最重要的工作是育人。因為任何業務都是人做的，要對人培養好人，業務自然的走到下個環節，就會有更好的人才涌現，況且大部分情況，人員的發展速度是快過公司的。這也解釋了為啥我們互金公司產品人員都去大的公司。

額外的分享一些人員成長的看法，我之前非常不喜歡公司里面一個領導，因為他毫無原則的保護組內的人，我認為毫無原則的袒護是一種對于組內人員的溺愛。當然這是管理理念的不同。但是一次他的行為讓我對他改善了很多，就是他組織自己部門的人學習。

要知道一般的公司不會對公司人員的成長花費成本的。這種成長培養是一種長期投入，太多的公司覺得劃不來，他們只是把員工作為一種耗材。但是如果你所在的公司，他們還愿意培養你，那么證明你所在的公司為你的長遠至少有打算，你應該感謝它們，因為這樣的公司真心不多。

通常人員的成長，最基礎的是業務增速，這只是基礎。但是人員能不能隨著業務長起來，要看他的成長速度。成長速度第一奧義是動機，第二奧義是方法。動機就包含了你想成為什么樣的職場人，你想針對業務做怎樣的變化。而方法就是你要有很好的思維模型。

你大概知道一個事情比較專業的做法是怎么樣的。所以大量的工作量是一個人成長的必要條件。而不是充要條件。他需要閱讀到專業的方法論，用專業方式來做事情，其次在實踐過程中，消化吸收，不斷思考。所以俞軍說閱讀，思考，實踐，三者最低的環節確定了你的上限。

我最近咨詢的兩家公司都出現了人員非常忙，但是他們都沒有什么提高的情況。就是他們反復的在低等的維度訓練，關鍵的是他們不知道什么是更高的維度，不知道自己不知道，這個才是可怕的。有興趣的可以讀我的另外一個文章：掌握更好的思維模型，在職場脫穎而出

比如一個產品經理，一開始只是實現需求好似沒有問題的，但是如果持續的只是做實現需求就會沒價值。他做的事情就算堆滿了他也沒有價值。

因為更加有價值的事情是權衡需求的優先級，知道哪些先做，哪些后做，在這之后就是做需求規劃，知道未來要做什么，在規劃的基礎上就是做落地，知道一個規劃如何實施。這就需要一個產品經理不斷地提升自己的工作難度和復雜度。

同理可以說明一切行業，如果一個產品經理只是反復做需求，完成基本的需求實現，他是沒有成長的。有時候特別忙，沒有方法并不是好事兒。

需要說明的一點，這里的閱讀畢竟不是看書，而是指一起獲得專業方法，提升思維模型的渠道，與高手聊天也是可以的，但是有一些人沒有這樣的資源。比如俞軍老師曾經說高階大佬為什么成長快，就是因為他可以和各行各業的高手溝通學習，他自然成長快。但是低階小弟不是有這個樣的機會，他們沒有機會和高手聊天，但是可以和高手寫的書學習。

三、針對KPI的一些看法

在一個工作流程和組織結構不具備數據驅動的時候，是無法直接通過KPI去驅動的。比如沒有數據看板，沒有持續獲取數據的流程，那么就沒法監控過程，如果過程做得不好不可控，那么結果怎么可能是可控的。你通過指標驅動就沒有意義，因為你只能下發指標，你沒法通過數據去優化指標。

在工作流程穩定數據驅動的情況下，具備一定的數據體量，可以進行指標的測算，因為太小的數據量預估會不太準確。KPI的目標沒有太大意義。如果數據量是可以進行預估的，那么就涉及到KPI的分配方法問題了。

首先我要說下以KPI 驅動是沒有問題的，但是不要依靠KPI驅動要注意幾個點，因為未來的目標達成具備一定的不確定和不可預估度。指標化會導致為了達到指標的動作變形。就拿我之前寫的文章來講這個事情，一個咖啡館他預估了自己下個季度的GMV，那么他怎么確定這個GMV是合理的，他沒辦法確定。

但是這會導致人員過度運營，比如我去喝咖啡的時候，他不管我的需求，只會給我推薦價格高的產品。這樣有助于他完成KPI，這種短期對KPI的達成，長期是傷害業務的。

這里有一種辦法就是facebook 使用的50%機制，就是大家都可以提報KPI，每個業務，每個季度，或者半年評估一下，就是看你的指標你完成或者沒有完成，無論完成或者沒有完成都沒有關系，但是長期看你的指標應該是一半情況下是完成的，一半情況沒有完成， 如果你的指標總是完成證明你定的KPI低了。

還有一種KPI的背負方法就是看置信度，因為業務大部分是有自然增長的部分，所以提升delta值有置信度，比如提升10%他的置信度，和提升80%他的置信度是不一樣的?？梢詫Σ煌闹眯哦鹊臉I績分批次激勵。