How to build an AI roadmap without picking technology first

Most AI initiatives start with a demo. A vendor shows an impressive application, someone on the shop floor plays with a new tool, or management hears that a competitor is already working with AI. And then comes the question: how do we use this technology in our own company? That sounds logical, but there is a catch. You start from the solution while the problem is not yet clearly defined. A good AI roadmap therefore does not begin with technology. It begins with your business goals, your processes and the decisions you make every day.

An AI roadmap is not a shopping list of tools

A roadmap is not a list of tools you plan to buy later. It describes which results you want to achieve, which bottlenecks you want to solve and in which order you will tackle them. Technology only enters the picture once you know what you want to automate, accelerate or improve. Anyone who works the other way around ends up with a collection of scattered experiments without a common thread and without measurable impact on the organisation.

Step 1: start from your business goals

Every AI roadmap starts with the question of what your company concretely wants to achieve over the next two to three years. Protecting your margins despite rising costs, quoting faster for complex products, lowering your inventory without disappointing customers, curbing administrative growth as your order book expands, capturing the knowledge of experienced staff before they leave, lifting your delivery reliability, speeding up your reporting, or replying to customers faster. As long as you do not make these goals explicit, AI remains a technology looking for a problem.

Step 2: find the structural bottlenecks in your processes

Once your goals are on the table, you look specifically at the processes that weigh on you the most. Where do people spend hours every week searching through large volumes of documents, contracts or specifications? Where do staff copy information by hand from one system to another? Where do you repeatedly run similar analyses for different cases or clients? Where do you struggle to combine data from ERP, CRM and Excel before making a decision? Where does a lot of time go into classifying exceptions or answering repetitive questions? And where would you like to forecast based on historical data, but today you lack the time or the model to do so? These bottlenecks form the foundation of your roadmap.

Step 3: describe the desired result for each bottleneck

A roadmap only gains weight when you describe the target result sharply for each bottleneck. "Quoting faster" is too vague to act on. "Reducing the lead time of a quote for product X from an average of 90 minutes to 60 minutes without an increase in errors" is workable. That kind of formulation immediately gives you a yardstick: you know what you measure, when you measure it and when a solution is good enough to build on further.

Step 4: assess opportunities on more than business value alone

Not every opportunity with high business value is also immediately realistic. To avoid choosing based on enthusiasm, you assess every opportunity on seven dimensions. How large is the business value in time, money or quality? What process volume is involved, because a solution for ten cases a year rarely justifies the investment? Is the data you need available, reliable and up to date? What is the impact of an error: a minor irritation or an incorrectly paid invoice? How many exceptions sit inside the process? How heavy is the integration with your existing systems? And does your organisation have the change capacity to really engage with it? These seven dimensions help you separate real priorities from interesting ideas.

Step 5: define the function first, technology second

For each opportunity you describe what the solution has to do functionally, independent of any model, platform or vendor. Think of things like: extracting information from a specific type of document, formulating a proposal based on similar cases, showing the sources that support that proposal, indicating how confident the model is, leaving the final decision to a staff member, storing the approved result in your ERP and logging every change for audit purposes. This functional description keeps you vendor neutral later on. You compare candidates on what they actually solve, not on who gives the flashiest demo.

Step 6: split initiatives across three categories

Once your opportunities are scored and functionally described, you split them across three categories. Quick wins deliver measurable gains within a few months, without heavy integration or major data preparation. Strategic projects reach deeper into your processes and systems and require more preparation, budget and change management, but they also carry a clearly heavier business impact. Foundations are not AI applications in themselves, but preconditions without which the rest cannot run sustainably: data quality, master data, access management, integration layer, monitoring and governance. Without that base, ambitious projects remain built on shifting sand.

Step 7: plan experiments with clear boundaries

Before you launch a strategic project, plan an experiment with sharp boundaries. You decide up front which results the experiment must achieve to be considered a success. For example: the model classifies at least 85% of cases correctly, the average time per case drops by at least 20 minutes, staff adjust fewer than one in five proposals, and the operational cost stays below an agreed monthly amount. Without such criteria, a pilot drifts into a project without a clear end point.

Step 8: make ownership visible

Every opportunity on your roadmap gets three owners. The business owner carries the responsibility for the value the solution has to deliver. The process owner knows the working method, the exceptions and the colleagues who work with it every day. The technical lead safeguards the integration with existing systems, the data sources and the security. Without these three roles, an AI project stays an IT experiment disconnected from daily operations.

Step 9: revisit the roadmap periodically

An AI roadmap is not a document you dust off once a year. Models, vendors and prices evolve so quickly that what seemed unfeasible today may become realistic within six months, and vice versa. So plan a short review at least every six months. You check whether the goals still hold, whether new bottlenecks are emerging, whether experiments are delivering their promised results and whether the foundations have matured enough to take on heavier projects.

Conclusion

A good AI roadmap does not start with a vendor, not with a demo and not with a tool. It starts with the question of which goals you want to reach, which bottlenecks you want to solve and which foundations you need to carry AI sustainably. Those who respect this order avoid tunnel vision on one technology and keep control in their own hands. Those who reverse it often pay twice: first for a tool that does not fit, then for the correction.