Get ready for some great content coming to your inbox from the team at UserTesting!
One of a product manager’s more difficult tasks is delivering the message when something in the product’s development doesn’t go according plan or to stakeholder expectations. When things go wrong, we all know what can happen to the messenger.
But if there’s one truth in product management, it’s that things will go wrong. Stakeholder priorities will change. Budgets will tighten. Resources will get shifted away from your initiative. A red-hot patch or bug fix will shoot to the top of the backlog and bump the development of an eagerly anticipated new feature.
Common, unforeseen obstacles like these mean that as a product owner, you need to be prepared for the possibility that some items on your product roadmap will slip. At some point, you will inevitably miss your release date, and you’ll need to communicate this disappointing news to various stakeholders.
Honesty and directness are easy when everything is running according to plan. But it’s when your development suffers a setback or challenge that transparency will prove most valuable. Here’s what I mean.
You’ve just realized that you are going to have to delay a new feature on your product roadmap—a feature, let’s assume, that your sales team or executives are eager to see released. Now it’s time to communicate that news to those stakeholders. Here are the approaches I have found to be the most effective.
Often when delivering bad news, people 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, it can be easier for the messenger to communicate, and at the same time, it can soften the blow for the recipient.
But when you need to communicate to stakeholders that you’re not going to have a product feature ready by the time they’re expecting it, you’ll need to be direct and clear. There’s no room for “It might not be ready by the timeframe indicated on the roadmap,” or “I don’t know if we can release it on schedule.” These hedges will only create confusion—and, in many cases, force you to come back and deliver the same bad news again.
Remember, you’re the product owner. You’ll need to own the problems, too.
Of course, you’re not a robot, either. When you have to let down a stakeholder with news that her much-anticipated new set of features won’t make it into the next release, you can’t simply walk up to her, say “All of the features will need to slip by three months,” and then walk away. Successful product management also requires mastering some soft skills.
One of those soft skills is empathy. You also need to show your stakeholder that you understand why this news will be disappointing — and disappointing to her specifically, not simply in the general sense that “Yeah, it’s too bad we won’t have the feature done by the next release.”
You will first want to communicate the news that the feature won’t make the roadmap’s estimated release date—making sure not to slip in any confusing hedge phrasing like “maybe” or “probably.” Then, immediately after this, you will want to let your stakeholder—let’s say she’s one of your sales executives—understand that you know she was expecting it, counting on it as a new way to generate leads, and that she might have even begun telling customers and prospects about it.
In other words, you want to give your stakeholder the green light to be frustrated about the delay. Remember, as the product owner part of your role is to be the messenger—and sometimes that won’t be pleasant.
Finally, you’ll want to communicate the “why” behind the disappointing news. After all, for an anticipated feature not to make the timeframe indicated in your product roadmap, you will need a good reason.
But here, too, you will want to tailor your communication to the specific stakeholder you are talking to. You need to explain your bad news in terms that will be meaningful to them.
If you are speaking to a disappointed customer who was expecting the delayed feature, for example, you won’t want to tell them that the reason for the delay is a shifting of development resources from your product to a more high-profile initiative at the company. Customers don’t care about your resource constraints, and that excuse won’t soften the blow one bit. In fact, it will only weaken their confidence in your organization and product.
For a customer, your explanation will need to center around the fact that, with your existing resources, you determined your team wouldn’t be able to roll out the new feature in a way that you could assure it would be stable and at the level of quality they deserve. In other words, you chose to protect them from a potentially flawed or unstable feature.
Now, with an internal stakeholder—an executive at your company, for example—the more relevant and meaningful explanation will be the resource constraints the company has just placed on your product.
Indeed, this could actually be a useful conversation for your products going forward. If your executive team moved some of your developers off of your product and onto a higher-profile project, they need to understand the fallout of that decision. So when you bring to them news that some important features scheduled for your next release will have to slip into the future, they will have to understand that pulling away your development resources had consequences.
Now that we’ve covered suggestions on how to deal with the crisis, how do you prevent missed expectations? Here are some suggestions on how to avoid having to deliver bad news to stakeholders in the first place.
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, after all, should communicate your product’s strategy, how that strategy supports your company’s larger strategic objectives, and what your product is going to do for your customers and market. But are firm dates always critical? They can help orient your stakeholders in time, yes, but they might not always be as necessary to the roadmap as you think.
One strategy we have seen work for our customers is to create roadmaps without dates. These can be particularly effective for sharing with external audiences such as your customers—because they emphasize your product’s strategic vision and plan, without committing your team to arbitrary dates.
But if your organizational culture is such that you do need to include time frames on your product roadmap, another way to de-emphasize deadlines in the planning stage is to provide broader time estimates than specific dates. This works particularly well the farther out in time you go.
For example, if you’re in 2016 and you need to tell the market something in terms of a timeframe they can expect your new product, you can tell them you’ll have something in 2017. As you enter 2017, and you review what’s still ahead on your development calendar, you can become a bit more specific—you’ll have something in Q3 2017. When you reach mid-year, maybe you’ll be comfortable saying you’ll have something in October. And so on.
Roadmaps should be living documents. They should reflect the latest thinking for the product. Even if your organization’s development process isn’t agile, it’s likely that priorities are changing often. With a static roadmap, the roadmap grows outdated and less useful.
Product managers should work with stakeholders so they understand the roadmap is a living document that will change.
It’s also important for stakeholders to understand your prioritization process, and how you’re strategically making tradeoffs. It’s imperative for stakeholder groups to understand that initiatives are not set in stone, and may change based on market dynamics, customer needs, and internal priorities.
This is why many product managers publish their product roadmap to an internal platform such as Confluence. With ProductPlan, for example, our customers embed their live roadmaps on internal pages to give stakeholders self-service access to the latest plan.
Taking it a step further, some organizations are comfortable publishing the roadmap outside the organization, or even publicly. For example, one of our customers at ProductPlan is GOV.UK. Their main philosophy is one of transparency. After the team built 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.
Another approach for reducing the change of missed expectations is to increase your engagement with stakeholder groups such as marketing, sales, development, customer success, and executive management.
Engagement can take many forms: Monthly roadmap meetings, product update meetings, prioritization input sessions are all great ways to ensure that stakeholders are on the same page.
From a development standpoint, the more closely you work with your developers, the more likely you are to have a clearer understanding of how long things will take—which means you are less likely to be surprised by delays and other timing problems.
The more closely aligned everyone across the organization is on your product’s development, the fewer roadblocks and setbacks your product will face—and the faster you’ll be able to work around them when they do surface.
Join 120,000 subscribers and get articles like this every month.
Get ready for some great content coming to your inbox from the team at UserTesting!