产品经理的工作中总不乏各种各样的问题需要解决，能够立体化、系统化地解决问题是身为产品人必须具备的能力。
产品经理要定义一个产品，定义产品的关键就是定义产品价值，产品的核心价值就是解决用的问题，没有价值的产品再优秀的研发团队都是徒劳的。
除了定义产品，产品经理还需要管理产品，甚至关注产品运营，这一切的工作本质上都可以抽象为一个问题，开一次产品需求评审会是要解决这份产品需求能否达标的问题，写一个产品立项书是为了解决产品研发能否有资源的问题，定义团队章程，协调成员沟通都是为了解决产品团队的问题，所以说产品经理的工作就是解决问题一点都不为过。
那么问题来了，到底什么是问题呢? 问题本质上就是期望和现状的差异，因为差异产生痛苦，因而产生问题。
为了更加全面的理解问题，我想从三个方面去论述，让你对问题的理解更加立体化、系统化。
一、定义问题
问题分类的维度很多，按照二元论，我认为问题分为两种，一种是看起来是问题的问题，一种是看起来不是问题的问题。
先来第一种，看起来是问题，比如你做产品测试时发现不满足需求，交互界面易用性不好，产品开发进度未按照预期完成，这些都是第一种问题，一看就是个问题。
还有一类问题看起来不是问题，比如你的上司让你写个产品方案，他要给老板汇报，用户调研需要写一个调研提纲，这些看起来更像是个任务，这任务本质也都是为了解决一个问题，你接到老板让你方案的任务，实际上是为了解决你的上司如何给老板汇报的问题，本质上是要解决你的主管领导对于这个产品的认知问题。
问题分类清楚了，接下来要有能力分辨这个问题对我来说到底是不是个真正的问题，听起来有点拗口，我举个例子，一个需求人员过来跟我说，研发未完全按照原型设计进行开发，我看了下，研发因为前端技术所限对界面有微小调整，不影响大局，总体来看这个调整是OK的，对我来说这就不是个问题，可对需求人员觉得是个问题。
再举个例子，一个技术架构组的的重要人员要离职了，这看起来对我而言不是个问题，可实际我们的产品的用到了他开发的技术组件，他的离职很可能会造成我负责产品的进度延迟，这对我来说就变成了一个问题。
所以辨别是否是一个真问题的关键，就要看这个问题对我来说到底是不是个问题。
这个PPT写得太差不合格，听起来这确实是个问题，但你还是不知道到底问题在哪?是PPT的布局不够美观？还是逻辑结构不够严谨?所以正确的说法是你的这个PPT篇幅太长，要表达的观点不变，精简到10页就可以了。
看到没，描述问题的关键就是现状和目标，这两个点说清楚了，问题就描述清楚了。
二、分析问题
分析问题要关注三个方面，问题出现的频率、问题的关联性、问题的因果关系。
先看问题的频率。在ITTL规范里有事件和问题的概念，假如一个信息化系统发生了故障，在最短的时间内解决故障，恢复服务这叫事件，如果这个故障反复出现，一个月出现了好几次，那就要重点关注，把这些重复出现的偶然事件就会定义为问题，技术专家要想办法给出彻底的解决办法，解决这个问题。所以分析问题的频率很关键，不同的频率解决方案也会不同。
再看问题的关联性，如果我们的信息化系统需要升级一个底层组件，解决一个安全漏洞，看似很简单，可是真的升级了就解决问题了，他是否会引发新的问题，当前的安全问题是解决了，可是因为有个功能模块只能适配这个最组件的旧版本，新版本升级了马上新问题出现了。
最后就是问题的因果关系，我们要学会寻根溯源，打破砂锅问到底，像剥洋葱一样，层层把这个问题分解，透过问题的表面看本质，只有这样才能根本上的解决问题。
我举个实际的例子，我有个同事给客户演示系统，结果演示的效果不好，用户不太满意，后来我们复盘这件事，发现了以下子问题。
演示地点是客户的办公室，那一次的办公室没有外网环境，这个事先没有调研清楚，到了现场才发现，只能临时用的手机热点联网，系统的速度显得比较慢。
另外演示的投影仪连接电脑有些问题，捣鼓了几分钟才开始正式演示，这给用户留下了坏印象。
演示的过程中出现了一次系统bug，而这个bug的出现是演示的准备不足造成，研发知道有这么个问题，只是暂时来不及解决，如果提前准备充分，这小功能根本不会主动点开。
所以这些问题的叠加最终造成了一次失败的系统演示。
先说一个点，解决问题一定要以自己拥有的资源为最基础，否则得不偿失，说白了就是看自己手里有什么牌，才好出招。
比如一个用户提出一个系统需求，要真正的实现这个需求，我们现在的技术能力是不具备的，可能需要和别的厂商合作，或者需要付出大量的人力去做技术预研，成本都是非常高的，解决了用户的问题但是项目赚不到钱，怎么办?
问题还是要解决，我们回到问题的定义，问题就是预期和现状的差异，现状无法改变，只能降低用户期望了，通过成本较低的替代方案最终解决用户的问题。
问题经过分解，出现了很多子任务，这些任务都完成了，问题才算真正的解决，如何排定这些任务的优先级，有两个很关键的因素，一个是外部资源，如果这个任务需要其他人协助解决，这个人是不太可控的，所以这类任务优先级一定是最高的，另外一个就是依赖关系，通过任务的依赖关系明确哪些任务可以并行优先做。
最后问题的任务都分解完了，计划也定了，也分配到具体负责人了，那是不是就万事大吉坐等问题解决，显然并不是这样的，产品经理要全程追踪问题的解决过程，有问题及时沟通协调。问题解决后还要验证。
最近有个项目，我分配给一个现场的工程人员去部署附件服务，要实现多个节点的同步和负载均衡，他干了一天和我说问题解决了，这比我预期的要快很多，然后我再问他你验证了吗？怎么证明你部署成功了呢？他才晓得原来还有验证这一步。所以未经验证解决的问题，都不能算真的解决了。
这里把角色放的更大一些，你除了是一个产品经理，在家里你可能是一个父亲、一个妻子，在一个读书会你可能是一个读书会的会员或是组织者，在医院里你是医生的病人。我们每个角色所作的思考、决策、行为其实都是为了解决问题。
辅导孩子的功课是为解决孩子的成绩问题，带家人旅游，是为了满足精神上的释放，甚至我们每天吃饭、睡觉都是为了解决身体本身的健康问题。
