Frameworks are what make an improvised answer sound structured instead of rambling.

1 · The discovery ladder

Discovery When someone asks for a solution instead of describing a problem.

People request artefacts — a dashboard, a report, an automation — because an artefact is easier to ask for than a problem is to describe. The ladder walks the request back down to the decision underneath it.

1. Request. What they asked for. Write it down and then set it aside.
2. Task. What they physically do today instead. "Walk me through last month."
3. Decision. What decision the output feeds. If there isn't one, that's the finding.
4. Consequence. What changes if the decision is better or faster. This is where the business case lives, and it's usually smaller or much larger than anyone assumed.

The reason it works is that the gap between rung one and rung four is where all the wasted build effort in a transformation team goes. A request for a dashboard that bottoms out at "a VP asks one question in a Monday meeting" does not need a dashboard.

"Before I design anything — what decision does this let you make that you can't make today? And walk me through what you do at the moment instead."

Protects against: building a faithful version of the wrong thing, which is the most expensive failure available to a team like this because it looks like success until adoption numbers come in.

2 · Automate, redesign, or eliminate

Judgment Any question about improving an existing process.

Start from the assumption that the process should not exist, and make it earn its place. Then sort what remains by why it exists, because the three reasons want completely different treatment.

"My first question isn't how to automate it, it's whether the step should exist. Automating step four of a seven-step process that shouldn't have seven steps looks like progress and locks in the bad design."

Protects against: the classic transformation failure — paving the cow path. Also the single most senior-sounding thing you can say in a process conversation, because juniors optimise and veterans delete.

3 · Definition of ready

Delivery When the build side asks what a good requirement contains.

Six parts. You should be able to list them without hesitating, because this is the artefact you'd own and being vague about your own deliverable is fatal.

1. The problem in the user's words, not yours.
2. Current-state cost, with a number. Hours, cycle days, error rate, or money. If you can't put a number on it, you haven't finished discovery.
3. Explicitly out of scope. The section that saves the most time.
4. Data sources and field definitions, agreed with whoever owns them. "Headcount" means four different things until someone writes down which one.
5. Acceptance criteria that can be tested. Not "the dashboard is accurate" — "the total ties to the GL trial balance to within £X".
6. Open questions, each with a name and a date against it.

Points three and six are the ones to emphasise out loud. Every requirements template has the first two; the out-of-scope list and the owned open questions are what a build team actually notices.

"The out-of-scope section and the open-questions list are the two that save your team time. Everything else is table stakes."

Protects against: being seen as a documentation layer. A definition of ready is a contract, and having one is the difference between a partner and a pass-through.

4 · Make the trade visible

People Saying no, prioritising, or delivering bad news about cost.

Never refuse. Convert the refusal into a choice and hand the choice to the person whose job it is to make it.

1. Price it. "That's roughly six weeks."
2. Name what it displaces. "Which pushes the accruals work into next quarter."
3. Offer the cheap 70%. Almost everyone takes most of the value for a fifth of the effort when someone puts it in front of them — but only if you offer it, because they can't design it themselves.
4. Let them choose, and write down who chose. Not to cover yourself. So the retrospective is honest.

The uncomfortable case is when the answer really is no because the idea is bad. Then say it plainly, once, with the reason — and if they still want it, build it properly rather than half-heartedly, and make sure the decision is recorded. Sulking through a build you argued against is the thing that ends these relationships.

"I don't say no, I make the trade visible. That turns it from me refusing into them prioritising, which is their job anyway."

5 · The adoption triangle

People Any change-management, rollout or "how do you get people to use it" question.

Adoption is a design constraint from day one, not a phase at the end. Three things, and the claim to make is that missing any one of them predicts failure.

1. A named champion, involved not consulted. Someone respected inside the affected team, whose name is on the thing from the first prototype. Consultation produces politeness; involvement produces ownership.
2. A sunset date for the old path, announced in advance. Parallel-running forever guarantees the new thing stays optional, and optional things don't get learned.
3. A usage number reviewed monthly. "Rollout complete" and "people are using it" are different facts, and only one of them is worth anything.

"Adoption is a design constraint, not a phase at the end. If I'm only thinking about it at go-live, I've already lost."

Protects against: the most common thing a transformation team gets quietly judged on — a portfolio of technically successful builds with nobody in them.

6 · The AI confidence ladder

Judgment Any "where would you use AI here" or "how do you handle hallucination" question. Expect at least one.

The role has "AI" in the title and sits in a finance org, which means the interesting question is never can a model do it — it's what happens when it's wrong. Climb the ladder only as far as the consequence of error allows.

Two things to say alongside it, both of which mark you as having done this in a regulated context rather than a demo:

Evaluate against ground truth before you trust it. A labelled set of past cases, a measured accuracy figure, and a stated threshold below which a human sees it. "The model seemed good" is not a control.

Wrong-and-fast is worse than slow. In a finance org, a bad number that ships quickly gets into a deck and someone makes a decision on it. That asymmetry is the whole reason the ladder exists.

"The question isn't whether a model can do it, it's what happens when it's wrong. In a close process, a confident wrong number is worse than no number, so I'd put a human above a materiality threshold and measure the accuracy before anyone relies on it."

Which framework, which question

Things not to say