AI use is accelerating across the modern enterprise. Teams are moving faster. The barrier to building will continue to drop.
But the cost of building the wrong thing is about to skyrocket, because teams can now ship more of it, faster.
Atlassian’s State of Teams 2026 report found that 89% of executives say AI has increased the speed of work. But only 6% feel confident they can point to specific organisation-wide AI ROI. That gap is a sign that speed, on its own, doesn’t actually create better products.
After watching hundreds of product managers across Atlassian navigate this shift over the past year, we think solving the speed‑without‑ROI problem is less about tools and more about three changes in how product teams work.
The job hasn’t changed. How you do it has.
1. Product craft is still the differentiator
The PMs who thrive won’t be the ones who use AI most. They’ll be the ones who use it with sharper judgment, who know what’s worth building and why.
Atlassian’s AI Collaboration Index found that teams who treat AI as a shared partner, rather than a personal shortcut, see 2x the ROI on their AI efforts. The difference isn’t adoption. It’s judgment about where to apply AI and when to override it.
AI changes how you work. Your judgment is what makes it count.
2. AI collapses the distance between idea and evidence
Product managers have always sat between the customer and the solution. The problem was the distance: commission the research, wait for the readout, translate for the team, review the mocks, ship, and hope for the best.
AI compresses that loop. PMs can now prototype ideas, query customer data, and test concepts directly, not to become designers or engineers, but to develop ‘product builder’ skills. That means flexing into areas that were previously out of reach.
The closer you are to the work, the sharper the craft. So, discover faster, validate sooner, and communicate with a working prototype, not a document.
3. The PM’s job is to rewire how the team learns, decides, and acts
Here’s the part most AI productivity conversations miss entirely.
The bottleneck in most teams isn’t execution anymore. It’s how fast the team can learn, decide, and act together. The State of Teams 2026 report calls this the ‘AI fragmentation tax’: as individuals use AI to move faster, coordination gets harder. Reviews, approvals, and alignment decisions can’t keep up with the flood of new work. Across the Fortune 500, that adds up to roughly $161 billion a year in lost productivity.
The teams winning right now have rewired how they generate insights and make decisions. AI-native PMs don’t sit at the centre of every decision, they remove themselves as the bottleneck. They build the conditions for their team to move at speed: the context, the data, and setting the bar for quality. You build a high-performing team by scaling your team members’ autonomy.
What AI-native product management actually looks like
There’s a useful distinction that keeps coming up in conversations with product leaders. We see three archetypes forming, and only one of them is where product management is headed.
The PM who becomes an engineer: A PM whose primary value has shifted to writing code. Real PM work gets left undone: customer context drifts, strategy conversations stop happening, and the team loses its navigator. Builder skills used this way don’t amplify craft, they replace it.
The PM who uses AI as a productivity layer: A PM who uses AI to do their existing job faster without changing how they make decisions. For instance, AI might be used to summarise the meeting or draft the PRD. It’s useful, but not transformative. The bar is whether AI changed the decisions, not just the admin.
The AI-native product manager: A PM whose team makes good decisions faster than they used to, because the PM changed how context moves. They build to learn, and they’re as quick to stop work as they are to start it. The real measure is how fast the team can learn, decide, and act, not the PM’s own output.
That third archetype is where the role is heading, and it shows up in specific, practical ways across the product development lifecycle.
What changes in practice: learn, decide, act
The shift from ‘AI as a productivity tool’ to ‘AI-native practice’ shows up in three areas.
1. Customer understanding moves from scheduled to continuous (Learn)
Customer understanding is the bottleneck on every decision your team makes. What’s changed is that you don’t need to commission it anymore – now you can build the system that generates it.
AI agents that synthesise support tickets, NPS data, forum conversations, and in-product behaviour allow you to regularly understand what your customers need. The shift is from pull to push, and ultimately the process has become more proactive.
For example, one of our PM teams replaced a two-week research cycle with an agent that synthesised support data, NPS feedback, and in-product behaviour. They got to the same calibre of insights they’d usually expect from this two-week cycle, all in an afternoon. This wasn’t because AI had better judgment, but because the PM had designed a system that made the data available on demand.
The takeaway: your team can answer a specific customer question in minutes, not days, without scheduling a research session.
2. Prototypes replace documents as the starting point for decisions (Decide)
A prototype answers “should we build this?” faster than a Product Requirements Document ever could, especially when real users are reacting to it.
The value is less about the coding itself and more about compressing the loop between idea, customer feedback, and evidence so you can make a decision while it can still change the outcome. So, build a rough prototype, back it with real data, and show it to customers. The prototype becomes a conversation rather than just an output.
Across our product teams, prototyping has shifted from a specialist skill to a default starting point. The question isn’t whether to prototype. It’s how many ideas were ruled out early because a prototype made it obvious the direction was wrong. Faster clarity on what’s worth building and what isn’t: that’s the real ROI.
The takeaway: you can go from idea to working prototype to customer reaction to a build decision in a single week.
A note on code contribution: the goal isn’t to turn PMs into engineers. It’s to make product managers more fluent in the systems they’re shaping. PMs who can contribute code, even in small ways, get closer to the trade-offs behind the product. They ask sharper questions, write clearer specs, and spot issues earlier because they understand how the work actually gets built.
3. Quality becomes a feedback loop, not a launch gate (Act)
With traditional software, a feature either works or it doesn’t. AI features are different. They work on a spectrum of quality, and someone has to define what ‘good enough’ looks like, defend that bar through the build, and keep watching it after launch.
Without evaluations, you won’t find out where you landed until users tell you. And by then you’ve already shipped the wrong thing at scale.
Evals are how PMs’ judgment calls become legible to the rest of the team. Define ‘good’ before the sprint starts. Run a suite before shipping. Monitor after launch. The bar moves with the model. The PM’s job is to hold it.
The takeaway: every AI feature shipped has eval criteria defined before build begins, and a monitoring view in place after launch.
Measuring what matters (and what doesn’t)
The obvious question: how do you know if your team is actually becoming AI-native, or just using AI more?
Most organisations start by measuring adoption — logins, prompts, and tool usage. Those numbers go up quickly and tell you almost nothing about whether the team is making better decisions.
The distinction that’s helped us is separating role expectations from capabilities. Role expectations describe the scope and impact expected at each level. AI is raising that bar. PMs can now get closer to customer signal, data, prototypes, technical context, and quality feedback than ever before. Capabilities describe how PMs grow into that expanded scope without losing the craft that made them effective in the first place.
We’ve been mapping AI fluency across six capability areas:
- Tool fluency: knowing which AI tools to use, when to use them, and when human judgment should override them.
- Discovery: using AI to turn customer signal into insights faster.
- Data and insights: automating the flow of evidence teams use to make decisions.
- Evals and quality: defining, testing, and monitoring what ‘good’ looks like.
- Prototyping: turning ideas into working artifacts quickly enough to learn from them.
- Technical leverage: getting close enough to the code, systems, and trade-offs to make sharper product calls.
Across each capability, we use a simple progression from L1: Curious to L5: Pioneering. It gives PMs and teams direction for growth: where they are today, where their context asks them to go deeper, and what good could look like next.
The capability mix will vary by team. What matters is that PMs have a shared language for growth, and teams have a clearer way to ask the real question: has AI changed how we learn, decide, and hold the quality bar?
What we’re learning along the way
We’re sharing this because we think the shift is universal, not Atlassian-specific. But we’d be dishonest if we presented it as a clean playbook. It’s messier than that.
In our most recent AI Builders Week, we saw a jump in AI intensity with super users increasing usage by 147% and average users by 175%. We also saw a 15-20x spike in daily usage for Rovo Dev, Atlassian’s coding agent. But the numbers only tell part of the story — what actually shifted was how teams learned from each other along the way.
Training matters, and it’s continuous. As AI evolves and teams discover new ways of working, the training muscle needs to keep flexing. But the thing we didn’t fully appreciate early on was how much the culture around training would matter. The teams that changed fastest weren’t just the ones who attended sessions. They were the ones where a PM ran an experiment, shared what they learned in Slack, and someone else copied it the next day.
That pattern of small experiments shared visibly turned out to be the multiplier. Training builds the foundation. Community and visible sharing build the compounding loop where teams continually optimise, evolve, and get better together. As Dr. Molly Sands, Head of Atlassian’s Teamwork Lab, has noted in broader research: teams where managers demonstrate AI use see 3x higher strategic AI adoption.
The other thing that surprised us: the hard part wasn’t getting PMs to use AI. It was getting them to change the decisions they made with it. While summarising meetings faster is useful, replacing a two-week research cycle with continuous customer understanding is actually transformative. Those two outcomes look similar on the surface. The gap between them is mindset, not tooling.
Where to start
If you’re leading a product team and any of this resonates, here are three things you can do this week:
- Pick one customer question you’d normally wait a week to answer. Try to answer it from live data in 30 minutes. See what’s possible with the tools you already have.
- Replace one PRD or spec doc with a working prototype. Even a rough one. Use it to get feedback from a customer or stakeholder before committing to build.
- Define ‘good’ and ‘failure’ for your next AI feature before the sprint starts. Write down the eval criteria. Share them with the team. Revisit them after launch.
None of these require new tools, budgets, or approvals. All you need is a willingness to work differently.
The product team that learns fastest will build the best products. That’s no longer a bet, that’s an expectation. The learning doesn’t necessarily even need to be about AI technology itself, it’s more about what AI makes possible when product teams use it to get closer to the work that already mattered. These priorities haven’t changed. It’s still about understanding the customer, making sharper calls, and knowing when to stop building.
For more on how teams are adapting to this shift, read the full State of Teams 2026 report or download the AI Fluency ebook.
