关于产品的一些浅见--《人人都是产品经理》读后

问题的本质是什么？

问题就是理想和现实的差距，这个差距就是一个产品的机会，你的产品是否能存活下来，就看是否能够弥补现实和理想之间的这个差距，也就是我们经常说的“痛点”。

产品用户

一个产品的目标用户必须是明确的，你不可能讨好所有人，只要抓住自己的核心用户就好了。所有这就要求产品在初期的时候能够清晰明确的确定自己的核心目标用户，之后所有的事情就很简单了： 讨好你的目标用户。

需求还分真伪？

目标用户确定了之后，就会引发下一个问题：什么才是目标用户真正的需求，很多时候用户提出的需求并不一定是用户真正想要的，比如一个马车夫的需求可能是一匹健壮的马，但是其背后真正的需求可能（很大程度上）是快速安全的到达目的地，那么如果你按照他的需求给他一匹千里马，这只是满足其基本需求；但如果你给他一辆超跑，可能才是在挖掘其真正需求后的最好方案。 很多时候我们可能需要认真分析用户的需求，去挖掘在表面背后更深处的真正需求，给用户一个惊喜，满足他自己都未能发现的“痛点”。

不是所有用户的需求都要满足，不要被用户的需求牵着鼻子走，用户的需求只能作为下个迭代方向的参考，而不是下个迭代的方向。尽量避免耗费80%的精力去满足2%的用户的不常用需求这样的事情，除非你的技术人员天天都无所事事。

技术无罪？技术也无效

技术人员通常都会有一个通病，那就是一味追求技术，简单的认为更高级、先进的技术必定是好，但是最好的未必是最合适的？ 套用快播创始人一句话，技术无罪，同样的，技术也无效。放到正确的、合适的地方，让技术发挥作用，才是好的技术。简而言之，不管黑猫白猫，抓住老鼠就是好猫。

提前验证

在开发前期出现原型或者demo的时候，有条件的情况下可以让用户来试用、测试下产品，我们只需要完整的记录，不可引导。 简称为 可用性测试。这个过程越前越好，越靠前，越有可能提前发现因为种种局限性而未能发现的问题，也更能提前的解决这个问题。一栋大楼的地基打完后，再想调整大楼的结构可能就不太现实了。。。

最后

我们需要明确几个概念：

用户需求： 用户自以为的需求，并且经常表达为用户的解决方案。
产品需求： 经过我们的分析，找到的真是的需求，并且表达为产品的解决方案。
需求分析： 从用户提出的需求出发， 找到用户内心真正的渴望，再转化为产品需求的过程。

技术分析是 树干 - 树枝 -- 树叶 的分析过程，需求分析是 先 树叶-树枝-树干，然后再树干-树枝-树叶 的过程，也就是一个 分-总-分 的过程。

伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说用户真正想要的东西。销售人员经常说：“用户是为想要的东西买单，而不是需要的”，简单的说，就是用户是为自己的解决方案买单，而不是我们的解决方案。 这其实就是 短期利益和长期利益的权衡。