B端产品经理：复杂业务方案设计的7个小技巧.docxVIP

B端产品经理：复杂业务方案设计的7个小技巧 编辑导语：作为一名产品经理，需要有将业务转化为产品设计方案的能力。对于比较复杂的业务流程，该怎样更好地进行转化？作者总结了7个快速了解业务流程和范围，并转化成可行的业务方案产品设计，分享给你。 将业务流程转化为产品设计方案是一个B端产品经理的基础能力。那遇到复杂的业务逻辑时，如何更好地转化为设计方案呢？ 不管是自家产品的设计还是为不同合作客户项目设计方案时，B端产品经理需要深入到业务里做方案设计。 此时需要快速了解业务流程和范围，并利用合理的工具和方法梳理业务流程，设计出到合理的产品方案。 分享7个小技巧。 一、复杂逻辑里找到关键主路径 在链路比较长的业务里，多角色，多权限，多状态的流程有时候会混在一起，不好拆解。此时，从各个角色流程中找到核心的主流程来进行设计。利用一条主线??关键逻辑两个维度进行梳理，可以将复杂的功能点进行拆解： 比如我们在设计一个订单流程，我们可以按照订单全部的时间状态转化，提供一个这样的梳理结构： 按照订单的状态，不同订单状态下不同的操作，以及发生订单状态更新时的操作行为以及各个行为的判断条件。 再比如我们设计一个分销系统时，可以按照业务时间先找到主脉络 分销方式-上下级关系-记录分销行为逻辑-返利触发行为-触发行为判断条件； 用二维的表格，找到关键业务路径，再围绕业务路径找到影响的维度，可以帮你简化复杂逻辑。 二、不熟悉的行业里做好关键词的定义 设计产品的过程，是不断学习的过程，有非常多的产品经理其实是业务专家，但是也不乏相同行业内，不同客户的需求和业务定义是不一样的。那么在此时，我们找到关键逻辑点的核心定义，有助于简化复杂逻辑。 最常见的比如我们设计一个数据系统时，关键统计数据的指标定义是什么？业务描述和数据来源描述是我们要确定的； 我们在设计一个订单系统时，结算金额的定义是什么？有哪些限定条件？计算公式是什么？业务方给出明确定义就可以帮我们框定好功能范围和影响因素。 三、逐步拆解：先定义好功能架构，再填充血肉 在前期梳理业务时，要搭建一个初步的功能结构。将所有涉及到的功能进行分类，避免后期陷入到细节内后遗漏功能。 这个架构并不是一蹴而就完成的，需要多次的调整，可能模块要调整，可能分类要调整，也可能到后期有些功能是要去掉的，可能 被其他的业务功能直接消化掉了。 搭建功能架构的好处是：帮助你圈定范围，避免遗漏； 后续就是填充细节。填充细节的过程中，就是将数据流，业务流，结合架构做不断的比对和调整。最后方案逐步完善。 四、善于用客户的业务能力 我们做B端产品设计时，可以利用客户的业务优势，辅助我们设计产品。 例如关键页面的字段要求，导出数据的表头设计，对方的项目负责人和其他业务人员的沟通记录结果，我们能利用身边有能力的资源时，一定不要忽略他们的价值。有时能起到事半功倍的效果。 最近一次过需求时，在一个关键业务页面字段沟通时，我发现对方其实有非常清晰的业务诉求，在这种情况下，直接让对方提供详细的要求即可。 五、善于画图做沟通 和客户沟通，或者和技术团队沟通时，画图是最高效的沟通方式。 一般两种图效率最高：一种是业务流程图；一种是页面交互图。 业务流程图帮助和客户确认需求主路径是否是正确的，页面交互图和客户确认设计方案是否是符合业务逻辑和关键字段。 沟通时，直接在白板上画图沟通，效率特别高。 B端产品销售阶段，画图也是沟通效率非常高的。我们之前就通过一个用户服务体验地图的流程，在和另一个公司做方案PK时取得了优势，拿下了订单。 和客户沟通后，将业务流程画出架构图，其实也是团队理解能力和设计转化能力的体现。 六、判断力：解决方案和需求 所有的客户都喜欢给解决方案。 但是解决方案背后不见得是客户的需求。 产品经理一定注意这点： 他说这个页面你要给我加一个输入框，我要记录东西。但是其实是对方在统计的时候需要能根据这个字段进行筛选；那我们需要增加的是一个字段值并且字典内容要定义好，而不是一个简单的文本框； 他说你这里要给我做一个按钮，我一点击就能转成另一个数据表了；但是其实解决方案背后是在说数据流的流转逻辑，真正的交互式设计方案，并不是一个按钮就可以解决的。 所以，在和客户沟通时，注意听客户解决方案背后的真实需求，大胆做决策。 七、将抽象的沟通转化为具象的业务场景 和客户沟通时，如果遇到发散性的客户，在描述需求时，特别喜欢将需求场景转化为比喻的场景。 比如在讨论整个模块设计时，客户说：这里很简单啊，就是像盖房子一样，你这里盖好了，再复制一下，那边数据就有了。我就可以把这个模式复制过去了。 在做方案落地的业务沟通阶段，如果你遇到了客户喜欢做比喻一定及时引导做转化。这样的比喻引导和实际的逻辑设计相差可能非常大。 如果产品经理想当然被客户带着思路走了，在设计方案时会非常危险。