Underpromise and Overdeliver: Preventing Failed Expectations
Why companies might be stuck in the overpromise & underdeliver loop, how to escape it, and ways to set the correct expectations for leadership.
👋 Hey, it’s András here! I write about all things product management: concepts, frameworks, career guidance, and hot takes to help you build better products. Subscribe for each article to be delivered when it’s out!
Chances are, you’ve been part of a project where the expectations were much higher than the reality. Plus, as a customer, you’ve also probably been promised something by a company that wasn’t fully delivered.
It’s always better to get more than what you expect. It’s not so fun the other way around.
In this article, I’ll be looking into how the underpromise-overdeliver strategy can work out for product teams, its disadvantages, and how to overcome a situation where the expectations have already been set sky-high.
The challenge with estimations
An incorrect estimation is one of the key reasons software projects are not completed on time. But estimation is difficult, and the bigger an initiative is, the more chances there are that something will be miscalculated. Or completely forgotten.
When estimating work, we can face different types of complexities, and these definitions originate from the Johari window model:
Known knowns: we know what to do and how to do it (maybe we’ve done it before), so we can provide a confident estimate.
Known unknowns: we know what’s coming, but we don’t know how to carry it out. So while it’ll be part of the estimation, it might be under or overestimated.
Unknown unknowns: we’re not aware that some new kind of work will be needed. Thus we cannot estimate it, nor calculate a proper buffer.
During project planning, a team should strive to estimate what is known and identify most of what has been “unknown unknown” before. This and a healthy amount of buffer can go a long way to set correct expectations towards an initiative.
Setting expectations
A product team must manage two kinds of expectations: internal and external.
Internal expectations are coming from the organization. From marketing, sales, leadership, and from external partners we might be working with. These expectations mostly revolve around scope, timeline, and cost.
Good product managers also communicate what’s excluded from the scope, as part of these expectations. When reading a solution description, different people will assume different things, and it’s a good method to align others on what not to expect.
One of the most critical misalignments is if there is a gap in the understanding between the product team and the company’s leadership. For example, if the senior executives are expecting something, but the team is planning to ship something else, it’ll eventually result in a blowback.
If we notice a situation like this, we should course-correct as soon as possible!
It’s better to admit a mistake than willfully mislead others, knowing that something cannot be reached—even if we were not setting those expectations up in the first place.
Nokia lost in the smartphone race partially because management was afraid to communicate the truth to the top and instead painted a more rosy picture of the state of business.
But the strategy of underpromise & overdeliver is not suitable in all scenarios.
When pitching a new initiative or team, we want to be as realistic as possible. A too-ambitious timeline might get us in trouble, resulting in failed expectations if we can’t deliver. On the other hand, being too pessimistic might cause the project to be rejected—before it could have started.
And now, let’s talk about external expectations.
When communicating to customers about new functionalities, one mistake is to set expectations too high. Of course, there is nothing wrong with creating some hype, but too much publicity could easily backfire.
The video game, Cyberpunk 2077, is a notorious example of creating too much hype. The development studio behind set gamers’ expectations too high by promising previously unseen, next-generational gameplay. But when the title was released (after eight months of delays), initial reviews quickly pointed out the buggy game experience. And then, the studio needed to spend the next months mitigating the issues.
Another mistake organizations make is to communicate a too-ambitious timeline.
There can be many unforeseen complexities in software projects. By a general rule of thumb, the more complex a product is, the more chances there are for complications.
Even well-known companies like Apple or Google fall into the trap when announcing new solutions, and then it turns out that the project is more complex than initially thought, like Apple Pay Later.
Sell the product, not the roadmap
Product roadmaps can be a great communication tool with customers, especially in B2B. The roadmap can kickstart discussions on customer priorities and expectations, and if presented with the correct narration, it can be powerful equipment to validate the product direction.
The product roadmap is the prototype of the product strategy, similarly as design prototypes are a visualization of new functionalities. But many people use roadmaps the wrong way.
Generally speaking, customers should buy the product because of its capabilities today and not because of what’s promised for the future. Roadmaps are not commitments, and they shouldn’t be treated like one.
And paying customers are also not early investors, providing funding for an idea.
When companies sell the product roadmap, they’re onboarding customers with high expectations, with the promise that those roadmap items will be delivered, in the initial timeframe.
But that’s rarely the case.
Instead, these clients return a few months later, taking the company accountable for its promises. And then, the company needs to explain its way out of the previous commitment, give steeper discounts, or risk churning the customer.
In a recent Reforge program, Jeff Dwyer, former tech lead at HubSpot, shared how the company handled roadmaps and in-development functionalities a few years ago: the sales team was not allowed to show roadmaps to (potential) customers. Even the product teams were only permitted to demo and talk about solutions internally that are already running in the production environment.
This was HubSpot’s method of not selling the roadmap. And a few years ago, the company even featured the following statement on its “what’s new” page:
“As we like to be transparent with our customers, we want to include a reminder that while we endeavor to continually develop our software, we do so in an agile way. This means that even our best-laid plans get adjusted. While we do expect to develop and improve our products, we can’t promise any specific features will be delivered on any specific timeline, including the features discussed above. We hope you’ll buy the product for where it’s at today and continue to see value over time. This means that you should not decide to buy based on a feature being made available in the future.”
Mitigating an overpromise
Let’s face it; overpromises happen from time to time. And no matter if we made those commitments originally or not, it’s better to correct them than let the situation slide.
First, identify what’s the reason for the mismatching expectation.
Did someone promise too many features or subproducts that just don’t seem realistic now? Was it an overly ambitious timeline for a priority project? Something else? Once a root cause is identified, try to mitigate it by looking at the scope-resource-time triangle and the possible opportunities.
Second, have there been any external commitments? If so, how strong are those?
There is a difference between mentioning a new feature in an informal discussion, promising a solution to 20+ customers, or making contractually binding commitments.
At worst, we have to face financial and reputational consequences for the commitments that we can’t fulfill. But those are very rare cases, and most overpromises have a limited impact.
Being transparent about failures and delays can also be a good thing. And if those are done in an honest way, they can even build trust towards our company.
Conclusion
So how can we avoid failing our own expectations?
We should aim to overdeliver, not overpromise. Better estimations and proper expectation setting help a lot, but we also shouldn’t be afraid to adjust expectations if those are wrong in the first place.
And when discussing plans with customers, remember: we want to ensure that the current product is providing value and avoid selling an idea that might or might not come true. Customers are not early investors funding a dream.
Underpromise & overdeliver is not always the most effective strategy. If the situation requires a fair portrayal—like presenting to leadership for budget approval—we should do our best to paint a realistic picture.
And last but not least, overdelivering can take many forms. It doesn’t always have to be new and powerful features. Sometimes, it’s things that positively surprise customers: subtle animations, cheerful images, or a unique voice in copywriting.