There’s a powerful mental tool used in elite weightlifting and strength-training circles, called the “cue.”
In this context, a cue is just a way of thinking about some aspect of a lift to help the athlete perform it successfully. For example, you might hear a coach shout at an athlete who’s about to perform a barbell deadlift: “Don’t lift the bar; push your feet through the floor!” Or an athlete might say to herself a few times as she loads a barbell onto her back for a squat: Bend the bar across your back. Bend the bar across your back.
They might sound simple. They might sound silly. They might even be technically incorrect. (Aren’t you supposed to lift the bar in a deadlift?) But when athletes are attempting to move hundreds of pounds—enough weight to kill them if they don’t handle it properly—they often find that tiny mental triggers like these make the difference in their ability to complete the movement.
Are you looking at your roadmap document all wrong?
This brings me to the roadmap.
Whether you’re a product manager responsible for a product roadmap or a professional whose job involves developing and maintaining some other type of roadmap—a technology roadmap, business roadmap, marketing roadmap—you might repeatedly be sending yourself and your team a counterproductive cue about your roadmap. And this mistake, I’m going to argue, could be undermining your process and even the success of your products.
In our work over the years with product managers and other roadmap owners across just about every industry, we at ProductPlan have noticed that many people responsible for their organization’s strategic roadmaps often refer to them as “roadmap documents.”
But here’s the thing: A roadmap is not just a document. Not in the way we tend to think of that word. I’ll explain what I mean in a minute, but I first want to point out that thinking of your roadmap as a document is a cue. It’s a way of internalizing and cementing a view of your roadmap and what it should be used for.
And just as a bad cue can undermine an athlete in the middle of a heavy lift—“Imagine your nose is itchy!”—thinking of your roadmap with the wrong mental cue can undermine its effectiveness and ultimately harm your product development process.
Tweet This:
“A roadmap is more of a process than a thing. You might even think of your roadmap as a strategic conversation.”
Why You Shouldn’t Think of Your Roadmap as a Document
When I say a roadmap is not a document, I mean that it’s not really a thing at all. That’s a far too narrow way of thinking about this all-important strategic guide to your product’s goals and plans. In reality, a roadmap is more of a process than a thing.
Here’s why this matters. When you think of the word “document,” what comes to mind? I’ll offer a few thoughts of my own:
- Documents are written, and then they’re done.
- Documents feel finalized, set in stone, unchangeable.
- Documents get shoved in a drawer.
- Even in verb form, the word brings to mind something complete and not up for rethinking or further discussion. For example, “Our disaster recovery plan has been documented.” Does that sound like a plan that’s open to additional input?
Okay, you might be thinking, so some people think of their product roadmaps as “roadmap documents.” Does that really matter?
My answer: Yes. It matters because it’s a cue, because cues have power, and because the “roadmap document” framework is the wrong cue to keep sending yourself—and the rest of your organization—about your roadmap.
There is no product roadmap bible out there that will tell you exactly how to develop your roadmap, what to include in it, and how and where to use it.
Because there’s no one-size-fits-all set of roadmap instructions, you’re like an author beginning a new book and facing a blank screen when you begin creating a new roadmap. You can take that roadmap in any direction you choose, include as much or as little detail as you want, and set priorities in whichever order makes sense to you.
But as you know, if you have any experience overseeing a complex initiative like developing a product, much of the information you include in your first iteration of that roadmap will change with time. It might frequently change, in fact. And if you’ve given yourself the cue that your roadmap is a document, here are a couple of the ways you might be internalizing that roadmap without even realizing it.
I have to “document” everything.
Because you’re thinking of this as a documentation exercise, you will tend to include far more of the ground-level details in your roadmap than you would if you thought of it as the dynamic, living guide that it is.
This can lead to a roadmap where the high-level objectives and strategic thinking are lost in a cluttered mess of tactics, to-do lists, and other details.
After my “roadmap document” receives stakeholder buy-in, we’ll have to stick to it, even if new realities suggest we should change course.
Another problem with thinking of your roadmap as a document is that you’ll be communicating this cue to everyone else in your organization. You’ll describe it as a document. You’ll present it as a document. And when your cross-functional team agrees on the substance of your strategic plan, they’ll come away thinking they’ve given the green light to what was in that specific document.
This means that when priorities or needs inevitably change, you’ll have much more difficulty adjusting course than you would have if you’d communicated to your team that the roadmap is just a strategic overview—and not a start-to-finish plan that’s set in stone.
What other counterproductive cues are you sending yourself about your roadmap?
On our product roadmap basics page, we discuss what a product roadmap is and what it is not. If you’ve been operating under the “roadmap document” framework, that page might help reorient you to think about the roadmap as a strategic guide and communication tool for your product’s goals and plans.
It’s also worth summarizing that page’s a discussion of “what a roadmap is not” here. Ask yourself if you’re using any of these inaccurate and counterproductive cues about your roadmap.
- Your roadmap is not a list of features.
- Your roadmap is not your to-do list or your project management tracking tool.
- Your roadmap is not simply the slideshow file you’ll use for your product meetings.
So how should you think of your roadmap?
If your roadmap isn’t just a document, then what is it? The cue I’d suggest you start using when you think of your roadmaps is Strategic conversation.
Your roadmap isn’t actually a conversation, of course, just as that weightlifter can’t actually push his feet through the floor during the deadlift. Instead, it’s just a useful cue to get you thinking about your roadmaps in a much more useful, strategic way.
Brian Crofts, Chief Product Officer at Pendo, gets this right. As he told us when we interviewed him for our Product Lessons Learned series with product leaders, Brian uses roadmaps to “facilitate the communication of what we’re doing, when we’re doing it, and, ultimately, why we’re doing it.” (Read the full interview.)
As you can see from the photo, Brian keeps his team’s product roadmap up and visible at all times in a common area of the office that allows anyone from his cross-functional team to view the roadmap, to check if anything has changed, and to gather around it and have productive, strategic product discussions.
That’s how you should think of your roadmap! It’s a conversation, an ongoing process of capturing, reviewing, and updating the strategic decisions to help your team drive your products to successful completion.
Think of it as a brainstorm centerpiece for people to gather around. Think of it as a dynamic communication tool. Finally, think of it as a strategic guide.
But for heaven’s sake, please don’t think of your roadmap as a document.
