How to communicate product roadmap changes no one wants to hear

Today’s article is a guest post from Jim Semick, co-Founder of ProductPlan. Enjoy!

Product roadmaps are created with the best of intentions—this is what we think will happen, what we’d like to happen, what we hope will happen—but reality has a funny way of scuttling the best-laid plans.  Priorities change. Budgets shrink. Resources are reprioritized. Emergency bug fixes and patches bump expected enhancements. Customer emergencies jump the queue—there’s no shortage of causes for the previously-scheduled programming to end up disrupted, interrupted, and rearranged. But after creating and presenting a roadmap that’s now significantly out-of-date or inaccurate, product teams have the challenge of breaking this unfortunate news to stakeholders and contributors. The product team spent so much time creating a solid roadmap, building consensus, and generating excitement that these unwelcome updates can put a damper on the enthusiasm for the plan and can shake people’s confidence in the reliability of these artifacts. But given that eventually, things will slip (or fall off the roadmap completely), product managers should be prepared for these situations and ready to communicate. And while honesty and directness are easy when everything is running according to plan, when you suffer a setback or challenge, transparency will prove more valuable than ever.

How to defuse the situation

You’ve just realized you need to delay a new feature on your product roadmap—a feature your sales team or executives are eager to see released. Now it’s time to communicate with the stakeholders. Here are the approaches I’ve found most effective.

1. Directness

When delivering bad news, people often use wishy-washy terms like “might not” or “I don’t know if we can,” even when they’re certain that the answer is no. Under some circumstances—particularly in social situations—this is fine. It sounds less harsh and can soften the blow for the recipient. But when you’re informing stakeholders that something won’t be ready when they were expecting it, you must be direct and clear. There’s no room for, “It might not be ready in the time frame indicated on the roadmap,” or “I don’t know if we can release it on schedule.” These hedges only create confusion and often force you to come back and deliver the same bad news again. Remember, you’re the product owner. You must own the problems, too. Just be upfront and honest and don’t leave any wiggle room for misinterpretation.

2. Empathy

Of course, you’re not a robot, either. When disappointing a stakeholder with the news that their much-anticipated new set of features won’t make it into the next release, you can’t simply drop that grenade and then walk away. Successful product management also requires mastering some soft skills, one of which is empathy. Show your stakeholder you understand why this will be disappointing—and disappointing to them specifically versus a generic “it stinks” kind of message. There are repercussions for stakeholders beyond simply not getting what they want when they expected it. Commiserating with stakeholders about how frustrating this will be to customers who were counting on things or to board members who had expectations or how it screws up a trade show or sales meeting humanizes and personalizes the communication. Give your stakeholder the green light to be frustrated about the delay.

3. Reasoning

Finally, you’ll want to communicate the “why” behind the disappointing update. After all, when something slips it should be for a good reason. Here as well you’ll want to tailor your communication to the specific stakeholder, explaining the bad news in terms and with a context that’s meaningful to them. When speaking to a disappointed customer expecting the delayed feature, for example, you won’t want to tell them the delay is due to shifting of development resources from your product to a more high-profile initiative at the company. Customers don’t care about resource constraints and that excuse will only weaken their confidence in your organization and product rather than soften the blow. The explanation should instead center around the fact that the team wouldn’t be able to meet the expected release date while maintaining the level of quality the customer deserves. In other words, the delay is protecting them from a potentially flawed or unstable feature. Now, with an internal stakeholder—such as an executive at your company—the more relevant and meaningful explanation will reference the resource constraints the company has just placed on your product. This can create a meaningful dialogue about the impact of resource allocation and the product team’s ability to reliably forecast release dates as part of the roadmapping process. If the executive team moves developers off a product for a higher-profile project, there’s fallout from that decision. Bumping some important features scheduled for the next release illustrates how pulling away development resources has consequences.

Preventing the situation

Now that we’ve covered suggestions on how to deal with the crisis, how do you avoid missing expectations in the first place? Here are some suggestions on avoiding the need to deliver bad news to stakeholders at all.

1. Reduce the emphasis on dates

One way to minimize the chance of blowback from a product delay is to de-emphasize the dates and deadlines on the roadmap. A successful product roadmap communicates the product strategy, how that supports the company’s larger strategic objectives, and what the product will do for customers and the market. But are firm dates always critical? While they can help orient stakeholders, they might not always be as necessary to the roadmap as you’d think. One strategy that often works well is creating roadmaps without dates. These are particularly effective for sharing with external audiences because they emphasize the product’s strategic vision and plan without committing to arbitrary dates. But if time frames must be included, another way to de-emphasize deadlines in the planning stage is to provide broad time estimates rather than specific dates, getting even looser the further the roadmap extends. Start by pegging items to a particular year, then try to assign them to quarters once that year begins, only getting down to specific months when there’s near-term confidence in delivery.

2. Increase roadmap transparency

Roadmaps are living documents reflecting the latest thinking for the product. Even if an organization’s development process isn’t agile, it’s still likely that priorities change often and roadmaps become outdated and less useful as time goes by. To avoid misconceptions that a roadmap is the same as a committed development schedule, product managers should educate stakeholders that it is really a living document that will change. Initiatives are not set in stone and may change based on market dynamics, customer needs, and internal priorities. Likewise, stakeholders should also understand the prioritization process and the strategy of making tradeoffs. Using tools such as ProductPlan, product teams can embed their live roadmaps on internal pages to give stakeholders self-service access to the latest plan. This real-time access ensures no one is looking at an old, outdated version and there is universal access to the most up-to-date plan. Some organizations are comfortable publishing their roadmap outside the organization, even making it widely available to the general public. For example, GOV.UK embraces a philosophy built on transparency. After building a visual, easy-to-update product roadmap, the head of the agency made the bold decision to make that roadmap public—so UK citizens and interested viewers around the world would know what to expect next from GOV.UK.  

3. Increase communication throughout the process

Another approach for minimizing the drama of missed expectations is increasing engagement with stakeholder groups such as marketing, sales, development, customer success, and executive management specifically around roadmapping. This can take many forms. Monthly roadmap meetings, product update meetings, and prioritization input sessions are all great ways to ensure stakeholders are on the same page. On the product development side, the closer product teams work with developers, the more likely all parties will have a clearer understanding of how long things will take, meaning fewer surprises generated by delays and other scheduling issues. With closer alignment across the organization, products face fewer roadblocks and setbacks and there’s quicker resolution when they do arise since everyone is operating from the same baseline understanding.

Don’t take it personally

Even following all of the above advice, there will still be times when the product team has to be the bearer of bad news. Just remember this is not a referendum on your worthiness as a product manager. Delays, slips, and adjustments are part of the game. As long as you’re being as proactive and prompt as possible in your communications, stakeholders and coworkers will appreciate the transparency, honesty, and conscientiousness of your updates, regardless of their disappointing consequences.

Want to learn more?

If you’d like to learn how UserTesting can help you understand your customers through on-demand human insight, contact us here.