Why not Jira?
As some of you know, I'm building a tool for creating actionable roadmaps. The most common question I've been getting is: Why not Jira? There are a million tools out there already. Why not use those?
Contrary to most developers, I think Jira is fine. It's flexible and good at what it does: backlog management. There are plenty of those systems out there, and while they each have their flavour, they all share the same core concepts. Tickets can have sub-tickets and are managed in lists and boards. Ticket-based project management systems are a digital replacement of the Post-It notes of old. These Kanban boards still play a central part in contemporary software development, and there are plenty of tools to scratch that itch.
Over the last decade, another class of tools has gained in popularity: product management systems. What works for software engineers doesn't necessarily work well for product people, and product managers have rallied behind tools like Aha! or Airfocus. These products work wonders when it comes to product discovery and value prioritization. They support “roadmaps” of the Now-Next-Later variety. They create gorgeous charts to present at the next board meeting.
Both types of products serve a valuable purpose. They are each tailored to their target audience. The roadmaps they create, however, are far from actionable. They all neglect the When question. If they support timelines at all, they do so by applying counter-productive anti-patterns.
Non-native timelines
Both project and product management systems have naive support for timelines. They both embrace prioritization as their core concept. Sure, there is Jira Advanced Roadmaps, but those timelines are cosmetic afterthoughts. You can move a feature to next year on the roadmap, but it stays in today's sprint until you change that too.
An actionable roadmap has a timeline at its core. In fact, an actionable roadmap is a timeline. It tells us when the engineers will work on which feature.
Our tools need to be timeline-centric.
Ticket based priorities
As I wrote a few weeks ago, priority fields and due dates on a ticket level don't make sense. A backlog item's priority depends on its place in the backlog. Yet, these tools are built around these nonsensical attributes. In most of them, it's impossible to even delete those fields!
This creates a situation where managers are incentivized to set ticket-level priorities or deadlines. That offloads the responsibility for planning to the developers who somehow need to make those deadlines work.
An actionable roadmap puts the onus of planning on leadership. It's up to them to decide what the teams will work on and when. If the team is expected to finish feature A, they can't be working on feature B. That's the tough call that management has to make.
Our tools need to stimulate those tough calls rather than allow conflicting priorities.
Segregated audiences
A roadmap can only be actionable if it is the roadmap– If everyone refers to the same one. Yet, how often do your engineers look at Airfocus? I bet most of them don't even have an account.
When PMs prioritize strategic features, they should take into account the team's capacity. Is there room on the Kanban board? How much of their time do they spend on operational work? Are they bogged down in paying back technical debt? In reality, product management tools start from the idea that developers are always ready to tackle feature work 100% of the time. They invite you to stuff Q1 with feature work and pretend the developers have nothing else to do.
An actionable roadmap is shared among all stakeholders. It’s the one source of truth everybody turns to. It treats operational work as a first-class citizen.
Our tools need to speak to all stakeholders at once.
Out of touch with reality
Most roadmaps are pure fantasy. They are the PM's ambitions poured into a good-looking chart, untethered to the actual work. I often meet startup teams where the developers are struggling to catch up with last quarter's roadmap. Just because the Jira roadmap claims that the feature will be delivered in March doesn't make it so. Just because a feature is marked as Now doesn't mean it will get shipped any time soon.
An actionable roadmap doesn't just say when we expect a feature to be delivered– It tells us when developers will work on it. Without it, we're making promises we don't intend to keep.
Our tools need to tell us when developers will work on a feature.
Unwieldy interface for roadmaps
Plans change all the time. That's the beauty of agile software development. That means changing our roadmap should be trivial. Try freeing up a week in Azure DevOps by pushing the rest of the timeline back. There's always a ticket or two that refuses to move because of some obscure due date in a sub-task. Good luck hunting for those.
This is not just a usability issue. Crafting a timeline in these systems is often unnecessarily hard. As a result, the roadmaps aren't updated in real-time, leading to unclear planning.
Our tools should allow changing an actionable roadmap in seconds, not minutes.
No stakeholder insights
So, we've made the tough call to push the mobile app to Q3. Given the limited engineering resources, that was the right move to make. Do all of our stakeholders know? Has Jim even seen the new revision? Or is he still discussing last week's PowerPoint slide that promises the mobile app in May?
Jira can't warn you when a stakeholder is out of sync. It doesn't even know the concept of a stakeholder. There’s room for improvement.
Our tools should know our stakeholders and give us valuable insights about them.
Project management tools like Jira are great at managing backlogs, and product management tools support valuable discovery work. But they both incentivize lazy leadership. They push PMs to create roadmaps that are out of touch with engineering reality. They tell engineering managers to care about the short term over strategic deadlines.
They encourage both to sidestep the When question completely at the expense of the stakeholders and engineers.
Both types of tools have their place, but there's a timeline between them that currently goes unmanaged. There needs to be a system that gives managers the tools to make the tough calls about when to allocate our resources. Something that encourages them to pick up the responsibility for planning rather than passing the buck to the engineers.
And that's the tool I'm building.