I have asked the same five questions at the start of every piece of digital work for about fifteen years, in start-ups, in a FTSE 100 group, in a professional-services partnership and in private-equity-backed businesses. They have survived three technology waves without needing to change, which is the main thing I can say for them. Here they are, with what a bad answer sounds like, because the bad answers are how you learn to use them.

1. What value does this actually create?

Not what it does. What it is worth, to whom, and how we will know. A bad answer names a capability ("a single view of the customer") or an activity ("we will have migrated to the new platform"). A good answer names a number somebody outside the project would recognise: revenue we could not book before, cost that leaves the business, a risk that stops being carried, a multiple that moves.

The word actually is doing work. Most investment cases describe value that could be created if several other things also happened. Ask which of those other things are in the plan.

Projects should be killed the same way they are funded: against value, not activity.

2. Who owns the commercial outcome?

A person, with a name, whose year is worse if it does not happen. Not a steering committee, not "the business", not the programme director. If nobody's objectives change when the project succeeds or fails, the project has no owner, and work without an owner drifts towards being finished rather than being useful.

This is the question that kills the most projects fastest, and it should. It is also the cheapest fix: sometimes the answer is to find the owner before funding anything.

3. If this succeeds, how does enterprise value improve?

The board's version of question one. Digital work should be traceable to one of a small number of things a buyer or an investor pays for: growth that is recurring rather than one-off, margin that holds, revenue that is tied to product rather than to people, risk that is controlled and can be shown to be. If the trace does not exist, the work may still be worth doing, but it should be funded as hygiene, priced as hygiene, and never called transformation.

4. What job is the customer hiring this to do, and what happens five minutes either side?

The first half is the jobs-to-be-done question and most people know it. The second half is the one I have found more useful. For any step in a process: what happens immediately before it, and immediately after? It exposes the real constraint, the steps that exist only because a person once needed time, and the handovers that broker information a system now holds. Asked properly across a workflow it sorts the work into what to delete, what to automate and what to keep for judgement, and the delete pile is always bigger than people expect.

5. Would we build this with our own money?

The last question is the honest one. Strip away the budget line and the strategy slide and ask whether you would fund it as an owner, with the returns and the risks as they actually are. It is remarkable how often the answer is no, and how often the project goes ahead anyway because the money was already allocated.

What the questions do together

In the first ninety days of any business I have run, the order of work has been the same: customers, commercial model, operating model, incentives. Technology comes later, because it is rarely the constraint. The five questions are how that order gets enforced when the pressure is to start building.

They also decide how work ends. Projects should be killed the same way they are funded: against value, not activity. A programme that reports only what it delivered is not believed by anyone who has run a P&L. One that also publishes what it stopped, and why, is.

Over the years the questions hardened into a way of developing propositions, with a structured, measured risk decision at each stage: ideation, design, execution, acceleration, scaling. There is nothing novel about the stages. What matters is that the decision to continue is taken in the room, against criteria written down before the work started, so that proposition development becomes consistent, teachable and worth investing in. I wrote that method up in 2023 as the IDEAS framework; the questions are what run underneath it.