Intro to the Problem Driven Structure
The key to solving any complicated problem is to break it down into smaller, simpler sub-problems to create an easy to follow roadmap to the solution – this is the structure
There are two main possible case focuses – Issue based cases - whose objective is to solve a specific problem and Cases where you need to support strategic decisions. A structure is fundamental in both instances.
Breaking down a problem helps us quickly reach a solution. A complex business problem is invariably a collection of smaller sub-problems. Once you identify the sub-problems, it becomes easier to tackle them and simplifies the main problem.
Structure requirements
MECE stands for Mutually Exclusive - or ME - and Collectively Exhaustive - or CE. Mutually exclusive implies that no element of your structure overlaps with any other.
Level Consistency. This is a simple idea - All sub-groups should belong to the same logical category: that is, be subsets of the same set. In other words, if A and B are listed together, A cannot be a subset of B.
Simplicity is ensured by avoiding structures that are too complex and/or lead to overlaps.
Unless you have a specific reason, you should avoid over-segmenting the problem. Materiality should be on your mind throughout the case
The final requirement for our structure that we need to keep in mind is actionability. In short, this means that, when breaking down a problem, you should try to choose drivers which you have control of.
When segmenting a problem we can use multiple drivers to break that problem down - the key is finding the one that works best. A few examples of drivers are:
- Financials
- Customer characteristics
- Value chain
- Geography
- Product lines
- Company-internal vs. external market-driven factors
A mathematical breakdown consists of describing an element using a mathematical operation between its sub-elements
When dealing with cases, the initial problem to be segmented can be expressed as either an issue or an hypothesis tree.
An issue tree structure involves breaking down the identified problem into sub-problems to be analyzed.
A hypothesis tree, on the other hand, involves a structure which assumes the problem can be solved, and then breaks it down into sub-hypothesis
Deploying, testing and communicating our structure.
Although, you could start from scratch to build each structure, you would realize that, often, parts of your structures will recur. These will be part of your toolkit; they are the starting points or building blocks for bigger issue trees.
Some key building blocks are:
- Segmentation and Estimates
- Profitability
- Pricing
- Valuation
- Competitive interaction
You can find them in the building block section of our course.
Let’s recap some of the dos and don’ts or common mistakes made during structuring.
