When your product backlog is a prioritized list of problems instead of a list of features, it becomes easier to respond to change; you don’t have to commit early to delivering features and can use new technology when it becomes available. Visualizing your roadmap and regularly taking in new information and using it to reassess your roadmap helps to keep you agile.
When your product backlog is a prioritized list of problems instead of a list of features, it becomes easier to respond to change; you don’t have to commit early to delivering features and can use new technology when it becomes available. Visualizing your roadmap and regularly taking in new information and using it to reassess your roadmap helps to keep you agile.
Jonno Katahanas, product manager at Atlassian, explored how the team behind Portfolio for Jira builds their roadmap at the Atlassian Summit 2018. InfoQ is covering this event with summaries and Q&As.
InfoQ interviewed Katahanas about building long and short-term roadmaps, keeping the roadmaps agile for responding to change, and tips for managing product roadmaps.
InfoQ: Who do you involve when working on the roadmap for Portfolio for Jira?
Jonno Katahanas: Lots of people! When we’re setting our product’s high-level plan for the next three years, we involve a pretty broad number of people. This isn’t so much a typical roadmap where we list out a bunch of things to work on, it’s more a clear articulation of what Portfolio aspires to be and what success looks like for us. Internally, we work closely with our product’s designer, engineering manager, and product marketer to draft our initial three year plan. This is based largely off things we already know, and further supplemental research we do as a core team. Externally, we spend a lot of time talking to customers to understand their needs and pain points. We also survey a lot of other channels to strengthen our customer understanding. These channels include feedback from our support team and in-app surveys.
When we’re looking at our short-term roadmap for the year ahead of us, from an external perspective, again, we put a lot of weight on interactions and feedback we get from customers. From an internal perspective, our core team includes product management, our designer, engineering manager, and product marketer. At the end of the day, it’s generally the product manager that makes the final call on what ends up where on the roadmap. But, this decision is made with a lot of input and discussion from other members of the team. Where necessary, we also bring in people from other teams that are relevant to any specific roadmap items. If there’s anything on our roadmap that we think is dependent on another team, we try to involve them as early as possible. This gives us more time to work through any potential blockers.
InfoQ: How do you ensure that the roadmap is agile enough to respond to change?
Katahanas: I’ll answer this question by focusing on how we approach creating our short-term, one year roadmap. When we’re building out our one year roadmap we aim to have a list of problems to solve during the course of the year, not features to build. This is counter to a common pattern I’ve seen where product teams build a roadmap that’s a laundry list of features they’re going to ship. It’s not abnormal to talk to a team that will tell you what feature they’re going to ship in 9 months time.
The reason we focus on having a roadmap that’s a prioritized list of problems, not features, is two-fold. Firstly, whether we like it or not, as soon as we add a feature to a roadmap with a date beside it, stakeholders take that to mean commitment. Commitment that you’re going to ship the feature at that point in time. The challenge with this is that we don’t know with certainty that what our customer’s wants or needs are now will be the same in 6,9 or 12 months time. How can we know the exact feature that will best serve their needs when we come to actually working on the problem? Many teams tout that they’re agile and are constantly iterating to respond to customer needs. But, how can this really be the case if they’ve already committed to shipping a feature many months down the track? This unconscious commitment is all driven by the simple act of putting a feature and date on a roadmap, so far in advance.
The second reason is based on the rate of change with technology. Technology is changing so quickly that what might not be possible now, could very easily be possible in under a year’s time. This means that when we come to tackling a problem on our roadmap, we may be able to ship a feature that wasn’t possible when we initially planned the roadmap. As an example, we’re in the process of improving the usability of a table that user’s utilize in our product to manage large data sets. We also recently made internal improvements to our tech stack. Some of the solutions we’re looking at potentially shipping now weren’t as viable last year when we created our one year roadmap.
InfoQ: What have you learned?
Katahanas: Probably the biggest learning for me has been that the roadmapping process isn’t purely the act of writing a list of things to do with some dates attached. I feel weird writing it now, but it was genuinely the impression I had before becoming a product manager. There are so many roadmap related activities that happen before we even start to draw up what most would think as a typical roadmap: an ordered list of when we’re going to work on things and how long we think each work item will take.
Many take the roadmapping process to purely mean the act of writing a list of work to do, but don’t effectively consider all the foundational activities that come before that physical list of prioritized work even starts to be created. These foundational activities include things like getting really clear on your product’s long-term plans. It’s crucial for teams to look 3-5 years out and define what their product aspires to be, how their product wins in the market, and what success looks like for them. This helps provide focus when the product team is deciding what to add to their short-term roadmap for the next year.
InfoQ: What tips do you have for teams for managing their product roadmap?
Katahanas: I have two key tips that have really helped our team with our roadmapping process.
My first tip is for product teams to have a mechanism to create a shared understanding of your product’s long-term direction. All product teams at Atlassian have recently adopted a framework called a “VSO” to help with this. “VSO” stands for vision, strategy and objectives. It’s a one page resource that we use to clearly define where our product is heading in the next three years.
