以前觉得做产品是那么骄傲的事情。现在越来越感受到，越是骄傲，越当沉重而行。
Takeaway:
1. 不是做了用户调研、输出了详细完整的PRD文档就了事的，更要严格把关最终呈现给用户的产品体验，一定要充分灰度测试，并在灰度期间密切关注用户反馈。
2. 对于异常情况、系统可靠性不可以放松警惕。一旦出现系统罢工，给用户带来的体验是最最差的。这个层面上，技术架构真的很重要很重要很重要。
3. 产品经理要真正有ownership。对于风险，一定要提出让每个人知悉。如果产品存在体验黑洞，一定要把住，不能就这样带给用户。
4. MVP的概念同样适用于硬件产品。在产品还没有达到最低体验标准时，贸然呈献给用户，是会损失用户的，对品牌名誉造成很大伤害。
从新产品说起
公司和一个合作伙伴一起推出一个产品。产品在面世后，暴露了一些体验问题，严重影响着用户体验。有两个问题，被用户吐槽得很惨烈。奇怪点在于，公司内部其实一直有关于这两个问题的讨论，产品们私下里都吐槽过，但是问题一直没有得到足够的资源支持而被去解决。
一个原因，是这次发布非常赶时间，因此牺牲了很多测试和灰度的空间。
一个原因，是长久以来积累的问题（技术搭建的不足、产品规划流程的不足等）相加1+1>2的呈现。
但更让我警惕的是，是在做产品的过程中，由于种种资源、技术、个人精力限制，逐渐丧失了“不管怎么样，我要对用户负责，我不能让这样的体验给到用户”的信念。因为没有这样的信念，就没有了充分暴露问题、充分为用户发声、充分推动解决问题的动力。说实话，当在微信群中看到一个又一个用户反馈上来的问题，那种感觉比我想象得要难过很多，即使这个问题不在我，这个项目不在我，我也依然感到后悔和愧疚。
每一个用户都很重要
雪上加霜的事情出现了。刚发布后的第3天，服务器崩溃了，有那么10分钟，用户完全不能使用产品，而且当时正处于产品使用的黄金时期。即使经历过前面所述的问题，我也依然觉得这个问题是非常严重的，因为带来的体验恶化是直接了当，并且受众广泛。这时候我很挫败地想到，即使表层产品设计得再好，没有优秀的底层结构作支撑，用户体验也根本无法保证，这也是为什么往往大公司的产品更加令人信赖的原因之一。
问题紧急修复后，我们在用户群里更新消息。一位用户说：
孩子已经睡了。也已经用不着了。
没有在用户最需要的时候，及时给到产品价值，真是让人难过。
我要怎么做
1. 为用户体验负责。为用户体验负责。为用户体验负责。对严重影响用户体验的问题要坚决暴露到底、解决到底。不解决，不发布。
2. 严肃参加测试评审。制定严格的测试用例。
3. 一定考虑异常情况，一定要充分灰度测试。必要时，在发布前就考虑异常情况下的紧急措施。
