AI Thinking is open source

For years, I worked with Design Thinking, Agile development and Lean Startup to create new digital products and services.

Then AI changed the conversation.

Teams suddenly had access to technology that could understand language, recognise patterns, generate content and make predictions. The possibilities were easy to demonstrate. Deciding what to build—and what not to build—was much harder.

I kept hearing the same questions. Where do we start? Which problems genuinely make sense for AI? Do we have the data? How should designers, developers and AI specialists work on the same problem? And once something works in a prototype, how do we turn it into a service people can rely on?

Those questions became the starting point for AI Thinking.

At the centre of the work is a process we called the Double A Framework. The two As stand for AI and Agile, with Design Thinking shaping how we approach people, problems and the experience around the technology. I wanted to create something teams could actually use.

Start with the opportunity

A lot of AI work starts with the technology. Someone sees a model, an API or a new capability and immediately begins looking for somewhere to put it.

AI Thinking starts with the opportunity.

What is happening in the business? Where are people struggling? Where is there too much information for people to process manually? Where are existing systems reaching their limits?

The first part of the framework asks the team to make that opportunity specific and connect it to business goals, user needs and the data already available. This sounds obvious. In practice, it changes the project.

The starting point is not what AI can do. It is what people and organisations need to do better.

Break the big problem into tasks

One idea became especially important while we developed the framework: think in tasks.

AI does specific things. One model classifies an image. Another predicts demand. Another extracts information from text. A language model can generate or interpret language.

So instead of asking, ‘How can we use AI for customer service?’, we break the opportunity into smaller jobs. What information goes in? What needs to come out? Which part could AI handle? Which model is suitable? What data would it need?

This is what we call Framing.

Framing creates a bridge between the business problem and the technology. The guide suggests a deliberately simple mental model: one task, one model. From there, a team can test feasibility early and compare possible approaches based on performance, cost, privacy, integration and other practical constraints.

That early work matters. An exciting concept can fall apart quickly when the data is poor, the model is too slow or the economics make no sense. It is better to discover that before the idea becomes expensive.

Design the service around the AI

Then the designer comes back into the picture.

This is one of the parts of AI Thinking that matters most to me. An AI model on its own is rarely the product. People experience a service around it.

During the Creating phase, we explore what that service could be. We sketch ideas, prototype flows and put early concepts in front of users. At the same time, we begin shaping the technical architecture and tracing how data moves through the service.

The two sides need to develop together. A designer needs to understand where a model influences the experience. A technical team needs to understand what the person using the product is trying to achieve.

That relationship becomes especially important with AI because the output can vary. The experience has to account for uncertainty. Sometimes the system will be wrong. Sometimes it needs more information. Sometimes a person must make the final decision.

These are not edge cases to add later. They belong in the design of the service from the beginning.

Plan. Build. Run.

The framework eventually became a loop with three larger stages: Plan, Build and Run.

Plan is where we understand the opportunity, frame what AI needs to do and confront the data question.

Build is where ideas become prototypes and then a working minimum viable product. Design, architecture and model customisation begin to come together. General models can also be adapted using the organisation’s own data, language and context.

Run is where reality enters.

We deliberately start with a limited group of users. We measure how the models perform, but also whether the service creates the value we expected and what people actually think about using it. Then we go around again.

The loop matters because AI products continue to move after launch. Models change. Data changes. User behaviour changes. New capabilities appear. The work continues.

AI makes iteration necessary

This was probably the biggest adjustment from the way I had worked with digital services before.

With a conventional digital product, continuous improvement is good practice. With AI, it becomes part of the product itself.

The framework treats monitoring, user feedback, model updates and new data as ongoing work. Even the metrics may change as we learn how the service behaves in real use.

That is why Agile became such an important part of AI Thinking. The technology is moving too quickly for a long project where everything is specified at the beginning. Teams need to prototype, test and adjust as they learn. Design Thinking keeps the human perspective present while Agile gives the work a rhythm for learning.

Give the team a common language

There was another reason to create the framework.

AI projects bring together people who often think very differently. Business leaders talk about value. Designers talk about behaviour and experience. Data scientists think about models, training data and performance. Developers think about systems and integration.

Without a shared structure, it is surprisingly easy for everyone to work on a different version of the same problem.

AI Thinking gives the team a map. It recommends cross-functional teams, clear ownership, executive support and ways of measuring success. For me, that is a large part of its value. It gives people somewhere to have the conversation—and a way to connect their decisions.

From an AI experiment to something useful

The framework was designed around a practical outcome: get to a working minimum viable product, put it into use, learn from it and improve it. The unit of work is a real business opportunity, with the organisation’s wider AI strategy sitting above it.

That keeps the conversation grounded. Does the problem matter? Can AI realistically help? Can we build it responsibly? Do people want to use it? Does it create enough value to continue?

AI Thinking grew from trying to answer those questions in a repeatable way. The diagrams and steps came later. The thinking began with a simpler problem: companies could see AI moving incredibly fast, but many still needed a practical way to move from curiosity to something that works.

That is also why we made AI Thinking open source. A framework like this becomes useful when teams can apply it to real work, adapt it to their context and challenge what no longer holds.

The AI Thinking playbook and guide are free for any organisation to use.