Your customers don’t care how many pull requests you shipped.

A bigger pull request count makes an impressive AI productivity update. Meanwhile, a customer can still be rebuilding the same report every Monday, wondering when your product will make that job easier.

Atlassian’s State of Product 2027 captures that disconnect. Of the 1,000 product professionals surveyed, 80% say AI helps them ship faster, but customers aren’t seeing value any sooner. And 69% say decision-making hasn’t sped up alongside the push to ship faster.

There are useful gains here. In the same survey, 53% say AI has freed up more time for strategic planning and roadmap development. Teams have more capacity to build and more time to think. Yet those improvements aren’t consistently translating into earlier customer benefit.

Our takeaway is that product teams need to take responsibility for the whole journey from a customer problem to a useful change. That means following the work before development starts and after the release goes live.

Data-driven product management means using customer evidence and product data to decide what to build, then checking whether that decision helped. Customer conversations and observed behaviour count alongside analytics. The evidence needs to be able to change the plan.

A feedback inbox can become a very organised dead end

In Atlassian’s survey, 64% of respondents say customer feedback isn’t consistently used in their teams’ decisions. Asked about the challenges of using feedback for roadmap decisions, 43% cite the lack of a standard process.

That should give anyone adding another feedback channel pause. Making requests easier to submit won’t help much if the context disappears before planning.

Consider a hypothetical example. Several customers ask for a custom dashboard. A conversation reveals that they rebuild the same filtered report every Monday, then send it to a manager. The painful part is repeating the setup.

A backlog entry called “Custom dashboard builder” loses that distinction. It records the proposed solution and makes it easy to start building. A problem statement about repeated report setup leaves room to find a better answer.

Keep the original feedback attached. Watch someone produce the report, check whether usage data supports what you’ve heard, and find out which customers experience the problem. Request count is useful context; the cost of the workaround and its relevance to your product strategy matter too.

A useful customer feedback process lets anyone reviewing an idea find the evidence behind it. Our guide to collecting customer feedback in Jira covers how to connect those conversations to delivery work.

The test is whether a customer conversation can change a roadmap decision. A tidier inbox alone won’t tell you that.

Bring engineering in before the prototype wins the argument

Only 18% of survey respondents say engineers help shape features and the roadmap from the beginning of ideation. Another 38% involve them during early concept validation. That’s valuable input, but there is more room to question an approach while the solution is still open.

AI makes it easier for a PM to arrive with a convincing demo. Once people have seen it working, the conversation can drift towards how to ship it. The team starts estimating a solution it hasn’t properly challenged.

In our reporting example, an engineer might point out that the product already stores most of the settings a saved report would need. That opens up a smaller option: let customers save and reuse their report configuration. A designer can help test whether people understand the interaction.

Those contributions can change the scope before it becomes a commitment. Bring engineering into a customer conversation, share the evidence and explore alternatives together. You don’t need a finished specification to make that discussion useful.

Use AI to test competing approaches while changing direction is cheap. A polished prototype should give the team something to investigate, rather than an early commitment to defend.

If a decision comes down to gut feel write it down

The survey found that 77% of respondents say executive instinct overrides their team’s data-driven decisions at least sometimes.

That doesn’t tell us whether those decisions were wrong. Leaders may have commercial context the team hasn’t seen. Customer evidence will often be incomplete, and some worthwhile bets have to be made before the data catches up.

The problem comes when nobody can explain the assumption behind the bet, or what would make them reconsider it.

A short decision note for the reporting example could read:

We’re testing saved report configurations because customer observations suggest repeated setup is the main source of effort. We expect customers to complete their weekly report more quickly and reuse the saved configuration. We’ll compare the workflow with how they work today, then review the results after pilot customers have completed two weekly reporting cycles.

Keep links to the evidence beside that note. Name the person responsible for the review. If leadership chooses the dashboard builder for a strategic reason instead, record that reason and the assumption it depends on.

This also gives the roadmap a useful explanation. The goal is to reduce effort in weekly reporting, which can survive a change in the proposed feature. Our product roadmap guide shows how to keep goals and evidence connected to the plan.

Data-driven product management still requires judgment. Writing down the reasoning makes that judgment open to challenge and gives the team something to learn from later.

Your AI shortcut can become someone else’s work

With the decision made, AI can help draft a specification, generate code or prepare release notes. But the cost of getting that work into a usable state belongs in the productivity calculation.

In Atlassian’s survey, 82% of respondents say teammates produce low-effort AI work and revise it after feedback at least sometimes. For 28%, it happens often or all the time.

A generated specification can look complete while leaving the hard questions unanswered. For saved reports, who can see a saved configuration? What happens when a field disappears? How should permissions work? Someone still has to decide.

If the author skips those questions, the reviewer inherits them. The first draft gets faster while the next person spends longer reconstructing the context and correcting the work.

Before handing something over, check the claims, resolve the questions you’re responsible for and make the remaining uncertainties explicit. Link the original evidence so reviewers can check the reasoning without retracing the entire conversation.

When assessing AI productivity, count review and rework alongside drafting time. Your colleagues’ time counts too.

Customer adoption belongs in the delivery plan

The saved report feature is now live. Our hypothetical customer may still be rebuilding their report every Monday.

That can happen even when the team chose the right problem and built a good solution. The customer hasn’t found it, doesn’t understand what changed or can’t access it yet.

Plan for that before launch. A release note should explain the job that got easier, where to find the change and any limitations. Give support enough context to help someone use it. Our guide to automating release notes from Jira covers the drafting and publishing workflow.

Closing the customer feedback loop also means returning to the people who raised the problem. Tell them what changed and ask them to try it. A published changelog gives you something useful to share; the conversation tells you whether the change helped.

For saved reports, measure how long customers take to produce the weekly report and whether they reuse the configuration. Look at failed attempts and support questions too. A click on the new button tells you less than a completed report.

If customers don’t discover the feature, improve the communication or onboarding. If they try it and keep using the workaround, return to the evidence. Shipping another feature is an expensive way to avoid that conversation.

Find the delay in one real release

Pick one upcoming improvement and track the elapsed time from identifying the customer problem to making a decision, then from that decision to availability and successful use. Record review and rework effort separately. A week waiting for approval and a week spent correcting a specification need different fixes.

You don’t need to redesign the whole product organisation to find where this breaks. One release should give you something concrete to improve, and a reason to look beyond how much work engineering finished.

For teams working in Jira, Released Hub helps connect feedback to Jira work, share customer-facing roadmaps and publish release notes. Keep the customer’s context close to the delivery work, then give someone responsibility for checking the outcome after launch.

The number worth bragging about is how quickly a customer can stop using the workaround.

About the survey

Atlassian’s State of Product 2027 research was conducted by Wakefield Research among 1,000 product professionals at manager level or above, working at companies with 500 to 10,000 employees. Respondents were in the US (700), Germany (150) and France (150). The online survey ran from 13 to 26 August 2026. Findings are self-reported. The reporting example and practical recommendations in this article are editorial illustrations, rather than measured survey outcomes.

Sources

Survey findings from Atlassian and Wakefield Research. The reporting example and practical recommendations are editorial illustrations.

• Atlassian State of Product 2027