On Murphy’s Law, Agile, and Product Management
Everything that can break will break
People: “May the odds ever be in your favour.”
Murphy: “haha, hold my beer.”
Murphy’s law is an adage that explains that “everything that can go wrong will go wrong.” Murphy was an engineer in the US Air force; perhaps he saw enough to come to this conclusion. He was clearly not an optimist — he seems like bad vibes and is casting a shadow on our sunshine. However, when I think about it, his position really isn't that far from reality. I can't decide if he’s a pessimist or a realist. You’ve kept an umbrella in your car or office for 6 months. Somehow, the day you take it out or borrow someone is the day there’s a downpour. That is also the day you have an important meeting out of the office. Or how your hard drive miraculously gets a virus on the morning of your presentation right after you burn your shirt while ironing. Yep, that’s Murphy doing his thing.
What does this have to do with product management?
“Houston, we have a problem (again)” — me announcing that something else has broken.
After being in this role for a while now, I’ve seen things break quite a bit, for no reason. Technically, there’s a reason but just play along. I’m going about my day, figuring out how things work, and out of nowhere I see “server error” or “invoice not found”. Being a non-technical PM, such situations are very annoying because there’s not much I can do about them. I have to wait and pray that fixing that issue doesn’t break anything else. I think my favourite is when something that has been tested 6 times suddenly decides to stop working during a demo, and the engineer and I are looking at each other like….
Murphy’s law and your roadmap
While bugs are annoying, they are relatively easy to spot and fix. Not all disruptions give you that luxury. Take for instance you’re working on a product that gives users virtual bank accounts and then the Central Bank bans your provider. So now you have to “innovate around regulation”. Or your engineers and designers just happen to move on to other projects at a busy period, creating a resource constraint. There goes your roadmap!
Murphy’s law and Agile
Responding to change over following a plan — the 4th Agile value
The Agile manifesto is basically a guide to agile software development. Rather than defining a set of rules, the agile manifesto suggests a mindset with which to approach work. The fourth value highlighted above preaches adaptability. It is not an excuse to be capricious, easily swayed by any wind, and not stick to agreed plans. Instead, it recognises that life happens and whatever the new information or change may be — customer requirements, regulations etc — we need to remain flexible.
Initially, when things went awry, I would get so worked up and panic. Now instead of haphazard thoughts and actions, I try to be agile. I focus on finding the problem, the person that can fix it, and ways to provide temporarily succour. Tbh, I still get stressed but now I can make jokes about it. Sometimes I realize that the previous timeline was not realistic and need to adjust it because good things take time. Ideally, these things shouldn’t happen often, but they do.
There’s no moral lesson to this article or “10 tips for preventing things from going wrong”. The long and short is this — just like every other job, product management doesn't come with guaranteed sunshine every day. There will be bad days, but you need to learn from that event, keep moving, and work on preventing repeat cases if within your control. So…
