The problem you can't name is the use case you'll never use.

Picture a retailer that's bought a "predictive replenishment" tool. Hot category, clean demos, contract signed. Six months later, leadership is still trying to work out which problem it was supposed to solve. Demand forecasting? Out-of-stocks? Buyer productivity? Each champion's framing makes the tool look slightly oblique to the others. Eighteen months later, quiet decommission.

That shape is familiar. The use case arrives first; the organisation spends two quarters hunting for the problem it's meant to fit. The cost is rarely the licence. It's the attention. The strategy review that should have covered the organisation's actual constraints turns into justifying a tool somebody already bought.

The use case matters; how it applies to you matters more

The instinct, reading the failure rates and the scaling stalls, is to call them use-case selection problems. The organisation picked the wrong thing. That instinct is only half right.

In the last three years the use-case catalog has standardised. Recommenders, assistants, document extraction, demand forecasters: every vendor carries reference evaluations for the same shortlist. Two organisations in the same vertical can pick the same five off the same shelf and still land in completely different places three quarters later. Picking the right use case still matters; the use case alone doesn't decide the outcome. The nuance does: how that use case applies to this particular business, against its problems, in its context.

Context is what makes the difference: which problems the organisation actually faces, who's affected, in what systems, at what scale, in what geography, at what maturity. The use case still gets evaluated; the context is what makes the evaluation worth anything.

Two things make Accelerate's first track different, and both have to be in place.

The first layer: the Knowledge Bank

The Knowledge Bank is the substrate of objectives, problem types, and use cases the organisation walks into rather than rebuilds. Three properties make it that.

Depth and nuance

Depth is how many axes the Knowledge Bank holds; nuance is what each axis does to a use case once it lands in a real organisation. It disambiguates along every axis that materially changes how a use case shows up: sub-industry, sub-function, geography, baseline systems, org size, workflow shape, regulatory scope, maturity stage, and the dependencies that gate each use case. The same use case looks different in a regulated EU hospital network running centralised IT than in a US private clinic with a federated, outsourced ops model. The Knowledge Bank carries those distinctions natively, so picking it up isn't a matter of trimming a generic catalog down to fit. The shape that fits is already there.

Shared meaning across the organisation

Everyone works against the same use cases, capabilities, and problems, but each part of the business sees them in its own language. Finance, operations, engineering, and the contributors on the floor read the same underlying entity through their own framing, so nobody has to translate before they can engage with what's there.

Structure

One framework. Common elements and edge cases sit at the same depth, in one consistent ontology, so rare configurations carry the same scaffolding as common ones. Thin catalogs bury edge cases in an appendix. The Knowledge Bank doesn't have an appendix. The Knowledge Bank keeps growing, so what's available off the shelf next quarter covers more than what's there today.

The second layer: collective problem discovery

On its own, the Knowledge Bank is still just a library. A library doesn't tell the organisation which of its own problems are real, which are urgent, who's affected, or how badly. That's the work of Accelerate's problem-discovery engine, and what makes it distinct from any consultant interview round is that the engine is contributor-driven; it unfolds as the organisation engages with it and picks up industry insights along the way.

Problems get collected from the people they actually affect. Contributors across the organisation surface what's breaking in their work against the structured problem types the Knowledge Bank already carries. They confirm magnitude through a sizing engine they validate themselves, and name exactly where and how the problem lands. The same named problem in the same function looks different across two teams, and the aggregation captures that. The result is a picture of the organisation's problems built from distributed knowledge, not from analyst inference walking upward through three layers of executive interviews. That picture is what gets matched to use cases, from the same Knowledge Bank the contributors' problems landed against.

A discovery engine without the Knowledge Bank rediscovers problem categories from scratch every quarter. The Knowledge Bank without the discovery engine is a library the organisation can't apply. Both layers have to be there.

Why reference evaluation alone isn't load-bearing here

Every use case in the Knowledge Bank carries a reference evaluation, the impact a competent implementation tends to produce under reasonable conditions. Useful as a first reference point. The org-specific adjustment (which workflow has to redesign, which capabilities have to backfill, what accountability has to remap) is the work that comes after, in Decide and Deliver. The job at this stage is to make sure the use cases reaching Decide are anchored to problems the organisation actually has, sized by the people experiencing them.

Where this leaves us

The retailer in the opening would have caught the misfit in a week. The discovery engine would have named the problems each champion was trying to solve, sized them against impact on the planning team, and shown the tool oblique before the contract was signed. Most of the scaling-stall picture is the same story: technology and AI solutions in search of problems, not problems solved with the appropriate technology and AI.

The question this leaves open

The Knowledge Bank and discovery engine are the answer to use-case anchoring. What they don't yet explain is what's actually inside the Knowledge Bank: how deep it goes, what gets extended, and what makes that extension compound over time.

Next week: the Knowledge Bank itself. What it contains, what gets extended, and where the depth compounds over time.