Not All Companies and Products Require Roadmaps | by John Utz | Jul, 2023

Challenging the absolute: A paradigm shift in product.

As I’ve often shared, a not-so-distant coffee meeting led me down a path I never would have guessed. It forced me to question a belief, as a product leader, I treated as an absolute — that products always require roadmaps.

My mentor and I started in our usual spot, talking about startups and new products in the healthcare industry. This went on for ten minutes, and then it got fuzzy. Given the shock of the question I’m about to share, I forget exactly how we arrived and what led to it.

“Do you think every company and product needs a roadmap?” he asked. This was not a question as much as a test of my ability to think critically.

“Of course.”, I answered.

“Are you sure? What about a seed-stage startup? Or an entirely new product?” he challenged.

Ok, here we go. The conversation pushed me outside my comfort zone like so many times in the past. My inner dialog engaged in its own debate. While I thought it was an absolute, for a micro-second, I questioned it, and then the floodgates of doubt opened — maybe not such a bad thing in this case.

“Well, nothing is absolute. There are always exceptions, no matter how rare.”, I said. Then I thought further; maybe scenarios exist where roadmaps are optional. For anyone who has spent their career anchoring in an absolute or first principle, challenges to core beliefs hit hard.

“Tell me your perspective.”, I said, now open-minded and in a learning mindset.

An hour flew by. Fast forward to the end, there are, in fact, scenarios where companies and products do not need roadmaps.

Roadmaps seem to be a universal answer for product companies regardless of stage or size. They were for me, at least. Yet now, it’s an absolute I’d like to challenge. The coffee conversation with my mentor was a turning point. Roadmaps are not always needed.

When you compare the investment of time vs. value and return of a roadmap, there are situations where the equation doesn’t work. In other cases, you need to minimize the investment in the roadmap to ensure the return is worthwhile. And ultimately, I concluded that there are two specific situations where a roadmap is unnecessary (and can be considered a detriment).

• Early Stage Company or Internal Startup — Roadmaps aren’t valuable when a company or internal startup is in concept, seed stage, or Series A. When you are early on, your goal is to learn not to document. Your goal is to be nimble. To allow space to pivot. Roadmaps early on tend to box you in. Honestly, only once you have a product in the market that is a general release with paying users is a roadmap worth considering. You know enough to create a loose plan reflected in a roadmap at that point.
• Early Stage Product — New products, even in mature companies with products in the market, require distinction. Products in concept, prototyping, alpha, beta, and MVP should focus on learning and not the predictability of a roadmap. Especially in mature companies, roadmaps provide a false sense of certainty when you are early in developing a product. Focus on the learning loop, rapid adjustments, and validation. Being early means learning, not committing. Roadmaps in large or mature companies communicate an understanding that doesn’t exist early in a product’s life.

Looking in the rearview, this makes sense. I didn’t have a roadmap for the two product companies I started, at least for the first six months. And both were successful. Given that, I am unsure when and how I decided to go against my own experience and adopt an absolute established by others — that roadmaps are always required.

To make an even finer point, put me aside for a moment. Let’s instead look at one of the most famous inventors of all time. Thomas Edison. Do you believe for a moment he had a roadmap while iterating rapidly to create a stable lightbulb? I don’t. What would be on it? Create a stable light bulb so that… You get my point. I’m sure the thought didn’t even cross his mind. Or maybe it did, and he quickly dismissed it.

However, once he stabilized the light bulb, I’m sure he had a strategic plan (I’m not sure they used product roadmaps back then).

Think of all the logistics around scaling a lightbulb — things like creating a factory that can mass-produce vacuum-sealed glass to produce lightbulbs rapidly and reliably. Or, create an electric distribution grid so homes can use the lightbulb. So many moving pieces that were only necessary once the lightbulb became real.

If you are early on in your company or product, consider passing on the roadmap. The value won’t justify the investment, and the roadmap will change endlessly. Focus instead on learning and creating a solid backlog. Note: This does not mean you don’t have an overall plan.

When it comes to roadmaps, there are different variations and flavors for different situations and stages. If you are early stage or early on in your product journey and need a roadmap, I’ve included a few options where a smaller investment can cover you.

• The sketch. A sketch roadmap is a timeline view of planned releases without further data. It shows release names and dates to indicate when you plan to drop a new product version or capability. The sketch is called the sketch because it can be easily erased, modified, or redrawn.
• The slide. A sketch plus high-level epics/features tied to each release. At the highest level, the slide provides macro capabilities connected to each drop date (e.g., accept third-party payments). The slide doesn’t guide product teams for planning purposes. It’s for investors and sales.
• The release brief. The slide plus high-level details, usually 2–3 pages, on each release. The release brief includes detail on each macro capability, defining them in a way a product team can understand but still has flexibility and can learn early stage. I would only complete one release brief at a time, especially early stage. This is true for an MVP or a significant new capability build.
• The full-fledged roadmap. We all know a roadmap when we see it. However, I will stress that any roadmap builds on the previous three bullets and has only enough detail for each release (not just the first one) — outcomes, initiatives, epics, stories, value metrics, etc. A roadmap provides a clear plan for a product and engineering team to execute over time (with the flexibility to adapt per release). Roadmaps are not rigid contracts that product delivery teams execute without question.

If having a roadmap is not an absolute, the question becomes when a roadmap is worth it. In my recently changed opinion, three criteria exist:

• Your company is at a stage where more than one team, pod, or unit is working on the product. The value of the roadmap increases exponentially based on the number of engineers and executors (e.g., sales, marketing) involved and the number of customers and stakeholders engaged.
• Your product is in the market, has users, and is past its first major release. You must work toward defined future releases in partnership with the engineering team.
• You need to communicate your product story beyond the product team. Your audience might be sales, marketing, company leadership, or investors. If you need to talk with an audience about your product, you need a roadmap at some level.

While these are loose guidelines, they can help you decide if your company and product are roadmap worthy. Remember, the ultimate value of a roadmap is the plan it sets, the story it tells, and the success metrics it lays out.

If your company and product are not at a place where a roadmap is needed, the question is how to manage the early development efforts toward a prototype, alpha, beta, or MVP. Since your goal is to learn, iterate and adapt at an early stage, you can manage the product development with the following elements:

• North Star — What is your vision? Your guiding waypoint? Use the North Star statement to anchor the early development and iteration.
• Concept — What is the product concept? What are you aiming to release? Define the product concept and initial capabilities/features at a high level.
• Target Market — What market do you plan to sell to? Who are your target users? What are their needs?
• OKRs (objectives and key results) — How will you measure the success of each iteration, and how does each iteration tie back to an overall objective? For example, an objective might be — feedback from Gen Z city dwellers with a key result of ten engaged users indicating a willingness to pay the target price of $10 per month by the end of June.
• Product release brief — In place of a roadmap, the release brief describes the strategy and the components/features of the release in a way the product and engineering teams can execute.

That’s it. Don’t overinvest early. Focus on enough detail to build a prototype, alpha, beta, or MVP that allows for creativity, flexibility, and iteration.

To drive understanding, support, engagement, and excitement about a product, stakeholders, customers, and delivery teams must understand the why. What’s the big picture behind the product? What’s the strategy? You can’t expect that the person viewing your document, plan, or roadmap on their own can read your mind. You need to set it up for them. At a minimum, this includes:

• Why you are building this product
• The purpose of the product
• Your vision for the product
• Who is your buyer/user is
• What problem are you solving for them, and why would the user care
• The market size/space you are entering
• How will you compete/win
• If you have developed your product strategy, you can also include a link

And before you panic, don’t think you need a 20-page, single-space written document. It can be 2–3 pages or a slide per topic. You are setting up the roadmap, not presenting the entirety of the product strategy. Best case, it takes them a few minutes to understand the context behind the product, roadmap, release, etc.

I am often asked how much and what detail to include in a roadmap. The answer again depends on the stage of the company, the product, who your audience is, and whether you are presenting it or publishing it. And even for a mature product, your roadmap should only reflect commitments. So when exploring a possible feature where you won’t have much detail, don’t worry — it shouldn’t be on the roadmap in the first place — it’s called discovery for a reason. Let’s explore a few scenarios.

Scenario One: Early Stage Product / New Concept

When short on details, don’t make them up to satisfy stakeholders, customers, or teams. Keep the details high-level, think initiatives, and possibly epics.

And when it comes to both, keep it to short, outcome-oriented descriptions that do not include specifics on how.

Let’s look at an example. You are launching a new digital product within an established, medium-sized donut business. Your product is a digital, tradeable donut to go with each physical donut purchase with the goal of increasing engagement amongst Gen Z customers. Rather than talk about how this will work, since you don’t know yet, one initiative on your roadmap might be to increase brand engagement between visits to the donut shop from one to two per week.

Your epic might be to create tradeable, NFT-based donuts resulting in one interaction per week. I’d stop there. You are looking to set a high-level direction. So whether a new product or a significant capability add to an existing product, remember it’s called discovery. You are learning, not committing.

Scenario Two: Established Product — Roadmap for Stakeholders or Customers

This is where details are important, to an extent. Remember, your goal is not to put your stakeholders and customers to sleep. Details create boredom for those not involved in the actual day-to-day delivery. And even for those who are involved daily, details can be constraining. If you create a roadmap for stakeholders and customers, you should provide enough detail to accomplish your goal — engagement, excitement, and support. Details don’t often drive the behaviors you are looking for, with rare exceptions. Instead, they have the opposite effect. Details create the perception that there is more certainty than you mean to convey regarding what will be delivered, when, and how.

Scenario Three: Established Product with Multiple Product Delivery Teams

This is where I get in trouble and have what can be considered a heretical view. So before you read this, remember that you know your company and teams better than I do. I err on providing as little detail as is required to get the teams moving and working together. You hire smart people for a reason. And as a result, you don’t need to provide specific instructions on exactly how you expect things to be built. Your roadmap should set the direction but allow the teams to explore, learn, debate, and land on the correct answer. If product managers are expected to know exactly how to build a feature, they might as well be the designers and engineers. Product managers should explain their hypothesis for the feature in the context of why, the outcome, the user, and what they want to accomplish. They should not detail exactly how it should be done. Leave room for the delivery teams to be creative. To figure out the best ‘how.’

Of course, these are only a few examples of many possible scenarios. You can use these as loose models when thinking through your situation. However, in all cases, a guideline you can live by is to provide only as much detail as you know with certainty and only as much detail needed to accomplish the goal.

“What!?” you may be saying to yourself. What did he say? Yes, a roadmap can lead to higher rates of waste and failure at product companies. Having a roadmap is not always a good thing — especially a detailed, step-by-step, time-bound roadmap. As a product manager, you need to learn to thrive in ambiguity and uncertainty. And while done right, roadmaps can reduce waste and failure, all too often, they are done wrong or for the wrong reasons.

To help you avoid catastrophe, here are a few ways roadmaps can lead to waste and failure, as well as how to avoid them:

• It’s too early. We’ve covered this one in detail above; however, to summarize — when it’s early, avoid a roadmap.
• Management dictates the roadmap or the need for a roadmap. Without exception, if you are told you need one without a valid reason and comply, the result won’t be good. Management should not dictate what you build or the need to document it in a roadmap. If management is asking and won’t back down, put their ideas on the backlog and show only enough detail to get by.
• The roadmap exists to create certainty. Too much certainty can be a bad thing, especially when it’s false. I’ve seen so many companies create roadmaps as a security blanket. As a way to feel in control. Product management is a discipline steeped in ambiguity, continuous learning, pivoting, and uncertainty. Creating a roadmap to give management a false sense of security is a large cause of waste and failure. This is, again, a case where you need to manage expectations and details. I’d only show what’s committed for the next quarter.
• Roadmaps are unchecked. Teams plod through, never questioning. There is no dialog. And when things go wrong, teams blame each other for what’s on the roadmap. Roadmaps exist to spur debate. To facilitate prioritization. To provide a loose target for what must be done. Your job as a product manager is to encourage your team to push back. To question. To challenge.
• You hide the roadmap. If a roadmap exists and no one knows about it, does it matter? No. A core purpose of a roadmap, when you do need one, is to create transparency. All teams have the same information at the same time. Openly publish roadmaps to the teams working on them. And barring any confidentiality issues, they should be published to the company and customers.
• Output over outcomes. When roadmaps are used to measure output, not outcomes, run the other way. Output is a false measure of productivity. What really matters are the outcomes you create for your company and customers. If you are pushed to measure output, tie it to outcomes and only show the two together. And steer whoever is asking away from counting features. I’ve seen this happen all too often. If you have to show a productivity measure and outcomes, use story points, as all features are not created equal.

It’s amazing my belief about roadmaps fundamentally changed based on one conversation. Or the thought was brewing long before the conversation and needed a catalyst. Either way, I learned a key lesson — don’t accept anything as an absolute in business. Many times you don’t need a roadmap. And the level of detail in your roadmap can and should vary.

So challenge yourself to consider where the accepted norm should not be the accepted norm.