尤其在创业公司，不知各位产品狗狗们在评审后会不会有一种感觉，花了那么多时间出的方案几乎一无是处，怎么感觉像给程序添乱的样子。这时候往往有一个经验丰富的程序老大，直接提出一个各方面都完美的方案，更有价值，程序实现也更简单。嗯，你提的方案真的是一个浪费别人时间的东西。
一个岗位不仅没能产生价值，反倒给别人添乱，产品经理开始怀疑人生，不行，我们必须解决这个问题。
个人认为这个问题的根本原因在于需求调研不足。一个产品方案，我们一般会从“价值性、可行性和可用性”来去评判它。早期的需求调研也一样，我们要确认推进的方案是否有价值，流程及交互是否可用以及开发成本大小。
先说价值
一个东西是否有价值，关键看两点。一是有没有抓住用户的核心痛点，二是能否比市面上的其它解决方法更优秀。程序抗拒需求，不想增加工作量是一方面，更核心的问题其实是你的方案他认为没有价值。一个东西被认为没有价值，一是因为你没有说清楚，二是因为它真的没有价值。而有价值的东西大部分几乎不言而喻，因此当一个方案很难推动时，沟通是一方面，更重要的是要去思考你有没有解决到对的问题。这是价值调研的重要性，而具体的调研方法，不在本文讨论范围。
然后是可用性
这个词一般出现在大公司的体验部门，小公司几乎不去考虑。但可用性关乎体验，小公司的产品应该思考如何用更简单的方法去验证可用性，哪怕只是小规模的内部测试。拿车载产品举例，很多人觉得通过语音而不是复杂的操作进行交互是个显而易见的方法，但是沉迷于设计细节和各种抽象问题的产品经理在没有亲自开过车的情况下，很可能关注不到这个核心可用性问题（港真，方案上线后，很多可用性错误在实际使用情景下，真的充分验证了产品经理的傻逼属性），做最简单的DEMO，去模拟实际的使用场景，很多你注意不到却又至关重要的细节突然豁然开朗了。
最后说可行性
这里区分一下新方案和迭代方案，尤其是迭代性的方案，它不仅要考虑实现的成本，更要考虑对旧架构的适配。很多产品经理因为对代码逻辑不太清楚，会提很多对旧有架构造成破坏影响的方案，导致同样一个功能的迭代，不同的人提出了底层逻辑都不同的实现方案，程序需要一遍又一遍的重写。拿个快递还得换条内裤，靠，换件衣服不就完了。
结合这三点，每次出方案前，产品经理都应该心里有个底，10天出方案，5天都应该在调研，任何一块的疏忽，都会在日后推动实现和上线实用后收到更大的报应。
