相信大家做產品到一定經驗之後，很多時候都會依據自己的經驗去設計產品，可能經驗已經被過往的產品驗證過了，所以在設計新產品的時候沒有多加考慮。進入大資料時代後，我發現這一經驗法則不再適用，很多場景下，過往的經驗只會讓產品變差，可以說這是因為沒有與時俱進，但從務實的角度看，卻是沒有在根本上從使用者角度出發。問大家乙個問題，當你的經驗與產品的資料反饋相違背的時候，你會選擇相信哪個?
現在產品的發展思路中，資料基礎的建設越來越受重視，這和大資料的概念和資料營銷的方法離不開，這幾年對資料的應用使越來越多的人開始相信「資料會說話」，拍腦袋的決策減少了很多。對於產品經理來說，原先就要做很多分析：市場分析、競品分析、需求分析等，現在只是多加了乙個「資料分析」，這些「分析」的手段雖然不一樣，但目的都是相同的，因此接收起來應該沒難度，只不過被包了一層「大資料」的外衣，不知道是什麼東西了。概念永遠只是概念，落到實處的做法才是我們真正需要關心的。就像「雲計算」概念，各種「雲」，弄的很玄乎，實際上是虛擬機器、網路硬碟等技術的變種。
有了資料之後，如何應用又是乙個問題。讓資料躺在那裡睡大覺是發揮不了效用的，要結合工作實際需要去針對性的分析，在《電商平台商家改價行為的資料分析實踐》中我也提到，一定要帶著目的去分析資料。分析的結果可能與你原來的經驗相符，也有可能相反，就我自己目前遇到的幾個場景，來說一下資料的威力在哪，它是如何改變過往產品經驗的。
場景一：合併支付的功能
做過電子商務的朋友應該都對這個功能有了解，就是未支付的訂單可以合在一起一筆支付掉，支付成功後，合併的每個訂單的支付狀態都會更新。最早見於**，因其支付寶可以支援這樣的業務功能，之後別的支付方式也逐漸開始支援這個功能，合併支付在電商**上就逐漸都有了。合併支付有乙個數量上的限制，就是一次可以合併支付多少個訂單。拍腦袋的想肯定是越多越好，最好是無限制，但這個功能有一定的技術侷限性，無法支援很多訂單同時支付。
這個場景所遇到的就是這個問題，產品端設計時把數量閥值設為20單，從過往經驗來看，使用者分別去下20個訂單，然後再去合併支付的可能性非常小，從使用者的購物習慣來分析，要買很多東西的話盡量會下在乙個訂單內，就像去超市購物會一車推出來一起結算，這個從自營電商的角度看，基本上就是這樣的。從平台電商的角度看，每個商家的發貨、物流體系不同，一次下單可能會生成多個店鋪的訂單，但數量能超過20個店鋪的比例應該也非常小。但就是這個閥值出了問題。
某次**，收到很多使用者反饋無法完成支付，提示訂單數量不能超過20.說實話當時是很驚奇的，拉了一下資料發現，**期間支付請求訂單數超過20的有5000多次，涉及到15000多個訂單，排除掉重複請求的因素，每次請求的平均訂單數是30單，大大超過了我們所設定的閥值。針對這個問題，我們拉了一下平常的資料，發現支付請求訂單數超過20的平均每天有600多次，假設以客單價100元來計算，每天大概影響了600*20*100=120萬的銷售額，看到這個資料真是汗滴滴啊，乙個閥值影響了這麼多錢，可能平時反饋的不多，被忽略掉了，**的時候集中爆發了。
當然這裡面肯定有原因存在，事後的原因分析這裡不做詳細介紹，但產品設計時沒有設計好是有責任的，解決方案就兩種：一種是調高這個閥值;一種是在下單支付流程上就限制住，不讓使用者一口氣下20單以上或同時選擇20單以上進行支付，具體採用哪個方案，取決於技術的支援和其他因素的綜合考慮。
場景二：支付成功後取消訂單
取消訂單的功能相信大家都了解，在網上買過東西的人都知道，在對方發貨之前是可以取消訂單的。對於未支付的訂單取消，因沒有產生任何交易，是沒有問題的，但是已經支付的訂單取消，就需要考慮取消的時機了。首先發貨後肯定不能取消，貨物在途不好追償;其次如果是定製類的商品，支付成功後可能商家已經開始定貨了，要取消的話就需要商家確認。這裡要分享的場景就是後面一種，需要商家同意才能取消的訂單。
從產品角度來看，取消訂單是乙個很好的收集反饋的入口，可以設定有針對性的原因讓使用者去選擇，從而收集回來改進產品。我們根據產品的訴求和一些目的，設定了7個初始化的原因，而一般在設定原因的時候，因為沒法囊括所有的情況，都會設定乙個「其他」的選項。而最後收集回來的資料發現7成左右都集中這個選項上，如果根據經驗去看這份資料，就失去了意義。但這是很奇怪的乙個現象，難道真是我們所設定的初始化原因沒有戳到使用者取消訂單的痛點麼?乙個原因沒有戳中也就算了，總共有7個原因，不可能都沒有命中的。
通過資料分析我們發現，使用者第一次提交取消訂單請求的時候，「其他」選項的佔比才2成都不到，而商家處理結束後，「其他」選項的佔比卻上公升到7成，剩餘的3成大部分還是因為超時未處理而取消掉的。這說明了乙個問題，那就是使用者修改過取消訂單的原因，從資料日誌記錄上看也印證了有修改。也就是說我們原先設定的原因基本上還是命中了的，如果就採用最終收集的佔比資料去看這個過程，那就沒有任何意義了。
至於為什麼會導致使用者去修改原因，這裡不做詳細說明。最終的結論是，我們只能參考日誌資料中使用者第一次提交的原因資料。
通過這兩個場景的舉例，可以看到有些時候依據經驗辦事已經不靠譜了，需要透過現象，去看背後資料反饋出來的本質，產品經理要站在更高的角度去看待產品設計，脫離原來經驗的束縛。但這並不是說資料是萬能的，我只贊同資料可以提供很好的參考，提供決策的依據，但資料不是全部，很多時候還是要靠產品經理去判斷產品的發展趨勢，過往經驗也能提供很好的參考。只不過經驗從「遵循」變成了「參考」，資料也是「參考」，這樣能讓產品經理更客觀的去做決策。
優秀的無線AP產品，改變你的工作感受
曾經因為無線ap的訊號覆蓋問題讓本人感到了來自這個世界的深深惡意。本人的工作是個某公司的網路管理人員，說起來現在網際網路行業發展這麼快，可到了我公司這種傳統行業上的公司來說，所有的網路問題就落到了我乙個人身上，什麼和網路沾邊的都得我來負責。其實就單單從網路上來說，也沒多大問題。可當公司的無線接入點出...
你所做的產品，並不是資料產品
前一階段，木東居士分享了乙個案例，個人認為很有代表性，這裡簡略敘述一下，作為問題的起點 一位朋友從運營晉公升為管理層，開始帶團隊，因為朋友本身是運營出身的，所以對於業務的訴求，非常了解，但團隊成員大多是技術出身，總是get不到業務需求的點，容易陷入到技術的追求中不可自拔。其實這個問題並不是乙個孤立的...
改變你做事的步伐
同事小勤摘錄的一篇文章 如何讓工作富有創造性 很好，我也去搜尋了，找到的鏈結在 這裡 改變你做事的步伐。作者提出了 轉換速度 這個詞，我覺得很有針對性。我發現包括自己在內的好些人，之所以有做事拖拉的毛病，都是因為對自己做一件事的速度 所耗的時間 缺乏要求，總是習慣按照既有的速度慢慢去做，而不能主動提...