本文發布于@pmben 的個人博客。什么是用戶“G點”？我在這里將這個G點定義為：用戶的爽點，即能讓用戶眼前一亮并感覺到很爽的地方！

通俗的講，G點就是用戶的某個需求點，當用戶的需求點被滿足時，他自然而然的會有很爽的感覺。成功的互聯網產品，無不都是滿足了用戶的一個或者多個G點。這跟現實生活中的G點有點異曲同工哦，你們懂的！

G點是互聯網產品獲得成功的必要條件

成功的互聯網產品，無不都是滿足了用戶的一個或者多個G點。微信一開始的成功源于它可以語音發信，這點是利用了用戶懶惰的特性，讓用戶用起來很方便，繼而很爽。QQ通訊錄的成功源于它可以將通訊錄同步到云端，在能進行批量處理通訊錄的同時還避免了通訊錄的丟失，用戶用起來也必然很爽。

通俗的講，G點就是用戶的某個需求點，當用戶的需求點被滿足時，他自然而然的會有很爽的感覺，而爽的程度則取決于產品具體的交互設計。反過來說，抓住了用戶的G點，產品一定會成功嗎？這就不一定了！

Kozmo.com：在線倉儲和送貨服務商。對于城里人來說，Kozmo.com的確既酷又方便，你可以訂購從電影到小吃各類物品，然后僅用一個小時就能讓它們到你的家門口。爽不爽？肯定爽啊，而且這也是用戶的真實需求。但是對于Kozmo.com來說，這已經變成了一個不可能完成的任務!在把業務擴展到7個城市后，Kozmo.com發現，跋山涉水地送一張光盤或者一包口香糖簡直糟透了!最后不得不面臨倒閉的后果。

所以說，尋找用戶的G點，是在做產品的時候首要要考慮的問題。你的產品滿足了用戶哪些需求？用戶用起來會不會很爽？如果你覺得找到了用戶的G點，那么就去看看你的產品是不是真的能讓用戶爽起來。怎么去嘗試呢？有種方式：

根據這個G點，開始做產品概念圖，然后根據概念圖搭建出產品的基本框架，規劃出產品的各個功能模塊，然后再針對每個功能模塊設計產品交互。如果功能點很多，那可能還需要進行版本劃分，按照優先級將功能模塊劃分為幾個等級，之后不斷迭代。然后在版本升級過程中看用戶的反饋和數據，如果數據不理想則再進行調整。

這個應該是大部分產品人使用的產品設計流程，那么在這里這種方式是不是真的適合呢？在回答這個問題之前我們不妨看看下面這種方式！

MVP開發模式—精簡、直接、快速

還是針對上面的那個問題，我們的另外一種解決方式就是MVP開發模式：圍繞用戶的G點（需求點），建立最精簡的產品原型，這個原型只包含最基本的功能模塊，注意，這里是最基本的，不能再做減法的功能模塊，然后在最短的時間內上線這個最基本的產品原型，上線后看用戶的反饋和數據，如果這個點不能讓用戶爽起來，那么就立即改變產品設計的方向。

舉個例子，人們都有喝水的生理需求，經過調查，用戶對甜的水普遍有好感，這個甜水就是用戶的G點。找到了用戶的G點后就要開始生產水了。

第一種方式：規劃好生產的數量、每瓶水的含糖量、每瓶水的體積、大小、定價、銷售渠道等內容后，開始大批量生成，生產之后進行大批量銷售。

第二種方式：生產一小批甜水、一小批無糖水、一小批咸水等，之后進行銷售，根據銷售業績來決定生產方向。

兩種方式的結果怎樣呢？在銷售過程中發現，其實用戶對甜的水并不買賬，他們可能只是平時喝點，但是喝的最多的還是無糖水。結果可想而知，第一種方式肯定虧大了。

當我們在找到用戶G點的時候，不要急著去做大的產品規劃，而是要針對這個G點建立最小最小的產品型態，先看看這個是不是真正的用戶G點，我們的產品是不是真正的滿足了用戶的這個G點，用最小的代價去做個實驗，這才是明智的選擇。

和用戶一起開發產品

剛才上面的第二種方式實際上是一種產品設計理念的體現：和你的用戶一起開發產品。產品是給用戶用的，產品又是我們自己設計的，除非你非常了解用戶的需求并能從這些需求中找到真正的突破點，否則產品是很難成功的！

所以我們提倡，和你的用戶一起開發產品。如何一起開發呢？我們就用上面的MVP開發模式，在最短的時間內上線一個產品型態，看用戶買不買賬，如果不買賬，立即轉化思路，進行另外一個G點的實驗，上面的礦泉水例子就是一個很好的體現。

另外一個例子，國外某網盤產品經理想設計一個網盤，但又不清楚產品能不能滿足用戶的需求。于是，他沒有做任何產品設計相關的工作，只是把此網盤的產品大概型態和操作流程拍了個視頻放到網上，統計需要此網盤的用戶數量，需求量達到一個數字級別后才開始進行產品設計和開發。這樣就避免了產品設計出來后沒有人用的惡果。

無獨有偶，國內某皮鞋批發商，專門去各個皮鞋批發地拍攝各式各樣的皮鞋相片，然后通過郵件等方式發給朋友、網友等，看看哪種皮鞋需求量最大。等有人想購買皮鞋時，這個批發商再去批發地購買，再郵購給終端用戶。

這兩個例子充分說明了：不打無準備之仗，我們在設計產品的時候也應該知道，在著手做之前，應該要清楚這個產品成功的幾率大不大，用戶是不是喜歡。在有一定把握的時候再開始動工！