如果在一个岗位工作了5年以上，会有很多实战经验，首先不会太差。
在这个基础上，普通和优秀的区别，体现在遇到一个难题的处理方法上。
1. 普通人：用自己的经验解决问题，遇到了难题，卡住了。郁闷，难过，然后继续努力的用自己的经验来解决问题，来来回回都是一套逻辑；
2. 优秀的人：也会用自己的经验来解决问题，没搞定，卡住了。会重新思考问题出在哪里，换个方法试试；
这个在我们之前的六步法，从根因上解决问题里提到过，普通人和优秀的人在遇到问题时的处理方式的差异。
那如何确保换个方法就能解决问题呢？
首先要重新定义问题。也就是以终为始，将这个看得见的问题进行转换，变成一个新问题，并进行定义。
你会发现，有的时候我们以为要解决的问题是A，但其实问题是B或者C。
经常举的例子是，你以为用户要一批更快的马，但其实他想要的是更快的到达目的地，汽车有可能更适合他。
找到本质问题的方法，就是多问why。
当找到真正的问题后，要有能力将问题拆分成多个独立可验证的子问题，当验证和解决了一个个小的子问题，那么整体的大问题也就被解决了。
如果问题不能被拆解成子问题，那就要设计出一种快速试验的方法。
我们之前说过，科学是在试验中前进的。
有了理论推导，那究竟能不能有效果呢？得靠试验，不停的试验找到最优解。
当遇到一个自己不知道的问题时，即不知道可行的方案，也没有能力拆解变为小的问题。
那就可以尝试一些自己认为可行的方案去试。
有的人面对一个没遇到过的问题，期望设计出一个完整的解决方案，然后再投入大量的精力和资源去验证。
这其实得不偿失，看起来也不尊重科学。
对于试验方法上，可以遵循这些原则：
1. 验证方法成本是否足够低？
2. 是否能确保足够多的测试？
3. 有基于目标的反馈机制吗？
4. 每次反馈的速度足够快吗？反馈结论足够清晰吗？
5. 思维被禁锢了吗？
提倡的是第3种方法来做试验解决问题，用1/2逼近问题的真相。
当然，你如果试验的工程化做得不错，也可以将三者结合，用3同样可以不断逼近问题的真相。
这个原则适用于技术开发，也适用于做产品，就是所谓的MVP模型。
你不知道这个方案能不能解决用户的问题，那就低成本去试试。
但有些能力不足的产品同学，往往会在一开始就期望搞一个大活，设计一个巨复杂的方案，而且信誓旦旦的说，这个一定可以解决用户的问题。
最后一看效果，即没达到预期，也浪费了研发资源，自己懵逼了。
如果不反思，还将锅甩到研发身上，那就太不懂事了。
我之前说过，有的时候提高研发效率不一定是好事。当面对差劲的产品经理时，将差劲的需求交付到用户手中的几率就变高了。
