If you have the product manager title but don't actually decide what your team works on next, you're not alone. At nearly every organization we consult with, we run into the same problem: product managers who feel more like order takers than strategic decision-makers.
The root cause is that most organizations skip product discovery entirely. They take ideas straight from stakeholders into the delivery backlog, and the team burns through work with no validation of whether they're building the right thing.
The result is costly. Research from Pendo's 2019 Feature Adoption Report found that 80% of features in the average software product are rarely or never used. (This was long before people were using Claude to pump out features no one asked for even faster, too.) Pendo estimated that public cloud companies alone waste up to $29.5 billion in R&D on features that go unadopted. The Standish Group's data across 500,000+ projects tells a similar story: 64% of delivered features are rarely or never used.
Those numbers point more to a systemic planning failure than a coding failure. The fix is figuring out what to build before you commit engineering time. That's where Jira Product Discovery comes in.
Three root causes that kill product ownership
1 – The order taker trap
You might be able to break down work and say this epic is 20 stories. But the actual decision of what the team works on next is made by someone above you. If you try to push back, you get overruled. Your roadmap changes based on who complained last, not what's best for the product or the customer.
True product managers should have their own informed opinion on what should be worked on. They don't say "no" outright. They say "not right now, and here's why." But that requires genuine trust between product managers and their leaders. Without that trust, you're just a queue manager.
2 – "Just add it to the backlog" syndrome
You've heard it a hundred times: "Great idea. Just add it to the backlog." In theory, the backlog is a placeholder for future conversations. In practice, something in the human mind creates a built-in assumption that once an idea is in the backlog, it will eventually get done.
That assumption is false. We've seen backlogs with seven or eight-year-old items where the person who entered them doesn't even work at the company anymore. Stakeholders lose trust because the things they care about keep rotting further down the list. The backlog doesn't get refined, duplicates pile up, and people stop paying attention.
3 – Death by competing stakeholder demands
When every stakeholder insists their request is the most important thing, product managers spend all their time negotiating between people instead of thinking about what's actually best for the product. It becomes more like a screaming match than a strategy session. And nowhere in that process does anyone ask, “what's the most valuable thing for our customer or our business?”
Why introducing a new discipline beats fighting the culture
You could try to beg your boss for more autonomy. You could push to redefine role responsibilities and decision rights. In large enterprises, that's a multi-month (if not multi-year) effort that involves HR, leadership, and organizational politics.
There's an easier path. Instead of trying to fix behaviors you don't like, introduce a new discipline that makes the old behavior obsolete. That discipline is product discovery: the practice of pausing before you agree to build something, comparing it to everything else you could build, and deciding what you're not going to do.
Even in 2026, most organizations that use agile frameworks skip this step entirely. They go straight from a stakeholder's idea to the backlog to sprint planning, with no validation in between. Discovery happens before and outside of your requirements gathering and sprint planning. It's where you step back and ask: should we spend any time on this at all? Is there a cheaper, simpler way to achieve this outcome?
Start with the process. Then introduce a tool that supports it. When there's a real tool for discovery, people treat it with the formality it deserves.
What Jira Product Discovery is (and how it differs from Jira)
Jira Product Discovery (JPD) is a separate application within the Atlassian ecosystem. It's a complement to (rather than a replacement for) Jira.
- Jira handles delivery: sprints, tasks, bugs, story management.
- JPD handles discovery: ideas, insights, impact measurement, and prioritization.
The key distinction is that JPD feeds validated ideas into Jira when they're ready to be worked on. Ideas live in a separate space from your delivery backlog. You can even set up automation rules to put the admin work on autopilot. Your development team doesn't see them until they've been vetted. That separation eliminates the false expectation that everything in the backlog will eventually get built.
JPD is organized into spaces (similar to Jira) with flexible views: list views for spreadsheet-style organization, matrix views for visual prioritization, timeline views for roadmap planning, and board views for tracking discovery status. Almost everything in the Atlassian ecosystem is customizable, and most of what you need works out of the box.
Forcing clarity before anyone starts solutioning
People tend to submit requests in the form of solutions. "Build me a dashboard." "Buy me a helicopter." "Sign me up for a new mailing list." They're asking for what they've seen before, not describing the problem they need solved.
JPD helps you push back constructively. When someone submits an idea, description templates prompt them to answer real questions: What problem are you trying to solve? Who will use this? What outcome do you expect? How will we measure success?
If they can't answer those questions, the idea isn't ready. You can also make specific fields required before an idea can be created. The goal isn't to create a hundred-field intake form. It's to get just enough information so you're not spending time refining or estimating work before the requester has done basic homework.
This shifts the conversation from "when will you build my thing?" to "let's figure out if this is the right thing to build."
Hypothesis-driven thinking and RICE scoring
If your idea is well-formed, you should be able to complete this statement: "We believe [doing this] will [produce this outcome] for [these users]." If a requester can't fill in those blanks, the idea isn't ready for prime time. This format is objective. There's no ego in it. It forces you to name your users, articulate the expected outcome, and define what you're actually doing.
This also makes it safe to kill ideas. When you're comparing multiple ideas, you want to run with the one that will affect 10,000 users over the one that affects only one. But if you haven't done enough preliminary work to fill in the hypothesis statement, you can't make that comparison yet.
JPD supports this with calculated fields using RICE scoring: Reach, Impact, Confidence, and Effort. The formula (Reach x Impact x Confidence / Effort) calculates automatically. Change any value and the score updates in real time. Color coding makes the results immediately clear: green is good, red is bad.
The matrix view takes this further. Ideas appear as bubbles on an X-Y grid. You might put Impact on the X-axis and Confidence on the Y-axis, with bubble size determined by RICE score. Drag an idea across the grid and watch the fields and scores update live.
This is where it gets practical for stakeholder management. If stakeholder A owns the waiting list feature and stakeholder B owns express checkout, the RICE scores take you out of the hot seat. Instead of arguing with each other, stakeholders discuss the metrics: "Do we not understand the reach? Do we not understand the impact?" They attack the problem rather than each other.
Evidence gates: when ideas earn their way into delivery
Not everything in discovery should move to a committed backlog. You need clear criteria, published and agreed upon, that an idea must meet before it deserves engineering time. These are evidence gates.
The specifics will vary by organization, but the principle is consistent. Has a customer actually validated this idea? Can we get someone to commit to testing it when it's done? Has a sponsor been responsive? If your stakeholder hasn't responded to your emails in three months, that idea probably isn't ready to move forward.
JPD workflows support this with statuses (like "submitted," "under review," "gathering evidence," and "ready for delivery") and validators that prevent ideas from advancing if required fields are empty. When an idea does reach the "ready for delivery" status, you can create a linked Jira work item directly from JPD. The summary, description, and pinned fields carry over automatically.
Related reading: Use Jira automation to create Confluence documentation
JPD's delivery tab then shows real-time progress on linked Jira items. You can see how many are done, in progress, or blocked without leaving the discovery space. Discovery and delivery stay separate, but everyone stays informed.
Running discovery and delivery as parallel tracks
Discovery isn't a phase you complete before delivery starts. It's an ongoing discipline that runs alongside your sprint cadence. While your team delivers sprint 15, you're discovering and validating ideas for sprint 18.
Block time on your calendar for discovery every week (or at minimum every other week). Protect that time. Use it to explore ideas, talk to users and stakeholders, validate hypotheses, and update RICE scores. Meanwhile, your iterations keep running. Your team always has a continuous pipeline of validated work, not just busy work pulled from a stale backlog.
The teams that get this right are the ones whose users actually look forward to the next release. They've thought through the impact of what they're building because they gave themselves the time and space to do it.
Getting started with JPD
You don't need to provision licenses for your entire organization on day one. Start with a couple of pilot teams and a handful of product managers. JPD licensing works similarly to Jira Service Management: paid users can edit ideas, link them to delivery items, add insights, and manage workflows. Unpaid users can submit ideas and view them, which opens up intake to a much broader group at minimal cost.
Each space can be customized independently, so different teams can configure their own fields, workflows, and views based on how they evaluate work. As pilot teams demonstrate the value of structured discovery, peer pressure builds and adoption grows organically.
Sketch is an Atlassian Solutions Partner, and our team helps organizations implement JPD and connect it to their existing Jira delivery workflows. We also provide teams with the Atlassian training you need to get more from your existing tools. If you're interested in exploring what product discovery could look like for your team, reach out to schedule a conversation.
Agile
Atlassian