The Misconception of Failure
I have learned a lot this week about the taboo that is failure, particularly in the workplace so much so that I have decided to write about my observations. When it comes to failure it seems like there’s two wildly bi-polar approaches as to how we handle the event or sequence of events that can be considered failures. Firstly, in traditional organizations we penalize failure in all forms and view it as a bad thing. It reflects badly on the company and your competence as a product manager or any role you play for that matter.
Then we have the ‘don’t be scared to fail’ cliche that dons the inspirational pictures that adorn workplace walls and that circulate on LinkedIn. A cliché that is grounded in the legends and testimonials of Googles risk taking and sometimes crashing whilst always being awesome…or at at least that’s the perception. It’s a practice we’ve glorified and one which we have a certain romance for, as ‘The Failure Myth’ details. How we communicate failure is void of a middle ground. We make bold statements about it, prides ourselves on avoiding and or embracing it. However, there’s a happy and notable in between.
Failure As A Bad Thing
Let’s focus on the former. Failure is bad. In most organizations, even ones that proclaim to be cutting edge, innovative and risk taking the reality is that things need to be done in a certain way and you are merited on your ability to do something diligently and correctly first time around. I recently heard a quote that resonated with me. A fortune 100 company had head hunted a seriously good consultant to better their agile and product delivery process. After a couple of weeks of asking questions and meeting various functions she collected the masses in a room — her observations?
Everything’s perfect. You’re doing everything right and have a thousand success stories to share. What baffles me is why your stock price isn’t sky rocketing. Why do you need me here?
The reality was things weren’t good at all. Additionally, they weren’t terrible by any standards. There was in reality areas of improvement or opportunity, which is the way we should articulate things that aren’t working as well as they could be…or things that suck for that matter. Some functions were performing better than others but no one wanted to be the under performers. Some teams were doing agile OK but like every team in the world they weren’t doing it perfectly (because there’s no such thing). Some product owners were delivering awesome features, but no ones that were solving needs. Others were delivering mundane features but ones anchored in data and solving real user needs. Some testers were finding every single defect but taking 10 weeks to do so and thus delaying launches whilst others were finding 90% of the scariest defects but helping ship features quickly. The one thing all of these groups had in common is that they were succeeding whichever way you looked at it. They were scared of their bosses seeing them as not performing perfectly, scared of the repercussions.
What would a wise consultant say to all of this? Maybe to not put lip stick on a pig and say everything’s perfect? Conversely they could also say don’t simply reel off a list of problems and things that suck. It’s easy to list problems, everyone knows what the problems are. Not everyone can spot an opportunity and present a solution to solve the problem. These are your million dollar people.
Don’t put lipstick on a pig. On the same note, don’t simply reel of a list of problems and things that suck. Instead list all the solutions you have to the areas of opportunity so that you no longer are left with a pig. Unless it’s a micro pig — they’re cute.
So why is the ‘failure is bad’ mindset the wrong approach? Firstly you force people to conceal things you should be solving for. If your a leader in and organization of this type and all you’re getting is updates that everything is awesome (think about the Lego movie and deep lessons we learned from watching it), the processes are perfect and what you’re delivering is great then your in a bad place. Ignorance is not always bliss. In fact it rarely is. If this is the kind of update you get then you’ll probably say, “Keep doing what your doing” and what they’re doing is masquerading the problems and not making progress bettering the process, the product or themselves.
The second problem of having adopted this mindset is that you will focus on fixing all of the issues and not solving for untapped needs and evolving your product. Everything about a product that’s sub optimal or which can be better can be considered an ‘issue’. However, just because there’s 3 http timeout sessions according to your server logs doesn’t mean that you have to fix it. If you have 1 million daily visitors and only 3 visitors time out your availability is actually relatively good. Remember, a product is a working living thing. A product is imperfect. If you spend all your time fixing trivial problems to create flawless error reports and communicate this as success then you’re setting your product up to stagnate. You aren’t working on new features, you’re not addressing your massive bounce rate and worse — you’re probably tracking and reporting on the wrong metrics. Metrics that don’t give you or your leaders a reflective picture of the health of your product. Metrics not aligned to your product vision.
Failure As A Good Thing
OK, so let’s all fail and be cool with it? No, that’s the other end of the spectrum which makes no sense either. Sometimes we naively take sayings such as ‘don’t be scared to fail’ literally. As if a free pass to fail because it’s what innovative people do. It’s what Steve Jobs did and look at him now. Wrong. Innovative and awesome product owners take calculated risks. They’re diligent. They often fail due to unforeseen circumstances or in ways that don’t bring their companies to their knees.
Try to be successful. Make decisions informed with data, be diligent and if even then you fail learn from it. Don’t celebrate your failure. Celebrate putting your learning’s into practice to succeed second time around. After all isn’t a minimum viable product (or minimum desirable product, whichever is hipper these days) a calculated and diligent way of eliciting validated learning. Learning that may come about from the failure or success of the feature but a learning that will not ruin your product or company?
Naturally there’s a balancing act. You have imperfect data, strict timelines to react to competitors, limited test accounts that may contribute to your ability to be super diligent. That’s cool. Don’t let this paralyze you. Simply take a calculated risk and be prepared for worst cases. Again, isn’t this the joys of launching MVP’s? You don’t spend 1 year overdoing the development of a feature that may not be desirable to your users? Isn’t missing the boat and an opportunity to elicit this learning a failure in it’s own right? Yes it is.
A Failed Summary
The best teams are transparent about their areas of opportunity, both in product and process. In being so they open themselves up to rectifying and putting in place changes i.e. the solutions, that can plug gaps so that they grow as product teams. Failure isn’t bad. It could be that you fail but themetrics that are used to measures success are bad metrics. It could be that you failed but you learned from it. What’s important is that you try not to fail but balance that with not over compensating and suffering paralysis as a result of the fear of failure. What’s important is being transparent about your shortcomings and failings so that you and your support network can be people who put in place solutions which you can act upon.
Don’t take a turd, roll it in glitter and tell everyone that everything is fine. Avoid creating the turd in the first instance. If you are unfortunate enough to make one think about how you can stop it from continuing to be a turd. Communicate and act up on your solutions. Avoid the need to have to buy glitter.