做产品的第三年，我负责过两款产品从 0 到 1 的完整过程，因此也对最简化可实行产品（MVP）有了更多的认识。
上周六，在参与了 Sopio 老师《客户洞察与运营》课程后，因此想结合着谈谈我对这 MVP 的理解和看法。
定义
Minimum Viable Product – 最简化可实行产品，即 MVP 是由 Eric ries 在《精益创业》一书中提出的。
A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
MVP 产品提供足够简单的功能版本给早期用户来使用，以收集反馈服务于后期的产品发展。
在设计 MVP 时，我们需关注这三个重点：
足够简单：如何定义足够？如何定义简单？
早期用户：什么是早期用户，他和我们未来要服务的用户有什么区别？
收集反馈：如何收集？什么是好的反馈？
1. 足够简单
MVP 产品的关键在于提出一个产品假设，并设计一套方案来进行验证。而如何定义「足够简单」，则要看能否满足验证产品假设的最低所需。
举个例子，我们想要验证自定义广告落地页会提高广告的留资率。那我们最小的产品模型是否需要提供一套允许用户搭建落地页的系统呢？答案显然是不需要的，我们可以通过针对验证客户先开发独立的落地页进行快速验证。
MVP 产品的设计非常考验产品经理的能力，一方面要能在前期混沌阶段梳理清楚产品验证的主流程并砍掉支线需求，一方面要能够保障 MVP 功能的拓展性，减少后期重复开发的工作量。
我在负责第二款产品时，尽管吸取了自己在第一款产品贪图 MVP 产品求大求全的经验教训，但还是做了不少冗余设计。周末跟 Sopio 老师的课程学习也让我反思我的思考顺序。
在过去我常思考的顺序是：用户遇到的问题是什么？我的产品如何解决用户的问题？这种方案容易导致方案脱离用户当前所做的工作，因为需求更容易发散。
而 Sopio 老师更推荐的逻辑是：用户最近在做的工作是什么？有什么问题很棘手？我的产品如何缓解用户的问题？我的产品如何给用户额外的收获是什么？
通过结合用户最近在做的工作，能让 MVP 产品出来时就能被用起来。
当然这里也有个概念值得强调下，有些人认为「MVP 产品」就能接受产品的可用性低、稳定性差。我个人认为这是不妥的，因为即便是早期用户，我们也需要注重口碑。
2. 早期用户
正如我在《只有真正解决「小」问题，才能跨越「鸿沟」》提到的，早期用户很多都是发明家，他们擅长自己动手解决问题，对新鲜事物接受程度高，对产品容忍程度也高。但在 MVP 产品期间，我们所提及的早期用户并非这个群体，而是实用主义者。
也就是说，我们进行产品验证的客户必须是未来会买我们的产品的典型客户，是实用主义者。
如果能够让用户付费参与验证，那么是更好的。（尽管很难，但需要尝试）
我在第一款产品进行 MVP 验证时，出现了产品调研跟产品验证用户不一致的问题，也就是跟我们聊需求的用户并非最后决定产品能够被采买的用户。这也导致我们浪费了不少时间。
而跟早期用户在沟通和传递时，我们也要传递好产品的价值主张。在这个过程中，我们需要不断反思我们的产品定位是什么。因为早期用户认为你的产品是什么，就是未来大众主流用户对你产品的定位。
总结下，在早期用户这里我们要认清：
MVP 产品的「早期用户」是实用主义者的代表，是未来会付费买我们产品的代表；
跟「早期用户」在沟通中，要探索清楚产品的定位是什么，产品的竞品是谁。
3. 收集反馈
几乎所有同学都能够意识到产品反馈的重要性，而在 MVP 产品期间收集用户反馈更是常见的事情。在这个过程中，我们对两种情况保持警惕。
用户无反馈；
用户有大量反馈。
针对无反馈情况，那么我们要关注的是用户用起来产品了吗？为什么没有用？是功能不好用还是因为产品过于复杂？
针对大量反馈的情况，我们要及时分类反馈的问题类别：
体验类：整体优先级不高。在 MVP 期间要容忍一部分的体验缺陷；
缺陷类：值得引起重视。需要看清楚缺陷的影响范围，如果影响的是用户验证的主路径或者用户重视的重要资产，需要第一时间跟进；
需求类：要结合产品的定位和「足够简单」的 MVP 目标，对需求进行整理。
这个过程也非常考验产品经理的功力。我们需要随时进行复盘迭代的目标，思考自己的功能意图。
总结
产品在早期过程中，就犹如身处混沌。而 MVP 产品像是大雾中我们抛出的信号标，用来帮助我们探索前行的路。
这个过程中，由于信号标会随着环境移动，所以信号标可能不会回馈信号，可能会偏离目标。我们需要看准我们想要去的方向，做出一次又一次的决定。
路漫漫其修远兮，吾将上下而求索。