Never start with solutions

Someone tells you the purchase order process is too slow. Watch what happens next. Within about ninety seconds, somebody in the room will have suggested a piece of software.

That instinct isn’t laziness. It’s the opposite: capable people seeing a problem and wanting to fix it. But in process work, it’s the single most reliable way to spend money on the wrong thing, and I’ve watched it happen in every industry I’ve worked in.

The first phase of the PURE methodology exists to interrupt that moment. P is for Purpose, and it asks two questions that sound almost too obvious to be worth the meeting: what is this process actually trying to achieve, and where does it start and end?

Why purpose gets skipped

Because everybody assumes they already know. Of course we know what the purchase order process is for. Why waste an afternoon stating the obvious when we could be fixing it?

Here’s what I’ve found. When you actually sit a team down and ask them to write the purpose of a process, one of two things happens. Either they can’t agree, which tells you immediately that the process has been quietly serving different masters for different people, or they agree on something far too narrow, scoping the work around a symptom rather than the thing underneath it.

Both are dangerous, and both are cheap to fix at this stage and ruinously expensive to fix later. Disagreement about purpose means you’ll optimize for one group at the expense of another and build resistance into the outcome before you’ve designed anything. Too-narrow scoping means you’ll fix one step beautifully and leave the real waste sitting untouched on either side of it.

The purpose is bigger than the complaint

When somebody says “our purchase order process is too slow,” the tempting purpose is: make purchase orders faster. But that’s a solution wearing a purpose as a disguise.

The real purpose is closer to: ensure the right materials are available to the right people at the right time, at an acceptable cost, with the compliance controls the business genuinely needs.

The first one leads you to a faster PO system. The second one opens up a set of options in which the purchase order might not need to exist for most of what you buy. Those aren’t the same project.

Nobody agrees where the process starts

Scope is the boundary of the work: what’s in, what’s out, where it begins and where it ends. Getting it right is a balancing act. Too narrow and you polish one step while the waste sits upstream. Too broad and the project becomes unmanageable, the stakeholder group expands past what anyone can hold, and it quietly dies of its own weight.

My rule of thumb: scope should be wide enough to cover the full end-to-end journey a stakeholder actually experiences, and narrow enough that one team can own the outcome. If you find yourself needing more than one governance structure to run the project, your scope is too big. Break it into phases.

Then there’s the thing that catches almost everybody out. Different stakeholders have genuinely different beliefs about where a process starts.

• Finance thinks procurement starts with a budget approval.
• The scientist thinks it starts the moment they need a reagent.
• The supplier thinks it starts when a purchase order arrives.
• Facilities thinks it starts when something turns up at the loading bay.

Every one of them is right, from where they’re standing. And if you don’t surface those views before you start, you’ll design something that works beautifully for one of them and creates new problems for the other three.

So I validate scope explicitly with every stakeholder group before going anywhere near the Understand phase. Not as a formality, as a real conversation. Here’s what we think this covers. Here’s where we think it starts and stops. Do you agree? What have we missed?

The disagreements that surface in that conversation are the most valuable thing you’ll get. Misalignment costs almost nothing to fix at the purpose stage. After you’ve built the solution, it costs everything.

Definition of Done

One of my team came back from a product management course years ago with the term Definition of Done, and I’ve used it ever since.

It’s a set of specific, measurable acceptance criteria describing what success looks like. Not vaguely, specifically. What will be different when we’re finished? How will we know? What will we measure? What will people be able to do that they can’t do today?

A Definition of Done turns purpose from a statement into a blueprint. It gives the team something to aim at, something to test every idea against, and something to be held to. And it gives whoever is sponsoring the work a clear basis for saying this is finished, or this isn’t finished yet. It catches the ambiguity that would otherwise surface as a disagreement six months later, when it’s a great deal more expensive.

What this looked like at scale

When I was responsible for global API category management at a large pharmaceutical company, I had 115 manufacturing sites buying the same active pharmaceutical ingredients.

The obvious purpose, the one most procurement functions would have written, was: negotiate better prices. Had we gone with it, we’d have run a tender, banked a number, and finished.

Instead we stepped back and asked the bigger question, and the purpose came out completely differently: coordinate breakthrough improvement across 115 sites to deliver savings, reduce risk, ensure quality and build supplier relationships that would still be serving the business a decade later. Price was one element of something much larger.

That broader purpose changed who we talked to, what we analyzed, which options we considered and what we eventually built. And the results weren’t marginally better than the tender would have been. They were a different order of magnitude.

Solutioneering

I use that word deliberately. Solutioneering is what happens when intelligent, motivated people skip Purpose and Understand and go straight to designing.

It’s seductive because it feels productive. The room is energized. The whiteboard fills up. Everyone leaves feeling like something happened. But the ideas are untethered: solutions looking for problems, or solutions aimed at symptoms rather than causes. Three months later the thing gets built, and the original complaint is still there wearing different clothes.

The antidote is the sequence itself. If you’ve done Purpose and Understand properly, you have a Definition of Done and an evidence base, and options get judged against criteria rather than against enthusiasm.

The rule

If I could give you one rule from thirty years of this work, it’s this. Never start with solutions.

When someone asks what software we should buy, stop. That’s a solution hunting for a problem. The question is: what is this process trying to achieve, and is it achieving it?

When someone asks how we improve the current process, stop again. That question smuggles in an assumption: that the current process ought to exist at all. The question is: why does this exist, and what would we design if we were starting today?

This is harder than it sounds. It takes patience. It takes the confidence to slow down while everyone around you wants to move. And it needs a kind of discipline most organizations don’t reward, because most organizations reward visible action rather than accurate understanding.

But the return on that patience is enormous. In my experience, the Purpose phase eliminates more wasted effort than any other single activity in the methodology, not because it’s clever, but because it forces the question nobody else is asking. Why?