任何一个合格的产品负责人，都会具有一个特点，就是喜欢使用、捣腾自己的产品以及同行的产品。就拿今天来说，抱着思考产品特性和探究异常处理逻辑的想法，我故意在收银台签约并支付时，输错3次短信验证码，果不其然，在点击支付时，系统报交易存在风险，交易失败。
一切都和预期一致，于是我想，简单测试完了，估计是触发了风控规则，，找客服帮我解锁吧。但想了想，正好可以验证下这种输错验证码被拦截的常见场景，客服处理起来效率怎么样。
于是我找了在线客服，然后角色扮演一位不小心输错验证码而被锁的可怜顾客，并只提供少量信息。我本以为是很简单就能定位的事，所以也估计客服也能很快就能解决。但实际情况是，客服给了我一个完全错误的解决方案，而且把出现异常的原因认定为我输错了银行预留手机号导致的。
这个结论是很致命的，因为他完全判断错误了问题的根本原因，自然给用户的解决方案是错误的。
对于客服的这个回答我是很震惊的，于是我想去了解客服是如何得出这个结论的，是通过哪些工具，经历了哪些思维过程？会不会是我们的后台不好用，还是后台提供的错误信息太多而掩盖了真实的信息？又或者是需要协助客服了解更多产品相关知识以提高问题的定位能力？只有弄清楚背后的本质，我才好一步一步来判断是否可以优化的环节。
于是我找了一个又一个的人问，终于找到了对应的客服负责人，也把我的初衷告诉了她。可是不知道她是不是没仔细看我的话，还是职业习惯导致，她直接拉了一堆人开始给我解决问题。
这就导致了另一个让我惊讶的结果，说我这个问题是很罕见的，具体原因还无法确定。我想，我的天，我都把场景给他们描述了，而是还是很常见的异常场景，他们却说很罕见。罕见就算了，还从4点半到6点下班，这个问题还没给我解决，要知道内部员工都处理的这么慢，更不用说用户了。
这里我并不想也不是抱怨，而是想说，我从今天的事中明白了一些道理。
1、你不输验证多次而导致账户被锁，你永远不知道用户在遇到问题是多么的无奈、焦虑和痛苦。所以，我们在设计时，多考虑些异常场景。处理用户反馈时，速度快点、效率高些。
2、不要站在高处和远方眺望你的产品。你不多使用你的产品，怎么知道它好不好用，容易不容易出问题。你不去论坛、微博等社交平台逛逛，怎么知道用户怎么看待你的产品。你不去体验下咨询客服，怎么知道客服处理的快不快。你不去和客服和运维了解、沟通，你怎么知道他们是否能快速高效的帮用户解决问题。很多事情，不去体验，不去调查，得到的永远是纸上谈兵。
3、请密切关注异常场景和客服。因为前者决定了用户抛弃你的速度，而后者是离用户最近、最了解用户的不满抱怨和痛苦的人。
4、切勿头痛医头，脚痛医脚。一定要探究事物的本质，找到问题的根本所在。
