Uncertainty requires embracing the unknown. A traditional product roadmap built around projects and timelines doesn’t typically allow for this—it breaks before it bends. A roadmap built around questions, on the other hand, steers products through uncertainty and gives product managers an advantage that’s essential during times of chaos: adaptability.

During uncertainty, it’s best to think about your roadmap the way an engineer thinks about constructing a building in a seismic zone: make the foundational pieces as flexible as possible. Movement in times of stress is a good sign; it means you’ve built something that can absorb intense amounts of pressure. Build too rigidly, and you risk everything snapping beneath your feet.

Consider questions-based product roadmaps

When you build a roadmap around questions—not projects—you’re doing the same thing: allowing for give when the world begins to shake.

I described this type of roadmap at the Women in Product conference in November 2019, just a few months before COVID-19 disrupted life around the world. I positioned it as a method for inspiring product innovation and growth. As I’ve learned over the last two months, it’s also incredibly useful for steering your product during times of uncertainty.

A questions-based roadmap stands in sharp contrast to a traditional product roadmap. A traditional roadmap is a list of projects with desired start and end dates. The process of coming up with the list seems structurally sound: you spend time thinking about a set of objectives, like improving signup rates or decreasing churn. You look at how your product is performing and where it’s failing short. You focus on what’s falling short, and vet potential solutions with stakeholders. Stakeholders help estimate projects, and those estimates are represented as neatly arranged boxes in a spreadsheet or table. The output usually looks something like this:

Product Roadmap estimates

It doesn’t take long before your neatly arranged roadmap falls out of line with reality. Estimates turn out to be grossly underestimated. Your head of product comes up with a “great idea” and wants it prioritized immediately. You didn’t account for bugs and enhancements in your original plan, despite the reality that they occupy a lot of the team’s time.  

Under normal operating circumstances, all of this spells disaster for a well-intentioned roadmap. Add global uncertainty to those normal operating circumstances, and the building completely snaps beneath you.

What does this look like?

To contrast, there are no boxes representing projects or timelines in a questions-based roadmap. But it’s also not a free-for-all: key results still matter, and areas of opportunity are prioritized to ensure focus on the parts of your product that need attention. It looks like this:

Questions-based roadmap

Betterment’s Growth team roadmap (illustrative, not real)

Here’s the critical difference between this type of roadmap and the traditional one: when you build a roadmap around questions, you’re committing to an uncertain future. Unlike a sequenced set of boxes, questions leave the future open to a path of learning and discovery. That’s what makes it great for innovation: you’re not bound by pre-determined (and often ill-determined) scope or timelines, so there’s room to think creatively about solutions as you uncover insights about your users and your product. It’s also great for navigating uncertainty. Because you aren’t setting a plan for an unknown future, it’s easier to adjust course when bigger forces threaten success.

How to create a questions-based product roadmap

Devising questions that can steer your product through thick and thin, across a quarter or year, isn’t always simple. Here’s a process I follow.

  1. Define your product’s opportunity areas. Opportunity areas reflect the milestones in your user’s relationship with your product. They typically encompass a larger surface area than a single feature or screen (for example, new user onboarding).
  2. Brainstorm solutions. It may seem counter to the premise of this article, but the best way to uncover the questions at play in your product is to lay out all the possible projects for each opportunity area you’ve identified. Group similar ones together, and ask yourself why these came to mind for you. That insight usually can be translated into a question.
  3. Ask “how.” Your questions should be as open-ended as possible, which means avoiding anything that can be answered with a yes or no. “How” is one of my favorite question-starters. It usually results in detailed answers that are less black-and-white, which in turn inspires more rounds of questions. 
  4. Identify answer signals. How will you know whether what you’re building is answering your question or not? Your product can’t talk to you, but your metrics can. Identify the one or two that you’d expect to move as you start to pursue answers to a particular question. These are your roadmap’s key results.
  5. Those solutions you brainstormed? Throw them away. Your job now is to let the questions they inspired steer you towards launching your first question-based product investment. As that investment starts to demonstrate answers to your questions, use those insights to determine the next investment. Repeat the process until you’ve seen meaningful change in your key results or you run out of ideas—the latter is usually a sign that it’s time for a new question.

Uncertainty reminds us that being data-driven isn’t always enough. Even the most cleanly rationalized decisions can fall apart when the future suddenly turns hazy. A product development process with questions at its core allows us to think about our products in creative, unbounded ways—while also being inherently adaptable to an evolving and unpredictable future.

About the Speaker

Recent Posts