A Product Manager’s kryptonite? Deadlines and #noestimates in Product Management

“It’s hard to make predictions, especially about the future.” (Yogi Berra)

We’ve all been there. Just as you’re completing your backlog planning, you start hearing rumours of ‘a date’. This date has mysteriously been announced by someone much higher up on the org chart than yourself. The date affects your next release.

Eventually you find out when the date is, or is supposed to be. It is not presented to you as an option. It has not been informed by the detailed analysis you and the team have done. It is always much sooner than the one you had in mind.

From that moment forward, you and the Product Team are on a death march. Racing against the clock, piling up technical debt, frustration and burnout.

In a world of continuous deployment and frequent shipping, dates should cease to matter. The next big feature should be ‘just’ one release of many. Yet dates and unrealistic deadlines remain a major source of anxiety in our lives. As a Product Manager, you want to focus on outcomes and long term business value but seem to spend most of your time discussing whether or not you will ‘hit your date’.

Understanding why this is the case is critical for any Product Manager in a large organisation who wants to progress in their career. Large companies demand predictability. Estimation and budgeting are part of a cyclical planning process that underpins how they function. Detailed forecasts are necessary to unlock budget and measure return on investment over the long term.

Embracing the unknown may be part of our experimental mindset, but admitting that you ‘don’t know’ is kryptonite within a corporate culture. Looking like you know what you’re doing isn’t just important in this environment, it’s everything.

I’ve learnt the hard way that being cavalier or vague about dates and deadlines sets off major alarm bells and can backfire badly. Quoting Yogi Berra’s well known observation (reproduced at the top of this post) will immediately be interpreted as evasive. John Carmack may be able to get away with saying ‘it’s done when it’s done‘ about Doom4, but we can’t.

As a Product Manager, it’s common to find yourself trapped between the rock of staying true to your principles and the hard place of being pressured to commit the team to deadlines that make you uneasy. So what’s the answer? It’s best to start by understanding the environment you’re in and the ‘macro-forces’ in play.

Estimation has always been a contentious issue within software, exemplified by the CHAOS report’s infamous statistic that 80% of software projects fail to deliver on time and on budget, whilst 31% are scrapped outright. More recent versions show these figures slowly improving but a majority still fail to meet expectations.

This persistent backstory has birthed increasing adherence to the #noestimates movement in the last couple of years. Not surprisingly, given their name, #noestimates folk believe we should abandon software estimates completely. To them, the CHAOS report highlights NOT that Product Teams are poor at delivering, but that they can’t estimate well.

Estimates, they say, are inherently unrealistic as they are always based on imperfect information and inevitably wrong. Allen Holub, in an impassioned speech at Tech World, cited evidence that simply counting the number of stories on the backlog produced estimates that were just as accurate (if not more so) as detailed plans.

Thanks to Neil Killick for the graphic.

Even the process of estimating is time wasted that could be spent on ‘real’ work, say #noestimates converts. They point out that estimates frequently get turned into commitments which are used as a rod to beat the Product Team with.

As someone who has tried (and failed) to move focus away from the ritualistic fabrication of numbers that is the quarterly planning cycle, I get where the #noestimates movement is coming from. But I’m sceptical of it achieving much headway inside large organisations any time soon.

Trying to remove deadlines and dates is like trying to remove part of the cultural fabric. If you’re dismissive of dates, business stakeholders will interpret this as both a lack of commitment and a lack of confidence in the abilities of your Product Team. Any sign of this and trust deteriorates rapidly, leading to unwanted interference and micromanagement from outside.

Estimates definitely do get turned into commitments (I feel your pain on this one) but it’s not entirely clear to me how the #noestimates’ preferred tactic (‘the forecast’) will be treated differently or how Product Managers should respond to the inevitable question: ‘When will this be done?”

Also, having experienced the titanic efforts organisations make to shepherd frequently dysfunctional units towards a common goal, I understand why dates are so critical. If you don’t put a stake in the ground then nothing happens…ever. Deadlines are valuable tools to force closure in an environment that would push out for eternity if allowed to do so.

Corporations are not ‘default ship’ like a startup, in fact they are ‘default delay’ which is why it’s crucial for Product Managers to have an ‘Always Be Shipping’ mindset in order to maintain momentum.

Once again, patience and forbearance are the key to success. Attitudes will slowly change overtime, just not overnight. Other factors must change alongside. ‘Big bang’ launches that hinge on a specific date are a throwback to an era of above-the-line marketing, when media space needed to be purchased far in advance.

In these circumstances missing the date was indeed costly and wasteful, especially if a television campaign had to be scrapped. But as digital marketing and SEO begin to take over, launching becomes a process rather than an event. Things don’t need to be perfect immediately: typos, branding and messaging can continue to evolve in live. This can be hard for traditional marketers to accept. In print, you can’t roll back.

At the same time, it’s critical to maintain a long-term view and put short-term nervousness into perspective. I’ve lost track of the number of times I’ve been asked to pointlessly submit an expedite request to Apple just to hit an arbitrary internal deadline. (Always denied, by the way.) No one remembers these details after the event, but they do remember the overall success metrics of the product.

It may feel like dates are important when anticipation builds around your next release but good Product Managers understand that outcomes are what matter over time.