Stop Overthinking. Start Moving. The Keystone Method Will Change How You Solve Problems.

How exactly 5 moves—like the keystone in an arch—hold your entire plan together

---

You're staring at a whiteboard covered in arrows, boxes, and question marks. Your team has been "brainstorming solutions" for 90 minutes. Everyone's knackered. And you're no closer to knowing what to actually do on Monday morning.

Sound familiar?

Here's the thing: we've got brilliant problem-solving frameworks. The 5 Whys for root causes. Wardley Maps for strategic positioning. Blue Ocean for competitive analysis. Each one useful. Each one leaving you with the same question:

"Right, but what do I actually DO?"

That's the gap. The chasm between insight and action. Between "we should" and "we did."

I've spent years watching smart people spin their wheels in strategy sessions. The best plans always had one thing in common: they knew exactly what the next 5 steps were.

Not 3. Not 10. Not "let's see how it goes."

Five.

So I built a framework around it.

---

What Makes This Different

Most frameworks excel at either exploration (5 Whys, Ishikawa) or visualisation (Wardley Maps). The Keystone Method™ bridges both—from problem exploration through to concrete action.

Think of it like building an arch. You need:

• Foundation stones (understanding the problem)

• Supporting stones (possible solutions)

• The keystone (the 5 moves that lock everything together)

Remove any of those 5 moves, and the whole structure collapses. That's why it's exactly 5—no more, no less.

Three Phases

DIVERGE: Explore the problem broadly through hypothesis generation

CONVERGE: Synthesise insights into actionable solution pathways

SEQUENCE: Define exactly 5 specific moves from decision to outcome

---

An Example: Support Team Drowning

Let me show you how this works with a real problem.

THE ANCHOR

Problem: Customer support response time increased from 4 hours to 14 hours over 6 months. Customer satisfaction dropping.

PHASE 1: DIVERGE (15 minutes)

First, we generate several possible hypotheses:

Initial Hypotheses:

• Volume increased 3x but team size only 1.5x (🟢 High likelihood, ⚡⚡⚡ High impact)

• New product features confusing users (🟡 Medium likelihood, ⚡⚡ Medium impact)

• Knowledge base outdated (🟢 High likelihood, ⚡⚡ Medium impact)

• No ticket routing/triage system (🟢 High likelihood, ⚡⚡⚡ High impact)

• Support team has poor tools (🔴 Low likelihood, ⚡ Low impact)

Then we dive deeper on the highest-impact hypothesis using 5 Whys:

H1: Volume increased 3x but team size only 1.5x

Why? Ticket volume jumped from 150/week to 450/week over 6 months

Why did tickets increase? New features launched without proper documentation

Why no documentation? Product moved fast, docs were an afterthought

Why afterthought? No ownership of knowledge base, fell between teams

Why no ownership? Never assigned when we were small, never fixed as we grew

Root cause: Organisational gap—no one owns user education/enablement

This deeper exploration revealed the real problem wasn't just capacity, but a systemic gap in how we support users.

1. Initial hypotheses brainstorm (5-7 sticky notes with icons for likelihood/impact)

2. Deep-dive on H1 using 5 Whys (vertical flow showing each "why" question)

3. Root cause highlighted at the bottom

PHASE 2: CONVERGE (15 minutes)

Looking at our hypotheses, we can generate three solution pathways:

S1: Just hire more people

• Cost: £££ (£150K/year for 3 agents)

• Time: ⏱️⏱️⏱️ Long (2-3 months)

• Addresses: H1 only

• Risk: Doesn't fix efficiency

S2: Fix the system

• Cost: £ (£8K for triage tool + contractor)

• Time: ⏱️⏱️ Medium (4-6 weeks)

• Addresses: H2, H3, H4

• Risk: Doesn't help if volume keeps growing

S3: Hybrid approach ← Chosen

• Cost: ££ (£75K: 1.5 agents + triage + docs)

• Time: ⏱️⏱️ Medium

• Addresses: H1, H2, H3, H4

• Tackles both capacity AND efficiency

PHASE 3: SEQUENCE (15 minutes)

Now for the 5 moves—the keystone that holds it all together:

MOVE 1: Implement ticket triage with auto-routing (Week 1-2)

• Owner: Alex (Head of Support)

• Success: 80% of tickets route correctly

• Why this first: Immediate efficiency gain, enables everything else

MOVE 2: Hire technical writer to rewrite top 20 KB articles (Week 2-4)

• Owner: Sarah (Product)

• Success: 20 articles published, >70% helpful rating

• Builds on: Having triage data to know which articles matter most

MOVE 3: Launch self-serve bot before ticket creation (Week 3-5)

• Owner: Jamie (Engineering)

• Success: 30% find answers without creating ticket

• Depends on: Move 2 (needs good content)

MOVE 4: Hire 1 full-time support agent (Week 3-7)

• Owner: Morgan (HR) + Alex

• Success: Offer accepted, start date set

• Timing: While moves 2-3 are in flight

MOVE 5: Review metrics at 8 weeks, decide on 2nd hire (Week 8-9)

• Owner: Alex + Product lead

• Success: Decision made with data

• Why last: All systems in place, can measure real impact

---

Why Five? The Constraint That Creates Focus

I tried different numbers. Here's what I learned:

Three moves: Too shallow. Feels like you're just getting started.

Seven moves: Starts feeling like a project plan. You lose the strategic view.

Ten moves: Now it's a backlog. Complexity creeps back in.

Five? Five is the Goldilocks number.

It's:

• Substantial enough to create real progress

• Focused enough to maintain momentum

• Memorable enough to communicate easily

• Odd enough to force prioritisation

But here's the real power: Five moves forces you to think in phases.

Can't fit your entire strategy in 5 moves? Good. Break it into phases. Complete these 5, learn, then define the next 5.

This is how the best teams actually work. They don't execute 47-item roadmaps. They execute 5 things. Learn. Then 5 more.

---

How to Use The Keystone Method

Step 1: Write Your Anchor (5 minutes)

Your problem, opportunity, or goal. Be specific.

Rubbish anchor: "Improve marketing"

Good anchor: "Increase qualified demo requests from 20/month → 50/month by Q2"

Step 2: Generate & Explore Hypotheses (15 minutes)

Brainstorm 5-7 possible causes or approaches. Tag each with likelihood and impact.

Then pick your highest-impact hypothesis and go deep:

Ask "why?" five times. Don't stop at the surface. The first answer is rarely the real answer.

Example:

• Conversion rate is low

• Why? Landing page bounce rate is 73%

• Why? Value proposition isn't clear

• Why? We're describing features, not outcomes

• Why? Engineering wrote the copy

• Why? No one owns product marketing

• Root cause: Missing role/function in org structure

This is where the magic happens. You're not just listing problems—you're finding the actual root cause.

Step 3: Create Solutions (15 minutes)

Look at your hypotheses (especially the one you explored deeply). Generate 2-4 solution pathways.

For each:

• What hypotheses does it address?

• Cost, feasibility, timeline?

• What are the risks?

Step 4: Define The 5 Moves (15 minutes)

This is your keystone. Each move must have:

• Action: Specific verb + deliverable

• Owner: One person (not a team)

• Dependencies: What must happen first

• Success Criteria: How you know it's done

• Timeline: Specific date

If a move feels too big, it's probably 2-3 moves. Break it down.

Step 5: Define Expected Outcome (5 minutes)

What does success look like?

Rubbish outcome: "Things get better"

Good outcome: "Metric X improves from Y to Z by [date]. We'll know we succeeded when [specific observation]."

---

Planning for Reality: Branching

After using this for a while, I realised something was missing. Real plans don't execute linearly.

You launch that pilot with 10 customers. But you don't get 10 enthusiastic responses. You get 6 who love it, 3 who are lukewarm, and 1 who doesn't get it at all. Now what's Move 3?

This is where branching comes in.

The method still enforces exactly 5 moves on your primary path (what you expect). But for moves with genuine uncertainty, you can plan 2-3 possible outcomes:

Move 2: Test pricing with 50 beta customers

PRIMARY PATH (70%): 30+ upgrade
  → Move 3: Full launch to all users

BRANCH A (25%): 15-29 upgrade  
  → Move 3-alt: Survey feedback, refine messaging

BRANCH B (5%): <15 upgrade
  → STOP: Rethink value proposition

When reality diverges from your plan (and it will), you're not scrambling. You already thought through the alternatives.

The rule: Only branch on high-impact uncertainties. If you're 90% sure of the outcome, don't branch—just execute.

---

Common Mistakes

Mistake 1: Skipping the "why" questions

You think you know the problem. But forcing yourself to ask "why" five times reveals blind spots. The team size issue looked like a capacity problem. Five whys later, we found an organisational structure gap.

Mistake 2: Vague moves

"Improve the onboarding experience" isn't a move. It's a goal.

A move is: "Rewrite onboarding emails with specific examples, A/B test against current version, ship winner to 100% of users."

Could you hand this to someone else and they'd know exactly what to do? If not, add specifics.

Mistake 3: No real owner

"The team will handle it" means no one will.

Every move needs one human who's accountable. If you can't name a person, you don't have a move yet.

Mistake 4: Trying to solve everything

"But we have 8 critical moves!"

Then you're trying to do too much. Pick the 5 that create the most learning or unlock the most value. The other 3 belong in the next plan.

Better to complete 5 moves than start 8 and finish 2.

---

What Makes The Keystone Method Different?

You might think: "This sounds like a project plan."

Fair. But here's what makes it different:

It starts with thinking, not doing. Most plans begin with "What should we build?" The Keystone Method starts with "Why might this be happening?" That catches assumptions before they become expensive mistakes.

It forces convergence. Brainstorming generates ideas. This method synthesises them. You must go from 5 hypotheses → 3 solutions → 5 moves. That funnel forces clarity.

It's designed for learning. Each plan is an experiment. Complete the 5 moves, measure the outcome, learn. If you were wrong, brilliant—now you know. Create the next plan with better information.

It fits on one page. If you can't explain your plan on one page, you probably don't understand it yet.

---

Get Started Today

Think of one problem you're facing right now. Not the biggest. Not the scariest. Just something that's been bugging you.

Grab a piece of paper:

• Top: Write the problem

• Middle: Brainstorm 5 possible causes, then pick one and ask "why" five times

• Bottom: Write 5 specific moves you could take

Time yourself. 30 minutes.

That's it. You now have a plan.

Will it be perfect? No. But it'll be better than overthinking for another week.

And here's the secret: The first plan is never the final plan.

You'll complete those 5 moves. You'll learn something. You'll create a new plan with better information. Then another. Then another.

Each one sharper than the last.

That's how you build momentum. Not through perfect planning. Through rapid learning cycles.

Five moves at a time.

Download a template to get started here:

The Keystone Method - Planning Canvas.pdf

Download PDF • 366KB

---

About the Method

The Keystone Method draws inspiration from 5 Whys (Toyota), Wardley Mapping (Simon Wardley), OODA Loop (John Boyd), hypothesis cards, Solve-for-X, and architectural thinking. It synthesises their strengths whilst adding the critical bridge from insight to action.

Framework Licence: Creative Commons Attribution-ShareAlike 4.0You're free to use, adapt, and share this method. Just credit the source and share your improvements with the community.