The Constraint Ledger

Most AI strategy starts with the wrong question. "Where can we use AI" produces a list of use cases, and a list of use cases produces pilots, and pilots produce the 89-37-6 funnel McKinsey reported in August — nearly everyone using it, a third seeing any EBIT effect, six percent seeing it matter, and the bottom two numbers unmoved in a year.

The question I use instead is this. What does this business do only because human attention used to be expensive?

It's a different question and it returns a different kind of answer. Not opportunities. Costs you're still paying for a constraint that may have lifted while nobody was looking.

Here's the method. It takes a day with the right people in the room and it works in any business, which I know because I've now run it in US mortgage servicing, in industrial systems, in B2B software and in Indian real estate.

Step one — take the workflow that makes the money

Not the easiest one to change. Not the one with an enthusiastic sponsor. The one that generates revenue.

This sounds obvious and it's where most efforts go wrong on day one. Organisations pick a low-risk workflow to build confidence, then discover that succeeding at it changes nothing, because it wasn't attached to the money. You get a successful pilot and a flat P&L, which is the most common outcome in enterprise AI and the most demoralising.

If the revenue workflow is too frightening to touch, that's useful information about your organisation. It isn't a reason to pick a different workflow.

Step two — list constraints, not steps

Process mapping gives you steps. Steps tell you what happens. Constraints tell you why it happens that way, and only the second is actionable.

So for the revenue workflow, write down everything that stops it happening differently. Include the things nobody questions. Especially those — the constraints that never get stated are the ones that have been true longest, and the ones most likely to have quietly expired.

In a property sale, that list looks like: the buyer has to see something physical before committing, someone has to be available to answer questions, the eligibility rules require interpretation, documents must be collected and verified, a person with local standing has to vouch for it.

Some of those are laws of the world. Some are habits with a long history. Step three is about telling them apart.

Step three — sort into exactly four buckets

Every constraint goes in one bucket. No hedging, no "it's a bit of both." Forcing a single choice is what makes this useful.

Physics. It is physically impossible otherwise. A building cannot be occupied before it is built. A signature cannot be witnessed by somebody who is not there.

Regulation. The law requires it. Registration, disclosure, KYC, stamp duty.

Trust. It exists because a stranger has to be made credible. Sample flats, site offices, relationship managers, reference checks, the channel partner's reputation.

Price. It exists because doing it the other way used to cost more than doing it this way.

Most organisations discover, doing this honestly, that they have been treating the fourth bucket as the first.

Step four — audit the physics bucket ruthlessly

This is the step that matters, so give it the most time.

Go back through everything somebody put in Physics and ask: is this actually impossible, or has it been expensive for so long that it stopped feeling like a decision?

The sample flat is the example I know best. For thirty years in Indian real estate, a buyer seeing a physical unit before committing was treated as physics. It isn't. It's trust, and it was expensive to satisfy any other way. Once satisfying it another way became cheap, the sample flat became a choice — and a choice with a very large number attached to it.

I've seen the same error in other industries. In US property management, the belief that a renovation decision required a physical inspection by a qualified person. Partly true, and much less true than the process assumed. In industrial access control, the belief that a security policy change needed someone on site. In a software business, the belief that an enterprise customer needed a human to configure a workflow — a belief that supported an entire professional services organisation.

Every one of those was priced as physics and turned out to be price.

Step five — interrogate the trust bucket separately

The trust bucket needs its own treatment, because the naive move here is expensive.

For each constraint, ask what function it performs — not what form it takes. The function is real. The form is negotiable.

A site office performs the function of "someone is accountable and reachable." That function is real and removing it without replacement will cost you. The specific form — a physical room with a person in it during business hours — is one of several ways to deliver it, and not obviously the best one.

The failure mode is removing the form without replicating the function. That's not automation, that's just cost-cutting with a technology alibi, and customers notice immediately.

The opposite failure is assuming form equals function and leaving it alone. That's what most incumbents do, and it's why the trust bucket is usually where the largest unclaimed savings sit in a low-trust market.

What this produces

A ledger. Constraints down one side, buckets across the top, and an honest assessment of which ones have expired.

What it isn't is a technology plan. Nothing in the method mentions a model, a vendor or an architecture, and that's deliberate. By the time you're choosing a model you should already know precisely which constraint you're attacking and what it currently costs you. Most organisations do it the other way round, which is how you end up with an assistant nobody uses.

Two honest limitations

The method tells you what's possible. It doesn't tell you what's wise. We found the sample flat was price rather than physics; that didn't tell us whether removing it was a good idea, and we made that call separately, on judgement, and we could have been wrong.

And it's biased toward things you can see. Constraints that have been internalised as culture rather than process don't show up on the list, because nobody thinks to write them down. The best counter I've found is to have someone from outside the function run step two, because they'll ask why about things the team stopped noticing years ago.

One caution about what follows

Finding that a constraint has expired is the beginning of the work, not the end.

The redesign is where the return is. McKinsey's data this year found nearly three-quarters of high performers had fundamentally redesigned workflows, against a quarter of everyone else — and they're careful, rightly, to call that a distinguishing practice rather than a proven cause. But it matches everything I've watched from inside four companies over twenty years. The organisations that get nothing bought a capability and attached it to a process built around a constraint that no longer exists.

The constraint ledger is how you find out which one that is. What you do afterwards is the actual job.