Jira for product managers: the setup most PMs don’t know about

The PM’s Jira problem

Most product managers inherit Jira as “the engineering tool” and never realize it can do actual PM work. You end up maintaining a separate roadmap in Productboard, tracking priorities in a spreadsheet, and using Jira purely to watch tickets move from left to right. That’s a missed opportunity. Jira for product management isn’t just possible—when configured properly, it becomes the single source of truth that connects your strategy to what’s actually getting built.

The problem isn’t Jira itself. It’s that Jira out of the box is configured for Scrum teams, not product thinking. This guide shows you how to set it up for PM work, what views actually matter for your job, and how to extract insights without becoming a Jira admin.

Why most PMs underuse Jira

Jira’s default setup optimizes for sprint ceremonies: backlog grooming, sprint planning, velocity tracking. These matter, but they’re engineering concerns. Product managers need to answer different questions:

• What outcomes are we driving toward this quarter?
• How does this feature request connect to our strategy?
• What’s the status of Initiative X across multiple teams?
• Are we spending time on the right problems?

Out of the box, Jira doesn’t answer any of these. But with the right hierarchy, custom fields, and views, it can. The key is thinking of Jira as a work management system, not a ticket tracker.

Setting up Jira’s hierarchy for product work

Jira’s default hierarchy is Epic → Story → Subtask. This is too flat for product management. You need at least one level above Epics to represent strategic initiatives. In Jira Premium and Enterprise plans, you get access to additional hierarchy levels. Here’s the structure that works:

The four-level PM hierarchy

1. Initiatives (or Goals) — Quarterly or half-yearly strategic bets tied to outcomes. Example: “Reduce churn for SMB segment by 15%.”
2. Epics — Major features or workstreams that contribute to an initiative. Example: “Onboarding redesign for SMB accounts.”
3. Stories/Tasks — Shippable units of work. Example: “Add industry-specific onboarding templates.”
4. Subtasks — Implementation details owned by engineering.

This hierarchy lets you trace any piece of work back to the strategic bet it serves. When a stakeholder asks “why are we building this?”, the answer is in the ticket’s parent chain.

How to set this up

If you have Jira Premium, go to Project Settings → Issue Types → Issue Type Hierarchy and add a level above Epics. Call it “Initiative” or “Goal” (I prefer Initiative because it implies action).

If you’re on Jira Standard, you can fake this with labels or a custom “Initiative” field that links stories to a master list. It’s messier, but it works. Create a custom single-select field called “Initiative” and maintain the options as your quarterly priorities.

Using Jira roadmaps for PM planning

Jira’s built-in roadmap feature (formerly called “Plans” in Advanced Roadmaps) is underrated. Most PMs dismiss it because early versions were clunky. The current version is genuinely useful for Jira for product management workflows, especially if your roadmap is outcome-based rather than feature-based.

Basic Roadmap (included in all plans)

The Basic Roadmap shows Epics on a timeline within a single project. It’s useful for:

• Visualizing the next 2-3 months of committed work
• Spotting scheduling conflicts
• Giving stakeholders a “what’s coming” view without access to the full backlog

To make it useful: set start and due dates on your Epics (I know, PMs hate committing to dates, but “target quarter” granularity is fine). Group by Initiative if you’ve set up the hierarchy. Filter out anything in “Won’t Do” status.

Advanced Roadmaps (Premium only)

Advanced Roadmaps is where Jira becomes a real planning tool. It lets you:

• View work across multiple projects and teams
• Model capacity and see overallocation
• Create “what-if” scenarios without affecting live data
• Roll up progress from child issues automatically

The killer feature for PMs is dependency mapping. You can link Epics that depend on each other and see when downstream work is blocked by upstream delays. This is the view you show in cross-team planning sessions.

The PM views worth setting up

Jira’s power is in its filters and dashboards, but most PMs stick with default views. Here are five custom views worth creating:

1. The “My initiatives” board

Create a Kanban board filtered to show only Initiatives and Epics you own. Columns should be: Discovery, Ready for Dev, In Progress, Shipped, Measuring. This is your operating view—the first thing you check each morning.

2. The stakeholder update filter

Create a saved filter: project = [YOUR PROJECT] AND type = Epic AND updated >= -7d ORDER BY updated DESC. This shows everything that moved in the last week. Export it or share the link in your weekly update instead of writing status reports from scratch.

3. The “blocked” alert

Filter: status = "Blocked" OR flagged = Impediment. Check this daily. Your job includes removing obstacles for the team—this view tells you where to focus.

4. The quarterly priority view

Use labels or a custom field to tag items by quarter (Q1-2024, Q2-2024, etc.). Create a filter showing everything tagged for the current quarter, grouped by Initiative. This is your source of truth when someone asks “are we on track for Q2 goals?”

5. The discovery backlog

Not everything in your backlog is validated. Create an issue type called “Opportunity” or use a status called “Needs Discovery.” Filter to show only these. This is where feature requests and ideas live before they earn a spot in the prioritized backlog. Teresa Torres calls this the opportunity solution tree [INTERNAL_LINK: opportunity solution tree]—Jira can hold the opportunities even if you map the tree elsewhere.

Getting useful data out of Jira

Jira contains valuable data that most PMs never access because the reporting feels intimidating. You don’t need to be a Jira admin to pull insights. Here’s what’s actually useful:

Cycle time (how long things take)

In your board settings, enable the Control Chart. This shows how long issues spend in each status. Look for patterns: Are stories sitting in “Code Review” for days? That’s a process problem. Is “Ready for QA” a bottleneck? You might need to talk about testing capacity.

Marty Cagan talks about the importance of reducing time to learn [INTERNAL_LINK: continuous discovery]. Cycle time data shows you where learning gets delayed.

Velocity (but use it carefully)

Velocity charts show how many story points the team completes per sprint. This is useful for capacity planning but dangerous if used as a performance metric. Teams game story points when they’re measured on velocity. Use velocity to answer “can we fit this in the next sprint?” not “is the team working hard enough?”

Cumulative flow diagram

The CFD shows how work moves through your process over time. A healthy CFD has bands that are roughly parallel. If “In Progress” keeps widening, you’re starting more than you’re finishing—a sign of too much WIP. If “Done” flatlines while other bands grow, you’ve got a bottleneck.

Resolution time by initiative

Create a JQL query grouping completed items by Initiative: project = [YOUR PROJECT] AND resolved >= -90d AND "Initiative" is not EMPTY. Export to CSV and analyze in a spreadsheet. Which initiatives are shipping quickly? Which are dragging? This tells you where to investigate.

Common Jira mistakes PMs make

After watching dozens of PMs use Jira, these are the patterns that cause the most pain:

Mistake 1: Treating Jira as the source of truth for everything

Jira is good at tracking work that’s been committed to. It’s bad at early-stage strategy and customer research. Don’t force discovery notes or competitive analysis into Jira tickets. Use Notion, Confluence, or Dovetail for that, and link to Jira only when you’ve validated an opportunity enough to build something.

Mistake 2: Creating epics that are actually initiatives

An Epic called “Improve retention” isn’t an Epic—it’s a goal. Epics should be shippable. “Build cohort analysis dashboard” is an Epic. “Improve retention” is the Initiative it serves. Mixing levels creates confusion about what’s actually being worked on.

Mistake 3: Over-specifying stories

PMs sometimes write novels in story descriptions. Engineers then feel obligated to build exactly what’s specified, killing collaboration. A good story has: context (why this matters), acceptance criteria (how we’ll know it’s done), and open questions (what we still need to figure out). Save the implementation details for sprint planning conversations.

Mistake 4: Ignoring the “Won’t Do” resolution

Most teams only close tickets as “Done.” But explicitly marking things as “Won’t Do” with a reason is valuable. It creates a record of decisions, prevents the same idea from being re-proposed every quarter, and gives you data on how much of your backlog is noise.

Mistake 5: Not connecting Jira to outcomes

The biggest gap in most Jira setups: no link between shipped work and business results. Consider adding a custom field called “Outcome” or “Success Metric” to Epics. After launch, update the Epic with actual results. This creates institutional memory about what worked—useful for roadmap planning and building PM judgment.

Making Jira for product management work long-term

The secret to sustainable Jira usage isn’t complex configuration—it’s consistency. Pick a hierarchy that matches how your company thinks about work. Set up five views that answer your recurring questions. Review and clean the backlog monthly. Resist the temptation to create new issue types for every edge case.

Companies like Atlassian themselves (unsurprisingly), Spotify, and Square use Jira extensively for PM work. The difference between their setups and a frustrating Jira experience isn’t the tool—it’s the discipline to maintain clear structures and resist scope creep in configuration.

Start with one change this week: create the “My initiatives” board from the views section above. Use it as your daily operating view for a month. Once that’s habit, add the next view. Small improvements compound into a system that actually serves your PM work instead of just tracking developer tickets.

Frequently asked questions