Singing in the rain shower: building bathrooms vs managing digital products
Five things I learned from product management that also applied to renovating my flat
Recently I’ve been having the cloakroom and bathroom in my flat converted into a new bathroom and a walk-in wardrobe, alongside some improvements in the bedroom. This means half my flat has been a building site. I’ve been living in the other half, thinking about the differences between physical and digital projects — and more, about the things that are the same.
Many concepts are familiar, even if the builder wouldn’t recognise the names. Minimal viable product (MVP) for a bathroom turns out to be a toilet and a gym membership. Having an actual room — four walls and a door — is optional, at least if you live alone.
Project management is still about putting tasks into a sequence, with dependencies and risks — although physical materials bring their own challenges, starting with the sheer volume of stuff that needs to be delivered and stored and cut up and stuck together with other stuff. Code doesn’t need time to dry before you add more code, but adhesive and grout and filler and paint all do. Refactoring costs money as well as time.
The grind to the end is just the same. Everyone gets tired, everyone wants to finish, the last few things are still… not… done… and you lie awake at night thinking that if you’d done everything differently right at the very start, everything would have turned out… pretty much the same, actually.
Here are the five things I took from my experience managing digital products to the world of plumbing, tiling and paint.
1. Find your place
As the client of architects and builders, it was my role to set the brief; pay the bills; make decisions as required; ask questions and give feedback; and avoid being a pain in the arse.
As a Head of Product, I do similar things: set goals; ensure we’re delivering business value; help my team make good decisions; ask questions and give feedback; and avoid being a pain in the arse.
It’s the gap between the last two that I find hardest. At one end of the spectrum, you’re cold, uncaring, neglectful and largely redundant. At the other, you’re a megalomaniac, pain-in-the-arse micromanager.
Somewhere in the middle, I’m trying to do two things: check that people are competent, and remind them I care. I’m accountable for the work of my team, and I have to live in the work of my builder, so in the early stages of a project, I’m asking questions to find out what they know.
Me to builder: What’s with that pipe across the ceiling?
Builder: It’s the wrong size for a soil stack, and I haven’t heard anything come down it, so it’s probably going to a vent.
Me: Does it need to be supported?
Builder: If hot water does come down it, it’s going to sag, so yes, we’ll put a bracket in.
I’m genuinely concerned about the pipe, because the plumbing in my building was modelled on a demented game of snakes and ladders, but I’m also listening to the builder talk about what he’s seeing and hearing, and the properties of the materials, and how those things affect his decisions.
Later on in a project, it’s more about noticing and appreciating people’s work. Most people who create things — physical or digital — want the freedom to get on with it, but that doesn’t mean they want to work in a vacuum. Someone needs to care, but without being all over them.
2. Good, cheap, fast
Project management trades off good, cheap and fast — otherwise known as scope, resource and time. If you have money to burn, you can hire more people to hit a deadline. If your pockets are empty, you must change the date or reduce the scope. Scope is really two things, features and quality, so you can do less, or you can do it less well. If you can’t flex anything, you’re heading for trouble.
For my bathroom, I had a budget and a desired outcome. There were problems to solve — dodgy plumbing, poor layout, noise — and things I wanted to achieve — more storage, and a nicer place to live. I wanted the work done well, but I was relaxed about when.
Okay, that’s a lie. Over seven weeks of iterative bathroom, there wasn’t a day when I didn’t think it would be nice to shower IN MY OWN HOME and wonder when that might happen. I wasn’t relaxed, but I tried not to keep asking when it might be finished (see also: avoid being a pain in the arse).
Deadlines are useful, because otherwise you have infinite scope and unending cost. However, in 1o+ years of building products for publishers, I’ve done very few projects where hitting the deadline was the most important thing. If you’re creating special tools to cover an election, or report on a major sporting event, there’s no point having them a week late — so you remove features, cut corners or work crazy hours to hit the date. On every other project, the date may slip.
It’s easy to fixate on deadlines, because success is black and white. If I promised you something for the 20th, and today is the 21st, and you don’t have it, clearly I’ve failed. Woe is me, etc. But my bigger goal is to deliver value, so when push comes to shove, broken products don’t get pushed out.
As five weeks on the bathroom project turned into six, and seven, and eight, I grumbled to my friends and colleagues about neverending projects that never end, but I grumbled to the architect about the ceiling needing another coat of paint. There was no point saying, “You haven’t finished and you haven’t done it right,” because they couldn’t fix the speed and the quality. Knowing where I could flex made it easier to be clear about what mattered.
3. Estimate the optimism
At the start of the ninth week, there were 25–30 small things left to do. The architect told me they’d be done by Tuesday. The builder said he’d still be there on Wednesday. I thought they might finish by the end of the week.
They wrapped up on Friday.
I know nothing about building, so I wasn’t putting times against each task and totalling them up. I just looked at how many things were getting done in a typical day and divided the list by that number. It isn’t science, and it’s barely maths, but it mostly works.
Eliezer Yudkowsky’s article on the planning fallacy explains why. His thesis is that when people plan, they think about the best-case scenario. They imagine being motivated, getting everything done efficiently, and completing tasks in the best possible order. That is, after all, the point of planning — but it doesn’t account for off days, unexpected problems and random disasters.
Yudkowsky’s advice is to think about broadly similar tasks from the past and expect your current project to take about as long. I particularly like his closing line:
You’ll get back an answer that sounds hideously long, and clearly reflects no understanding of the special reasons why this particular task will take less time. This answer is true. Deal with it.
Some people do this naturally. Others live in the optimistic moment and find it hard to step back, think about the random issues that plagued previous projects, and imagine similar mishaps in the future. On the plus side, their optimism carries them through the dark days when the pessimists are dragged down by voices screaming, “THIS WILL NEVER END.”
If you’re good at estimating, the pragmatic solution is to identify the level of optimism and calibrate. If tasks that were supposed to take two days get done in four, a task that’s expected to take five days will need two weeks.
This may make you crazy, but on a one-off project, there’s very little you can do. There’s no point arguing about it, because the optimists believe the next task will go to plan. Ride their optimism — doom and gloom won’t speed things up — and quietly adjust your own schedule.
This may sound defeatist. Deal with it.
4 Always forward
On any project, things will go wrong. People will get sick, paperwork will go missing and supplies will turn up late, or wrong, or damaged, or not at all. There’ll be misunderstandings, mistakes and accidents. Some of the mistakes will make you wonder if you can facepalm while headdesking.
The single most stressful part of the bathroom project was the first day. It starts with the architect managing the project telling me he’s going on holiday for two weeks. Then I finally get hold of the managing agent, who I’ve been chasing for two weeks, and he says we can’t start work because the paperwork hasn’t come through — so I call my lawyer, who isn’t available. Meanwhile the builder is pulling the bathroom apart.
I decide destroying the bathroom can be put down as ‘investigation’ rather than actual ‘work’. Then the builder tells me he can’t come back until Wednesday. On any other day, this might seem like a bad thing, but it buys me time on the paperwork.
At this point I’m mostly cross with the managing agent for not getting back to me earlier, and somewhat annoyed with the lawyer for not warning me there might be a problem, and apparently I still have capacity to be irked with the architect for going away when it’s already all going wrong. I could happily yell at any of them, but that wouldn’t move things forward, so I chase round to find out what has actually happened (the freeholder’s copy of the paperwork has got lost in the post) and work out a compromise (the lawyers have the copy I signed, so they agree I can start). Eight hours of stress later, the crisis is over.
When things don’t go smoothly, you can be angry, or you can lie awake and worry, or you can figure out what to do next, or you can work out why things went wrong. Those things aren’t mutually exclusive: it’s quite possible to be cross and stressed while formulating a plan and changing your approach. However, it’s better to separate the last two.
“What do we need to do?” is a palatable question that brings people together to solve a problem. Something happened, we are where we are, we know where we want to get to — how do we move forward?
“Why did this go wrong?” is a much harder question, with its undertones of blame and fault. It involves looking backward and thinking about what could have been — or perhaps should have been — done differently.
Both questions have value, especially in a team that will stay together and encounter similar problems in the future — but if you try to answer them both at once, the emotions of the second can pollute the answer to the first. You’ll find yourself ranging from what has happened to what should have happened to what needs to happen. Everyone will have a slightly different view of what has happened, and there are many possibilities for what should have happened, all leading to places that aren’t where you are now, and those places would enable solutions which aren’t relevant — because you are where you are. If you weren’t cross when you started the conversation, you will be soon, and everyone will get confused.
In most cases, you should fix the problem, then have a retrospective. You might learn more about the problem as you solve it, and you’ll give everyone time to reflect and calm down. You might realise it was a genuine accident that’s unlikely to recur, or didn’t have much impact.
Conversely, if it has all gone to hell in a handbasket for the umpteenth time, do the opposite: park the problem and figure out why things keep going wrong.
Either way, your goal is to move forward, because that’s the only way you get a new shower — and between the dust and the stress, you’ll need it.
5 Communication is hard
Many bitter arguments include the words, “You should have said,” or, “You could have let me know,” or “Nobody consulted me.”
Communication should be easy, right? It’s just people talking to each other, and that’s easy, so when it doesn’t happen, it’s easy to get frustrated.
Brutal truth: communication is hard. Each person comes to a conversation with different experiences and assumptions, and it can be hard to spot the gaps, let alone bridge them with words.
For example, the first design for the bathroom features a marble bath surround. I hate it. I understand why a bath is shaped like a coffin, but I see no reason to slap a tombstone on the top.
I don’t say either of those things to the architects. “I hate it,” is an accurate statement of my emotional response, but it doesn’t help them choose a new direction. Likewise, I genuinely think it looks like a tombstone, but that’s probably because my previous bath was so much like a coffin that I’ve given up lying in it and just take showers. I could explain all that, but talking about tombstones and coffins is half a beat from talking about death, and who knows what experiences everyone will bring to that.
The architects don’t know me: smart, blunt, opinionated, introverted and a good heart behind the sharp edges. They don’t know I start at the edges of a problem and work towards to the centre. “I hate it,” is the starting point for a conversation about alternatives, not the precursor to, “FFS, you’re fired.” Likewise, I don’t know them. I don’t know whether they respond better to robust criticism or gentle coaxing, but I’m trying to start out polite. They can meet the real me later.
I tell them the marble slab is not for me, and find some non-death-related reasons for disliking it, and send them some examples of things I like, and we move forward (see also: always forward).
Here’s another example. It’s a Friday, and the new carpet for the bedroom is coming on Monday, but it still needs to be painted. Two of the builders turn up and tell me they’re going to paint the bedroom. This seems good.
Towards the end of the afternoon, the architect phones and says the builders haven’t quite finished the painting, because they’re run out of paint, but they’ll get the last bit done on Monday morning before the carpet arrives. This seems okay.
I get home in the evening and the painting is barely started. This is bad.
I spend 15 minutes translating “WTF?” into a passably polite email to the architects, who contact the builder in charge of the team, who speaks to the guys applying the paint, who admit that “nearly finished” might be a generous description of their progress. This gets passed back up the chain, the plan gets changed, the carpet goes down, the painting gets finished later and everything is fine. In the end.
Afterwards I calculate it has taken at least eight conversations over three days to get six people to a consensus on how much paint has been applied to the bedroom. Given we’re discussing observable facts, rather than plans or strategies or beliefs, how can this happen?
Whenever there’s a gap between what we want to say and what we think the other person wants to hear, the easiest option is to drop the message somewhere in the middle. The builders tell their boss they’ve made good progress. That’s what he wants to hear, and what architect wants to hear, and what I want to hear, so the update gets a little better on each telling — until reality intrudes, and I spend the weekend wondering what kinds of idiots I’ve hired to renovate my home (see also: facepalm headdesk).
I’ve had the same conversation on digital projects:
Developer to scrum master: I don’t know why it isn’t working. It should work. I’ve checked everything. To stop working like that, it would have to be… hmm… maybe… no.
Scrum master to product owner: The developers are working on it. They aren’t sure what the problem is, but they’ll keep looking. I just don’t know how long it’s going to take.
Product owner to me: The team will find the answer, they always do.
Me to stakeholder: We’re investigating the root cause, it’ll be fixed soon.
A week later:
Stakeholder to me: It’s still broken!
Me: Yeah, I know, we’re working on it.
At this point the stakeholder wonders what sort of idiot is managing their product…
The more links in the communication chain, the greater the risk of the message changing. Why not get everyone together? Because it would take longer to organise and be harder to manage. The dynamic of each conversation is different, depending on who works for whom and whether their relationships are short term or long term.
Talking to people is easy, but conveying information — accurately, effectively and efficiently — is hard. Sometimes you can get into a groove. There are people I’ll always call, or speak to face-to-face, even though email is best for me. Sometimes the groove becomes a rut and you have to do something different to wake people up.
It helps to be flexible, to reflect on what’s working and to repeat the key points. Sometimes people aren’t listening. Sometimes they assume you’re talking about question A and you think they’re answering question B, so listen carefully to see what’s landing. On the plus side, when you realise people haven’t heard, you can repeat yourself and they’ll think you’re saying a whole new thing.
More than anything, hold the people around you in affection. I haven’t mentioned that the new bathroom looks amazing, or that the builder was incredibly tidy, or that the architects dealt with my difficult neighbour when I was jet-lagged to incoherence. It’s genuinely uplifting to stand in the new shower and contemplate the day ahead. Everyone was helpful, good-humoured and a pleasure to have in my life — even for three months.
Focus on the many virtues of your team as your hands reach out to wring their necks. They aren’t perfect. You aren’t perfect. But if you remember you like each other, you can sort things out.
Wash-up
I hate having strangers in my home, so I never imagined a building project would be anything but stressful. It was worth it, though. And it turns out my job not only paid for it, but gave me some of the skills to get through it.
