Setting expectations is hard. Living up the them is harder.
Setting expectations as a Product Manager is hard. When pitching our product ideas and strategy we need to make a strong business case, with a significant value proposition. We don’t want to be too conservative and undersell our impact. This could weaken the proposal, and possibly lead our company to miss out on an awesome opportunity. On the other hand, overselling and under delivering can cause the company to make crucially wrong decisions, and will erode trust that we’ve earned from stakeholders and decision makers. But we can’t be both ambitious and conservative. Ambitious and realistic is the illusive goal.
Setting expectations is hard, living up to them is harder. We try to straddle the line between overpromising and underpromising, with only an educated guess at where the line really lies. Estimating how much time and work building a new product will take with any degree of accuracy is near impossible, even with the engineers' involvement. For both Product Managers and Engineers, our ambitions are always bigger than our execution capacity. So we make our educated guesses and do our best.
Things will go wrong! There are so many unknowns. The complexities which a product needs to overcome are always trickier than we and our engineers will anticipate. Tech debt always affects productivity more than we realise. There are always distractions, incidents, external asks, and a plethora of other reasons which take away focus from our team’s main goal. I’m sure that once in a while there are software projects which are completed on time, but I’ve never seen them. And as an old manager of mine used to say “Nobody gets fired by not getting the job done in time. You get fired for surprising people that you didn’t get the job done in time.”
We don’t screw up by not meeting expectations. We screw up by surprising stakeholders when we don’t meet expectations.
In other words, as soon as we know our original goals are out of reach and we won’t live up to the expectations we set, move the goalposts. Do it explicitly, and make sure that our stakeholders know.
I’ll never forget the first time I was telling a VP that the product we were building, that we said would be ready in October, was going to be done in February at the earliest. This was for good reasons, but still it would mean a big delay before our company could realise the impact it was supposed to have. He counted the months on his fingers and then said “We’ll that’s not acceptable. What help can I get your team to make it happen earlier?”. I was totally unprepared to answer that, because the only adjustment I had considered was moving the goalposts. Delivering what was promised, later.
It’s not that simple! If the opportunity our product is supposed to grasp is time sensitive (to stay ahead of a competitor, for example), and should have a huge impact if done quickly, then delaying the release is the wrong adjustment to make. Maybe there’s a key engineer working on another team that could join us, or maybe another team could pause what they are doing and collaborate with us. Maybe we need to break down the product and reduce scope, or maybe we can make some short term or “hacky” technical decisions which will save time.
I’ll call these adjustments ‘bad options’, because it is very possible that any of the alternatives we consider would have consequences which are not worth it. For example, if we consider moving an engineer from another team to join the project, there is ramp up time associated with adding them. Then, onboarding them splits the focus of the team, which increases communication overhead. And of course there are implications of moving them from their current team, like down prioritising or dropping something else. And sometimes problems just take wall-clock time to solve and increasing the number of engineers working on the problem might not help at all, maybe even make things worse. We’ll need to evaluate.
Maybe it is worth it. If one of these will actually help us do it faster, and the benefits of being faster outweigh the consequences of the “bad option”, then it could be a reasonable mitigation to the delay. But if we’ve considered the different ‘bad options’ and their implications, and decided that the extra benefits are not worth it, we aren’t just giving up. We’re saying that the best mitigation is to delay the end date of the project, and now we’ve chosen to do so explicitly.
What we absolutely can’t do is recognise the risk and hope for the best. When I raised with the stakeholder VP that we would be late, I luckily did so as soon as it was obvious. That gave us plenty of time to get other teams onboard to help, and this VP was able to help arrange that. I still looked foolish in this meeting, but I learned that I can’t raise the alarm without suggesting possible mitigations. And luckily I did so without surprising anybody, and without personal consequence.
Because when we pitch our ambitious product ideas and strategy, we are doing so with lots of uncertainty, and everybody recognises that. It’s still a key part of the Product Manager’s responsibility to set realistic expectations, and often that means explaining that the uncertainty meant that our original plan will no longer hold. But saying so isn’t as simple as saying “no, it won’t happen”. Instead we need to say “It won’t happen under the current conditions”, and propose alternatives. Alternatives which have consequences. But it could be worth it. And if it is, then we can achieve our ambitious, realistic goal. Just with some tweaks along the way.
I think our latest episode is our best one so far ! Arvid and I met in person (!!) during the Swedish vacation period and had a chat about setting and managing expectations, with emphasis on saying no. Please have a listen, and reach out to us to discuss or debate on Twitter @productinternal or at podcast@productinternals.com ! And if you’re enjoying the show so far please follow!
And if you liked this post we’d love to have you join the Product Internals community! Subscribe for a new post once a week or so. If you find them as valuable as we find writing them please share them with your friends and colleagues!