A roadmap that works perfectly for you can still fail everyone else.
Jensen Fleming, a Principal Product Manager on Atlassian’s Rovo Agents team, had built what felt like the ideal board in Jira Product Discovery (JPD). It tracked workstreams, timelines, delivery status, design progress, legal review, engineer assignments, Figma links … everything.
Then her designer opened it and froze. “There was just too much,” says Jensen.
The board wasn’t wrong. It was comprehensive, but it was optimized for the PM, not the people who needed to use it. That realization changed how Jensen thought about roadmaps. Instead of expecting every partner to navigate her control tower, she started building purpose-built views for each of them.
From ‘helpful’ to ‘cannot live without’
Jensen had been using Jira Product Discovery for years, but about a year ago, her approach changed. “I unlocked JPD’s value when I discovered micro views,” she says. “It went from helpful to something I couldn’t live without.”
Instead of expecting one board to serve everyone, Jensen started building purpose-built views for each recurring conversation: design, legal, support docs, front-end engineering, capacity planning. Each view showed only what that audience needed and nothing more.
What clarity looks like for design
Jensen’s designer, Kate, was the first beneficiary. Jensen’s main control tower has 21 fields, most of which Kate doesn’t need. Kate needs to know what requires design work, in what order, and when it starts blocking engineering.
Her dedicated design roadmap includes:
- Design status. Projects tagged “not needed” disappear, immediately filtering out 30–40% of items.
- Priority order. Jensen arranges the remaining work by what Kate should tackle next.
- Notes. A shared field captures action items between one-on-ones so they can pick up where they left off.
- Start dates. If designs aren’t ready by the start date, engineering stalls, so blockers are obvious.
- Engineer assignments. Kate can go directly to the right engineer without routing everything through Jensen.
- Figma links. No more daily “can you resend that?” messages.
The result is 13 fields instead of 21: A focused to-do list instead of an overwhelming dashboard. Once items are marked done, they disappear from Kate’s view, making progress feels tangible.
Fast reviews need focused views
Jensen meets with legal every two weeks for a 30-minute sync. The sessions move fast as they work through a focused list of items that need review.
The legal view includes a summary, legal review status, notes, and expected end dates. Items that don’t require review are filtered out.
“We go through it like a checklist,” Jensen says. “We don’t have time to talk about each item for more than two minutes.” The notes field captures follow-ups between meetings, turning context into visible action items for her PMs.
The view isn’t designed for legal to browse on their own. It’s built so Jensen and her team can run an efficient review and confirm approvals before launch. Legal status rolls up to the main board, so nothing ships without a clear sign-off.
Automation should start conversations
Serena, Jensen’s content designer for support documentation, has her own dedicated view with sizing, status, linked projects, and notes tailored to her work. Jensen also added a simple “two-week heads up” checkbox that automatically sends Serena a Slack message with the ticket link.
“It saves me from sending messages manually,” Jensen says. “She knows it’s just a button.” A recent heads-up led Serena to ask about three other features already in progress. “It enables us to have conversations in a really nice, async way that doesn’t require meetings.”
Build for buy-in
Jensen’s approach is grounded in a simple idea: “You need to build boards for other people in order to get their buy-in,” she says. “Otherwise you’re just doing this on your own.”
The views aren’t planned in advance. They emerge from real conversations. If a design meeting feels cluttered, she creates a filtered version. If context gets lost in a legal sync, she adds a notes field so nothing slips through.
Not every view lasts. Jensen has dozens and admits she doesn’t use half of them. “It’s important to stay iterative,” she says. “Don’t be scared to add new fields. You can always delete them later.”
Collaboration without chaos
Making Jira Product Discovery collaborative introduces a tradeoff. The more people who can edit views, the more likely someone rearranges yours. “When I first did this, people changed my view every day and I had a panic attack every minute,” says Jensen.
Her response wasn’t to lock everything down. She encourages PMs and engineering managers to create their own views. Instead, she protects herself through the micro-view structure itself. The control tower is shared and published, but Jensen’s day-to-day work happens in sub-views that others rarely touch.
External stakeholders get read-only access through published views. Internally, the history tab provides a safety net if something changes unexpectedly.
If your partners are drowning in your board, start here
Jensen’s approach is worth borrowing:
- Start with one partner. Begin with the person who is the most vocal about information overload. This could be your designer, your legal contact, your marketing lead.
- Ask one question: “What do you need to know to do your job?” Build a view that shows only that.
- Cut fields aggressively. If they don’t need it, they shouldn’t see it. Remember: 13 fields, not 21.
- Add a notes field. Use it to capture action items between your syncs. It replaces the agenda nobody writes.
- Iterate. If the view isn’t useful, delete it.
The point is to make sure the people who rely on your roadmap can actually use it. More visibility doesn’t always create alignment – but the right visibility does.
Ready to build views that work for the humans on the other side? Explore Jira Product Discovery to create purpose-built views that reduce noise and increase alignment.
