对于产品经理而言，结构化思维是不可缺少的素质之一。本文着眼工作中的结构化思维，结合案例阐述在产品设计的过程中，业务知识和解耦合能力两者结合对于产品的重要性和关键性。推荐产品伙伴们阅读学习～
解耦合，本质是一种结构化思维。
考过公务员的同学应该都知道结构化面试的含义，镜同学认为，结构化思维对于产品经理来说尤为重要，因为这是产品思维的最底层的认知基础。
也许你在日常工作中会发现一个现象：
有这么一些人，无论何时，当你和他交流时，他的回答总是很有层次。
比如，你问他一个问题时，他会告诉你，关于这个问题他有三点看法：首先可能会先描述下问题本身以及问题的原因；其次谈问题的解决方案；最后再说下问题可能带来的危害。
这是一个很简单的问题决策模型，但是足以说明，通过结构化的表达和持续练习，就会让你更容易看到问题的本质，也让目标用户的理解成本更低。
结构化更容易贴近本质需求，而结构化本身关键需要明确不同结构间的边界，要有清晰的结构层次，往往也意味着需要识别出来不同结构之间的区别和界限。
这就是解耦合的真谛：划分不同的领域事件。
而这对于产品经理在需求调研、产品设计的全生命周期都极有帮助，毫不夸张地说，想要成为优秀的产品经理，应当有意识地提高自己的解耦合能力。
为了方便你们理解，我举一个小的产品案例：
因为我们集团某个事业部提出了一个新的业务需求，那就在线课程的业务服务，这就需要我们进行在线课程的产品设计，所以上周我们安排团队的一个产品经理，进行了在线课程的需求调研和竞品分析。
先简单介绍下我们的产品规划，其实1.0版本的业务逻辑和产品设计也很简单，用户分为学员端、教师端和平台运营端，基础的业务场景是：
教师申请入驻平台，平台进行入驻审核，审核通过后教师可以发布视频，学员可以下单购买课程并可进行在线支付，完成后即可在线观看视频学习。
上周五，我们对产品经理的需求调研和竞品分析情况进行了评审讨论。
其中，在运营平台的竞品分析中，她讲到一个关于订单的产品设计，她发现竞品竟然有“课程订单”和“支付订单”两个一级菜单，她觉得应该合在一起，只需要在课程订单列表或详情里，把支付信息加进来就行了。
她认为没有必要做单独分开，一个菜单功能就能解决的问题，再进行分拆这不是在浪费开发资源吗？
如果是你来做这个产品分析，你会怎么理解的呢？
其实，如果有了足够的业务知识后，你就会明白这是两个业务领域，你就知道产品设计时是应该分开的，不同的领域事件应该做解耦合处理的，这样不是冗余反而是精炼。
我们简单分析下：
首先，我们要有基础的业务知识：
大家要知道，对于电商场景来说，订单是交易的载体，涉及交易一般都是三流合一，比如，业务流，也称为商流或货物流、资金流和发票流。
显然，这里的课程订单就是业务流，是对用户下单这个业务的数据处理，而支付订单则是资金流，是对资金信息的处理，或者你还可以简单理解成是给财务对账用的。
因此，两者面对的是不同的业务场景，当然就应该解耦出来，产品也应该有所侧重。
退一万步来讲，课程订单里可以冗余进去支付信息，但一定是两个领域，一定解耦合，课程订单里一定是订单状态，支付订单里一定是支付状态，当然，严格来说，支付订单应该叫支付流水。
我们还应该牢记两点：
所以你看，有足够的业务领域知识的基础上，更要学会对业务领域解耦合，这才是设计好产品的关键。
其实，对于软件开发来说，产品经理是关键的源头角色，我们应该有敬畏之心，事实上，只有当我们掌握了足够多的知识，有了领域和边界的思维之后，才能从源头避免技术负债的产生。
这一切，可能都要求我们在具体的产品设计时要有优秀的产品思维，要具备解耦合的意识和结构化的能力，当然，最关键的是一定要有边界理念和破界勇气。
所谓的破界，不是破外在现实的边界，而是破内在认知的边界。
正如古人所言：小知不及大知，认知无止境。
产品大峡谷，公众号：产品大峡谷，人人都是产品经理专栏作家。七年B端产品经理，供应链物流与金融领域，擅长需求设计、业务指导、商业观察等。
本文由@产品大峡谷 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。