When Do I Need A Product Roadmap? The Answer May Surprise You
“Challenges are gifts that force us to search for a new center of gravity. Don’t fight them. Just find a new way to stand.” — Oprah Winfrey
A recent 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 start-ups, and new products in the healthcare industry. This went on for ten minutes or so, and then it got fuzzy. Given the shock of the question, I honestly forget exactly how we arrived at the moment and what led to it.
“Do you think every company and product needs a roadmap?” he asked. I’m sure 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 start-up? 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 flood gates of doubt opened — maybe not such a bad thing in this case.
“Well, nothing is an absolute. There are always exceptions no matter how rare.”, I said. Then I thought further; maybe complete scenarios exist where roadmaps aren’t needed. 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.
When roadmaps are not required
Roadmaps seem to be a universal answer at product companies regardless of stage. They were for me, at least. It’s an absolute I’d like to challenge. The coffee conversation with my mentor was clearly a turning point.
It turns out there are situations where when you compare the investment of time vs. value and return of a roadmap, and the equation doesn’t work. There are yet other situations you need to minimize the investment in the roadmap to ensure the return is worthwhile.
Ultimately I concluded that there are two specific situations where a roadmap is unnecessary (and can be considered a detriment).
- Early Stage Company — When a company is in concept, seed stage, even Series A or the equivalent, roadmaps aren’t valuable. Only once you have a product in the market that is a general release with paying users is a roadmap worth considering. At that point, you know enough to create a plan reflected in a roadmap.
- Early Stage Product — New products, even in mature companies with products in general release, require distinction. Products in concept, prototyping, alpha, beta, and MVP should focus on learning and not the predictability of a roadmap. In mature companies, roadmaps provide a false sense of certainty when you are early on in developing a product. Focus on the learning loop, rapid adjustments, and validation.
Looking in the rearview, it made sense. I can say that I did not have a roadmap for the two product companies I started for the first six months. 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.
So, 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.
All roadmaps are not equal
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 with no further data. It shows release names and dates to indicate when you plan to drop a new product version.
- The slide. A sketch plus high-level 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, a new button on the remote for Hulu, etc.). To be clear, the slide isn’t useful for product teams or 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.
- The full-fledged roadmap. I think we all know a roadmap when we see it. However, I will stress that any roadmap builds on the previous three bullets and has enough detail for each release (not just the first one) — epics, stories, value metrics, etc. A roadmap provides a clear plan for a product and engineering team to execute over time (with flexibility to adapt per release).
How to know when a roadmap is worth the investment
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 now need to 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, I believe 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. Therefore, creating the roadmap for the right reasons at the right time will play a significant role in your company’s success.
What takes the roadmaps place early on?
If your company and product are not at a place where a roadmap is needed, the question is how to manage the early engineering 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.
It’s amazing my belief about roadmaps fundamentally changed based on one conversation. Or perhaps 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. Don’t think the exception to the rule is a one-off, edge case.
Challenge yourself to consider where the accepted norm should not be the accepted norm.
📌 Follow me on:
Linkedin: https://www.linkedin.com/in/john-utz/
YouTube: https://www.youtube.com/@prodlabio/featured
Twitter: https://twitter.com/prodlabio
Special thanks to Tremis Skeete, Executive Editor at Product Coalition for the valuable input which contributed to the editing of this article.
