Jira for Product Managers: How to Use It Without Losing Your Mind

Jira Is Not the Problem - Your Setup Is

Jira is the most polarising tool in product management. Engineers complain it’s bloated. PMs complain it’s designed for developers, not product people. Managers complain it doesn’t give them the visibility they need. And yet, Jira remains the most widely used project management tool in software development, powering over 75,000 organisations globally.

After years of managing AI products using Jira across teams of 10 to 100+, I’ve reached a conclusion that’s unpopular but true: Jira is not the problem. Bad Jira setup is the problem. A well-configured Jira instance is one of the most powerful tools a product manager can have. A poorly configured one is a productivity black hole.

Here’s how to set it up right, use it effectively, and avoid the traps that make teams hate it.

Setting Up Jira the Right Way

Project Structure

Most Jira disasters start with bad project structure. Here’s the approach that’s worked across multiple teams:

One project per product area, not per team. If your mobile app, web app, and API all serve the same product, they should be in the same Jira project. This gives you a unified product roadmap view and prevents cross-project dependency tracking nightmares.

Use components for sub-areas. Within a project, components let you categorise issues - Frontend, Backend, Mobile, Infrastructure, Design - without creating separate projects. This is cleaner and enables cross-cutting reporting.

Epics for features, not time periods. An epic should represent a user-facing capability or initiative, not “Sprint 23 work.” Good epics: “User Onboarding Redesign,” “Payment Processing V2,” “Search Performance Optimisation.” Bad epics: “Q3 Backend Work,” “Miscellaneous Bugs.”

Issue Types That Work

Keep issue types simple. The more types you create, the more confusion you generate:

• Epic - A feature or initiative. Owned by the PM. Contains the “why” and acceptance criteria
• Story - A user-facing piece of work within an epic. Written in user story format when possible. Estimated by engineering
• Task - A technical or operational work item that isn’t user-facing. Database migrations, infrastructure changes, documentation
• Bug - A defect in existing functionality. Include reproduction steps, expected vs. actual behaviour, and severity

That’s it. Resist the urge to add “Spike,” “Research,” “Tech Debt,” “Design Task,” and fifteen other custom types. You can use labels for those distinctions without polluting the issue type system.

Custom Fields - Less Is More

This is where most Jira instances go wrong. Every stakeholder wants their own custom field. After a year, you have thirty custom fields, and nobody fills in any of them consistently.

My rule: five custom fields maximum beyond Jira’s defaults:

• Customer Impact (Low/Medium/High) - Forces PMs to think about who benefits
• Effort Estimate (story points or T-shirt size) - For capacity planning
• Priority Score (number) - RICE or WSJF score for data-driven prioritisation
• Release Target (version) - Which release this ships in
• Team (if multiple teams share a project) - For filtering and reporting

Every custom field you add is a tax on your team. Only add fields that directly influence decisions.

Using Jira as a Product Manager

Sprint Planning

Jira’s board and backlog views are designed for agile product management. Here’s how I run sprint planning:

Before the meeting: Groom the top of the backlog. Ensure the top 15-20 stories have clear acceptance criteria, effort estimates, and are linked to the correct epic. Use Jira’s “Refine” label to tag items that need discussion.

During planning: Pull stories from the backlog into the sprint. Jira’s sprint velocity chart tells you your team’s average throughput. Don’t plan beyond 80% of velocity - leave buffer for bugs, production issues, and the unexpected.

During the sprint: Use the board view daily. The board should answer “what’s in progress, what’s blocked, and what’s done” in three seconds. If it takes longer, your workflow has too many columns.

Roadmap Visibility

Jira’s built-in roadmap (in Jira Premium/Advanced Roadmaps) has improved significantly. You get a timeline view of epics with dependencies, capacity indicators, and filtering by team or label.

For product roadmap tools, Jira’s roadmap is adequate for engineering-audience roadmaps. For executive or customer-facing roadmaps, you’ll want to supplement with Aha! or Productboard - tools built for strategic storytelling rather than execution tracking.

JQL - The PM’s Secret Weapon

JQL (Jira Query Language) is Jira’s most underused feature by PMs. Learning basic JQL transforms Jira from a task board into a powerful reporting tool.

Queries every PM should save:

“What shipped this sprint?” project = MYPROJECT AND sprint in openSprints() AND status = Done ORDER BY resolved DESC

“What’s blocked right now?” project = MYPROJECT AND status = Blocked ORDER BY priority DESC

“All bugs reported this month by severity” project = MYPROJECT AND type = Bug AND created >= startOfMonth() ORDER BY priority DESC

“My team’s velocity trend” - Use Jira’s built-in velocity report, but JQL dashboards can supplement this with custom dimensions.

“Features delivered this quarter” project = MYPROJECT AND type = Epic AND status = Done AND resolved >= startOfQuarter() ORDER BY resolved DESC

These saved filters, pinned to your Jira dashboard, give you instant answers to the questions stakeholders ask most frequently. Instead of digging through boards, you share a dashboard link.

Jira Integrations That Matter

Jira’s ecosystem is its moat. The Atlassian Marketplace has thousands of apps, but most PMs only need a handful:

• Confluence - For PRDs, specs, and decision documentation linked bidirectionally to Jira issues
• Slack integration - Jira notifications in Slack channels, plus the ability to create Jira issues from Slack messages
• Figma for Jira - Embed Figma designs directly in Jira issues. Designers and engineers see the same context
• GitHub/Bitbucket - See code commits, branches, and PRs linked to Jira issues. Track development progress without asking engineers for updates
• Automation for Jira - Built-in automation rules for transitions, assignments, and notifications. Reduces program management overhead

Common Jira Mistakes and How to Fix Them

The Jira Graveyard

Symptoms: Hundreds of stale tickets in the backlog that nobody looks at. Stories from eighteen months ago sitting at the bottom of an infinite scroll.

Fix: Quarterly backlog purges. Any ticket untouched for 90 days gets reviewed. If it’s still relevant, update it and prioritise it. If not, close it with resolution “Won’t Do.” A clean backlog is a usable backlog.

The Workflow Maze

Symptoms: A workflow with 12+ statuses, mandatory fields at every transition, and approval gates that slow engineering to a crawl.

Fix: Maximum six statuses. To Do → In Progress → In Review → QA → Done. Add “Blocked” if you need it. Every additional status is friction. Mandatory fields should only exist at creation, not at transitions.

The Estimation Nightmare

Symptoms: Two-hour sprint planning sessions because every story gets debated for twenty minutes. Story point debates that devolve into hours-vs-points philosophical arguments.

Fix: T-shirt sizing for planning, story points for tracking. Use S/M/L/XL in planning to quickly categorise effort. Map these to point values (S=1, M=3, L=5, XL=8) for velocity tracking. If a story is XL, it needs decomposition, not estimation.

The Dashboard Nobody Reads

Symptoms: An elaborate Jira dashboard with fifteen widgets that the PM updates weekly and nobody else opens.

Fix: Build dashboards for your audience, not yourself. An engineering lead needs sprint burn-down and blocked items. A VP needs epic progress and delivery dates. A program manager needs cross-team dependencies and risk indicators. One dashboard for each audience.

Jira vs. the Alternatives

Jira vs. Linear

Linear is faster, simpler, and more opinionated. It trades Jira’s flexibility for speed and developer experience. If your team is under 50 people and engineering-centric, Linear is usually the better choice. If you’re an enterprise with established Atlassian investments, compliance requirements, and complex workflows, Jira’s maturity matters.

Jira vs. ClickUp

ClickUp tries to do everything - docs, goals, whiteboards, time tracking - alongside project management. Jira does project management deeply and relies on Confluence, Trello, and marketplace apps for adjacent functions. ClickUp is broader; Jira is deeper. Choose based on whether you want one tool or an ecosystem.

Jira vs. Asana

Asana is friendlier for non-technical teams. Marketing program managers and brand managers often prefer Asana’s cleaner interface. Jira is better for engineering workflows. If your team is a mix, Jira with good configuration can serve both - but Asana requires less configuration to be usable.

My Verdict

Jira is powerful but demanding. It rewards teams that invest in configuration, maintain discipline about backlog hygiene, and use its advanced features (JQL, automation, roadmaps). It punishes teams that set it up carelessly and expect it to solve organisational problems that are really process problems.

If you’re choosing Jira, commit to maintaining it. Assign a Jira champion. Run quarterly reviews of workflows and custom fields. Purge the backlog. Jira is a tool that gets better or worse over time based entirely on how you maintain it.

The best product teams I’ve worked with use Jira extremely well. The worst product teams I’ve worked with also use Jira - they just use it badly. The tool isn’t the variable. Your discipline is.

---

If you’re part of Atlassian and reading this - I’d love to bring my experience in product management, AI products, and cross-functional program leadership to help evolve Jira for the next generation of product teams. If you have a role that matches my background, please reach out to me.

Related reading: product manager tools, agile product management, how to reduce release cycle time, or product roadmap tools.