Skip to main content

Part III

PART III: Build The Case-Solving Architecture

Chapter 5: The Case-Solving Process

Video: Where Do We Even Start: The Steps to Solve a Case

Resource: There is a case-solving tool developed in Excel by Cam Welsh that follows this process, available at https://buymeacoffee.com/treadsoftly.

A strong case solution follows a logical progression.

  1. DECIPHER: What is really happening?
  2. ANALYZE: What do we need to understand?
  3. DEVELOP: What could the organisation do?
  4. DECIDE: Which alternative is best?
  5. RECOMMEND: What exactly should the organisation do?
  6. IMPLEMENT: How will it happen?
  7. MEASURE: How will we know it worked?
  8. COMMUNICATE: How will we make the solution clear and persuasive?

This sequence is not a rigid formula. It is a thinking architecture. Sometimes you will move backwards. A new insight may change your problem statement. A financial analysis may cause you to rethink an alternative. A capability constraint may eliminate an otherwise attractive option. Good case teams iterate.

PART III: BUILD THE CASE-SOLVING ARCHITECTURE

Once you have deciphered the case and understood the organisation, you need a structure for turning that understanding into a decision. Case solving can feel chaotic.

  • There is information everywhere.
  • There are multiple problems.
  • There are competing perspectives.
  • There are frameworks to consider.
  • There are financial questions.
  • There are strategic alternatives.
  • There are implementation challenges.T
  • There is always a clock running.

A strong case-solving architecture gives the team a way to organise that complexity. The architecture in this manual is:

DECIPHER → ANALYZE → DEVELOP → DECIDE → RECOMMEND → IMPLEMENT → MEASURE → COMMUNICATE

This is not a checklist that must be completed once and then forgotten. It is a thinking architecture.

  • You may move forward.
  • You may move backwards.
  • You may revisit earlier decisions.
  • You may discover that an assumption was wrong.
  • You may eliminate an alternative because the financial analysis does not work.
  • You may discover a capability constraint that changes your recommendation.

That is not a breakdown of the process. That is good case solving.

Chapter 5: The Case-Solving Process

Central Question

How do you turn a complex case into a structured, defensible decision?

Video: Where Do We Even Start: The Steps to Solve a Case

Resource: There is a case-solving tool developed in Excel by Cam Welsh that follows this process, available at https://buymeacoffee.com/treadsoftly.

A strong case solution follows a logical progression.

DECIPHER: What is really happening? --> ANALYZE: What do we need to understand? --> DEVELOP: What could the organisation do? --> DECIDE: Which alternative is best? --> RECOMMEND: What exactly should the organisation do? --> IMPLEMENT: How will it happen? --> MEASURE: How will we know it worked? --> COMMUNICATE: How will we make the solution clear and persuasive?

These eight stages create the basic architecture of the Discover Your Mad Skills approach to case solving.

1. DECIPHER

What is really happening? Before you solve the problem, understand the problem. This is the work introduced in Part II. You are trying to establish:

  • What organisation are we advising?

  • What business are they really in?

  • What is happening?

  • What has changed?

  • What is the central problem?

  • What decision must management make?

  • What constraints matter?

  • What does success look like?

The output of this stage should be a clear problem and decision frame.

The Decipher Test

Your team should be able to complete: The organization is facing __________ because __________, and management needs to decide __________. If you cannot complete that sentence confidently, you may not be ready to move into detailed analysis.

2. ANALYZE

What do we need to understand? Once you understand the problem, determine what you need to know to make a good decision. This is where frameworks, data, calculations, research, and other analytical tools become useful. But remember the principle from Part II: Don't start with a framework. Start with a question. Ask:

  • What do we need to understand?

  • What information would change our decision?

  • What are the important drivers?

  • What are the organisation's strengths and weaknesses?

  • What external factors matter?

  • What financial implications exist?

  • What capabilities are available?

  • What risks and constraints exist?

The objective is not to complete every possible analysis. The objective is to generate decision-relevant insights.

From Information to Insight

One of the most important transitions in case solving is:

Information → Analysis → Insight → Implication

For example:

  • Information: Sales have declined 12%.
  • Analysis: Customer retention has declined, particularly among a high-value customer segment.
  • Insight: The sales decline is being driven disproportionately by the loss of valuable existing customers rather than a broad decline in market demand.
  • Implication: The organisation may need to prioritise retention before investing heavily in customer acquisition.

The insight changes the decision. That is the purpose of analysis.

3. DEVELOP

What could the organisation do? Once you understand the situation, generate potential ways forward. This is where teams begin developing alternatives. Good alternatives should be:

  • Relevant to the problem

  • Consistent with the organisation's objectives

  • Feasible

  • Meaningfully different

  • Capable of creating value

Avoid creating alternatives simply to have three boxes on a slide. Three alternatives that are essentially the same are not three alternatives. Likewise, a "do nothing" option may be useful as a benchmark, but it should not automatically count as a meaningful strategic alternative.

Think in Strategic Choices

Alternatives might involve decisions about:

  • Where to compete

  • Who to serve

  • What products or services to offer

  • How to price

  • How to distribute

  • Whether to build, buy, partner, or acquire

  • Whether to invest or divest

  • How to change the business model

  • How to improve operations

  • How to respond to competitors

The goal is to create real choices.

4. DECIDE

Which alternative is best? Generating alternatives is not enough. You need to choose. This is where many teams struggle. They present several alternatives and then jump to: "Therefore, we recommend Option A." The missing piece is the decision logic. Why is Option A better? The answer should be based on explicit criteria. Possible criteria include:

  • Strategic fit

  • Financial impact

  • Customer impact

  • Feasibility

  • Risk

  • Competitive advantage

  • Organizational capability

  • Speed

  • Sustainability

  • Stakeholder impact

The appropriate criteria depend on the case.

The Decision Test

Ask: What would make one alternative better than another? Then test each option against those criteria. For example:

Decision Criterion Option A Option B Option C
Strategic Fit High Medium High
Financial Impact High Medium Low
Feasibility Medium High Low
Risk Medium Low High
Overall Strongest Moderate Weakest

The table itself is not the answer. The purpose is to make the trade-offs visible.

5. RECOMMEND

What exactly should the organisation do? Once you have made the decision, turn it into a clear recommendation. A recommendation should not simply name an option. It should communicate:

  1. What? What exactly should the organisation do?
  2. Why? Why is this the best choice?
  3. How? At a high level, how will it create value?
  4. What does it require? What resources, capabilities, investment, or changes are necessary?
  5. What is the expected impact? What should the organisation gain?

A strong recommendation connects the decision to the organisation's problem and objectives.

The Recommendation Formula

A useful structure is: We recommend [ACTION] because [KEY REASON], enabling the organisation to [EXPECTED IMPACT]. We will do this through [KEY INITIATIVES], supported by [CRITICAL RESOURCES/CAPABILITIES]. This is not a script. It is a thinking tool. The actual wording should reflect the case.

6. IMPLEMENT

How will it happen? A recommendation without implementation is incomplete. The organisation needs to know what happens next. Consider:

  • Actions

  • Owners

  • Resources

  • Timing

  • Dependencies

  • Capabilities

  • Risks

  • Change management

A useful implementation structure is:

  1. NOW: What needs to happen immediately?
  2. NEXT: What needs to happen once the initial stage is underway?
  3. LATER: What needs to happen to scale, optimise, or institutionalise the solution?

The exact timing will depend on the case. The important point is to demonstrate that the recommendation can move from strategy to action.

Implementation Is More Than a Timeline

One of the most common mistakes is treating implementation as: Year 1 → Year 2 → Year 3. A timeline alone does not explain implementation. You also need to consider:

  • Ownership: Who is responsible?
  • Resources: What is required?
  • Dependencies: What must happen first?
  • Capabilities: What does the organisation need to be able to do?
  • Risks: What could prevent execution?
  • Change: Who needs to behave differently?

A strong implementation plan answers: How does the organisation actually make this recommendation happen?

7. MEASURE

How will we know it worked? Every recommendation should have a definition of success. Measurement connects the recommendation back to the organisation's objectives. Depending on the case, measures could include:

  • Revenue

  • Profit

  • Market share

  • Customer acquisition

  • Customer retention

  • Customer satisfaction

  • Cost reduction

  • Productivity

  • Employee engagement

  • Operational performance

  • Environmental impact

  • Strategic milestones

Leading and Lagging Indicators

Consider both.

Leading indicators: These provide an early signal that the strategy is working. Examples:

  • Customer inquiries

  • Trial sign-ups

  • Employee adoption

  • Training completion

  • Website traffic

  • Conversion rates

Lagging indicators: These show the eventual outcome. Examples:

  • Revenue

  • Profit

  • Market share

  • Customer retention

  • ROI

  • NPV

The best measurement systems often combine both.

The Measurement Test

Ask: If we came back six months from now, what would tell us whether this recommendation was working? If your team cannot answer that question, the recommendation may not yet be sufficiently developed.

8. COMMUNICATE

How will we make the solution clear and persuasive? Communication comes last in the architecture—but it should not be treated as an afterthought. The final presentation is the vehicle through which the judges experience your solution. Your team needs to determine:

  • What is the central message?

  • What does the audience need to understand?

  • What evidence matters?

  • What should be shown visually?

  • What should be left out?

  • How should the story flow?

  • Who communicates each part?

  • How will you handle questions?

This is where the work from the second Discover Your Mad Skills manual becomes particularly important.

  • Analysis creates the solution.
  • Communication creates understanding.

You need both.

The Architecture Is Iterative

The eight stages look linear:

DECIPHER → ANALYZE → DEVELOP → DECIDE → RECOMMEND → IMPLEMENT → MEASURE → COMMUNICATE

Real case solving is rarely linear. You may discover something during financial analysis that changes your understanding of the problem.

  • You may discover a capability constraint that eliminates your preferred alternative.
  • You may develop an alternative that reveals a new stakeholder issue.
  • You may discover during implementation planning that the recommendation is not feasible.
  • You may identify a measurement problem that forces you to rethink the recommendation.

This means the process can look more like:

DECIPHER → ANALYZE → DEVELOP → DECIDE --> New Insight --> Back to ANALYZE --> New Constraint --> Back to DEVELOP --> New Financial Result --> Back to DECIDE --> RECOMMEND → IMPLEMENT → MEASURE → COMMUNICATE

This is not wasted work. Iteration is part of the process.

The Architecture as a Series of Questions

An effective way to remember the process is to turn each stage into a question.

Stage Question
DECIPHER What is really happening?
ANALYZE What do we need to understand?
DEVELOP What could the organisation do?
DECIDE Which alternative is best?
RECOMMEND What exactly should the organisation do?
IMPLEMENT How will it happen?
MEASURE How will we know it worked?
COMMUNICATE How will we make it clear and persuasive?

This creates a simple mental model that can be used under competition pressure.

The Case-Solving Architecture Test

At any point in a case, ask:

  • Where are we?
    • Are we still deciphering?
  • Are we analysing?
    • Are we developing alternatives?
  • Are we deciding?
    • What question are we trying to answer?
    • If the team cannot identify the question, you may be analysing without purpose.
  • What do we know?
    • Separate facts from assumptions.
  • What don't we know?
    • Identify the gaps that could affect the decision.
  • What has changed?
    • Be willing to revise earlier conclusions.
  • What happens next?
    • Always know the next decision or analytical step.

A Practical Team Exercise

When you begin a case, put the eight stages on a whiteboard:

  • DECIPHER
  • ANALYZE
  • DEVELOP
  • DECIDE
  • RECOMMEND
  • IMPLEMENT
  • MEASURE
  • COMMUNICATE

Then use them as a team navigation system. You do not need to complete each stage perfectly before moving forward. Instead, ask: What do we need to know before we can move confidently to the next stage? This keeps the team moving without encouraging premature decisions.

The Architecture Under Competition Time Pressure

Time pressure changes the depth of your analysis. It does not eliminate the need for structure. For a short case, you may spend only a few minutes deciphering the situation. For a 24-hour case, you may spend hours developing and testing alternatives. The architecture remains the same.

  • The depth changes.
  • The process does not.

This is particularly important when teams move between different competition formats. A six-hour case and a 24-hour case require different levels of analysis, but both still require a clear path from problem to decision to action.

Discover Your Mad Skills Principle

Structure creates speed.

Teams sometimes believe structure slows them down. In reality, a clear architecture can make teams faster because it helps them recognise:

  • What they are doing

  • Why they are doing it

  • What information they need

  • What decision they are working toward

  • When they have enough analysis

The goal is not to eliminate thinking. The goal is to focus thinking.

Key Takeaways

  • A strong case solution follows a logical progression.

  • The Discover Your Mad Skills architecture is:
    DECIPHER → ANALYZE → DEVELOP → DECIDE → RECOMMEND → IMPLEMENT → MEASURE → COMMUNICATE

  • Each stage answers a different question.

  • Analysis should support a decision rather than exist for its own sake.

  • Alternatives should create meaningful choices.

  • Decisions should be based on explicit criteria and trade-offs.

  • Recommendations should be specific.

  • Implementation turns strategy into action.

  • Measurement defines success.

  • Communication turns the completed solution into a persuasive story.

  • The process is iterative rather than strictly linear.

  • New insights should be allowed to change earlier conclusions.

  • Structure does not replace judgment—it creates the conditions for better judgment.

The Bottom Line

A case is not solved when you have an answer. A case is solved when you can explain how you got from the problem to the decision—and how the organization can turn that decision into results.

The Complete Architecture

DECIPHER: What is really happening? --> ANALYZE: What do we need to understand? --> DEVELOP: What could the organisation do? --> DECIDE: Which alternative is best? --> RECOMMEND: What exactly should the organisation do? --> IMPLEMENT: How will it happen? --> MEASURE: How will we know it worked? --> COMMUNICATE: How will we make it clear and persuasive?

Don't treat this as a formula. Use it as your map.

Back to top