Opposite Views of a Product Roadmap

Spinning cat optical illusion - different people see it spinning in opposite directions, some people can switch

Your product roadmap is 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(1) 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.

visual of rolling-wave planning [larger image available in Janna’s article]

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.

Attributions

(1) Thanks Pech-Misfortune for the original animated image.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

10 thoughts on “Opposite Views of a Product Roadmap

  1. Definitely a quotable quote:

    Product managers should drive roadmaps based on “why” not “what.”

    An additional observation: the call for product roadmaps often indicates larger communication or strategy problems in the organization. A product roadmap can actually be a distraction and not an effective solution to these problems.

    1. Not only does “the call for product roadmaps often indicates larger communication or strategy problems in the organization”, it also indicates your company is not communicating effectively with your prospects and current customers.

      1. Thanks, Roger and Sally!

        I completely agree. I tend to see teams who (1) don’t talk enough with customers, who progress to (2) having a backlog / roadmap which is relatively immune to the feedback from customers. These teams then progress to (3) having a roadmap chock full of feature-requests from customers, and eventually to (4) having a roadmap prioritized based on deliverable value to customers. I have worked with very few folks who then move to (5) strategically targeting a specific group of customers for whom we’re delivering value, and (6) making sure that the delivery of value (to/for those customers) aligns with an increase in revenue or profitability, either in the short or long term.

        All of that lands under the “communicate effectively” heading.

  2. Nice post, Scott. I had a thought as I read your comment about selection of customers:

    “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.”

    I’m sure we all recognize that lots of churn takes place when this selection is too vague. It’s advantageous, although not always possible, to refine that early.

    I do like the way you contrast the clarity existing in the near term from one perspective, vs. the clarity existing in the long term from the other. Nicely done.

    1. Thanks, John! I think the challenge comes when organizations are trying to simultaneously change from the bottom up, and from the top down. The top-down changes identify strategic bad calls, like vague definition of customers (or selection of the wrong customers). As the top-down folks get smarter, they make better decisions about all of that.

      Meanwhile, the bottom up improvements are driving people to question feature requests, review market and competitive positions, etc. Quickly leading them to questions like “why _these_ customers?”

      When both sets of change meet in the middle, it definitely can reduce the levels of confidence of people on the team about the overall plan and its execution.

  3. The picture of the rotating cat is rotating clockwise, right? You mention that it’s could rotate either way based on your perception, but I’ve stared at it for a couple of minutes and can’t see how it could rotate counter clockwise…

    1. I promise, it can be seen rotating both ways. When I look at it for the first time (after more than a day), it could be rotating in either direction. I can make it reverse direction by thinking about it. No idea how to make it switch directions, but it does. As far as the article is concerned, the main idea is that any given person will see it one way – but it could be either way. And there are some folks for whom it is reversible.

    2. It took me a while to see it rotate in the other direction. I had to change the angle that I viewed the image from. Tip the screen on your laptop up and see if it changes.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.