閉環 | 從需求到數據到改進,在產品上精益求精
互聯網的產品相對傳統IT產業而言,需求更富有多樣性。傳統IT行業的需求點多是固定且符合驗收條件。但互聯網的產品則更多的從用戶體驗出發,更多的用數據來說話,不管是PV、UV、轉化率、留存等等。很顯然在一個接著一個的迭代背后,我們必須要讓需求到數據到改進實現閉環,才能在產品上精益求精。
今天就來探討下如何從項目經理的角度出發,將這些環節形成閉環,更好的為產品精益求精服務。
對于“需求—數據—改進”的閉環,可分解為以下三點:
- 產品功能交互設計之初,明確方向,設定指標(KPI)
- 產品開發過程做好埋點,確認數據來源,獲取數據
- 分析數據,并反饋到產品功能交互設計
下面,分別展開每一點在項目中我們應該如何去做。此處只是從項目經理的角度出發,講講我們在項目開展中可以關注的環節,對于數據驅動創新等更專業的內容建議大家閱讀《精益數據分析》。
功能設計之初,制定指標
產品的孵化和各功能模塊的設計在最初的時候都有一個初衷,去解決用戶的痛點。從產品初衷到產品形態,如何去衡量我們做的每一個功能用戶是買賬的。在最初始階段,我們就需要設定指標來衡量,而其中數據指標是最為量化和直觀的。但在這個過程中,不能僅僅就提出數據指標,更要明確定義每個指標的具體意義以及計算方式。
舉個例子,比如想用每日活躍用戶的數量來衡量app的受歡迎程度。初一看覺得這樣的指標很合理,但其實是不夠的,因為沒有對活躍用戶做一個定義,不同的定義會極大的影響我們的判斷。所以我們必須做到精確定義,排除可能造成干擾的其他因素。
每個指標的背后,都應該為產品的方向和目標服務。比如一個即時通訊的工具,那么用戶之間的消息量、好友數也許是我們衡量這個產品健康度的指標,因為這兩個指標和我們的核心功能切合。
通常來說,在產品設計之初,產品經理和策劃就應該根據自己對產品的思考整理出核心指標。核心指標也并不是不變的,在產品MVP驗證探索階段,也許產品的方向都可能發生變化,此時核心指標也會發生相應的轉變。
在定義好核心的指標之后,我們應該針對這樣的指標讓整個團隊達成共識。這樣的方式可以采取多次的頭腦風暴,以及討論會。在這樣的過程中,其實大家可以更加深入的去挖掘。參與人員包含運營市場產品設計以及開發測試,只有大家共同理解目標,在每個工作環節才能集中精力為這樣的目標去努力奮斗。同時這樣的一個過程也建立大家對產品的一種主人翁意識。
鋪平數據來源之路
對于數據指標達成一致意見之后,那又如何常規的獲取數據呢?
在產品研發過程中,對于數據獲取的途徑一并考慮,則可以節約很多后期跑取數據的繁復過程。比如數據埋點的接入,核心KPI系統的搭建。都是用來呈現常規數據的手段,隨用隨查,而無需再讓開發人員去跑取。
在我們日常產品中,通常數據的來源有三處,一個是服務器數據庫數據,二是日志數據,三是埋點后收集的數據。服務器的數據和日志的數據相對來說比較精準,但很難做用戶使用路徑的分析。而埋點數據,由于受第三方數據分析系統的上傳策略限制,在精確性上存在一定的折損,通常用來做用戶路徑的分析,數據對比,以及日常觀測。
對于埋點,會涉及到埋點事件,以及埋點事件的屬性和標簽,結合數據分析平臺。產品策劃同樣需要在產品設計過程中,理清楚埋點的需求,提交給開發。而埋點的需求通常會結合分析用戶行為、各維度數據呈現的要求。同樣埋點需求文檔也是需要在產品迭代中不斷的維護更新。因此,也建議大家將埋點需求文檔和需求管理結合起來。在整體的開發流程中,關注埋點需求的落實和驗證。
所謂工欲善其事必先利其器,想讓數據驅動,那么這些工作的完備開展會極大的幫助大家的日常工作。
數據指標帶來的反饋
有了數據,我們又應該如何去對待數據從而帶來正向的反饋呢?
對于團隊
數據指標應該定期的反饋給團隊,做到數據信息透明。這個有很多的方式,比如例行的數據周報發送,數據平臺的權限開放。另外,也需要培養和調動大家對數據的敏感性。我們以前一直在談如何提高成員的ownership感,而我認為,讓大家更透明的了解自己正在為之奮斗的產品的狀況則是非常重要的一點。核心數據指標較為健康,整體向上的趨勢,對團隊來說無疑是最好的激勵。而當數據下滑或者出現異常,也便于整個團隊提高危機感,從而共同審視當前的工作,是否可以為了數據上揚而做些力所能及的事情。
對于產品運營
上面講了那么多,其實最終還是要為產品和運營服務。那么最后一環我們應該怎么做,才能真正的達到閉環,讓數據真正的被利用起來呢。配合相應案例,希望對大家能有所思考。
(1)案例一:預警和產品、運營的優化
數據的異常變動,可能提示著某個異常,舉個例子:某產品在頁面上端做了黃條的消息提示,用來做日常信息通知等。但在一次版本改版中,為了便于區分不同的信息類型,新增了灰條。數據后臺則會發現,頂端消息通知的點擊率大幅度的下降,灰色相對黃色,醒目程度大打折扣。后續產品做了緊急調整,棄用灰條。
又比如用戶流失預警系統,下圖則是某產品流失預警中的某個表格。很顯然,通過這個表格,則可以明顯的發現有一部分用戶流失概率較高。從而可以抽取這部分用戶,對這部分的用戶做一些特征的挖掘,或者直接通過電話訪問等方式來調查用戶流失的原因。從而使得產品在這些方面得到反省和優化。當然,也可以針對高流失概率的用戶做一些運營活動的召回。
(2)案例二:驗證設想, A/B test
這里舉個栗子,某產品需要獲取用戶的GPS信息,便于補充用戶畫像的數據。但由于手機系統權限的設計,獲取GPS信息會在app啟動初始彈窗詢問用戶是否允許。在這樣的情況下,產品猜測會有對新用戶的注冊轉化率有一定的影響。于是,挑取兩個小眾化的渠道來做測試,只針對這兩個渠道下載包的用戶做了GPS信息的收集。最終發現注冊轉化率的數據上和之前對比沒有異常和波動。得到這個結論后,則可以大膽的將此功能開放到全局平臺。
又如:在某產品的某個頁面中,對于商品的展示方式如何能帶來更高的點擊率,設計了兩個模式。因此需要對這兩種方案設計A/B test。如下圖所示,就是A/B test的數據對比,很顯然,下圖中的D版本明顯點擊優于其他版本。最終則考慮所有的頁面全部切到D方案。
綜上幾個案例,我相信大家肯定可以看到數據在產品和運營中的這種反饋作用。而這個過程更多的需要產品策劃和運營具有一定的數據驅動意識,在這個方向上的精進,無疑對工作會帶來很大的益處。
最后的最后
以上,是筆者在日常項目管理過程中,對于需求—數據—改進閉環形成的看法。對于數據創新驅動業務等課題,已經有很多專業性的文章和書籍做了研究,但筆者想表達的是,在日常工作中,我們關注點點滴滴,踏實做好每一步才是最重要的。
作者:周巧芬,網易杭研項目管理部,CSM、PMP認證,對於傳統軟件開發項目管理和互聯網行業敏捷轉型均有涉獵,目前在易信擔任項目經理,負責整體項目管理工作,專注于大型團隊高效合作、版本交付及流程優化。《網易一千零一夜》編輯團隊之一。
本文由 @網易杭研項目管理(微信公眾號:NetEasePM) 原創發布于人都是產品經理。未經許可,禁止轉載。
挺好的,數據導向,提前埋點,研發的連貫性
看完了,支持作者觀點
??
我們關注點點滴滴,踏實做好每一步才是最重要的。
??