Features do not a Product Roadmap Make

list of features

Last month, Mike Smart of Egress Solutions and I gave a webinar for Pragmatic Marketing on product roadmapping when working in agile environments. We had a great turnout of over 1500 people in the session – with not nearly enough time to answer all of the questions.

One attendee asked, “Please explain how a prioritized list of features is not a roadmap?

A fantastic question, which we did not see in time to answer during the call.

Why and What and When

The shortest answer I can come up with for the question – and probably all we would have had time to address during the call is the following:

A roadmap tells you both “why” and “what;” a list of features tells you only “what.”

If all you need is the answer above, then this is a really short article for you – you can stop here. There is some nuance to the above statement, which helps you address something more valuable – having a good roadmap. If that’s interesting, then keep reading.

Which What?

Seven years ago this month, I joined in the fracas stirred up by an article where the author

  1. Described something (bad) which was not a roadmap
  2. Called it a roadmap, then
  3. Concluded that roadmaps are bad.

I would describe the author’s complaints [about roadmaps] as a list of things which can go wrong when you treat a list of features as if it were a roadmap.

Seven years later, this is still a source of confusion. Perhaps it is the logical conclusion of anointing people with the title of “product manager” and not giving them the training, tools, and mentorship needed to learn the craft while simultaneously doing the work.

Some of the confusion may come from how we talk about roadmaps. My tweetably short answer above leaves something to be desired.

Roadmap vs Backlog

All of the different containers for requirements document “what” the team will be building. The different containers do this in different ways – and the roadmap has a qualifier.

  • PRD – identifies all the things which the team will build*, and the context in which those items are relevant or organized (e.g. the “Shopping Cart” section of the PRD for an ecommerce website will include the requirements for including controls that allow a user to update the quantity of items in the cart).
  • List of Features – possibly the most abhorrent of the containers – in the midst of a long list, will be the requirement to include an “update quantity” control with every item in the shopping cart. If you’re lucky, the requirement will be tagged with “shopping cart” for ease of organizing / tracking progress. Given the lack of context provided by a list of features, this requirement might be preceded by the “update inventory levels” requirement and followed by the “update user profile picture” requirement.
  • Backlog – when someone takes a list of features and sorts them by “give me this first” you get a backlog. The story at the top of the list may be “As a [shopper in a hurry, who is multitasking while waiting in line at the DMV] I need to be able to update the quantity of items in my shopping cart because someone jostled me and I double-tapped my phone when I meant to single-tap, so that I only purchase the quantity I intended.” The question too many people are happy to dodge is why is this story at the top of the list? We’ll have to come back to that another time.
  • Roadmap – “Yes, but” is consultant speak for “I’m answering your question, but let me tell you the question you should have asked – and the answer to that question as well.” If your roadmap says “Will include update quantity control in shopping cart” you’re doing it wrong. Your roadmap should say “Improved shopping experience on mobile” or “Better shopping experience for spearfisher persona.” Those descriptions of “what” are at a higher level, and articulate intentionality. So, yes, a roadmap includes “what” – but not the same “what” as a backlog.

*As an aside – the team won’t actually build all of the stuff in the PRD, nor will they build what they build when the PRD says it will happen, and it will be over-budget. But that’s another discussion entirely – and a big part of why “agile” came into existence in the first place.

When a roadmap is being used to communicate “what” the product will be, it should be in the language of describing which problems will be addressed, for whom, or in what context. This is the most important type of theme which would be part of a thematic roadmap. Other themes could be “improve our positioning relative to competitor X” or “fill in a missing component in our portfolio strategy.”

Context in Design

Requirements, by their nature, live in a particular context. At one elevation or perspective, something is a requirement, defining and constraining what must be done; in a different context, that same something is a design choice representing a choice about how to do what must be done.

Several months ago, Andy Polaine posted a presentation about the future of UX, in which he presented a compelling imagery establishing the context in which design decisions are made.

Andy Polaine context slide

To fully appreciate the power of what Andy is talking about, I believe you have to view the above slide (#55), in the context of his presentation. After experiencing it that way, the imagery has infused itself into how I frame product management activities.

If you cannot make time for now, the metaphor still works – solving the “visible and available” problem happens in the context of a wider environment (a larger, more complex problem), which is itself in the context of a wider environment, etc.

I find that I also apply the same concept when thinking about investments across differing time horizons.

On a given day, a member of the product team is implementing the code for adjusting the quantity of an item in the shopping cart. Implementation is not the rote mechanical movements of a machine – it is a series of choices and actions.

Those implementation decisions happen within the context of implementing a story from the top of the backlog – helping someone place orders on their phone while waiting in line somewhere. This context informs choices (like not requiring a modal dialogue to confirm the user’s choice when making a change in quantity, or making the change to “quantity of zero” be an explicit and distinct interaction).

The decision to prioritize empowering mobile users this quarter comes within the context of a decision to focus on 18 to 26 year olds as a key demographic for our product sales. Improvements to the mobile shopping experience happen in conjunction with a change in inventory, a partnership with another company, and a targeted advertising campaign.

The focus on this particular group of customers is a “business design” choice as well.

Context in Agile

A backlog lives within a roadmap, it does not replace it.

A similar perspective on context is presented by Mike Cottmeyer of Leading Agile when looking at how you put the work the teams are doing into context. A “release backlog” or “product backlog” is defined within the context of strategy – which is manifested in the roadmap.

strategic agile context

Mike’s slide (#92 in a great deck) stops with “strategic” context for a release. He and I have talked about this, and I believe we have strikingly similar views on context. This view marries both the time-horizon and the problem-definition notions of context, from the perspective of the person doing the work and understanding the “why” of doing the work.

Within each context is framed a set of choices – providing both boundaries and flexibility to adapt to what we learn, but at a lower level of detail, with less ultimate potential value, for a shorter period of time.

Conclusion

A backlog – a prioritized list of features – is not a roadmap. It is a reflection of a set of design choices which happen to fulfill in product what the roadmap sets out as a manifestation of strategy.

A roadmap tells you both “why” and “what;” a backlog tells you only “what.”

  • 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.

12 thoughts on “Features do not a Product Roadmap Make

  1. A very good article – enjoyed reading it.

    I guess another quick way of going about it is that Roadmap is strategy, while backlog/features are tactics. Roadmap should be concise and focussed, while backlog is means of translating that roadmap to something that engineers can build.

    Also, backlog can include items that exist outside of the roadmap, e.g. a minor featurette to satisfy an important customer renewal, even though it does not fold into the main strategy.

    1. Thanks, Roman, and welcome to Tyner Blain!

      Excellent addition about the minor featurette. Also, great name for it. I am stealing that. :)

      There’s a phrase I heard once – If you stand far enough to the left, everyone is to the right of you. And I think the idea applies when making a distinction between strategies and tactics. When you are a product manager, the roadmap manifests your strategy (and the backlog is tactics). When you’re a product owner, the backlog manifests your strategy (and the task decomposition and sequencing is tactics). What about going in the other direction? When you are a CMO or VP, the product strategy grid manifests your strategy (and the product roadmap is tactics).

      I’m actually doing a workshop for a client later this week to help with developing a product strategy grid, to establish the context for creating a powerful roadmap. The roadmap then establishes a context for backlog creation and grooming, which creates an environment for great product development, etc.

      Thanks again!

    2. Another point I want to add, Roman…

      A lot of teams have two roadmaps – one for external communication, and one for internal communication and planning and alignment.

      The internal roadmap would ( / could / should) have an item which says something like “5% Deal Driven” – which means “5% of the development team’s time will be allocated to minor featurettes and other one-off activities required to support marquee customers – new deals, renewals, general good will.”

      This enables the team to have frank discussions about the company’s sales effectiveness and customer relationships – in order to have a fact-based conversation about how high of a “tax” the development team needs to pay (one way to think about one-off, custom development activities) during each quarter for near term gain. Your business model may have a high reliance on COTS revenue, or your top-down focus and vision may be about scaling the business with a non-customized solution.

      That discussion may cause you to change what you build too – making the product more configurable (by end customers, channel partners, individual users), as a technique to simultaneously create scale as an organization while providing a (more) tailored solution for individual customers. When I still worked as a mechanical engineer, we called this mass customization.

  2. Useful explanation of the difference between a backlog and a roadmap, Scott! I suspect it will be a link I’ll share many times in the future :-).

    One point, though. From my experience, failing to communicating “what” the product will do can be very frustrating for the audiences of a roadmap (executives, engineers, sales team, etc.) — in particular regarding what’s in the near time horizon. Also, while I agree that the description of the what “should be in the language of describing which problems will be addressed, for whom, or in what context”, in practice that can be hard to do with few enough words to fit into a visual representation of a roadmap, without being too generic. For that reason, I find it useful sometimes to list the feature that is going to be delivered next, with the context around “why” depicted in an impact map or similar artifact.

    To use your example, of “Improved shopping experience on mobile”, for things happening soon enough, I could have in the roadmap, under the theme “Improved mobile experience”, Q2 (confirmed): Editable Shopping Cart; Q3 (planned): Update Order After Submission.

    In the impact map, I would have both items associated with “improved shopping experience on mobile”, with their corresponding contributions (say, remove frustration associated with not being able to update quantities or edit the products in the cart before ordering, and delight customers with the option to change their minds after submitting an order by making it possible to add/remove items on their mobile devices before the order is shipped).

    Do you see any problem with using this approach?

    1. Thanks Adriana!

      First, I completely agree about the value of – and often the pragmatic need for – communicating near-term details about the product, in addition to the discussion of why you’re building – and the higher level view of “what.” I would suggest that the need to have this communication does not imply that the roadmap needs to include this information. Share the “color commentary” verbally. If you must share documentation of the detailed choices of “what” – then share the backlog. Don’t duplicate the backlog within the roadmap. Think of how often the backlog changes (in content, sequence, and clarifications). Do you want to also update the roadmap with that frequency? What about “knowing” that the “current” version of the roadmap is out of date, because the near term details have changed, but you haven’t had time to update the near-term-details section of the roadmap?

      I agree with the convenience of listing the near term features in a conversation with stakeholders / prospects. I just don’t document the details in the roadmap.

      I like the example you picked, because it is challenging, in a slippery-slope way. I think identifying “editable shopping cart” as part of the “improved mobile experience” theme is probably fine. If, however, you were to list out things like

      • “estimated shipping charges update automatically when editing cart”
      • “user must be authenticated when updating cart”
      • “cart contents must be available within 1 minute on alternative devices”

      Then I would have a problem.

      On impact mapping, to date I’ve had

      1. Great success in extracting important insights and developing new areas of inquiry during the process of impact mapping. making products and plans dramatically better.
      2. Good success in reviewing an impact map with others, walking through the thought process, helping others grasp the epiphanies and contexts in which conclusions were reached.
      3. Little success in having an impact map work as a self-serve artifact which could be delivered to someone else.

      So, I’d be concerned about relying on an impact map (or similar artifacts) to be self-serve vehicles for communicating context to other stakeholders or customers. Also, while I assume competitors will (eventually) see the roadmap, I would really not want them to know how I and my team think about the problem with the level of insight you can get from an impact map. So I would not want to share it, except verbally. I cannot remember the exact quote from the Toyota Kaizen revolution, but it is something like “What they need to copy, they cannot see.”

      Also – I love the idea of notifying someone – “hey, we’re planning to ship your order in a couple hours – do you want to change anything before it’s too late?” What a crisp value proposition for increasing average order value while improving the customer experience. And an easy hypothesis to test too (“doing this will yield X% response, worth $Y per order in increased AOV”), with a manual or semi-automated prototype.

  3. Wow, thank you for the additional insights, Scott (you wrote another article in the comments section :-).

    “I agree with the convenience of listing the near term features in a conversation with stakeholders / prospects. I just don’t document the details in the roadmap.”

    I get it. Still, in one of the companies I worked for recently, we were doing this in the internal roadmap at the executives requests. I can see it being useful under our circumstances — otherwise, when we were working on a series of improvements that would come sequentially, they’d only see “Improvements to the mobile experience” listed quarter after quarter, and that wouldn’t be very useful for the audience. I agree that you wouldn’t go beyond the level of “editable shopping cart”, though — that’s the lowest level of granularity that would make the internal roadmap (and only for near-term things that made sense for execs and the sales team to be aware of). As for asking them to look at the backlog instead, it wouldn’t be convenient because the level of detail there would be too great (most things in the roadmap would be at the high-level you describe; only when more context was required additional info was added like in my example).

    As for the impact map, I’m on the same page. What I meant is the second use you listed, “reviewing an impact map with others, walking through the thought process, helping others grasp the epiphanies and contexts in which conclusions were reached”. I found it very useful to communicate why we’re investing on a feature, the measurable change on business and product that the feature would have, and the assumptions used to prioritize it above other items, showing some nuance that complemented well the info on the roadmap.

    1. Thanks again!

      On the impact map review process, I’ve found this to be great when I’m having a collaborative conversation with someone. Someone who can question items in the impact map, and contribute to the discussion. In those cases, it is fantastic, exactly as you describe. I worry when using it to communicate “decisions and the context in which they were made” in cases where I’m not looking to collaborate, only to inform. The challenge comes – I think – from the mixture of convergent and divergent thinking which goes into an impact map. I’ve used other tools to emphasize and communicate an understanding of our customers, their goals, and for which goals we’re choosing to invest in solutions – vs. those goals which will be addressed later or never.

      Now, next, not yet, and never is a nice (I think) way to frame it.

      Again – my only concern is when using the impact map in a non-collaborative session, where I’m not asking the other people to help with solutioning.

      Thanks also for clarifying specifics of when putting more detail (but not excruciating detail) into the roadmap is appropriate. The data points will help people who are trying to make nuanced decisions in the future – and it serves as a reminder that there are very few “hard and fast” rules to product management, only guidelines and biases.

      1. Hi, Scott! I’m coming back after taking some time to further reflect on a comment you made:

        “I worry when using it to communicate “decisions and the context in which they were made” in cases where I’m not looking to collaborate, only to inform. The challenge comes – I think – from the mixture of convergent and divergent thinking which goes into an impact map. ”

        After giving it more thought, I’m still not convinced that the usefulness of an impact map fades when you finish the collaboration piece and starts to communicate / inform. Although I agree the main benefit is to extract important insights during the impact mapping exercising, based on my experience, the impact map can also be of great value to explain decisions after they have been solidified.

        For example, if I’m talking to the new Product Marketing Manager who is getting up to speed with the current plans, or a Sales Manager who wants more detail around what business results we are hoping to achieve with the next deliverables, I find the impact map to be a great tool to visually demonstrate the chain of reasoning that led to the why-what-when that’s depicted in the roadmap.

        (Perhaps my experience is colored by the type of template used in most of the organizations I’ve worked for to graphically depict the product roadmap, which, even though presenting the business objectives behind the deliverables, isn’t as visually effective as the impact map to show this alignment between deliverables and goals in more detail. With the impact map you add nuance, showing for example the change in actor behavior that is required to support the desired impacts).

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.