At one of my first product management jobs, I helped coordinate our weekly roadmap check-in with execs from other teams. To be honest, from the phrase “weekly roadmap check-in” I’d say that ‘weekly’ was the only accurate part of the description. They were insane and went a little something like this:

Step 1: About 15 minutes before the meeting, I’d run around to every team lead to see which items they’d done since the previous week.

Step 2: I’d update a long-running Google Doc page for that week based on their input.

Step 3: We’d project the Google Doc so everyone could see it.

Step 4: Each engineering and product lead read aloud the statuses that I just wrote moments ago.

Step 5: Each person argued about something that often wasn’t consistent with their stance from the previous week.

Step 6: We’d close the Google Doc and not think about it again for a week.

It was as crazy as it sounds. We certainly had no good way to communicate our product plans around the company.

Now, there’s a lot of great advice out there about better ways to handle that situation—how to make a good roadmap. But I thought I’d take a step back and think about why we even need a thing we call a roadmap anyway. The scene above was definitely not a functioning roadmap, so without one, what did I experience? Often, pretty irate coworkers who were constantly wondering what the hell was going on.

Misaligned expectations

Danae Ringelmann, Co-Founder of Indiegogo, once told me that disappointment is merely the consequence of an expectation not being met. So what happens in the absence of a plan of some kind? Well, folks start finding anyone they can ask to get some insight on what’s coming next. These might be passing conversations by the coffee machine or in a meeting with people who don’t really represent the product. As a product manager, you may even say something like “Yeah, that could be something we’re thinking about doing in Q2.”

But then what happens? In someone’s head, “that could be something we’re thinking about in Q2” becomes “it’s being released in Q2, time to tell everyone.” And without an accessible plan, it becomes a new expectation. Now amplify that across a bunch of people across marketing, sales, support, customer success, and of course, the executive team. Soon you’ll be asked when your AI-powered time machine that’s apparently coming out in Q3 is going to support blockchain. Everyone has expectations! Are you going to meet them? Probably not! That’s a lot of disappointment to deal with. So what do we do?

It starts with communication

“The single biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw

Like most things in life, any semblance of alignment begins with communication. Before necessarily going down the path of asking the question, “how can I create a good roadmap,” ask yourself, “how can I communicate effectively across the company?” It’ll be helpful to think about how to lay the groundwork for effective communication before getting into the details of applying to how you scale roadmap discussions across the company. Here are a few tips to think about how to communicate to an audience full of people with different needs and interests.

Meet your audience where they are

Don’t assume that your audience knows anything you know. At a company all-hands presentation I attended, the company’s CFO talked about their quarterly financials and dropped just about every financial acronym as if he was trying to win a contest for it. I approached him afterward and gave the feedback that no one outside of the 3 financial analysts in the 500+ person could understand what he was saying.

When you’re thinking about how to communicate your product development plan, get a feel for how sales, support, and marketing think about product. Sales may want to know what they can upsell to get better commissions, support may want to offer feedback given their experience on the front-line, and marketing will want to know how it all fits their overall messaging. If you’re not sure what’s important to them, just ask! You may need to figure out how to tailor your communication to each of them uniquely.

Be clear

When you hear someone meandering around using a bunch of jargon, it’s pretty obvious that they’re full of it. If you ever visit Reddit, you may have come across the subreddit, ELI5 – Explain it Like I’m 5 – where people explain complicated topics in a way that’s easy to understand by almost anyone. While it sounds easy to explain something to a child, the process to break your thinking down into its simplest components and choosing what to communicate and what not to can take a while.

An important thing to remember is that communication doesn’t end when you’re done talking. What you say will be internalized and repeated to others. Have you ever played the telephone game? You don’t want your product plan to get screwed up by the time it gets to the 3rd or 4th person. Keep your communication clear, concise, and in the active voice, such as “We will release Feature X on Date Y. The dependencies are A, B, and C.” Think about how you can minimize someone else getting it wrong when they communicate that to someone else.

Use visual guides

The oldest saying for storytelling is, “show don’t tell.”  (I probably should have used an image here). Though often overused, PowerPoint tends to be a helpful tool for communicating ideas, especially when using charts, graphs, images.

When communicating your product plan, visual guides can help people understand what’s being released relative to each other and can make it easier to visualize and discuss the impact of re-prioritizing various items on your product plan. More importantly, you might think of how you can visually represent your overall product strategy and set of business objectives. Again, when thinking about what visuals best fit what you’re communicating, think about everything above: Can everyone understand it especially if you’re not around to explain it? Is it clear?

Get feedback

This is often forgotten. When you write something, you share it with others to get feedback before you distribute it more broadly, right? Well, this is no different.

To be clear, I’m not talking about feedback for the plan you’re communicating. I mean you need to get feedback if it was understood. The best thing you can do is to have the person you’re talking to play it all back to you. See what they took away. Did the telephone game fall apart when it got to the 2nd person?

Scale it all out

Ok, so you might be thinking, “this all sounds great, but I need to communicate what we’re doing with the product to hundreds or even thousands of people.” Absolutely. The exercise in thinking about the basics of communication seems most helpful when you’re talking to one or two people, but it’s still an important foundation to know how you’d want to communicate to a larger group, whether it’s 5 or 500 people. Once you get those fundamentals in place, it’s time to start thinking about how you want to build the processes and what kind of tool you need to make that happen across your company. What you don’t want to do is develop your processes on a bad foundation.

In future posts, we’ll talk about more specific ways to approach roadmaps from a process and tools perspective. Stay tuned!