在各种琐碎信息中，如何找到清晰的产品发展方向？

在承接各种需求时，我们经常会遇到完全不同的业务类型。这时候，常遇到的一个挑战是：如何确定产品的下一步发展方向要怎么走？

这次，将会以我在试用业务中的真实分析案例，来为大家介绍一种思路，用于解决这样的场景。

每一个业务都是从了解情况开始的。与项目组成员沟通 / 搜索 / 体验竞品 / 提取数据等等渠道，我们能获取到以下信息：

• 用研报告
• 行业报告
• 竞品情况
• 产品数据
• 产品过去迭代经验
• 业务资源配置情况

只有获取足够的信息，才能客观地看清全局。信息源越单一，得出的方向的可靠度就越低——巧妇难为无米之炊嘛。

（试用案例中，从各方获取到的一些前期资料）

关于如何获取更多信息的方法，我们在过去的文章里也有简单地谈到过，戳这里可以参考。

这里就不赘述了。

在上一个阶段中，我们获取了各种琐碎的信息。

现在需要对信息进行初步的梳理，找一个分类维度把它们规整起来。这个维度的选取，取决于你面对的问题的大小。

例如，在“支付流程中用户遇到的问题”这样比较明确的、较小的问题里，分类维度很明显是流程中的不同阶段，这样的做法也常见于 journey map 中。

而如果问题是：“从试用业务的生态系统中确定现在的迭代方向”这样的大问题，首先，需要区分组成这个生态系统的各方利益相关者，在试用业务这个场景里，即是“用户、商家和平台”。

好了，现在问题都被规整得很清晰了，那么我们是不是要开始去解决这些问题了呢？

——如果你这么做了，那么就能明白为什么需求是永远做不完的。因为发现问题很容易，细碎的小问题总是层出不穷、解决不完的。

真正困难的事情，是决定先做什么，后做什么，不做什么。

在上一步中，我们选取的最大维度是利益相关的各方，从发散问题的角度来看，这样是能把现有问题囊括得比较全面的。

但是当进入到解决问题的思路时，会发现有些问题与问题之间有因果关系，例如用户侧的“写测评流程体验差、感受不到奖惩机制”等这些问题，是导致了商家和平台侧的“测评质量低”的原因。这就说明我们现在得出的问题不够聚焦，还有整理的余地。

因此我们需要把各方的问题再进行归类。归类的原则如下：

• 能在同一个方案下解决的，归为一类
• 各项问题都指向同一个更大的系统问题的，归为一类
• 实在无法归入其他类的，独立成一类

这样问题就更清晰而聚焦了，可以开始进入下一步的价值判断了。

把各个大问题列在表格里，分别评估每一个问题的解决成本、获得的收益、可能遇到的风险。这样就能知道这些问题的解决是否有价值、投入产出比如何了。 

这一步的关键点是，一定要与项目的各方小伙伴一起去讨论，因为大家手上掌握的资源是不一样的。

例如我们是设计侧，对于我们来说“页面挑选不便&调性不高”这种问题，就一定是解决起来更低风险、更好去预估成本及收益的；“寻找更多流量来源”这种，就是相对陌生的目标，乍一看也不知道如何下手。但换成一个运营小伙伴，这可能是他 / 她得心应手的事情。

不同的角色，视角及资源不同，一起坐下盘一盘，才能确定哪个问题最好解决、哪个问题最有性价比、哪个问题风险最大最难做。

以下产品阶段分析用的图表，用来判断我们当前的产品策略；那么从试用案例里遇到的场景来看，试用业务的位置在哪里？

首先我们可以确定，试用业务活下去是没有问题的，因为数据表明，我们已经拥有较高粘度的用户群体了；也证明了试用这个业务从用户需求角度是不需要再去讨论验证的了。

但我们也还没有到成熟期，一是用户量级不够；二是还没有盈利。所以可以假设我们在成长期的初期。

这时候，上一步推导出来的关键问题及机会点，就可以按照产品发展的基本原则，区分出优先级来了：在产品处于体验问题较大的阶段，先解决基础体验，再扩大产品的规模、试验更多机会点。

到了这一步，我们未来要走的方向就很清晰了。接下来就可以深入到各个方向的细节问题、开始发散解决方案啦。

让我们再来回顾一下整体的思路。从琐碎的问题到聚焦的几个清晰方向，一共走过了这些步骤：

• 收集信息
• 问题整理
• 归类重组
• 评估成本、收益、风险
• 以产品阶段确定优先级

未来再遇到同样的场景，就可以用这样的思路去一步一步确定大方向，不用怕被各种问题给绕晕了。