You can't refuse to make promises and expect to be part of the decision-making process.
Yet, if you read LinkedIn or Product Manager Twitter, that seems to be the prevailing sentiment.
Don't give timelines to your customers!
Don't make promises to your stakeholders!
Tell 'em nothing!
Building software products is a bumpy road, and plans will change. The easiest way to cover your ass is not to plan at all.
The fallacy with this kind of thinking is that plans are not projections. A plan is not how we guarantee the future will unfold. The plan itself is not our promise. The plan is our tool for evolving our product deliberately while keeping our stakeholders and customers satisfied.
That means making and keeping promises. Our product is a painkiller, and our customers want to know when they can expect relief.
But making promises involves a risk.
Sometimes, promises need to be broken.
Sometimes, for whatever reason, we need to postpone or retract.
So how do we disappoint stakeholders or customers without breaking trust?
That other two pizza rule
Let's say you order a pizza online. Due to high demand, the app claims it will take one hour to deliver. That's not great, but you like this restaurant, so you begrudgingly accept. After 15 minutes, you get a notification that it will take an additional 30 minutes.
*sigh* This pizza better be good…
Now think of this alternative. You order a pizza online, and the app claims to deliver within half an hour. When those 30 minutes pass and no rider is in sight, you call the restaurant. The owner assures you that it's on its way! Twenty more minutes pass. They don't pick up the phone anymore. When the driver arrives after another 15 minutes, you're fuming. Never again!
It's obvious where I'm going with this. The first scenario took 90 minutes to deliver a pizza. The second took only 65. Yet the first restaurant handles breaking their promises way better.
Warn as early as possible
A team showing up empty-handed on the promised date frustrates a stakeholder. The feature was always on track, 80% done. Now that it's supposed to be released, all of a sudden, an additional two weeks are needed. Grrr!
Not only does this last-minute surprise disappoint the stakeholder, but it also signals the team doesn’t have its act together. It’s not hard to see how that significantly undermines perceived trust.
Teams that rely solely on backlog prioritization often communicate at the last minute. They need to. They have no other tools.
So, build early warning systems by breaking the Domino Effect. When we start cutting into our Recovery buffers consistently, we need to rearrange the timeline. Pushing back November's feature is no problem if we can warn the stakeholders in May.
Communicate anticipated change
You don't want to look out the window hungry, hoping the delivery guy shows up. Your stakeholders don't like that feeling either.
People can accept delays and changes as long as they are kept in the loop. There’s a reason you get a ton of Track&Trace mail from parcel companies.
When the plan changes, your stakeholders should hear it immediately and hear it from you. If they have to call the restaurant, trust has already been damaged.
Stakeholders and customers care surprisingly little about the actual delivery date. They just don't want to stare out the window, pining for the pizza guy.
So, communicate changes to the plan early and often.
"Our target for November is under pressure. We are still on track, but there is a chance we'll have to postpone until January. We'll keep you informed."
That's infinitely better than "maybe next sprint?"
Don’t break the same promise twice
Breaking the occasional promise is part of building software. We can’t control everything, so despite good planning, surprises will occur.
Breaking the same promise twice, however, is unacceptable. Unfortunately, it’s rather common in teams without a long-term plan.
Nobody likes bringing bad news. The instinct is to placate the customer by making a new promise. "We'll have it ready in two weeks!”
While that makes the conversation a bit easier, this new promise better be thought through. Are we really sure we can deliver? Did we plan some buffers in case more skeletons are in the closet?
When breaking a promise, update the long-term plan to find a realistic new target date. Shift the timeline around until you find a new timebox where you can deliver. Resist the urge to delete Recovery blocks to be “more productive", and ensure your new plan doesn’t break other promises. You don’t want to start a fire to put out a fire.
The target date for the new promise will always be later than what feels comfortable. It’s never a week from now. It’s easier to tell a customer the pizza is on its way. It’s better to give them the honest 30 minutes.
Nobody likes to hear their highly-anticipated feature has been postponed. But there are objectively good and bad ways to break this news. Stakeholders and customers will be supportive if they feel their requests are being taken seriously.
Teams need their stakeholders’ trust. And that trust, like all trust, is earned.
We build that rapport by making promises and keeping most of them.
That’s why a backlog is not enough.
That’s why teams need actionable long-term plans.
I agree, the suggestion that you don't give estimates is unrealistic. As you rightly point out estimates are part of earning your seat at the table.
Better to give them, with the assumptions made to create them, then communicate changes to the plan early and often.