Once your Product Engineering foundations are in place, the next question is how to introduce AI in a way that creates real value rather than simply another organisation-wide technology rollout.
In our previous articles, we argued that organisations should stop assuming that more engineering capacity always requires more engineers, and that the foundation for AI-enabled delivery is strong Product Engineering capability.
The next question is a practical one:
how should you start introducing AI into Product Engineering teams?
Our view is that most organisations should resist the temptation to begin with a broad rollout. A better starting point is to choose one squad, one meaningful problem and one controlled experiment, then use what you learn to shape the wider approach.
Treat AI adoption as a product experiment
There is a familiar pattern with new enterprise technology. A set of tools is selected, access is provided, some training is offered and adoption is then measured by how many people start using them.
That may tell you whether a tool has been deployed successfully, but it tells you much less about whether AI is actually improving Product Engineering.
A more useful approach is to treat AI adoption as a product experiment. Choose a team with a genuine delivery challenge, be clear about what you are trying to improve, introduce AI deliberately into the way the team works and then measure the impact.
That gives you evidence about what AI changes in practice, rather than simply evidence that people have logged into a new tool.
Choose the right squad
Your first squad does not need to be the highest-performing team in the organisation, but it does need the right conditions for learning. It should have a reasonably clear product or service, enough autonomy to adapt its ways of working and a real challenge where improvement would matter.
Product and Engineering should also already be working reasonably well together. If the team is still struggling with ownership, handoffs or basic decision-making, AI is unlikely to resolve those issues. In fact, it may simply add another layer of complexity.
The purpose of the first experiment is to understand how AI can amplify a functioning Product Engineering team, not to use technology as a workaround for an operating model that is not yet working.
Start with the work, not the tool
One of the easiest mistakes to make is to start with a technology and then look for somewhere to use it. An organisation gets access to an AI coding assistant and asks where it can be deployed, or buys an agent platform and starts searching for processes to automate. We think the better starting point is the work itself.
Look at how work currently moves through the squad. Where does time disappear? Where are decisions slow? Where is work repeated? Where do people wait for specialist expertise? Which activities involve significant amounts of analysis, documentation or administration? Where does quality depend heavily on manual checking? Those are much better places to look for potential AI use cases.
The ideal first use case is significant enough that improving it would matter, but bounded enough that the team can understand what changed and why. You want a real problem with measurable consequences, not an artificial demonstration of what the technology can do.
Look across the whole Product Engineering flow
AI adoption often starts in Engineering because the opportunities are already visible. Coding assistants can help with development, testing, refactoring, debugging, documentation and technical analysis.
But AI-enabled Product Engineering is much broader than writing code faster.
Product teams can use AI to synthesise research, analyse customer feedback, explore opportunities and challenge assumptions. Designers can use it to generate concepts, prototype ideas and explore alternatives earlier. Teams can also use AI to reduce friction around planning, dependencies, knowledge capture and reporting.
The important question is therefore not simply, “Where can we add AI?” It is where can AI remove friction, improve the quality or speed of a decision, or increase the effective capacity of the team?
That shifts the discussion away from tools and towards outcomes.
Use real work and real constraints
The first experiment should take place within the squad’s actual work, not in an artificial AI exercise.
Perhaps Product uses AI to synthesise customer research before an important decision. Engineering might introduce AI-assisted development and test generation on a real feature. The team might use an agent to maintain technical documentation, or delegate a repetitive analysis task to AI with appropriate human oversight.
Working with real delivery exposes the things that demonstrations often hide. Data may not be as clean as expected. Review effort may offset some of the productivity gain. Governance controls may need to change. Teams may discover that some activities are easy to augment while others require much more judgement than anticipated.
Those are not failures. They are exactly the things the experiment is intended to uncover.
Measure the outcome, not the usage
AI adoption should not be judged by how many people are using a tool. High usage can coexist with very little improvement in delivery.
Instead, look at what changed in the performance of the squad. Did lead time improve? Could the team test more ideas? Did discovery become faster? Did quality improve? Did Engineers spend less time on repetitive work? Did Product have better evidence before making decisions? Most importantly, did the team create more customer or business value?
You should also look deliberately for negative effects. Perhaps review effort increased. Perhaps the team generated more output without creating more value. Perhaps quality deteriorated or new security, governance or reliability risks appeared.
That learning matters just as much as any productivity gain, because it tells you what needs to change before the approach is taken further.
Learn before you scale
Starting with one squad is valuable because you are not simply testing a tool. You are learning how AI works inside your own organisation.
You begin to understand which use cases genuinely create value, which tools fit your environment, where human oversight is essential, which controls need to be strengthened and what new skills teams require.
Only then does it make sense to take the approach into a second squad and then a third. Each new team becomes an opportunity to refine the model rather than simply repeat a rollout.
Over time, this creates something much more useful than an organisation-wide AI adoption programme: an AI-enabled Product Engineering model built from evidence generated by your own teams.
The opportunity is bigger than coding faster
The longer-term opportunity is not an engineering team equipped with better coding tools. It is a Product Engineering team where AI supports the whole flow of work, from understanding a problem through to designing, building, testing and learning from the outcome.
As AI agents become more capable, meaningful parts of that workflow will increasingly be delegated to AI under human direction. That is where the capacity model begins to change.
The organisation continues to retain product judgement, domain expertise, engineering leadership and accountability internally, while AI provides additional delivery capacity around those capabilities.
That transition should be developed through evidence and experience rather than imposed through a mass rollout.
Start small, then scale what works
If your Product Engineering foundations are in place, the next move should not automatically be to deploy AI everywhere.
Start with one squad and a real problem. Run a controlled experiment, measure what changes and understand both the benefits and the new risks. Keep the practices that create value, adapt the ones that do not, and then take the strongest patterns into the next team.
That is how AI starts to become part of the Product Engineering operating model rather than simply another set of tools sitting alongside it.
Practical next steps
If you are thinking about starting with one squad, we’ve created practical guidance in our AI-enabled Product Engineering Knowledge Hub to help move from initial readiness through to a controlled trial.
Check out or three step process for introducing AI into your portfolio.
