Your product roadmap a view of what you are building right now, in the near future, and in the more distant future. Or is your roadmap a view of why you are building whatever you’re building right now, in the near future, and in the more distant future?
Your roadmap is both – but one is more important than the other – and product managers need to be able to view the roadmap both ways.
When you view the spinning cat animation above, you will either see it as rotating clockwise or counter-clockwise. Everyone has a default. Because of bi-stable perception, the direction of rotation may reverse for you, but reversing direction is apparently more difficult for some people than others.
Depending on your role in your organization you will be biased towards viewing your roadmap either as a view of what the team will be building into your product, or a view of why the team will be building things into your product. As a product manager, it is imperative that you can view it both ways. I also hope to make the case that one view is more important than the other.
What the Team Will Be Building
Janna Bastow wrote an excellent article about the importance of flexibility in roadmaps. The article provides a really good explanation of how product management is not project management, and the evils of having a roadmap which is nothing more than a “glorified Gantt chart.”
She provides a great visual depiction of rolling-wave planning.
![[larger image available in Janna’s article]](https://www.javacodegeeks.com/wp-content/uploads/2014/12/bastow-image-flexible-roadmap-attributes.png)
I describe rolling-wave planning as being precise about the immediate-term future, having less specificity about the near future, and being nonspecific (but still helpful) about the more distant future. This is because – from the perspective of someone focusing on what they will be doing – there is too much uncertainty about what will happen between now and the future. [ BTW, this is where waterfall is wasteful – it assumes incorrectly an ability to predict the future in detail.]
The article provides very good explanations about the need for flexibility both in terms of time and scope within a roadmap. Shifting the delivery of something to an earlier or time frame, or alternately thinking about a particular time frame including more or less deliverable. This is however, only a “good explanation” when you’re thinking from the point of view of what the team will be building.
The key attributes of a product roadmap from this view are that descriptions of what to do are precise right now, less specific in the near term, and very flexible in the future. While I completely agree – given a focus on what is being built – I don’t think about product roadmaps in this way. I believe my thinking has shifted because I’m primarily creating roadmaps, not consuming them.
Intentionality
A concept which may help you shift to thinking about a product roadmap in terms of why the team will be building is intentionality. There is a reason why you’re building something.
Your team is building features because they are trying to build solutions. More precisely, your team is building a product with a set of capabilities, which you hope your customers will choose (and use) to help with solving their problems.
Customers are trying to solve problems, they aren’t trying to use features.
As a product manager, your perspective needs to be rooted in the perspective of the problems your customers are trying to solve – the intent driving your roadmap – not the things your team is building in order to solve the problem.
Why the Team Will Be Building
Where the view of what to build gets fuzzier as you move from the present to the future, the view of why you build gets clearer as you move from the present to the future. This is the exact opposite of rolling-wave planning, and that’s not only fine, it is good.
Choosing a particular group of customers (or market) to serve is a strategic decision. Generally this will not change, and when it does it will not be frequent. This is a long term view – the future for the team will involve building things to support this group of customers. There is great and powerful clarity here – specifically about the future. “We are, and will be, building to support customer group X.”
Given the decision to provide value for a specific group of customers, the logical next question is “how?” To avoid ambiguity, the question is really “which of the problems our target customer faces are we going to help them solve?” The charter for a product team can be described as “Help [a specific set of] customers solve [a specific set of] problems.”
In the near-term, there is flexibility in the choice of which problem to address next. Having that flexibility is imperative, because discovery (from feedback from customers) tells us if we’ve got the right problems, in the right sequence. So we need to be able to re-prioritize, and add or remove from the list of problems as we manage our roadmaps thematically.
In the “right now” the team is testing hypotheses. Given a customer, and a problem the customer is trying to solve, there is a hypothesis about how best to help. That hypothesis is a design. The design may or may not be a good one. The implementation of the design may be great, adequate, failing, or incomplete. In this time horizon, the activities of the team building the product are concrete – build, test, learn.
These activities are much hazier from the perspective of why the team is building something. Technically, there is still clarity about the customer and the problem (they aren’t changing). However, there’s additional explanation required – a description of the hypothesis – to explain why a particular activity is being managed for the current sprint or release. As an example
“We found that forcing users to make decision (X) when solving problem (Y) caused those users to abandon our product. Based on interviews we’re defaulting decision (X), and we believe this will reduce abandonment by (Z%).”
The need for explanation about the specific “what” is how I interpret the reduced clarity about the near term, when focusing on why versus what.
I selected the spinning cat image because both points of view are valid. From one point of view, all of the clarity occurs in the immediate term, and from the other point of view, all of the clarity manifests in the longer-term big picture. Most people first see the cat spinning in the same direction, and most of the time product managers should seef their roadmap “customer first.”
A product manager has to be able to switch between both views – and communicate in either framework – depending on the context of what they are doing in the moment. Building the roadmap is working backwards from the customer to the feature. Helping the team execute, and appreciate the context and relevance of what they are working on involves going from the current deliverables up to the intent for building them.
Frequency of Change from Learning
Another reason I work “outside in” in my thinking about roadmaps is the frequency of change which comes from what we learn as we engage with our market, study our competitors, and adapt to industry changes.
Significant and sustained* feedback is needed to tell us we have chosen the wrong customers. How we choose customers is a topic for another article. When I hear about companies pivoting, I think of it as picking different customers.
We start out engaging customers with a hypothesis that they will pay us to help them address a particular set of problems. We start this process with a point of view of the relative priority of solving each problem. Feedback from customers – throughout the product creation process – helps us improve this list of problems. All within the stable context of helping a particular customer group solve their problems. Processes like the structured conversation from Discover to Deliver include these activities as part of the overall product creation process.
While working with customers, we find out what it means to satisfice. We also develop and refine our understanding of the nature of the problems using tools like Kano analysis. We also have the opportunity to discover when a particular design does not achieve the goal of helping the customer, or when a poor implementation fails to achieve the vision of the designer. Sometimes, when stories are split to fit within a sprint, the smaller stories don’t actually solve the problem, and additional splits need to be completed before moving forward.
*This assumes we did not make colossally bad choices to begin with – opening us up to the debate between rationality and empiricism. Bad choices may be discovered immediately.
Communication and Conclusion
Executives (should) want to talk about intent and strategy for investment in the product. Base your conversations on this. If they need status report type updates about the activities of the team, then talk about features. But try and shift the conversation back to corporate goals, strategy, and the role your product is intended to fill.
Other interested stakeholders will almost always ask about features. This is perfectly understandable – they are not product managers, and they are focused on the wrong things. They are focused on problem manifestations, not problems. Help them refocus while you address their concerns.
Product managers should drive roadmaps based on “why” not “what.” We still need to be able to think in the opposite direction, but that approach should be secondary.
| Reference: | Opposite Views of a Product Roadmap from our JCG partner Scott Sehlhorst at the Tyner Blain’s blog blog. |
