Building got faster. Deciding did not.
My takeaways from Atlassian's State of Product 2027. AI has PMs, designers and engineers doing each other's work. It has not got them deciding together.
89% of product teams now regularly use AI to do work that used to belong to another function.
So you would expect the product trio to finally work as one team. It doesn't.
That number comes from Atlassian's State of Product 2027 report, based on a survey of 1,000 product professionals. I read it with one question in mind: if AI made everyone on the team more capable, did the team get better at deciding what to build? The short answer is no, and the numbers that show it are the interesting part of the report.
The building part sped up
Start with the good news, because it is real. 80% of respondents say AI helps them ship faster.
Now the rest of that sentence: customers are not seeing value any sooner. Faster shipping did not turn into faster value, because shipping was never the only thing in the way.
The report names the other thing directly. 69% agree that more effort has gone into shipping faster while decision-making hasn't sped up, even with AI. And 86% agree that, as shipping gets easier, deciding what to build matters more, because customer attention and go-to-market capacity are limited and every new feature adds maintenance.
So we've sped up the building part. But we're still getting stuck on what to build.
Who decides, and on what evidence
Two more numbers explain where the decisions get stuck.
77% say executive gut instinct overrides data-driven product decisions at least sometimes. Atlassian calls this the HiPPO problem, the highest-paid person's opinion. Data does not decide anything on its own, and I would not want it to. I argue for being data-informed, not data-driven. But when three in four teams see evidence lose to seniority at least some of the time, people learn that gathering it is optional.
Only 4% can trace every roadmap decision back to customer feedback or evidence. Most teams do collect feedback. The report says 77% log it formally, and 64% say it isn't consistently used in decisions. Collecting evidence and deciding with it are two different habits, and only the first one is common. That is the gap the Opportunity Solution Tree is meant to close: every feature tied to a customer problem you can point to.
Doing each other's jobs is not deciding together
And unfortunately, tech people still don't do discovery.
On 82% of teams, engineers are not involved from the beginning of ideation. They join during concept validation or later. Atlassian says that is essentially the same picture as last year.
Put that next to the 89% from the top. PMs prototype. Designers ship functional work. Engineers pick up product tasks. Everyone can now do a bit of everyone else's job. But the moment where the team decides what is worth building still happens without the engineer in the room.
People are doing each other's jobs. They're still not deciding together. They're just multiplying the work being done.
That is the opposite of what a product trio is for. The trio was never about three people who can each produce a bit of everything. It is three vantage points on one decision: is it valuable, is it usable, is it feasible, is it viable for the business. An engineer who joins after ideation can only tell you whether the idea is buildable. By then, the question of whether it is worth building has already been answered without them. I wrote about how AI is moving tasks between roles in AI is changing product team roles. This report adds the part that worries me: the tasks moved, the decision did not.
Use AI to learn, not just to ship
For me, all of this makes discovery more important, not less. I made the longer case in discovery matters more when building is cheap. The State of Product numbers are what that argument looks like from inside 1,000 teams.
Here is what I would do with AI instead of squeezing another feature into the sprint:
- Test an assumption. Pick the riskiest belief behind the next big item on the roadmap and check it before anyone builds.
- Explore a few options. Generate three or four ways to solve the problem, not one polished version of the first idea.
- Make sense of customer feedback. The teams logging feedback and not using it do not need more feedback. They need it summarized and in front of the people deciding.
A prototype built in an afternoon is great if it helps you learn something before committing weeks to it. Otherwise, you're just building the wrong thing faster.
Bring the engineer in at the start, when the options are still open, and put the evidence on the table before the highest-paid opinion lands. That is the shift the AI-First workshop and sprint is built around: using AI to decide faster, not just to build faster.
Where is the bottleneck on your team?
Building, deciding, or getting customers to actually use what you ship?
If the honest answer is deciding, more AI in the delivery pipeline will not move it. Who is in the room, and what evidence they bring, will.
