Pretence of predictability: Am I being as evil as my washing machine?

It’s Saturday morning, I am waiting for the washing machine to finish its cycle so I can go out. However, a design flaw in the machine is causing me disproportionate frustration.

As you would expect it has a small screen that indicates the time left. However, it never indicates the entire time left, only the time left at that particular stage of the washing cycle. I don’t know what these stages are, nor how many there are. Nothing on the machine indicates that either.

This means that when I put it on, it says 1h35, but if you come back in about that time, it suddenly says 40 minutes left. When you wait another 40, it might go back up to 30 or 40 minutes. Every time it goes down to zero, another timer starts. It’s completely infuriating when I try to organise my day around the washing cycle.

I call this annoying behaviour the pretence of predictability.

Pretence of predictability in product

Today, I came to the realisation that I have been just like my washing machine. Especially early on in my product career. 

“Yes the feature will come in August”

3 weeks later:

“It’s planned for September! The work we’re currently doing created a lot of bugs we’re fixing!’

A month later:

“We’re aiming for Q3 (October-December), we think that’s more realistic”

A few months later:

“We’re hoping to be done by early in the year… “

I have been wrong by 6-8 months on several occasions, of course every time there were reasons for it. I also became excellent at announcing delays, and with time I felt less and less bad about it. I mean, I was merely communicating what I knew at the time.

I gave a timeline because (I felt) I had to. Both customer-facing teams and higher management wanted dates so they could relay them. Inexperienced, I gave them dates I established with the team, but still a wild guess. We didn’t have enough experience of the product or the problem we’re trying to solve for users. Of course, we learned lots as we were developing the feature, and found many dependencies, blockers, technical challenges, and had to iterate some of the design. We gave a timeline, before we could even get an idea of what we were trying to size. 

I know better now (most of the time), but I think the organisation also made a crucial mistake there. They didn’t ask what was going wrong, or why I kept shifting the deadlines, they merely accepted the explanations and excuses I gave. It sent the message that it was ok to give completely inaccurate timelines, and hindered any good collaboration between product and sales/marketing.

What about not giving any indication of time

Well, that would be nice. “Hey product team, here’s lots of money, let me know when you’re done.” said no stakeholder ever. People who bear the responsibility over the work you do want to be kept in the loop, they need to manage other dependencies and report back to their stakeholders.

Not communicating until you’re done, even if it’s possible because you’re flying under the radar, is a terrible idea because you’re missing out on crucial feedback and not building buy-in with your stakeholders or customers.

It can be very tempting not to communicate when things are halted or advancing slowly– usually linked to having the right people in your team. Nothing’s going on, so why tell your stakeholders anything.

Silence on your part leaves lots of room for stakeholders to imagine what’s going on. If in a positive mindset, they may think you’re delivering well, and will get quite the wake-up call when they realise things aren’t progressing. If in a negative mindset, they’ll start losing confidence in your product or mission, and might even seek to invest in something else, or discredit you with others.

Even, if it’s not a popular message, you need to talk about what’s going on.

Giving wild guesses to get people off your back

As established above, giving wild guesses as to what is happening is a bad idea altogether. But sometimes you can feel like there’s a metaphorical gun to your head.

Then, there’s two steps to take:

1. Exaggerate your most generous guess
2. Ask yourself whether you want to be in an organisation like that or think about how you can fundamentally shift their thinking about product management

Communicating uncertainty

Communication comes down to being clear about what you know and are confident about, but also making it clear what you’re not certain about.

This means avoiding communicating something too specific like a feature and its delivery date, unless you’re shipping it tomorrow. Instead, having a roadmap to explain what outcomes you’re working on – when, is a better compromise.

I also like to indicate degrees of certainty alongside my predictions. Here’s the legend from my 1-3 certainty scale:

3 – we’re working on it now and know what we’re talking about

2 – we know what this is, and think it’s reasonable to assume that we’ll be able to tackle it in that timeframe

1 – we don’t know exactly what this entails, our estimate is practically a lie

I like to be flippant like that, as it makes people react and face the facts. If I wrote a euphemism like ‘least confident’ for the low end – then a stakeholder could quickly read that as ‘well, they’re a bit confident’.

Communicating the future as a product manager is easy to get wrong (and that’s ok!). There is of course ‘best practice’ out there, but you have to adapt it to your own context – like company culture, the personalities of your stakeholders, the speed of your industry etc.

However, it’s not all on the PM shoulders. To be able to do this effectively, they also require a product culture that enables them to communicate effectively. More on that later!