產品經理最花時間的2件事:異常邏輯梳理與數據處理

6 評論 11105 瀏覽 497 收藏 6 分鐘

?產品設計中,每一個步驟都不簡單。其中異常邏輯梳理、數據處理可能是產品經理們最需要花時間的兩件事,也是最耗費精力的兩件事。雖然很花時間,但每一秒認真投入其中的時間,將來都會10倍的回報你。事先沒有想清楚的,最后一定會報復你的。

冰山:異常邏輯梳理

1 冰山

也許你用了九牛二虎之力,終于把產品的主流程梳理清楚了,但是你看到的只是產品冰山海面上的那10%,剩下的90%是海面下各種情況的異常邏輯。

? 10%的冰山和90%的冰山

任何一個產品功能邏輯,都分為主邏輯和異常邏輯。產品經理們當然要花時間設計精妙的產品主邏輯,構建體驗良好的用戶使用流程,甚至考慮一個完整的用戶閉環。露出水面上10%的冰山,也許會讓你心醉;但水面以下90%的冰山,也許會讓你心碎??墒菦]辦法呢,產品經理也需要把主邏輯之外的復雜異常邏輯“盡量”梳理清楚。

? 常見的異常邏輯大禮包

常見的異常邏輯有網絡錯誤、新舊功能沖突、任務中斷、因延遲導致前端頁面與后臺邏輯不匹配等。Glen這里幫大家做了簡單的總結:

Snip20160405_1

上面簡單總結了一些異常邏輯,現實產品設計中遇到的各種異常邏輯遠不止這么少。做產品就像完成一件藝術品一樣,需要慢慢磨,耐心雕琢。

數據處理

很多童鞋在產品設計時,往往會忽略數據處理的重要性,往往最后會吃大虧。對的,Glen就吃過這個虧,然后被十倍報復了……

? 產品設計的每一個關鍵步驟都需要數據支持

大部分人,喜歡有創造性的工作,產品經理尤其如此。我們喜歡設計產品的界面、流程、閉環,有時候往往會忽略數據埋點的重要性。產品設計完成后,再返回去給每一個按鈕、每一個頁面、每一個關鍵位置標注數據埋點時,我們常常會覺得無聊,因而不重視,因而最后被坑的總是自己。產品設計的每一個關鍵步驟都需要數據支持,你必須在這些關鍵節點上做好數據統計埋點。產品上線之后有數據反饋,才能評估產品的品質。切記!

? 無處不在的漏斗

做任何一個產品,都能搭建各種漏斗模型,因為流失和損耗是不可避免的。產品體驗理論上可以由幾個基礎漏斗模型體現:前端用戶流程的漏斗模型后臺實現的漏斗模型、服務器交互的漏斗模型。他們中的每一個又可細分出N個小漏斗模型,可以細化到對應的關鍵數據指標,比如點擊轉化率、支付轉化率等。產品經理們,每天都需要關注這些關鍵的數據指標,更需要不斷完善各種漏斗模型:老的產品需要翻新、新的產品需要建立。

? 數據規范

幾乎所有的公司都知道數據的重要性,然而很多公司并沒有做好,原因很可能是沒有一個統一的數據埋點規范。只有統一化、標準化才能夠被良好的管理,不然依然是大道理懂了很多,卻依然過不好這一生。很有必要統一一套數據規范,例如:業務-渠道-平臺-功能-描述,然后在所有的產品上都按規范進行數據埋點,統一的數據平臺就這樣被建立起來了。當然統一也有弊端,就是限制了個性化,比如你想跟蹤不同的產品版本,如果還是走統一的數據埋點,那會導致兩個結果:要么你不敢放量,產品改進后看不出明顯的數據反饋;要么你膽兒肥放了很大的用戶量,但這樣你要承擔非常大的改動風險。

這里Glen推薦你一個方法,在規范的數據統計點的后面,再通過頁面或者客戶端給你增加一個版本段位 Version XXX,然后把版本數據這部分單獨上報到另一個地方。(如果你有更好的辦法,請告訴我,蟹蟹)

#專欄作家#

幽默、認真的產品經理Glen,微信公眾號:jiglen,人人都是產品經理專欄作家,華為、歡聚、迅雷工作經歷,有緣看到這篇文章,交個朋友吧。愛看書、喜歡碼字、愿意走出去看世界。不喜歡嚴肅、高冷的氛圍,喜歡在幽默中完成任務,力圖成為史上最幽默產品經理,歡迎交流。

本文原創發布于人人都是產品經理,未經許可,不得轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 學習了, ??

    來自廣東 回復
  2. 學習了。

    來自浙江 回復
  3. 對于PM來說對異常情況的處理需要先了解項目代碼么?

    來自浙江 回復
  4. 初來乍到,隨便一問。
    很多PM覺得異常邏輯處理和校驗應該是測試的責任。
    如果PM在設計需求的時候可以考慮到這么細致,他一定熟讀自己項目的代碼。
    例如:登錄狀態不匹配并不是一個通用的異常。哪些功能會遇到,哪些不會遇到,這個超出大部分PM的能力范疇了吧

    來自北京 回復
    1. 跟代碼有啥關系,異常邏輯處理是業務場景的異常邏輯,而不是代碼邏輯。
      打個比方:登錄失敗之后,需要顯示那些字,顯示在什么位置,是彈框還是浮動提示,浮動過幾秒消失,都是異常業務處理邏輯

      來自北京 回復
    2. 登錄失敗哪里是異常邏輯……那是包含在正常的登錄邏輯里的。
      你做登錄模塊,自然首先要分登錄成功和登錄失敗。
      你看樓主的舉例,指的是非自己所負責范圍內的異常問題。

      來自北京 回復