Think of Walt Disney walking into a meeting with his business partners to start discussions for building Disneyland. Do you think he began by saying, “Okay, my plan is to have seven rides, 11 restaurants, and maybe half a dozen theaters throughout the park so our cast members can do live shows”?
Nope. He started by telling his partners, “Let’s build the happiest place on earth. I’m talking about a place that makes children feel like they’ve stepped into a magical land, a place families will want to build vacations around.”
And when he secured the financial backing to move forward, Disney didn’t jump right into planning the ground-level tasks to construct Disneyland Park. He hired a team of designers, architects, and studio artists, and he shared his high-level vision with them so they could begin coming up with creative ideas of their own for the park.
In other words, Walt Disney didn’t have anything even close to a completed roadmap before he began—and before his stakeholders invested in—the magic kingdom.
Now let’s talk about you and your product roadmap.
Why Your Product Roadmap Shouldn’t Go All the Way to Completion
Your product roadmap is not your backlog, or a list of features, or a project-management tool to capture all tasks related to your product’s development. If you draft it correctly, your roadmap will be a strategic plan for your product that includes a high-level view of the major milestones needed to reach that goal.
As you know if you’ve been in product management for any length of time, the ground beneath your product’s plan is often shifting. Your organization might pull resources away from your project to put out fires on another project. Maybe the market will shift suddenly and force you to quickly adjust product priorities. The point is, you will almost certainly find yourself needing to update your strategic plan as you go.
So does it make sense to try mapping out every detail on your product roadmap from the beginning, listing everything you’re planning for the finished product including all of the bells and whistles you plan to build?
Of course not. Here’s what we’d suggest.
How to Build Your Product Roadmap (and Why You Can Leave Some of the Plans for Later)
Step 1: Develop a strong strategic justification for your product (the “Why?”).
Before you even start creating your roadmap, you’ll want to spend plenty of time and energy here—at the strategic justification stage. Be able to answer questions like:
– Why do we want to build this product, this way, at this time?
– Who exactly is this product for?
– How will it solve a problem for, or otherwise benefit, that target user?
– Why are we the team to build this product?
Walt Disney set out to build “the happiest place on Earth.” He didn’t need to know every last detail about how he was going to do that before he got the project underway. He started right here, at the strategic justification stage. You should, too.
Tweet This:
“Walt Disney set out to build “the happiest place on Earth.” He started right here, at the strategic justification stage. You should, too.”
Step 2: Go for the MVP.
Now you’re ready to start work on the first iteration of your product roadmap.
And make no mistake: This will be an iterative process. You’ll be returning to your roadmap frequently to make sure your team is executing successfully on your strategic plan, and you’ll be making updates to it as the ground shifts and priorities change.
Which is another reason we recommend that you don’t try to use presentation or spreadsheet software for your roadmaps, but instead use a purpose-built roadmap app. Frequently updating the roadmap and shifting things around is much more difficult when you’re using static software that wasn’t designed specifically for the constantly changing nature of product management.
At this MVP stage you’re just going to focus on how to build a minimum viable product—something worthy of your target users’ time and effort but that doesn’t yet need every feature and benefit you have in mind for the product.
So for your first version of the product roadmap, you’ll want to include just a few features, enough that your product will be able to complete whatever basic problem-solving function it promises users.
Oh, and you’ll want to include at least one customer-delight feature, even at this stage. If you don’t, your product might not be compelling enough for early adopters to stay with you long enough to see the fully formed product sometime down the road.
Not sure how to weigh features against each other to figure out what will give the MVP version of your product the best chance for success? We have some suggestions.
Step 3: Iterate every few hundred feet. (We’ll explain.)
When you have to drive someplace that’s, say, 20 miles away, can you see your destination as soon as you start your journey? Not even close. You can see only a relatively small portion of the way in front of you at any given moment. And at night, your car’s headlights will illuminate only the next few hundred feet of the road. But you still manage to get where you’re going, right?
Think of your product roadmap this way. At any given point, it should communicate your high-level strategy (“build the happiest place on earth”) and a few of the major milestones ahead on your path to get there.
But you don’t need all of the milestones on the roadmap, going all the way out into the future to describe a fully mature product with an enormous customer base. Most of those farther-out-in-time details will probably need to change, anyway, before you get to them. User feedback might sway things; so could budgets or available resources or something your competitor does.
So…
We suggest making a plan to return to your product roadmap at regular intervals—maybe once a month, or at most quarterly—and re-examining those few items you have listed on it against your current realities.
