在产品管理的复杂世界中，将用户需求转化为切实可行的解决方案是一项关键技能。这篇文章深入探讨了产品经理如何从需求出发，运用策略、工具和技巧找到并实施有效的解决方案。
有问题其实不用怕，为问题找到解决方案，反而是让我觉得很难。
作为产品经理，问题的来源有很多，而最终要给出的解决方案也很多。
这里的解决方案可以是
等等。
我们看下边几个例子：
用户需求：我想把我的动态分享给我的朋友
解决方案：分享功能，将动态生成图片分享、链接分享，同时可分享至微信用户、微信朋友圈。
用户需求：我已经发布的文章有错别字，想修改错别字
解决方案：添加编辑功能，支持二次编辑。
用户需求：选项内容太多，需要找很久才能找到自己想要的
解决方案：添加搜索功能，快速筛选数据。
也可以添加排序，用户进行排序筛选；
也可以根据使用次数，添加个计数，将常用的选项往前放。
用户需求：医生每次都要录入相同的药品，很费劲，想快速录入
解决方案：新增用药模板功能，直接添加药品模板中的药品；
也可以让医生用历史录入数据中查找，选择自动带入数据。
用户需求：后台导出数据超过1万条时，出现乱码，而且下载很慢，页面经常卡死。
解决方案：下载逻辑调整为分Excel下载，数据行数每5000行分成1个excel。
……
把需求当作问题，分析需求是为了找到最核心的问题。
想分析透彻一个需求，就用5W2H、5Y，这2个分析方法。
5W2H是一种分析方法论，通过不断的提出疑问句，然后进行答复，能够帮助我们全面的分析问题。
1）What（是什么）
这是最基本的问题，了解需求的内容是什么。在需求分析时我们可以先提出下方问题，然后对问题进行解答：
2）Why（为什么）
这个问题用于了解需求提出的原因和动机。必须深入探究为什么这个需求被提出，背后的业务目标是什么。围绕原因、动机、目标，我们可以这样提问：
在问为什么时，我们要深入挖掘，往深层次去挖，多问几个为什么。这就是5Y分析法：基于上一次问题的解答，继续追问为什么，深入了解动机。如：
这个例子并不是标准的，只是表达这个意思——用户想要的，并不是他们真正需要的，产品经理需要找到最核心的问题并进行解决。3）Where（在哪里）
这个问题用于了解需求发生的前后环境和具体场景，我们需要了解需求的应用场景和使用环境。
4）When（何时）
这个问题用于了解需求发生的时间和周期，围绕「时间」相关的问题。我们需要了解需求的紧急程度和时间要求，用于版本规划与项目立项。
5）Who（谁）
这个问题用于了解谁会受益或者受到影响，需求是为谁做的。
6）How（如何）
这个问题用于了解需求的实现方式和具体操作步骤，「How」是需求分析偏后的部分，我们需要将需求如何实现、如何设计等，包括设计方案、技术实现、资源投入、团队协作等方面。
7）How much（多少）
这个问题用于了解需求的成本和资源投入，产品经理需要知道成本，而不是就想着做需求，成本与价值、投入与产出，是来评价你的成绩的。
5W2H就是提出各类问题，当你把以上问题有了答案，这个需求问题也就弄的很透彻了。在分析过程中，当出现新的问题时，可以继续运用 5W2H 方法，对新问题继续进行分析。然后遇到再连续问5个为什么，从深度上挖掘问题。
找到问题的关系，划分出前后顺序、因果关系、关联关系、问题发生的频率、重要性、严重性。
解决方案可以新增功能，可以是一个策略的调整、可以是引入一个新技术，也可以是由产品经理解决，也可以由研发解决、也可以有业务方解决等等。
可行的解决方案会有很多，你可以把你能想到的都写出来。
但是有时候自己很难找到很好的解决方案，甚至很多时候一点思路都没有。
其实你可以放心，你能遇到的问题，肯定不是无解的问题。
方法总比问题多。
我的所用的最笨的方法就是多学多看，尽可能地多了解涉及到的内容。
学什么？和你工作中有关联的都可以学。
看什么？大到行业报告，小到竞品的版本更新说明。
总之，就是多了解，多学习。
如果你想自己有掌控感，就是要知道的多。
有下边几种方式可以帮助到你：
1）看行业通用方案，找业内人员问问。
2）找竞品，看竞品如何解决的。
3）找人问，问问别人是不是遇到过对应的问题。问研发、问业务方、问运营、问其他产品经理、问领导，看别人有没有建议。
4）问AI、Baidu、Google搜，看是否有其他网友分享出解决方案。
5）去垂直网站去找。每个行业都有一些垂直的社区、论坛，都可以去问去找。
6）去群里问，比如我在搞药学服务时，我混进了一个药师群，经常在群里问，有些药师还挺爱回答。
7）花钱，找人付费咨询。
……
当你通过学习积累，不断提升，不断积累经验。
当熟练后，就能直接看透需求目标与要解决的问题，能找到的解决方案会越来越多。
我们可以多出几个方案，让大家去评估去选择，然后最终决策出一个。
当解决方案定完后，产品经理可以与业务方、需求方、研发测试、领导初步评估方案，大家共同敲定一个都认同的方案。
在我们给出解决方案前，自己先从下方内容判断下：
1）最基本的：是否能满足需求，是否能解决问题，是否和目标一致
2）看投入成本：如果为了解决一个需求，2个解决方案都能满足需求，方案A需要7天上线，方案B需要3天上线，那就选方案B。
3）看紧急程度，着急就先出临时解决方案，比如有个bug直接影响到线上使用了，那就先采用个最简单最快的临时解决方案，先满足线上使用，然后在出一个最终解决方案，彻底解决这个问题。
4）看解决方案引发的新问题以及对当前业务的影响程度：如果引发新的问题，那就一并把新问题的解决方案也写出来
5）看规划，如果解决方案和下个季度的规划有重合，那我们就放到下个季度去做，先临时把问题处理了。
如果还是确定不了，那就找领导拍，把每个方案的好处与坏处写清楚，让领导去选择；
也可以拉会或者是私下找到团队的同学，和他们沟通，看要使用哪种方案。
我真实工作中遇到的，运营反馈：后台导出数据超过1万条时，出现乱码，而且下载很慢，页面经常卡死。
我们先看问题描述：
1）导出1万条数据，出现乱码
2）下载慢，页面卡死
先用5W2H分析下：
1、what：
1）描述的问题是什么？——导出1w条数据，有乱码，下载慢，页面卡死
2）导出 5k 条数据也有这个问题吗？——没有这个问题
3）乱码内容是什么？——看提供的Excel
4）卡死时页面是什么样子？——点击没有任何反应，浏览器出现提示：页面无响应
2、why：
1）已经导出了1w条乱码数据，为什么还会说下载慢，页面卡死？——有时候可以导出来，但是有时候也会卡死，过好久才下载出来。
2）为什么要导出1w条数据？——为了导出数据与合作方进行对账
订单数据也同步给合作方了，为什么还要用Excel对账？——合作方数据只有10月之后的，10月份之前的数据没有同步
2）为什么会出现乱码？——数据量太大，程序处理起来有bug
3）为什么下载慢，页面卡死？——因为数据量大，导出使用的同步下载，导出过程中不能去做其他操作，当数据量过大时，服务器负载太高，程序处理超时，导致页面无响应
3、when：
1）何时出现这个问题？——导出1w条数据时，当导出5000条时没有出现
2）什么时候要解决这个问题？——运营说影响线上使用，需要尽快解决。
3）导出对账用Excel的频次高不高？——每月初导出上个月的，每年要导出全年的。
4）这个问题发生的频率高不高？——只要数据量超过1w都有这个问题，要么是导出乱码，要么是页面卡死。
4、where
1）哪个列表的导出有这个问题？——订单明细列表，其它列表导出1w条数据时，没有出现这个问题
2）在哪一步出现的卡死现象？——当点击导出按钮后，页面开始加载后，就不再有响应。
5、who
1）谁导出发现的问题？——运营用户后台导出时发现的问题
2）其他人导出也有这个问题吗？——任意角色导出都有这个问题
经过分析，我们先确定我们解决这个问题的目标是：能快速导出正确数据，且数据能够满足对账需求。
基于上面的分析，提炼出3个核心问题：
1）数据量大
原因：导出数据的字段太多，导出的数据量也太大，1w条数据Excel文件大小有10M
2）下载出现乱码
原因：程序bug
3）下载的很慢，页面经常卡死
原因：数据量大，由于同步下载，每次都要等程序下载完才能进行其他操作，当数据量太大时，程序处理超时后就会报错。
运营说今天就要发给合作方进行对账，然后合作方进行打款。
这涉及到钱的，可不能卡在产品经理这。
我们得先给出临时方案，先让运营能导出来数据。
临时方案：先按时间进行筛选，每次导出的数据量导出少点，多导出几次。
如果导出的次数很多，那就找研发，让研发从数据库直接导出。
然后我们需要同步继续将这个问题进行解决：
对于下载出现乱码，这个就是bug，交给研发处理。
对于数据量大，下载慢，页面卡死的问题，最终到底都是由于数据量大导致的，那我们的解决方案就要重点关注数据量大这个问题。
1、数据量大：分为导出的行数多、导出的字段多
如何解决：
1）只导出对账用的字段，非必要的字段不导出，减少导出的字段，由原来的45个字段减少到5个
2）每个Excel设置上限，超过5000条数据时分成多个Excel文件，然后人工手动合并
3）同步下载修改为异步下载
转化成系统解决方法则是：
功能方案1：
1）新增勾选导出字段，导出前勾选需要的字段。（原计划只导出对账用字段，但是功能能使用场景太少，为提高灵活性，我们进行配置化，由运营手动勾选）
2）修改为导出压缩包，每5000条数据导出一个Excel，多个Excel合并成一个zip压缩包
功能方案2：
1）新增「下载中心」模块，同步下载修改为异步下载，用户选择导出后，在「下载中心」里下载处理好的Excel。
方案基本成型，和反馈问题的运营沟通后没有问题。
然后我们再看使用那种方案彻底解决这个问题：
那就看资源、看成本、看规划，
功能方案1：涉及到前端调整、后端调整
功能方案2：开发反馈周期大，领导说咱们下季度要把后台统一放到新后台，在新后台再做异步下载，这个后台先不改了。
OK，方法2直接淘汰。
所以，最终我们定的解决方案是方案1 只做 分Excel下载，前端页面的调整先不做。
这个方案可以解决问题，运营表示没问题，后端表示没问题，领导也没说啥。
那我们就敲定这个方案，放到下个版本里，等我出详细PRD，然后排期做。
解决问题是产品经理的日常，从很多信息中决策出一个可行的解决方案。
很难有一个方法能让你快速的找到解决方案，我只能给出具体的步骤与示例，最终靠的就是产品经理自己的能力。
不仅是需求分析能力，还有行业了解能力、竞品分析能力、沟通协调能力、挖掘问题的能力、经验丰富程度……
所以把产品看做一个病人的话，产品经理不仅要看病，还要能开药做手术，把一个产品给治好。
可能你会想到多个解决方案中，我们可以做ABtest，不过做ABtest意味着要多倍资源的投入，还要有能支持做ABtest的系统支持，绝大多数公司都不会做。
不过你觉得你的方案不是最好的，也不用担心，我们还能进行迭代，继续去优化。
有问题就解决问题，没有问题就去发现问题。
本文由人人都是产品经理作者【王大鹿】，微信公众号：【产品大鹿】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。