A Deep Dive on Product Roadmaps

I ran a survey to learn everything I could about product roadmaps. Here are the results... (#91)

Every company has a product roadmap of some kind. It’s true for 2-person startups and 200,000-person mega-companies. But after that, the disagreements begin…

• What is a product roadmap?

• How should it be used?

• How often should it be updated?

• How is it leveraged across an organization?

• And so on…

I ran a survey to dig into the topic of product roadmaps. I got 79 responses and a lot of great answers (many of the questions were long form and very detailed). The results were very interesting…

I want to thank a few people for helping me shape the survey, including Yana Welinder (CEO, Kraftful), Chris Chae (VP Product, Neo Financial), Vincent Liu (Lead Product Manager, Square), Oz Nazilli (Founder, PMF Studio) and Pawel Huryn (Author, The Product Compass).

1. Who Completed the Survey?

First, let’s look at who participated in the survey so we understand the break down.

Company Size & Number of Product Managers

Most respondents work at companies between 1-50 people, but the diversity was decent, including 20% in very large companies (1001+ employees).

About 70% of respondents have 1-10 product managers at their companies, but 9% of respondents have 201+ product managers. That’s a lot of product managers! 😵‍💫

2. What is the Purpose of a Product Roadmap?

The first key question was, “Do you see the product roadmap as a strategic or execution-focused asset?”

I was glad to see that most people leaned strategic. Product roadmaps are strategic tools first, with an element of execution mixed in.

• If the product roadmap doesn’t tell a story and align with the company’s mission and key objectives, it’ll fail to motivate and keep everyone on the same page (including non-builders within the organization).

• If the product roadmap is not executed consistently (i.e. you say you’ll do something and never do it) people lose faith in the product organization, which kills momentum completely.

A founder of a small startup wrote:

“I structure my roadmaps based on the product’s strategic objective at each stage (e.g., Validation, Growth, Diversification). I focus on identifying the riskiest assumption that, if validated, moves the business forward. Prioritization follows a Value (utility) vs. Risk (dev effort) matrix, ensuring I ship fast, test, and learn. In the early stages, I emphasize short-term execution since long-term planning only becomes viable once I have enough learnings. This approach balances a macro (5-year) vision with micro (1-2 year) execution, adapting as I progress through each stage.”

And a product manager at a giant company said:

“They tend to be a mix of long term vision coupled with targets and deliverables needed by senior management. ideally they would be rooted in a singular metric with deliverables focused on achieving that but they often become a hodgepodge based on business needs, which are not aligned on unified north stars.”

3. How Far in Advance does your Product Roadmap Plan For?

I asked people how far they plan, and the results were quite varied.

• 3 months, 6 months and 12 months are nearly the same at 25.7%-28.6% each

• “It’s complicated” had 11.4% (we’ll dig into that in a moment!)

• Only 5.7% go beyond 12 months (and this was all big companies)

Jarrett Quan-Hin, Head of Product at Mantle (< 50 person startup) spoke to some of the complexity, specifically around having “multiple product roadmaps with different timelines”:

“We typically use quarters as a frame of reference for planning thematic blocks of work out. These are what we build out our backlogs as a part of, which is done in Linear. Separately, in Notion, a higher-level year-long roadmap acts as a means of looking at the broader arc of where we are heading, and allows us to maintain a larger set of items to think about when prioritizing features or thinking about potential opportunities (or disruptions) that may come down the pipeline.”

In some cases, product managers are juggling multiple products and using different time horizons as a result:

“In my experience, so much depends on the nature and ‘philosophy’ of the company, as well as the intensity and urgency of the pressures (internal and external) it faces. Roadmaps need to start AND end somewhere, and with the variables of product intent (i.e. new to world, new to company, upgrades,/fixes, cost reduction, etc.) each developmental swim lane looks different. Additionally, PMs often have multiple products to juggle, further complicating their task at NPD navigation.” - Product consultant

Generally, I take the approach of having a fairly detailed roadmap for 1 month (possibly 1-3 months), and then a higher-level, more abstracted roadmap for 6-12 months. Honestly, for most startups, anything beyond 3 months is fantasy (because too much will change). Big companies often lock in 1-year roadmaps, with little room for change (I experienced this at Salesforce).

Interestingly, most respondents update the roadmap monthly, which suggests a broader recognition that 💩 happens and companies try to incorporate feedback + learnings consistently to update what they focus on.

When I asked how they felt about the level of detail on their roadmap, the answers were more varied:

• I’m glad 57.1% felt like the detail was “just right!”

• But a sizeable percentage (29.9%) felt like their roadmaps weren’t detailed enough.

“Product, market, phases, launch date. There are separate documents detailing the goals and KPIs. I typically miss the WHY, what work was done to arrive to the conclusion/ decision, what would have to be true to make this successful (beyond goals and KPIs that tend to be there as a result of the business case).” - Head of Design, 1000+ employee company

Missing “why” is common, particularly in bigger organizations where you may be handed the work to execute without being on the customer frontlines or in the boardroom where decisions get made.

This is why I believe product managers need to spend a lot of time understanding the business model, because everything they do should have an impact:

The Importance of Business Models to Building Great Products

---

“We’re generally very high level on the product side. We look for high level company themes, align to those with our priorities. Our engineering teams usually bring out more of the details that end up with us refactoring our roadmaps - some things are larger than expected, others are held back due to tech debt.” - Product Manager, 1000+ employee company

Aligning the roadmap to high level company themes makes sense, but in this case engineering is brought in too late. This likely creates more back and forth than necessary, and friction amongst different teams.

The earlier you align with key stakeholders and collaborators on the roadmap, the better. But this isn’t easy. Everyone has their own agenda. That’s why I like mapping the business as a systems diagram to make sure everyone understands how the whole business works and where people need to focus.

Your Startup is a System You Can Map to Identify Problems, Align the Team & Win

---

4. What’s Included on your Product Roadmap?

I asked people what they included on their roadmap, and provided the following options:

• Product vision

• Goals / objectives

• Focus areas / key themes

• Time-oriented (i.e. months, quarters, years)

• Goal-oriented (i.e. now, next, later)

• List of specific features, initiatives or capabilities to build

• Prioritization

• Status / progress indicators

• Metrics & success criteria

• Stakeholders involved

• Other

Here are the results:

A few interesting observations:

• About 50% include the product vision in the roadmap. This is always worth reinforcing, to highlight why everything is being done.

• Time-oriented > Goal-oriented, although I don’t think people saw these as mutually exclusive. The best roadmaps are goal-oriented, but I’m still a fan of deadlines. 😏

• Less than half use a product roadmap to track status or progress, which may mean that they’re using the product roadmap as a static document (i.e. do it once, get buy-in and then forget about it) and/or they’re tracking progress elsewhere (in a project management type system).

• About 50% include metrics and success indicators. This feels problematic, because it suggests people are using product roadmaps to just “do stuff” without really aligning on whether the work is driving measurable results.

Roman Pichler’s Tips on Great Product Roadmaps

Roman Pichler is a product management expert with multiple books. I asked him a few quick questions when preparing this survey, and wanted to share his responses below:

1. What makes a great product roadmap? And, what makes a bad one?

• Great: is outcome-based, implements the product strategy and directs the product backlog, is regularly updated, is owned by the extended product team (product person, UX designer, architect/programmer, tester/QA engineer, key stakeholders).

• Bad: is feature-based, driven by individual stakeholder requests and not owned by the product team (team can say no to requests), is seen as a fixed plan, is confused with a release/delivery/project plan.

2. Do you find most companies over-rely or under-rely on product roadmaps to build the right product, successfully?

The answer will depend on the specific company. But the larger the organisation, the more it tends to rely on plans in my experience.

3. What would be your top 3 recommendations for any company that's revisiting how they do product roadmapping?

Use a roadmap that is great, as described above. Also, I share more tips in this video:

5. Do you use any Formal Frameworks for Prioritization?

Interestingly, less than 50% of respondents use a formal prioritization methodology:

But those that do, often use multiple frameworks, which is clear when you look at the next graph (only 33 respondents said “yes” they use something, but the totals below are much higher):

• RICE and Company/Team OKRs are the most commonly used

• I’m glad to see “whatever the boss wants” wasn’t the most popular 😂

• T-shirt sizing wasn’t an option, because it’s not specifically a prioritization framework, but quite a few respondents did mention it in their responses

When I asked people for more context on how they prioritize, it hit a bit of a nerve. Here are some quotes:

“Too often prioritization ends up aligning with the career goals of the PMs. I would like a better way to share our prioritization process that would make these types of decisions immediately obvious to stakeholders.” - Product manager, 1000+ person company

I’ve never heard this before, but it speaks to the challenge of managing different stakeholders and their priorities. That’s quite a common difficulty for product managers.

Here’s what a product manager at a 50-200 person later stage startup wrote:

“These tactics are implemented at different stages of the planning phase and are may not be included in the end-state of the roadmap deliverable. Prioritization is done through conversations and reviews with both business and engineering stakeholders.”

A product manager at a < 50 employee early stage startup said:

“We try to have fairly contained prioritization ceremonies so that we are constantly reprioritizing while things are inflight. We have found that pivots are almost always necessary but that unfinished work piles up.”

Here’s the perspective from a senior product manager at a < 50 employee early stage startup:

“Exec/commercial involvement and alignment are also important. However, some roadmaps can have a mixed approach, in that ideas are bottom-up but evangelized top-to-bottom.”

I found this quote bang on. Ideas on what to build are coming from people “on the ground floor” but the product manager still needs to get executive level support. This shouldn’t surprise people, especially in smaller startups where founders are still running product.

6. What are the Most Important Inputs into the Product Roadmap?

I asked people to rank the most important inputs into their product roadmaps, with the following options (note: these options were displayed in a random order for each respondent):

• Customer demands / insights

• Business objectives

• Technical feasibility

• Competitive analysis

• CEO / Executive requests

• Other departments’ requests

• Bugs

• Technical debt

• Other

Here are the results:

• Customer Demand/Insights and Business Objectives nearly tied for most important and second most important. In aggregate though, Business Objectives outranked Customer Demand/Insights as the most important input.

• CEO/Executive Requests had a fairly even spread from most important to least important, which I found interesting. For example, 10 people ranked CEO/Executive Requests as the most important, whereas 13 ranked it the least important.

• Technical Feasibility ranked as the 3rd most important element in a product roadmap, followed by Competitive Analysis.

• Technical Debt and Bugs were most commonly in the 4th-7th position; important but not near the top of the list (although 4 respondents ranked Bugs as the top input!)

• I was surprised at how little influence Other Departments’ Requests had. It was most popular in the 8th position. This seems counter to a lot of what I’ve heard about how people struggle to align everyone’s priorities.

• Thankfully Other was prioritized the least. I felt like the options were comprehensive, so I’m not sure what people were including in this category.

7. How Important is Customer Feedback?

I wanted to zoom in on customer feedback and its impact on product roadmaps. So I asked people to score the importance of customer input from 0-10 (0 being the lowest, 10 being the highest).

Thankfully, most of the scores are in the higher range, although I applaud the one person who said “0”. That’s being honest! 😭

8. Does AI play a role in product roadmaps?

Here’s the question: Are you using AI to develop or manage product roadmaps?

Most said “no” but I think the question was misleading.

• Some said “no” but then said they’re using it to gather data more effectively.

• Others said “yes” but then said it was for transcribing meeting notes or something else.

For example, here’s a response: “No, but we use AI to create documentation that goes into the roadmap so that doesn't seem like a stretch, maybe I can try that.”

Here’s another response that’s aligned with many other respondents’ answers:

“We’re not fully automating our roadmap decisions with AI, but we do leverage AI insights to inform them. For instance, we analyze user feedback, usage patterns, and candidate data to identify high-impact opportunities—especially where the LLM can learn and improve. Ultimately, our product team still makes the final call on priorities, but AI plays an increasingly significant role in shaping our decisions and ensuring we’re building the most valuable features first.” - Head of Product, early stage startup

It seems like we’re still early days for leveraging AI in the roadmap building process.

Here are two additional quotes, not opposites, but with competing viewpoints:

“Industry analysis, competitive analysis, customer requests, opportunity analysis are key considerations while developing my roadmaps. AI has helped focus the time I need to spend doing research. It helps me get information quickly, even though AI can send me on a wild goose chase sometimes. I also use AI as a sounding board and can ask it really stupid questions without the risk of being judged. It also provides be a reasonable starting point in financial analysis over which I can overlay my situation specific and proprietary info.” - Product manager, early stage startup

And:

“No - It's funny to say that when you know I'm building AI tools to support product teams. But I'll argue using an AI is dangerous here, it should not replace someone's thinking and I have tons of examples on how ChatGPT is absolutely dumb in this area.” - Founder, early stage startup

9. How do you Communicate your Product Roadmap to your Team and Stakeholders, and Gather Feedback from them?

Product roadmaps are communication tools. But alignment with stakeholders is often a big challenge. So I asked for people’s advice on how to handle this. Responses were in long form, so I used ChatGPT to summarize and highlight from most common to least:

1. Meetings (All-Hands, Stakeholder, Weekly/Monthly/Quarterly Updates)

Most frequent approach for roadmap communication.

Common formats:

• Quarterly Meetings (Most Common)

  • Used for stakeholder reviews, executive updates, and company-wide roadmap presentations.

  • Often paired with a detailed slide deck for discussion.

  • Helps align teams with strategic objectives and long-term planning.

• Monthly Meetings (Very Common)

  • Used for team-wide roadmap updates, product team reviews, and leadership check-ins.

  • Often includes Q&A sessions for alignment.

  • Helps teams stay informed without overwhelming them with frequent updates.

• Biweekly Meetings (Common)

  • Product roadmap prioritization meetings.

  • Biweekly stakeholder syncs for ongoing roadmap adjustments.

  • Used in medium-sized teams where regular feedback loops are needed.

• Weekly Meetings (Fairly Common)

  • Weekly all-hands meetings for smaller teams and startups.

  • Sprint planning sessions to align short-term roadmap execution.

  • Check-ins with leadership and product teams to ensure alignment.

• Daily/Ad Hoc (Less Common, but Used in Startups)

  • Small teams and startups often discuss roadmaps on a daily or ad hoc basis.

  • Typically happens in standups or spontaneous discussions rather than formal meetings.

  • Enables quick pivots and fast decision-making.

2. Presentations & Slide Decks (Google Slides, PowerPoint)

• Roadmaps are often shared via Google Slides or PowerPoint.

• Decks are used for executive reviews, stakeholder alignment, and public documentation.

• Some use a single-page summary for executives and a more detailed deck for deeper discussions.

• Roadmap presentations are often paired with live meetings to walk through updates.

I asked ChatGPT for more information and it gave me this:

• Executive & Leadership Presentations (Quarterly/Biannual)

  • Depth: High-level, strategic overview. Focus on key initiatives rather than granular details.

  • Audience: Executives, senior leadership, board members.

  • Common Format:

    • Single-page executive summary + a detailed slide deck for those who want more depth.

    • Focus on business impact, objectives, and strategic alignment.

    • Biannual or quarterly updates for alignment.

  • Key Content:

    • What’s been achieved vs. planned.

    • Key strategic initiatives (not granular features).

    • High-level prioritization (e.g., “Now, Next, Later” frameworks).

    • Resource allocation and investment focus.

    • Adjustments based on market changes or new learnings.

• Team-Wide & Cross-Functional Presentations (Monthly/Biweekly)

  • Depth: Medium – balance of strategic alignment + operational details.

  • Audience: Product teams, engineering, design, marketing, sales.

  • Common Format:

    • Roadmap slides shared in company-wide meetings or team reviews.

    • Typically Google Slides, PowerPoint, or a Notion page for async access.

  • Key Content:

    • What’s coming in the next month or quarter.

    • Key priorities, new initiatives, and dependencies.

    • Changes in product direction (and why).

  • Opportunity for feedback & discussion.

• Sprint-Level or Tactical Roadmap Presentations (Weekly/Biweekly)

  • Depth: Highly detailed, focused on execution.

  • Audience: Engineering, product teams, sometimes customer support.

  • Common Format:

    • Slide decks, Jira boards, Linear/Asana views, or Notion pages.

    • Sometimes shared in weekly syncs, standups, or sprint planning.

  • Key Content:

    • Specific features in development, including status updates.

    • Prioritization and sequencing of tasks.

    • Dependencies/blockers.

    • Adjustments based on recent learnings or stakeholder feedback.

• Public & Customer-Facing Roadmap Presentations (Less Common)

  • Depth: High-level, limited details (to avoid setting expectations).

  • Audience: External customers, partners.

  • Common Format:

    • Quarterly or biannual roadmap presentations.

    • Marketing & sales teams present the roadmap to customers.

  • Key Content:

    • Short-term product vision.

    • Features that are “coming soon” without firm commitments.

    • Thematic roadmap (e.g., improving speed, security, integrations).

    • NO specific timelines to prevent misalignment.

Key takeaways:

✅ Executives get high-level, strategic overviews (often paired with an executive summary).

✅ Product & cross-functional teams get detailed updates (often in monthly or biweekly meetings).

✅ Sprint-level meetings are the most tactical and focus on execution.

✅ External roadmap presentations are vague to avoid over-promising features.

3. Documentation Tools (Notion, Confluence, Company Wiki)

• Notion is a very popular “source of truth” for roadmaps.

• Company Wikis or Confluence pages ensure the roadmap is permanently available to employees.

• Documents are used to provide async visibility, with updates shared periodically.

4. Roadmapping Tools (Jira, Asana, Linear, Productboard, Miro)

• Jira, Asana, and Linear are frequently used to track development progress.

• Productboard is used for roadmap sharing and feedback collection.

• Miro is sometimes used for roadmap visualization, especially in the brainstorming stage.

5. Email & Slack Updates

• Some teams distribute roadmap updates via email summaries.

• Slack is used for ongoing communication, reminders, and discussions.

• Certain companies have dedicated Slack channels for roadmap updates.

6. Interactive Feedback Sessions & Voting

• Some teams gather feedback via voting mechanisms (e.g., Jira comments, Miro voting, structured feedback sessions).

• User interviews and internal feedback meetings help refine the roadmap.

• Customer feedback is sometimes collected but not always shared broadly to avoid distraction.

7. Verbal & Ad Hoc Communication (Small Teams & Startups)

• In smaller teams (especially startups), roadmap discussions happen informally and frequently.

• Teams communicate verbally in daily or weekly standups instead of maintaining formal documentation.

8. Video Summaries (Async Video Updates)

• A few teams use short video clips to provide context and remove misunderstandings.

• Videos may accompany slide decks or be posted on internal company forums.

10. What's your Favorite Aspect of your Organization's Product Roadmap Creation Process and the Final Result?

This was a long-winded question, but I wanted to find out what people liked or thought was good about the process they use for creating and managing product roadmaps. I used ChatGPT to summarize responses and provide the top five common themes:

1. Collaboration & Alignment Across Teams

Many respondents highlighted the importance of involving different teams (engineering, sales, support, leadership, etc.) in shaping the roadmap. This ensures alignment across the company, fosters productive discussions, and creates clarity on priorities. Some emphasized the value of cross-functional teamwork, while others appreciated the “horse trading” and strategic debates that come with roadmap discussions.

“My favorite aspect of our product roadmap creation process is how dynamic we’ve become in prioritizing and discovering features. We work closely with sales and support teams to address the most immediate customer needs while ensuring every decision aligns with the overarching product vision. This balance allows us to stay agile and customer-focused without losing sight of our long-term goals.” - Managing Partner, Venture Studio

2. Flexibility & Adaptability

A recurring theme was that roadmaps are treated as living documents rather than rigid plans. Many product managers value the ability to reprioritize, iterate, and adjust the roadmap based on new insights, customer feedback, or company changes. This agility helps teams stay focused on solving the right problems without being locked into fixed commitments.

“It's a ongoing process and nothing is settled in stone. It's not like a contract that the Product dev team needs to deliver. It's a constructive, data-driven, customer-centric process.” - VP Product & Technology, 50-200 person company

3. Customer-Centric & Outcome-Driven Approach

Several respondents emphasized that their roadmap prioritization is heavily influenced by customer needs and feedback. Many product managers enjoy focusing on goals, outcomes, and impact, rather than just features. A few noted that their roadmaps serve as a tool to manage customer expectations, ensuring alignment with the product vision rather than just reacting to feature requests.

“It’s complete chaos! But when it spits out something that everyone sees and loves and wants to sell, I know it’s working!” - Chief of Product, early stage startup

“Execution - customer satisfaction and achievement of the business objectives. I don't create roadmaps for the sake of creating them.” - Product consultant

4. Transparency & Clarity

Many people appreciate that a good roadmap creates visibility across the company, making it clear what is being prioritized and why. Some specifically mentioned that roadmaps help provide a shared understanding of strategy and execution, reducing misalignment between teams and leadership.

“Acknowledgement that a roadmap is not guarantee, but a best plan at that moment that can change.” - Senior product manager, publicly traded software company

5. Strategic Decision-Making & Prioritization

A common theme was the balancing act of prioritization, where roadmaps help teams focus on the most impactful work. Some mentioned structured prioritization methods (e.g., data-driven, goal-oriented, strategic bets), while others enjoy the challenge of debating initiatives and justifying why certain projects take precedence.

“I love the horse trading with colleagues; getting a chance to hear everyone advocate for their respective initiatives and debating the merits of each.” - Founder, early stage startup

11. What are the Main Issues with the Roadmap and Process?

Of course, not everything is flowers and bubblegum. I wanted to get a sense of what people didn’t like about their product roadmap process. Again, this was a long form question, so I used ChatGPT to summarize responses:

1. Too Many Stakeholders, Opinions, and Misalignment

• Many responses indicate frustration with too many stakeholders wanting different things, leading to slow decision-making and difficulty in setting priorities.

• Some product managers feel their teams aren’t empowered to make decisions because executive, sales, and marketing teams dominate the conversation.

• Misalignment between top-down (leadership-driven) and bottom-up (team-driven) priorities creates tension.

• Roadmaps often replace direct relationships with stakeholders, leading to a reliance on documents instead of conversations.

“Too many people want too many things without building any kind of hypothesis for the project.” - Head of Product, Series A startup

2. Lack of Clarity, Strategy, and Consistency in Prioritization

• Some roadmaps lack strategic clarity, making it unclear how initiatives tie to business goals.

• Teams struggle to balance long-term vision with short-term execution, leading to shifting priorities and abandoned work.

• There’s frustration with ad hoc prioritization—sometimes driven by the loudest voice in the room, rather than data or impact.

• Some product managers feel roadmaps become “feature factories” instead of focusing on true product outcomes.

“It's easy to drop the ball on RICE...or, worse, tweak it so some initiatives get the prioritization we want. It's important to have a simple, unbiased, rigorous but not cumbersome process.” - VP Product, Series B startup

Note: I hear this quite often from people. They implement rigorous prioritization methodologies in the hopes of removing opinion / bias, but then (a) spend too much time prioritizing; and/or (b) “faking” the numbers to get the prioritization they want.

3. Overemphasis on Fixed Timelines & Predictability

• Executives often push for specific deadlines, forcing teams to cut scope or make trade-offs that compromise quality or impact.

• Some stakeholders treat roadmaps as a rigid commitment, rather than a flexible plan that can adapt based on new learnings.

• This creates tension with engineering, as delays are viewed negatively rather than as part of the normal product development process.

“Time based projects over product outcome. While we do use product outcomes and strategy to form the roadmap, it can take a lot of effort in keeping exec aligned with it when timelines shift to the point of cutting valuable scope to make a timeline.” - Director of Product, 200-500 person late stage startup

4. Lack of Customer Input and Data-Driven Decision Making

• Many product teams feel there isn’t enough real customer feedback incorporated into roadmaps.

• There’s often a disconnect between what customers want and what leadership prioritizes.

• Some roadmaps are too focused on internal priorities, like sales requests or investor expectations, rather than actual market needs.

• Some teams want better data tracking and continuous validation to ensure decisions are backed by insights, not just opinions.

“Getting enough time with the right people, and gathering enough customer insights to get consensus on what the product priorities should be. Execs and PMs always have pet projects that they will bias towards.” - Product Development Lead, later stage startup

5. Roadmaps Are Time-Consuming and Hard to Maintain

• Many find the process of creating and maintaining a roadmap too time-intensive, making it hard to keep updated.

• Some teams struggle with documentation gaps, where decisions aren’t clearly recorded, leading to confusion later.

• Others mention forgetting the rationale behind prioritization discussions, requiring rehashing the same debates in meetings.

• The balance between too much and too little detail is a challenge—too detailed and it becomes rigid, too vague and it lacks usefulness.

12. How Effective is the Overall Product Roadmap Process at your Organization?

This was the final question from the survey. The results aren’t a huge surprise:

Generally, people seem satisfied with how things are going, but there’s clearly room for improvement.

3 Product Roadmap Rules by Pawel Huryn

I asked Pawel Huryn for his input on product roadmaps. He’s an experienced product manager and has an awesome newsletter, The Product Compass.

“There are 3 rules:

1. Focus on goals, not features

2. Do not commit too soon

3. Shorten the planning horizon

My favorite format, and the only one I use, is Now-Next-Later, developed by

Janna Bastow

, co-founder of Mind the Product.”

Read more about Pawel’s roadmapping tips here: 3 Ways to Create 10X Better Product Roadmaps. (requires subscription)

Here are a few more quotes I found interesting:

This Head of Product of a 51-200 person company summarizes how roadmaps are structured:

“3 months view in priority order, with ROI, and t-shirt sizing by squad. Longer backlog of projects that people have thought hard enough about to create a one pager.”

The interesting thing is how she’s handling backlogs. The backlog doesn’t sound like a laundry list of everything under the sun. Instead it features things that people were willing to put some effort into (perhaps in the form of a Product Requirements Document/PRD).

Here’s a great quote from a VP Product at a similarly sized startup:

“We moved from ProductBoard to Product Discovery (Atlassian) last year and we have different ways to slice and dice the roadmap and adapt the view based on the need and audience. For the board of directors and the leadership team, it's a quarterly based roadmap tied to an OKR framework. We do show strategic swim lanes with business objectives and KPIs. We do show the same to the dev team but we drill down at a sprint level and develop more on the input metrics.”

This is a good reminder that there are “different versions of the roadmap” necessary for different stakeholders. Part of the challenge I’ve experienced is spending more time presenting the roadmap (in various formats) than doing the actual work of building product. I believe product management is communication, but stakeholder management can be all consuming.

Here’s a quote from a Product Designer at a small (1-50 employees) company:

“There is usually a short term list of features/stories that are being addressed now, a set of features that is being planned for implementation that is usually on a 3-6 mo time horizon, and a set of ‘parking lot’ features that are on the radar but will only be moved into planning during annual roadmap reviews... Unless something comes down from ‘on high’ where a particular feature or story becomes more important for some reason (market changes, product changes, competition, business changes, CEO decides, etc.)”

I didn’t ask any specific backlog / parking lot questions. That’s a topic that warrants its own deep dive. I see a lot of companies (of all sizes) with an enormous backlog that will never be addressed. But it stresses people out. My suggestion: Kill the backlog every once in awhile and start fresh. If something was important, it’ll bubble back up.

---

Conclusion (for now!)

Geez, this product roadmap thing is a mess. 🤣

A lot of people aim to keep their roadmaps simple, sticking to their guns on the level of detail & focusing on objectives/outcomes. But as companies grow, things get complicated. More stakeholders means more communication and socializing. It means more inputs from disparate sources. It means slicing and dicing the roadmap into different views to appease different audiences. And so on.

For startups we work with at Highline Beta in our venture studio, I’m less focused on the roadmap, and more focused on short-term prioritization. Getting alignment on that (without necessarily using rigorous prioritization techniques that consume a lot of time) is critical. It’s why I like 1-week sprints; it’s the fastest way to decide what needs to get built, build it, and measure the results (eventually moving to 2-week sprints).

Outcomes are more important than output, but if you can’t output anything, there’s zero chance of achieving actual outcomes. For early stage startups in particular, focus less on processes, and more on results. Use documentation and transparency as your tools to combat people saying, “I don’t know what the product team is working on.” Make sure everyone can see everything at all times. They probably won’t look, but it’ll be there.

A product roadmap is a tool designed to drive alignment. If it’s not doing that for you, it’s worth revisiting and digging into these survey results more seriously to see what you can learn from them.

Good luck! 💪

---