Capstone — Run a Real Engagement

Module 13

Capstone — Run a Real Engagement

A single repeatable workflow that applies every module to one real business — ideally yours. Knowledge becomes skill only when you run the loop.

Reading about consulting makes you literate; running an engagement makes you a consultant. This capstone is a checklist you can run end to end on any real business — a friend's company, a local shop, or Orelis itself. Do it once properly and the whole guide stops being theory.

The engagement, step by step

Step 1 — Scope (Module 6). Pick a real business and one real problem. Write a one-paragraph scope: the problem in a sentence, what success looks like, what's out of scope, and what you'll produce (a one-page recommendation). Agreeing this — even with yourself — is the discipline.

Step 2 — Understand the business (Module 1). Write the business model in plain language: who's the customer (B2B/B2C), what's sold, how it charges, where the value loop is, whether there's a moat. If you can't, you don't yet know enough — go find out.

Step 3 — Get the numbers (Module 2). Gather whatever financials you can: revenue, costs, margins, and ideally unit economics (CAC, LTV) and cash position. Compute the obvious diagnostics. Note every assumption you had to make.

Step 4 — Define the real problem and structure it (Module 4). Restate the problem (is the stated one the real one?). Build an issue tree, MECE, down to checkable questions. Form an explicit hypothesis about where the answer lies.

Step 5 — Investigate the vital few (Modules 3, 4, 7–10). Use the 80/20 to chase the branches that matter. Reach for a framework only if it forces a needed question — Five Forces if it's an industry-attractiveness question, the funnel if it's a customer problem, a process map if it's operational, incentives if behaviour is the issue. Test your hypothesis against the evidence; kill it and reform if needed.

Step 6 — Synthesise (Module 4). Force everything into one governing "so what": given all this, here's what's going on and what they should do. If you can't say it in a sentence, keep thinking.

Step 7 — Pressure-test adoption (Module 9). Will the structure, incentives, and culture actually allow your recommendation? What's the people-side risk, and how would they roll it out and get an early win?

Step 8 — Communicate (Module 5). Produce a one-pager: open with SCQA, lead with the recommendation, give three reasons with evidence, surface key assumptions, end with the first concrete next step. That single page is your deliverable — and your proof you can do this.

A reusable engagement checklist

  • Scope agreed and written (problem, success, out-of-scope, deliverable)
  • Business model articulated in plain language
  • Key numbers gathered; diagnostics computed; assumptions noted
  • Real problem defined; issue tree built; hypothesis stated
  • Vital-few branches investigated; hypothesis tested and updated
  • One governing "so what" synthesised in a sentence
  • Adoption, incentives, and change risks checked
  • Answer-first one-pager produced (SCQA, recommendation, 3 reasons, assumptions, next step)

Then do it again

The first engagement will feel slow and awkward — that's the sign you're actually learning rather than recognising. The second is faster. By the third, the loop runs in the background and you'll catch yourself structuring problems this way without trying. That involuntary reflex is what "being a consultant" actually is.

Key takeaway

Run the full loop on one real business: scope, understand, get numbers, define and structure the problem, investigate the vital few, synthesise, pressure-test adoption, and communicate an answer-first one-pager. Then repeat. Skill lives in the reps, not the reading.

For Orelis & the app

Run this capstone on Orelis itself — it's the best possible first engagement, and it'll surface your own gaps in the model, numbers, and positioning. Then notice: this eight-step loop is a product flow. The clearest version of your app might simply be this engagement, made interactive — guiding a user through the same steps, producing the same one-pager. You'd be shipping the exact discipline this guide taught, which is a far stronger foundation than "an AI that answers business questions."

You've finished the course. You started with no background; you now have a working model of business, financial fluency, a strategy toolkit, the core problem-solving method, communication discipline, the marketing and operations and people lenses, negotiation skills, a clear-eyed read on AI's real value, a product spec for your app, and a repeatable way to apply all of it. That's a genuine foundation. Now go run the loop on something real — and keep this guide as the reference you return to.

Test yourself

Q1Why is your very first engagement supposed to feel slow and awkward — and why is that a good sign?
Show a worked answer
Because you're consciously running each step rather than pattern-matching from memory, which is exactly what learning a skill feels like before it becomes automatic. Smoothness on attempt one would mean you were recognising familiar moves, not building new ones. The awkwardness is the deliberate practice doing its work; by the third engagement the loop runs in the background. Treat the discomfort as evidence it's working, not that you're bad at it.
Q2You're tempted to skip Step 1 (scope) and Step 7 (adoption) because the 'real work' is the analysis in between. Why is that the classic beginner error?
Show a worked answer
Because scope and adoption are where engagements actually succeed or fail. Skip scope and you risk solving the wrong problem brilliantly — the most expensive mistake in consulting. Skip adoption and you produce a clever recommendation no one implements because the incentives, structure, or culture won't allow it. The middle analysis feels like the 'real work,' but it's only valuable if it's aimed at the right problem (scope) and can actually be acted on (adoption). The bookends are what make the analysis matter.