編輯導語：本篇文章從産品規劃、産品設計和整合資源這三個模塊來進行分析和講述，這三個模塊能夠幫助我們更好地搭建一款使用戶滿意的産品并加深對産品搭建的認識，推薦想要了解如何搭建優秀産品的群體閱讀。

周末參加了一場分享，我基于之前自己2年半的BI産品建設經驗，分享了如何從0-1搭建産品的完整路徑，并将其轉化為文字稿。

整個内容從産品規劃、産品設計和整合資源三個模塊來講。産品規劃，是要讓我們做一個定位正确的産品；産品設計，講究的是一個正确的過程；而整合資源呢，則是是要有合适的人和正确的文化。

一、産品規劃——做正确的産品

1. 了解業務背景确定産品的定位

要做一款正确的産品，首先我們需要知道什麼是正确的、好的産品。

一個好産品，應該有三個屬性：有效用、有利潤和可持續。

所謂的有效用指的是對于用戶主觀感受上來說，這個産品是有價值的；有利潤指的是，對于我們的商業主體來講産品是有利可圖的，這裡的有利可圖可以是直接獲得收益也可以是成本的降低，而可持續呢，講的是說我們的有效用和有利潤一定是一個可持續的過程，而不是一個一錘子的買賣；最後我們基于這三個屬性就能做出一個貼合市場需求的産品。

剛剛講到什麼是一個好産品，那麼我們接下來就看如何去做一個正确的産品。

要去做一個正确的産品，我們要從兩個步驟去做。首先，我們要了解業務背景，确定我們産品的定位，第二，就是我們要從MVP入手去進行産品的建設。

在去進行産品的背景了解和定位确定時，我們先要弄清楚四個問題：

我們為什麼要做這個産品？

這決定了我們的戰略定位用戶價值和企業價值是什麼。我們去做一個産品一定是有價值才會去做，而不是說老闆讓我們做，所以我們要做。

我們解決的誰的什麼問題？

這決定了我們的用戶屬性、用戶規模，以及我們最終需要解決用戶什麼問題。

用戶當前是怎麼去解決這些問題的？

這決定我們在建設産品時需要考慮用戶的替換成本。說到替換成本呢，我們就要說到另外一個經濟學概念，叫做“厭惡損失”。

所謂的厭惡損失，指的是當人們面臨同樣數量的收益和損失時，認為損失是更難以接受的。而我們的用戶價值=新體驗-舊體驗-替換成本，所以替換成本越高，我們就會認為損失也越大，那麼最終用戶感受到的用戶價值就會越低。所以替換成本是一個不得不考慮的問題。

我們如何占領潛在用戶的心智去超越競争對手？

這就到了我們的終極問題，我們的定位以及如何去占領用戶的心智。隻有我們的定位是準确的，才可能去占據用戶的心智。但究竟如何占領用戶的心智呢，市面上有一本非常有名的暢銷書叫做《定位》，書中說“人類是排斥信息的，人類的心智不僅排斥與現有的知識或經驗不符合的信息，他也沒有知識或者經驗來處理這些信息”。

所以如果新的産品想要進入用戶的大腦，我們就需要和原有的替代産品去建立聯系，與已經在潛在客戶的心智中存在的品牌去建立關聯，用戶才會去接受你，你才可能去占據用戶的心智。

舉個簡單大家又容易理解的例子，為什麼情侶吵架的時候總是覺得對方很不講理，總是沒辦法說服對方？

因為每個人不僅排斥信息，而且每個人的知識和經驗體系是不一樣的，你要去說服他，你首先要了解他已有的知識體系，你說服他的内容需要與他已有的知識體系去産生聯系，他才可能跟你産生情感上的共鳴，所以我們講産品經理為什麼要有同理心，其實也是一樣的道理。

接下來，我們以一個BI的産品的實際案例來看一下我們是怎麼去了解業務的背景，并去确定我們的産品定位的。

首先我們去進行了大量的調研訪談，大量的數據分析，我們發現業務在數據上的使用場景，主要為看數據、分析數據以及問題的追蹤。而他們當前已有的解決方案呢，主要是人工取數和Excel的線下分析。

在這個過程中面臨的問題一方面是依賴于排期的人工取數的效率很低，另一方面則是Excel隻能承載106萬行的數據，而我們的用戶最大需要500萬行的數據來進行分析，這時候Excel是沒辦法去完成的，所以現有的解決方案在效率和性能上都提出了挑戰。總結起來可以有如下幾點：

• 數據獲取周期長
• 缺少自助化的分析工具
• 不知道從哪裡獲取數據
• 不知道有什麼數據

其實說到這幾個點，我相信很多同學所在的公司都面臨同樣的問題，尤其是第三點和第四點，簡直就是業務同學共同的難題，大家基本都經曆過不知道有什麼數據，不知道從哪裡獲取數據的尴尬時刻。

那麼我們了解到了業務背景，接下來我們就可以去對我們的目标用戶進行畫像分析了。我們在分析的過程中發現，我們的服務對象主要有數據開發人員、分析師和業務人員。數據開發人員，他們的特點是技術指數特别的高，而數據分析師，他們的特點是分析思維指數很高，而業務人員他們的特點是他們對業務的理解更加深入。

基于這樣的一個背景，最終确定了我們産品的定位是：一個面向我們全集團的大數據報表和自助分析平台。一方面我們要提供可視化的報表的能力，另外一方面我們要提供自助分析的服務能力，我們希望通過提供這兩方面的能力，幫助我們的業務人員快速通過數據進行決策，打造我們集團數據驅動的文化，助力人人都是數據分析師文化的打造。

到這裡了，我們就确定了我們的産品的定位。确定産品定位之後，我們的第二步就是從MVP入手去進行産品的建設了。

2. 從MVP入手

首先什麼是MVP，我們都知道MVP是最小可行性産品。但到底什麼是最小可行性産品呢，我們來看一個網上的例子。

我們的終極目标是去生産一款能夠幫助用戶舒适快捷的到達目的地的小汽車，那麼什麼才是我們的MVP産品呢？當大家看到前兩幅圖的時候可能會覺得第二幅圖的一個圖就是我們的MVP産品，但是當你看到第三幅圖的時候，你才會發現，其實這裡的第一個才是真正的MVP産品，因為他才真正是最終目标小汽車的雛形，并且他是一個能夠真正跑得起來能解決用戶問題的一個産品。

而第二幅圖的第一個車有什麼問題，第一，不是小汽車的雛形，意味着未來我們的産品還要重構；第二，他跑不起來，解決不了用戶的任何問題。

所以所謂的最小可行性産品他一定是簡單直接、切中要害，直指用戶痛點，并且他要為用戶輸出核心的可以依賴的确定性的服務的一個産品。

我們知道了什麼是MVP産品，那麼接下來我們就要去看如何去設計我們的MVP産品。在進行MVP産品建設時，首先我們要做的是去提煉用戶故事。提煉用戶故事主要包括三個步驟：

第一，确定我們的典型的目标。

第二，針對這些典型的目标用戶，我們要構建特征鮮明的一個畫像。 什麼是特征鮮明，特征鮮明就是你所構建的畫像是貼合當前産品的場景的，而不是說隻要講到用戶畫像就是性别、年齡等等。

第三，我們要去明确用戶的痛點和需求，對他們的痛點和需求有一個完整的場景的定義。

最終基于這三個步驟，我們就能夠提煉出一個完整的有代表性的用戶故事。

接下來我們來看一個例子我們當時是怎麼去找到我們的MVP用戶并提煉出我們的用戶故事的。

首先我們要找到我們的MVP用戶，要找到他們其實是有一些判斷标準的。首先痛點非常迫切，所以願意與項目組共建，去花時間精力嘗試不完美不成熟的産品。第二個呢，就是态度上，他能夠積極地給予你一些反饋。

那我們能夠如何去找到我們的MVP用戶呢？這裡有兩個點，第一我們可以基于數據。比如說，以我的産品為例，我可以去看數據，哪些業務的需求特别多，解決的時間又特别長，哪些同學專門去負責接需求，又疲于奔命的。那這些用戶就一定是我的目标用戶了；第二個點可能會有一些虛，我們可以多交朋友，多聊天多去觀察多去思考找到我們的業務痛點和機會。

我們來看一下當時我們找到的一個MVP用戶的情況。他們當時情況，第一業務現狀非常的糟糕，包括數據人員少，等待需求響應時間長，數據獲取慢，不知道去哪裡獲取數據。第二，他們數據建設非常的不成熟，數據不足以支撐業務，同時所有報表都依賴定制化開發，缺少研發人員，無人響應需求，報表需求積壓嚴重，需求響應時間長達半年。

基于這樣的一個現狀用戶自然很痛，用戶的改變意願是非常的強烈的，他們非常希望能夠提高報表建設的效率，希望能夠擺脫數據需求的這種等待。

這樣我們的用戶故事基于我們的MVP用戶就提煉出來了。我們的第一個用戶故事，其實在我們提煉的時候，出現了一些偏差。本來我們的用戶包括數據人員、分析師以及業務人員，但是我們當時在提煉用戶故事的時候出現了一個偏差，我們隻提煉了數據人員的用戶故事，這也導緻後面我們踩了一次坑。

但是我今天不想略過這個坑，因為隻有把這樣的坑展示給大家，大家才能重視前期的所有準備工具，才不會像我這樣踩坑。

我們當時給數據人員提煉的用戶畫像是：懂技術懂底層數據，技術指數非常高。他們的痛點是重複的接業務需求，總在做零碎的數據需求，不停的幫用戶找數、取數、分析、建看闆，自身價值得不到體現，自身能力也得不到提升。他們的目标和預期是希望能夠快速幫助用戶完成數據看闆的搭建，完成數據分析和數據導出。

基于此，我們的第一步産品規劃其實就基本上完成了，我們确定了産品的定位也提煉出來了我們的用戶故事，那麼接下來我們要進行産品的設計了。

二、産品設計、正确的過程

産品的設計，我們一般會走三個步驟。

1. 确定産品整體的框架功能
2. 畫出産品的用戶體驗地圖
3. 細化産品整體的方案細節

我們當時基于我們的前期的調研設計出了整體的産品框架，主要包括三大功能。第一是門戶，可以去查看有權限的報表；第二是分析，可以開始自助分析和報表開發；第三是取數可以開始進行臨時的取數。

這個0.1版本上線之後，我們發現我們的數據人員在上面使用的非常得好，他們做出了自己的看闆，反饋了非常多的一些問題，然後也表示對這個産品的滿意。

但是我們在對于數據的觀察過程中發現有一類用戶上來之後很快就流失掉了，幾乎沒有留存，而且這一批用戶的占比還比較高。所以我們接下來就對這些用戶進行了分析，然後我們發現這一批用戶其實就是業務用戶，他們的畫像呢，就是不懂代碼，但是懂業務；他們的目标和預期都是通過數據分析得到結果去指導業務。

但是，他們在到我們的平台上去使用産品的時候卻出現了一些問題。

我們來看一看我們的用戶體驗地圖。首先，我們産品的整體的行為路徑其實是比較長的，從門戶到制作報表到連接數據源、制作數據集、制作報表。

但是我們的觸點卻隻有兩個，一個是門戶，一個是這個門戶上有一個新建分析的按鈕。那我們再來看用戶的情緒，我們發現，首先業務用戶進入到我們的門戶以後由于門戶上他可能沒有任何有權限的報表，所以他進來以後呢，是一個白闆。那這個時候，用戶可能就是一臉蒙逼了。

接着，他看到這個頁面上有一個分析入口，那麼他很開心說我可以點這個分析入口去進行報表的建設，可是他點了分析入口之後彈出一個彈窗，讓他去新建數據源，這些數據源包括Mysql、Hive等等，可是業務用戶他甚至都不知道Hive這些數據源是什麼東西。所以呢，用戶在這個過程中就是一個走向很絕望的過程。所以很快用戶就流失掉了。

那我們在這個過程中，也發現了一些痛點和機會。比如說在門戶上，我們沒有任何的指引對新手非常的不友好。第二個就是我們的鍊路過長，對于業務人員來說，連接數據源和制作數據集難度太大，不屬于他們的角色任務。

然後第三個呢，就是我們明明有大量的報表，可是我們因為沒有提供一個入口去存放和申請權限，所以導緻很多用戶上來以後看到的是一個白闆，或者是很多用戶都會重複的自己去建設直接看。

最後是我們的圖表制作模塊，也沒有任何的指引，交互邊界也不夠清晰，已經沒有辦法擴展。因為這些痛點，用戶的價值感很低，自然留存也很低。但是是痛點其實也是我們的機會。

增長黑客裡面有一句話說：不留存就去死。沒有留存，你的産品是沒有活路的。所以我們開始了一場産品改造的大戰。其實在上面我的用戶體驗地圖中已經找到了一些痛點和機會了，接下來我們要進行更詳細的用戶調研和分析，去驗證和挖掘需求。

首先我們向用戶征集了大量的反饋，然後我們開展了吐槽大會去收集用戶需求。吐槽大會是什麼情況呢，就是我作為産品經理坐在最前面，一群用戶坐在下面去吐槽，然後我還不能夠去反駁，因為我老闆就坐在我旁邊，如果我反駁的話，老闆就會說：哎呀，你不要反駁，好好聽着。這個過程還是很煎熬的，如果内心不夠強大，臉皮不夠厚是不行的。

最後，我們還去開展了一些問卷調研，同時我們也對我們的産品自己去進行了一些體驗，從體驗中去發現問題。

最終，我們又提煉出了我們的第二個用戶故事，也就是業務人員的用戶故事。我們發現他們的畫像是不懂代碼，他們的痛點是不知道自己要的數據在哪裡，不知道如何獲取數據，想要的看闆遲遲不能上線，重複繁瑣的線下Excel分析數據。

同時，我們又對于我們整體的産品的模式去進行一個分析，發現我們更多的是一種傳統的數據分析的模式，是以研發同學為主導的。研發同學去進行數據準備、報表開發，而業務人員在這個過程中，隻是對于數據進行一個驗收，如果驗收通過了，那就進行下一個需求，如果驗收沒有通過打回去研發重新開發。

這樣造成的結果就是需求反複溝通，報表重複的去開發。所以我們基于對研發人員和業務人員的角色畫像的理解，開始了一個全新的自助數據分析模式的探索。而在這個過程中，我們把研發人員和業務人員基于角色完全分離。研發人員的主要任務就是進行數據的準備，他把數據準備好之後放到一個地方，而業務人員獲取到這個數據并且去進行自助分析的探索。

最終在這個過程中，我們的業務人員獲得了分析的主導權，可以及時基于數據洞察業務問題，而我們的研發人員回歸到了自身的航道，去做更有價值的數據挖掘等相關的一些工作。

到這裡了，我們就完成了整個産品的框架的再次分析，那麼我們接下來就是對産品進行一個整體的産品框架上的調整。

為了解決找數據素材難的問題，我們提供了一個數據超市的功能，讓研發同學做的數據能夠直接放到超市裡面，讓業務同學能在這個數據超市裡面快速的找到他想要的數據。

為了解決找報表難的問題以及重複開發報表的問題了，我們去提供了一個報表超市的模塊，讓用戶直接來報表超市嘗試去檢索報表就能夠找到自己所想要的報表。

為了解決分析難的問題，提供拖拽式的交互方式，提供近30種常用圖表組件，提供上卷下鑽、一鍵同環比分析等功能，解決用戶數據分析難的問題。而且在這個過程中用戶不需要寫任何的腳本，而市面上其實還有很多BI産品還在讓用戶通過寫腳本的方式去實現這些功能，那對用戶來講，其實難度就特别大，而我們就想盡力去避免讓用戶寫腳本的方式。

到現在為止呢，其實我們又完成了産品的整體的框架的調整，我們其實也知道我們真正的1.0版本需要怎麼去進行改造了，但是我們前面講到我們的用戶留存低，僅僅是進行産品框架的改造，是不是能夠達到用戶留存提高的這個效果呢？所以我們還需要去看看這些框架層的改造能不能提高留存，所以，我們需要幫助用戶找到他的Aha時刻。

Aha時刻指的是新用戶第一次認識到産品的價值，從而脫口而出:”啊哈，原來這個産品可以幫我做這個”的那個時刻.這是一個非常重要的時刻，隻有找到這個時刻用戶才能夠認識到産品對它的價值才能真正留存下來，那麼我們具體是怎麼做的呢？

首先，我們對于用戶首次登錄提供了新手指引，去解決用戶首次登錄的認知問題，并且讓不同角色的用戶進來以後他就能夠找到自己角色的功能切入點；第二個就是我們增加了門戶的演示報表，我們會把我們每次疊代新增的任何一個可視化功能都融入到我們的門戶報表。

同時，我們門戶的演示報表中會有使用手冊的指引，那用戶進來之後，看到這個比較酷炫的演示報表，他瞬間就很驚喜，接着他還可以按照手冊的指引去完成他的一些關鍵行為，比如說完成一個自助分析，比如說完成一個看闆的建設。

那在這個時刻用戶就會脫口而出說：Aha，原來這個産品能夠幫我實現這樣的一個可視化的效果，能夠幫我完成這樣的一個分析的效果。這個時候呢，其實就是我們幫助用戶找到了他的Aha時刻，留存自然就能夠提高了。

接下來我們再來看，基于1.0版本我們的用戶體驗地圖是什麼樣子的，我們可以看到整體的行為路徑其實還是很長的，我們增加了報表超市、數據超市以及報表管理等等的模塊。但是我們再來看我們的觸點，我們會發現每一個模塊都有了他自己觸點，用戶可以基于觸點去切入到他們需要的産品模塊。

那我們再來看我們用戶的情緒，首先用戶進入到門戶以後他就直接能夠看到新手指引以及演示報表，這個時候用戶看到一個非常炫酷的一個報表，非常激動，這個過程就是我們增強了用戶的使用動力，整個情緒是非常驚喜的狀态。

接着，用戶按照我們的産品的指引進行報表的探索，在這個過程中會有一定的難度，所以用戶的情緒會有一定的下降但又不至于太低，慢慢的，當他摸索出該如何去進行報表的建設，并且完成關鍵行為的時候他就會非常的激動。而且我們在這個過程中通過一些指引以及交互上的優化減少了用戶使用的阻力，力求用戶激動指數的最大化。

最終用戶完成了自己的關鍵行為，并且把這個看闆分享給其他的用戶的時候，他的成就感得到最大化，他的激動指數也會達到一個峰值。（激動指數是一個從0-100的數值，簡單來說代表了用戶有多大動力在某個時刻完成某件事情，因此很形象的叫做激動指數）

到此時此刻我們基本上就完成了1.0的建設。在1.0的建設過程中，我們從MVP内核開始不斷地去疊代優化小步快跑，小範圍的試錯去為用戶提供好的産品，成就我們的産品。

在互聯網産品當中有一句話叫做效率為王，天下武功，唯快不破嘛。所以我們一定要小步快跑不斷地去疊代去優化我們的産品。

那在這個過程中，我們會注重兩個點，第一個是需求的推進，另外則是需求的篩選。在推進方面，我們當時用的是敏捷開發的方式，兩周一個疊代，小步快跑，不斷地和用戶溝通不斷的去調整優先級。

當然這種方式對于産品經理來講，其實非常的累，尤其是團隊比較大的情況是很累的，我當時就我一個産品經理，17個人的團隊，那段時間基本上可以說是疲于奔命的。

第二個呢就是需求的篩選。一方面需求是來自于我們的用戶，另一方面的需求其實是來自于産品，來自産品經理對産品的宏觀把握。最終，我們整理出大的需求池，并通過KANO模型就能夠去對于需求優先級進行分析。

那其實在這個過程中呢，我們還要始終記住産品體驗的五層，圍繞着我們的定位，在我們的産品範圍之内去進行産品的開發完善和優化，絕對不能走偏或者是超出我們的産品範圍。

到這裡我們就講完了整體的産品功能的0-1的過程了，那功能完全上線之後，是不是代表真正的0-1完成了呢？其實我們産品的0-1不僅僅是功能的完善，還包括用戶的留存和增長。因為你的産品如果沒有用戶增長或者沒有留存，那你的0-1其實也是很失敗的。所以，我們在這裡還要講一講運營拉動産品的增長。

我們當時用了四種方法：

第一個是體驗，我們先自己用起來，項目組就是我們自己的第一批用戶，我們自己覺得好用了，用戶才會覺得好用。

第二個是衡量，我們用數據去衡量我們的産品，我們一直在喊數字化，數字化就要從我們數據部門自身做起。關于這一點我看到市面上有一些有趣的現象，就是有一些做數據産品的，他去衡量别人的産品，但是他卻忘記了，自己作為一個産品，也是需要被衡量的。那如果你不去衡量自己産品，你怎麼去實現增長呢？第二個就是我們會關注NPS和滿意度

第三個就是用戶關系的維護，我們會去擴大種子用戶的規模，去維護種子用戶的關系去不斷地獲取用戶的反饋。

第四個是生态體系的建設，建立數據完整的生态體系。BI産品作為整個大數據平台中的一個産品，我們向下要去跟中台打通，讓中台能夠去支撐我們的整個産品的體驗。那向上呢，我們是最接近用戶的，我們不僅要向用戶去提供好用的體驗，同時我們也要建立數字化的思維體系去培養我們的數據人才。

最終呢，我們向用戶收集到了用戶反饋1100多個，用戶反饋完成了600多個，80多個疊代，1300百多個系統需求，完成了2000人培訓。那這裡就有一個很有趣的數據就是1300百多個系統需求，其中600個是用戶反饋的，所以還有近700個需求，其實是産品經理基于自己的對産品的宏觀中關微觀的一把握而規劃的需求。

截止到現在，我們完成了用戶故事的提煉，進行了用戶體驗地圖的刻畫，對于需求優先級也進行了不斷地探索，并且進行了用戶運營。這個時候，我們就能夠完成用戶模型的建立了，用戶模型是産品現有用 戶以及潛在用戶的偏好和行為反應模式。

當你掌握了用戶模型以後你才能分辨需求的優先級，才能預判産品疊代後用戶行為變化，而不會說産品上線後無人使用，潦草收場。可以毫不誇張的說，這個産品我做了2年半，我基本上能夠準确預判任何一個功能上線後用戶的反應模式。

三、資源整合—合适的人和正确的文化

最後到了第三個模塊，我們來講一講整合資源。

整合資源，主要是合适的人和正确的文化。但是實際上合适的人和正确的文化，從來不是一上來就會有的，除非你非常的幸運。比如我，我覺得我就是一個很幸運的人，我的團隊基本上都是合适的人，而且大家都是積極向上非常具有能動性和積極性的這樣的一些同學。但如果你的團隊沒有這麼理想化的話，你應該怎麼去做呢？

首先，我們要達到目标一緻，不要吝啬向整個團隊傳達産品的使命願景目标，要讓大家看到未來，從而去提高大家的能動性和積極性。

第二，我們要明确産品的價值。在産品大的願景的前提下，明确産品設計的目标和價值，要讓團隊每個人都知道做這件事情的價值，能夠解決用戶什麼問題，能夠帶來怎樣的價值，而不是産品讓我做我就做了。

第三是主人翁意識，要讓團隊的每個成員感受到自己的價值所在明白自己的重要性，并培養每一個人的主人翁意識。最後是開放，就是不要害怕質疑和争吵，我們要讓團隊的同學為了打造更好的産品去争吵和質疑産品經理，有一個開放的環境。

我們當時基于這些方案，打造了一個優秀的最具凝聚力的團隊，團隊獲得了重點項目、優秀團隊、中心标杆項目等多個榮譽。

那最後，我們也基本上實現了人人都是數據分析師這樣的一個願景。當然，其實也沒有所有的人，但是我們至少實現了大部分。我們最終累計用戶達到了10萬，月活用戶4萬，用戶滿意度92%， NPS 94%，ROI 2400%，這其實是一個比較高的數據了。

至此，我們的0-1就完全完成了。

四、結語

最後，我想用梁甯老師的一句話來做一個結尾。

産品能力是訓練一個人：判斷信息，抓住要點，整合有限的資源，把自己的價值打包成一個産品向世界交付，并且獲得回報的一個過程。我希望我們所有的産品、運營，以及正奮戰在建設産品路上的小夥伴們，都能夠向世界交付你的價值，并且獲得回報。

本文由 @糖糖是老壇酸菜女王 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部