“Adopting AI” is not a single act. The opportunities a business identifies reach deployment along different routes, and the surest way to disappoint a leadership team is to treat them all as though they can be switched on next quarter. In our discovery programmes every consolidated use case is assigned one of four adoption pathways: a short description of what actually has to happen before it can deliver, and in what order. They are not a ranking. A use case follows the pathway its nature demands.
Research-led
Some opportunities depend on data or capabilities the business does not yet know it can rely on. They cannot be bought or specified up front; they have to be investigated first. The pathway starts with a plain question, do the required data and the underlying capability actually exist?, proceeds through a bounded prototype that establishes what is feasible, and ends with a clear decision to commit the idea to delivery or close it out.
The pattern is most pronounced in R&D and in anything driven by device or sensor data. On-device AI is the clearest example we have seen: the ambition was well understood, but usable data existed only in some areas and was not available off the device in a form that could be analysed, and some target applications had no sensor data at all. Work of that kind should be funded as a research programme with engineering time set aside and concept demonstrators as the output. It should not be scoped as a conventional business case with fixed costs and returns until the research provides the evidence to do so.
Product-led
A large proportion of opportunities can be met by a product that already exists, and here the task is selection rather than invention. The pathway runs from a market scan, through selection, to validation on a bounded scope, then adoption. The discipline is that the scan comes first. Discovery workshops surface a wide field of candidate products against many ideas, from competitor-intelligence tools to content, knowledge and productivity platforms, and the right choice depends on how each fits the existing systems, data and licensing. A shortlist is the start of selection, not the end, and selection should be validated against a real, contained use before the business commits.
This is also the pathway where a consultancy’s incentives matter. We hold no reseller margin, so the scan is run on the evidence; a partner with a quota to hit runs it differently.
System-embedded
A third group of opportunities arrives not as separate tools but as capabilities inside systems the business already runs, most obviously the ERP and the CRM, as vendors add AI to their products. For these the pathway is validation rather than acquisition: confirm the embedded capability does what is claimed, check the quality and readiness of the data it will draw on, weigh the governance and change implications, and then switch it on.
The cost may be modest, since the capability comes with software the business already licenses. The diligence is not optional. An embedded feature is only as good as the data beneath it, and adopting it without that check simply moves the risk downstream to the people who rely on its output.
Data-foundation
The single most important finding of every programme sits underneath the other three pathways: data is the limiting factor. In many cases the data needed for an opportunity either does not exist or exists scattered across systems in inconsistent formats. Where that is true, no amount of tooling helps until the data is addressed, so these opportunities begin with a data-collection and pooling initiative that must precede research, product selection or system adoption alike.
This is why master-data quality emerges in findings as an enabler rather than an end in itself, and why a single, trusted knowledge foundation is recommended as an early, cross-cutting investment: it is the ground the majority of the more ambitious use cases stand on.
What the pathways change
| Pathway | First step | Funded as | Typical horizon |
|---|---|---|---|
| Research-led | Establish that the data and capability exist | Research programme, commit-or-close decision | One to two quarters to a decision |
| Product-led | Market scan and shortlist | Selection, validation, licence | Weeks |
| System-embedded | Validate the vendor’s feature on your data | Diligence, then configuration | Weeks to months |
| Data-foundation | Collect, pool and reconcile the data | Foundation programme | Quarters, in parallel with quick wins |
Two consequences run through every roadmap. The data-foundation work is a genuine precondition for the ambitious use cases, so it starts early even though it delivers later. And the work is sequenced by readiness, not enthusiasm: data-in-hand opportunities proceed now, while the data-dependent ones enter their pathway first. Different teams can progress different pathways in parallel; the roadmap is not a single queue.
The pathways have their own page under our approach, and they are assigned in every discovery programme.