If Product Engineering is the foundation for AI-enabled delivery, how do you build that capability across an entire portfolio?
In our last article, Stop Scaling Engineering With Headcount, we argued that organisations should stop assuming that more engineering capacity always means more engineers.
AI changes that equation. But there was an important caveat: before organisations can effectively orchestrate AI delivery, Product and Engineering need to be able to work effectively together themselves. Wisereach
That raises the next question.
How do you build strong Product Engineering capability across dozens of teams without putting everybody through the same training programme?
AI will amplify the operating model you already have
There is a danger in treating AI as a productivity layer that can simply be added to existing teams.
If Product still defines requirements and hands them over to Engineering, AI may make that handoff faster. If teams are focused primarily on output, AI may help them create more output. If technical health is routinely traded away for short-term delivery, AI can accelerate that too.
AI does not automatically create better product teams. It amplifies the way those teams already work.
So before giving every squad access to more AI tools, organisations should ask a more fundamental question:
Are our Product and Engineering teams operating in a way that allows AI to create real value?
Product Engineering starts with shared ownership
At Wisereach, we think of Product Engineering as Product and Engineering working together around a shared outcome.
That does not mean blurring accountability.
Product still needs to understand the customer, define the problem, establish the value and decide what matters most. Engineering still needs to understand the technology, shape the solution, make sound technical decisions and understand what it will take to deliver.
But the important decisions are made together.
The team understands the problem together, shapes the solution together, estimates together, delivers together and learns together.
That creates a much stronger foundation for AI-enabled delivery, because AI is then augmenting a team that already knows how to make good decisions.
Don't put everybody through the same programme
Once organisations recognise that Product Engineering capability matters, the obvious response can be to launch a large training programme.
We think there is a better model.
Start by creating a common Product Engineering foundation across the portfolio.
Product Managers, Engineers, Designers, Delivery people and Technical Leaders should all understand the core principles: customer value, business outcomes, technical health, discovery, delivery and shared team ownership.
That creates a common language and a minimum baseline.
After that, teams should be able to follow different paths.
Different squads have different gaps
One squad may have excellent engineering capability but weak product discovery. Another may know its customers extremely well but struggle to break work into small, testable increments.
Another may deliver rapidly but continually accumulate technical debt. Another may still have Product and Engineering operating as two separate functions.
It makes little sense to send all four teams through exactly the same learning.
A better approach is to establish the baseline, then help each squad understand where it needs to improve most.
For one team, that may mean product discovery. For another, it may be technical health, experimentation, prioritisation, outcome-based planning or simply improving the way Product and Engineering make decisions together.
The aim is not to make every squad identical.
It is to get every squad to a level where it can operate effectively — and then let each team strengthen the areas that matter most.
Learning should be part of changing how the team works
This is also why we increasingly think learning should be closely connected to real work.
A team should not learn about experimentation because it happens to be the next module in a course. It should learn about experimentation because it has a real hypothesis it needs to test.
It should not learn about technical health as an abstract concept. It should use the learning to make better decisions about its own architecture, maintainability and engineering trade-offs. That makes capability building much more practical.
It also means the learning pathway can become part of the transformation itself rather than something that happens alongside it.
Then AI becomes an accelerator
Once teams have that foundation, the opportunity from AI becomes significantly more interesting.
AI can help Product teams analyse customer feedback, synthesise research, explore opportunities and challenge assumptions. It can help Designers move from idea to prototype faster. It can help Engineers code, test, refactor, document and investigate defects.
It can also begin to perform meaningful parts of the product engineering workflow through increasingly capable AI agents.
But the teams most likely to benefit will not necessarily be the ones with the most AI tools.
They will be the teams that know what outcome they are trying to achieve, work effectively across Product and Engineering, maintain sensible technical standards and can judge where AI should — and should not — be trusted.
Build capability, then increase capacity
That gives us a practical sequence for organisations that want to move towards AI-enabled Product Engineering.
First, establish a common Product Engineering foundation across the portfolio.
Then help each squad improve the areas where it has the greatest gaps.
Only then start introducing AI into teams where it can genuinely increase capacity or improve decisions. That sequence matters.
Because the real opportunity is not simply to help existing teams produce more software. It is to build stronger internal product and engineering capability, then surround that capability with increasingly scalable AI delivery capacity.
That is the model we believe will create the biggest advantage.
