Good PM Bad PM – Roadmap Edition

Roadmaps should be... maps, the death of InVision, and the betrayal of Carta

As your team ramps up to full steam in 2024, it’s a great time to consider how you and your team are planning to navigate the waters ahead.

How are you communicating what comes next? And how are you doing that without locking your team into building features you might realize aren’t going to work?

This, of course, can only lead to a discussion about one thing: the roadmap. 

In today’s issue:

  • Good PM Bad PM: Product roadmaps

    • How most companies approach roadmaps

    • Why they're flawed, but why they do it

    • A better approach

    • Resources to learn more

  • News from the Product-Verse

    • Carta’s betrayal

    • The death of Invision

Forwarded this email? Sign up here.

I just wanted to share my appreciation for Coda as the ultimate document tool for product teams. These days, I use it for absolutely everything, from writing LinkedIn posts to creating epic resources like my Ultimate PM Resource Database (which you get for free as a subscriber, btw). It’s even more powerful with a team.

It’s completely free to start, and the free plan is quite generous. Here’s my referral link, try it out!👇

This is where paid promos will go in the future, but this is not a paid promo.

Roadmaps (and how not to use them)

How Most Companies Approach Roadmaps

Many companies rely on linear product roadmaps that simply list out features and target launch dates over a 6-12 month timeline. These roadmaps take what is essentially the engineering team's sprint plan and extrapolate it out into the future.

These types of roadmaps provide the illusion of certainty - that the outlined features will launch on specific dates. In reality, of course, the further out the timeline goes, the less certainty there is.

These roadmaps are often created in a vacuum by the product and engineering teams, then shared out as the single source of truth across the business.

This results in things like:

  1. Marketing planning promotions around the feature launches.

  2. Sales reps making promises to prospects based on roadmap release dates.

  3. Executives holding teams accountable to hitting the predetermined dates.

The Problem with Linear Roadmaps

While simple in concept, these linear roadmaps come with several downsides:

  1. Unrealistic certainty: They imply a level of long-term certainty about product launches that rarely exists. Hitting dates 6+ months out is incredibly difficult (impossible) as priorities shift and new information emerges.

  2. Bad research: Teams feel locked into building whatever features are on the roadmap, even if they haven't properly validated ideas or if priorities change. Product teams often just ask UX researchers to validate what engineering is already going to build rather than truly pressure testing and trying to falsify concepts.

The end result is teams committing to a list of features disconnected from higher-level company goals and objectives.

It’s waterfall development mascarading as agile.

Why Companies Rely on Linear Roadmaps

Despite the drawbacks, linear roadmaps persist because:

  • Simplicty: Simple dated roadmaps feel easier to create and rally around than more complex strategic documents. They provide the facade of being agile without any of the uncertainty.

  • (The Illusion of) Certainty: Leadership desires certainty around what will get built and when. They want to set expectations both internally and sometimes even publicly via announcements.

  • Cross-functional collaboration: Departments like marketing, sales, and support need concrete timeframes to properly plan promotions, messaging, and training around feature launches.

While flawed, these are legitimate “competitive advantages” of the linear roadmap, so beating it requires any alternative solution to be simple and provide some level of expectation as well.

The Better Approach

A roadmap should serve more like an actual map – but not a modern map perfected with satellite imagining.

They’re more like an old-world map, where lots of things are wrong. Even entire continents are missing.

This unknown aspect matches the unknown exploration that building products is. You must plot a course through uncertain terrain based on the imperfect information you have, while allowing for discovery and changes in route as you make new findings.

The challenge is, can a single document provide this strategic flexibility while still supplying the concrete dates and specifics that business partners require?

The crux of this whole issue rests on a simple “no.” Attempting to force both aspects into one document results in either a vague strategic plan or a misleading timeline.

The solution is equally simple: create two separate documents:

  1. The roadmap is the strategic document based on company goals and metrics. It allows for uncertainty and discovery.

  2. The delivery plan contains‌ features informed by the roadmap and provides clear launch timeframes for coordination.

Building a Strategic Roadmap

A strategic roadmap should:

  • Connect to overarching company goals and multi-year objectives

  • Identify 3-5 key problems, opportunities, or outcomes to pursue

  • Define clear key results and metrics of success

  • Lay out a high-level plan to achieve the key results

  • Not be tied to specific features

The most famous type of roadmap, and my suggested alternative, that accomplishes this is the “Now, Next, Later” roadmap, created and popularized by Janna Bastow.

Creating this type of roadmap is relatively simple since it’s mainly just a new way of framing your current roadmap.

  1. Identify your key strategic themes and desired outcomes. Get alignment from leadership on the 3-5 main goals you want to work towards over the next 6-12 months. (I’ve written about coming up with a strategy and getting buy-in here.)

  2. Break down those objectives into the key problems or opportunities you need to address to achieve the outcomes. Don't think in terms of features yet.

  3. Plot each problem/opportunity into one of three buckets:

    • Now: What problem are you tackling right now? What initiative are you currently executing on?

    • Next: What 1-2 problems will you tackle next, once the current initiative is complete?

    • Later: What other 1-2 problems exist that will help you achieve your strategic goals? These are more long-term.

  4. For each problem/initiative, define what success looks like. What key results and metrics will tell you this objective has been achieved?

  5. Resist setting firm dates. The Now column will have more date certainty based on sprints. Next may have target timeframes. Later is more speculative.

Be ready to re-prioritize, add, or remove goals as you learn. The roadmap is a guide, not a commitment.

Notice how this type of roadmap is goal-based, not feature-based. You only move from one item to the next, once you’ve completed the goal. This is navigating a map, not following a straight line.

The Delivery Plan

With strategic flexibility established in the Now, Next, Later roadmap, the delivery plan can provide the specifics your business partners require:

  1. Outline of features, projects, or initiatives linked back to strategic goals

  2. List an owner for each item

  3. Give concrete release timeframes, especially for the next 1-3 months

  4. Provide less certainty about dates beyond 3 months out

These can be as lightweight as a simple bulleted list with date ranges (not specific dates if you avoid it).

Or as complex as something like this:

With this structure, you get strategic focus from the roadmap while business partners get the actionable dates and delivery details they need.

Putting it All Together

Now let’s put a nice bow on this what a Good PM Bad PM style wrap up.

Read more

Of course, there’s always more to learn. Some great resources:

From Around the Product-Verse

T’was a drama-filled week in the product world. Two stories dominated headlines:

  1. The Death of InVision: InVision, a design collaboration platform, announced that it will be shutting down its services by the end of 2024. Valued at $2 billion just a few years ago, the company was a cornerstone of the tech world. One of the founders published a stream of consciousness summary of how he thinks this happened in a random X comment. It’s an absolutely fascinating case study and a must-read for anyone interested in product strategy.

  2. Carta’s Betrayal: Carta basically powers the entire startup world’s handling of pre-IPO shares. This week, Linear CEO Karri Saarinen dropped a scathing accusation that Carta has been secretly using client information to fuel its brokerage business. This is an amazing overview, with great lessons on how not to do PR.

That’s All For Today

Last things:

  1. Upcoming AI course: I am getting close to finishing my first-ever paid course “AI for Product Managers” which goes in-depth with tactical ways PMs can leverage AI tools to save hundreds of hours at work. If that sounds interesting to you, drop your email in this 1-question form and I’ll send you updates, sneak previews, and a discount code when the course is launched.

  2. Sponsors: Carl’s Newsletter has its first official sponsor starting next weeks! But there’s still room beyond February, so if you or your company is interested in sponsoring this newsletter, I’ve posted sponsorship information on this snazzy new sponsorship page.

Here’s where else you can find me:

  1. Follow me on X, where I post the most content, including lots of memes.

  2. Follow me on LinkedIn, where I post longer-form content.

  3. Follow me on Instagram if you just want the memes.

And don’t forget that as a subscriber, you get free access to: