I just completed my company’s product roadmap, outlining the future of our suite of digital and physical products for the next 12 months.
It took me a little over a year to get it done.
What’s more is that the business is already seven years in, fully funded several times over, with hundreds of employees, doing mobile business in over 40 cities across the country at the rate of thousands of sales on any given day. (Oh, and this isn’t my first product rodeo. I’ve been building products and startups for a couple decades.) That said, I have a very simple, very important, one-word excuse for why the roadmap took me so long: Velocity.
In other words: The speed at which we push product out the door and bring revenue in.
A startup’s greatest limitation is time, and product planning is, at best, a luxury. But without product planning, there is chaos, and mistakes, and rework. So with that in mind, here’s how to build a product roadmap that aligns with your company’s goals and doesn’t turn your throughput into a slow, bureaucratic soup.
Why Most Startup Product Roadmaps Fail
That section title above is actually a little bit of a headfake. I’m not going to list a number of important-sounding reasons why every startup’s roadmap (except mine) doesn’t do what it’s supposed to do — which is provide a clear, unambiguous path to get the product from point A to point B.
A quick search of the internet will reward you with dozens of upsell documents containing such lists — covering everything from missed deadlines to poor document versioning.
But most of those content marketing pieces will mention, with maybe a little different wording, that one of the most common and biggest problems is that the roadmap is “just a list of features.”
This is meant to turn your head. That’s when most of those upsell pieces will get a little vague as to why having a company-wide communicated list of upcoming features is a problem.
Why vague? Because at its core, a product roadmap really is just a plain-english list of features.
That’s also usually when those articles try to sell you something.
Look, the problem with most roadmaps isn’t that they’re “just a list of features,” it’s that they’re a list of random features, with little-to-no connection to the company’s goals, and little-to-no allowance for the speed of the company’s build cycle.
That’s why roadmaps fail. That’s why it took over a year to get my roadmap done without burning all the runway. I had to plan slowly and carefully so as not to slow the pace of product going out and revenue coming in.
Mapping Company Goals
A few weeks ago, I wrote about a document I’ve been using for years to map out a startup’s goals and initiatives. It’s something I developed for use at the startups I work for, those I found, and those I advise. This document works at any size and for any stage.
TL:DR; Before you document your roadmaps and project plans, document your company’s business goals across a timeline. Each goal is made up of several initiatives, programs, projects — whatever it takes for your team to hit that goal. Define each goal clearly, execute it perfectly, scale the results, and refine it once you hit it. The things that get you to the goal — the initiatives, programs, and projects — can then be carried out such that the outcome is “achieve the goal,” not “finish the project.” Each of those initiatives, programs, and projects live on your product roadmap and in your project plans, tracked by timelines, updated in status meetings, or managed however you want to manage them.
With this goals roadmap in place, each item on your product roadmap must either be:
- A strategic initiative related directly to one of your goals, or
- A critical revenue-generating tactical project that produces far more return than the cost.
A Goal-Based Roadmap Eliminates a Lot Of Chaos
Your roadmap can just be a list of features, I don’t care. In our case (and I would assume in most cases), our org isn’t building one thing at a time, so our roadmap is, in Agile terms, more epic-based than story-based. However, each task that our builders work on can be tied directly back to a company goal, including how far that exact task gets us in terms of progress towards the objectives of those goals.
Not only that, when new tactical opportunities materialize, we can usually link those opportunities back to a strategic goal, or not, and then decide where that opportunity should be on our list of priorities. It gives our entire org, from executive management to sales exec to junior developer, flexibility and direction at the same time.
Less chaos. More progress.
Velocity Is How Fast You Make Progress Toward Your Goals
Velocity is one of those business terms that gets overused and for the wrong reasons. To be blunt, in start-up, velocity is how fast you can add runway without burning it.
In the early days of a startup, all the way up through the growth and scale stage and into maturity, priorities can change so often and so quickly that a product roadmap is usually out of date by the time it’s published.
Wait. Did the solution change? Did the requirements change? Heck, did the market change?
No. The “goals” changed. And what I mean by that is the goals weren’t documented in a definitive manner such that they would be adhered to from quarter to quarter as shiny new money-generating non-strategic opportunities materialized and vanished. In other words, the startup found new money to chase.
The fact is that right up until the point of maturity, the priorities for a startup are to do whatever it takes to keep the doors open and fuel growth. If founding teams, investors, and boards of directors knew exactly what it took to get that done, there would be no risk in startup. And no reward.
And it would be boring.
So, velocity in startup isn’t about the product roadmap features or the project plan milestones and deadlines. It’s about hitting the objectives that align with the goals. It takes time to codify those objectives, and to do it while you’re sprinting a million miles an hour doing thousands of sales a day is not only like building the car while it’s speeding down the highway, but designing it for that road that’s being paved in front of you, all without crashing.
When your product roadmap is based on goals, all the objectives of the tasks and initiatives to build the product become clear. When I showed the goals and initiatives document to my investor counterpart, he was skeptical, but he understood my reasoning on velocity. When I unveiled the goal-based roadmap a few months later, he was excited. When I explained that every item on my CTO’s Jira plan — down to the bug fixes — was aligned with not only the roadmap, but the company goals, he was thrilled. By keeping my eye on our velocity and our runway at first, now the startup had the speed for take-off.
