很久之前写的一篇文章，之前放在个人博客，整理过来

什么是用户“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点的实验，上面的矿泉水例子就是一个很好的体现。

另外一个例子，国外某网盘产品经理想设计一个网盘，但又不清楚产品能不能满足用户的需求。于是，他没有做任何产品设计相关的工作，只是把此网盘的产品大概型态和操作流程拍了个视频放到网上，统计需要此网盘的用户数量，需求量达到一个数字级别后才开始进行产品设计和开发。这样就避免了产品设计出来后没有人用的恶果。

无独有偶，国内某皮鞋批发商，专门去各个皮鞋批发地拍摄各式各样的皮鞋相片，然后通过邮件等方式发给朋友、网友等，看看哪种皮鞋需求量最大。等有人想购买皮鞋时，这个批发商再去批发地购买，再邮购给终端用户。

这两个例子充分说明了：不打无准备之仗，我们在设计产品的时候也应该知道，在着手做之前，应该要清楚这个产品成功的几率大不大，用户是不是喜欢。在有一定把握的时候再开始动工！