Most products fail, even in the best companies — and for every AdWords there’s a Google Glass. The failure rate for digital products could be as high as 90%, depending on which report you read.
It’s a metric that hasn’t moved much in the last few years, despite all we know about the benefits of cross-functional teams, running a product-led business, digital transformation, and how important it is to understand user needs and behaviour.
Here we dig into some of the big reasons why products fail.
Unrealistic expectations of what success looks like
There are plenty of famous product flops, but Google is a pretty good place to start an examination of product failure. It’s a company that has built something of a reputation for launching products to great fanfare and then terminating their existence a couple of years later. Software engineer Cody Ogden was a big fan of Inbox by Gmail and became very upset when Google announced the product would be shut down in March 2019. The announcement was the spark that inspired him to start the Google product graveyard, Killed by Google, a site which displays all of Google’s dead products and whose Twitter account now has over 22,000 followers.
From Cody’s perspective the most important thing when developing a product is to set realistic expectations about what success looks like. And for Google, success is likely to be an order of magnitude larger than it is for other businesses.
“Killed by Google started as a bit of fun, and definitely some venting,” says Cody, “I’d been a user of Google Reader, I’d used Google Wave, [both killed by Google] so it was not a new experience to be burned by Google.” As Cody points out, Google is unlike nearly any other software business, it employs well over 100,000 people and its campuses are the size of small towns, so what qualifies as viable and successful for Google is surely on a different scale from other businesses. As Cody says: “They have to have a billion-user scale to make a product viable.”
Cody has the impression that there’s a lot of internal competition within Google, saying “they create competing products, because their teams are so spread apart, and they’re all working in different directions”. He adds that he thinks that there is now an awareness in Google that the company has a reputation for killing products.
Cody’s not aware of any Google products coming back in their entirety from the grave, but the company does incorporate pieces of dead products into new products, experiences he terms “those experiences that hit metrics well”. For example, there was a snooze feature in Cody’s favourite product Inbox for Gmail which can now be found in Gmail.
As we’ve already said, for Google, success is probably an order of magnitude larger than it is for other businesses. Mind the Product Co-founder and ProdPad CEO Janna Bastow comments that not only should you be clear about what you expect success is upfront, you should find small ways to keep testing your expectations and assumptions.
You haven’t really built a product
The world is awash with products — conservatively it’s thought that over 30,000 are launched each year. Because it’s much easier to build a product than it used to be, says Janna, people don’t always think through whether they’re building a product that is valuable, usable, feasible and viable, and build a passion project instead — but it takes up space even if no one uses it (live but inactive sites take up about 85% of the internet). “To the extent that you now get joke products,” Janna says. “I found istheshipstillstuck.com in my browser history the other day, it’s a product that was built as a one-page site when Ever Given was stuck in the Suez Canal. No one visits it any more but it’s still there.”
Even if your product solves a problem, it doesn’t mean that it’s a viable product, says Janna. “It doesn’t mean that anybody cares enough about the problem and that it’s viable enough to make money,” she says.
Your product could fail because it solves for an area that has a lot of edge cases, she adds. “In this case you would have to make something that’s configurable. But in order to make something that’s configurable enough to fit everybody’s needs, you end up with something that’s a Frankenstein of a product that you can’t maintain.”
You don’t do the right research
Hopefully the above shows that conducting customer research and asking the right questions is fundamental to any product discovery process. It’s a lesson, however, that Filippo Morelli learned the hard way.
In the mid-noughties Filippo was a software engineer (he’s now a product manager) working in the UK and helping financial institutions to build products for the cloud. “I was asked to build the same thing over and over,” he says. At the same time he was very interested in the idea of startups and building a product business. So he stopped his consulting work, and took six months off to create the product he thought these financial businesses wanted. “Then I went back to some of the businesses who’d asked me to work for them and told them I had a product for them, and I got one no after another.” Filippo says that for him, as an engineer, talking to customers was primarily a matter of asking about their requirements: “I had a product, I had a set of features. They wanted a set of features, so if that was a match, to me it was done.”
What he discovered too late was that his potential customers didn’t want just to buy a piece of software, they wanted a person with a certain set of experiences to work for them and to create something bespoke. “For a high-profile institution, that person on site, that human component to the product, was critical and I had completely missed it. I was just thinking as an engineer, and I was just thinking about features.”
Your sponsors lose interest
As Arun Kumar Ahuja, a seasoned product manager with eight years of experience in building enterprise products used by Fortune 500 companies, comments, an enterprise or B2B product can fail because its sponsors lose interest in it over time. He says: “It is hard to sustain the intent and interest of your key customers or key sponsors. The perceived value of a product changes over time and from person to person, and there may come a time when you’re not able to sustain a critical mass of intent, or critical mass of perceived value in the product. That’s when your product loses sponsorship.”
Your product has launched, but you’re not done
Intercom SVP of Product Paul Adams, in this talk, Don’t join the cult from MTP Engage Hamburg, reminds us that products are temporary, everything we make and the ways we make them are temporary. He runs through the other teams in the business that need to be involved in a product in order ensure a product’s success. Janna says: “You might technically have the best product, but it does not mean that your product is done — you’ve not done your job yet. There is the marketing of your product and making sure that it is communicated and that the benefits of the product are known.”
Janna says product managers should think about the bigger picture beyond the product’s features: “Think about pricing, the proposition, the packaging. If you’re not able to get that clear, upfront, then you don’t have a clear picture of what success will be like.”
She cites the classic examples of competing products where one failed — Betamax vs VHS, Blu Ray vs HD DVD — because of poor marketing and poor understanding of the market and the product’s ecosystem. “Make sure to spend time measuring and learning,” she says, “not just building. Building is the exciting part. But teams don’t really like to go back and ask ‘did we do the right thing?’. It’s uncomfortable but, if you want your product to be successful, sometimes you have to go back and say, ‘that was junk, let’s take it out’.”
Janna’s comments are echoed by Arun, who says that the one thing enterprise product managers should do to ensure success is to consider the whole solution for an enterprise customer. “It’s not just the product,” he says. “Enterprise customers are buying a solution to a dynamic problem. They need to be able to trust that if the problem changes shape then you will be with them modifying the product or the approach if the problem changes shape in the future. They need to know you’re working with them to make sure that they are successful.”
Make sure to spend time measuring and learning, not just building… teams don’t like to back and ask ‘did we do the right thing?’Janna Bastow, CEO, ProdPad
Lack of clarity about what the business wants to achieve
Nhi Chang is a senior consultant at software consultancy Thoughtworks in Brisbane, Australia, who’s worked for startups and bigger companies in the past. While she applauds the drive towards value for the customer, she says that businesses are often unclear about what they want to achieve from a product and the value of a product to the business, and this lack of clarity leads to product failure. She says: “It’s really easy to think about what benefit you’re going to give the customer. There’s always a ‘why’ for the customer, but what is the business trying to achieve? When that’s not clearly understood it becomes a fight about what to build.”
Nhi tells the story of a workshop she led recently for a growing company. It has a great product, she says, and while it’s not making money yet it’s growing fast. She explains: “The founder told me his team wasn’t using their time well enough, and that frustrated him because the business was trying to move fast. Then it took him two hours to explain to me what he believed the vision and the value of the product was — two hours. I said, ‘if it’s taking you two hours to defend your product to me – and I’m not even a consumer of your product — doesn’t that tell you that your team’s not clear on what you want?’.”
Her initial advice, to a founder or anyone who is trying to get their ideas understood is to stand back. “Don’t try to defend your product. Instead listen to what those around you are saying and understand rather than try and be understood”. She adds that in her experience there is no golden set of rules for building a successful product. “It’s really about understanding who makes the product,and who it is that builds the product for you. When you can understand their motivations and their drivers it’s easier to see how to get alignment to the product vision.”
Don’t try to defend your product. Instead listen to what those around you are saying and understand rather than try and be understoodNhi Chang, senior consultant, Thoughtworks
No clear direction
In July 2020 Randeep Sidhu joined the UK’s Department of Health and Social Care as Head of Product. He’d previously developed health tech in Rwanda for Babylon Health, and joined the department of health with the remit to help build the second NHS Covid19 app after the first one was withdrawn. The app is the front door to the UK government’s Test and Trace service to help prevent the spread of Covid19. His story contains many lessons about both product failure and ensuring product success.
Team structures, reporting lines, and organisation structure have a big impact on the products produced — Conway’s Law states that “any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure”. The mistakes in leadership, missteps and errors of judgement that contributed to the failure of the first NHS Covid app show Conway’s Law in action, the errors are documented in this article, Piloted in May, ditched in June: the failure of England’s Covid19 app.
Randeep says that while plenty of talented engineers worked on the first app, it illustrated what can go wrong when product thinking is unclear, when teams don’t work together effectively, and engineers have directions changed. The engineers had built a technical solution, says Randeep, and the app simply didn’t work in the way it needed to. He says: “The first product built was an app that constantly pinged Bluetooth. Although some of the code was good, Apple and Google phones aren’t built to broadcast their locations continuously, and the engineers couldn’t compete with a system that Apple and Google ended up building into the operating system of the phone.”
At the heart of the challenge was a lack of clarity and consensus on what a Covid19 app should do, Randeep suggests. One person might say it should notify you that you’ve got Covid or that you’ve been exposed to Covid. An epidemiologist might say it needs to track the virus, while another might say it needs to be used as a centralised database of locations where there is high prevalence of Covid — and each of these functions is valid. The first product was built as a scientific tool rather than an app that more simply informed people about their exposure to the virus. Says Randeep: “The first app was conceptually interesting and ambitious, but ultimately strayed from the needs of users. Users didn’t need a scientific surveillance tool, they just needed to be told they’d been exposed to Covid.”
Lack of diversity in the team
Responsibility for the app had moved from NHSX, the government unit charged with setting national policy and developing best practice for NHS technology, digital and data, by the time Randeep joined the project. It was back in startup territory: there was no product team and the previous product manager had left within a week.
Randeep saw this as an opportunity to build diversity into the heart of the product and team. He points out that Covid is a disease of inequality — inequality of wealth, education and race — and that the new app had a chance to reach different communities and minority groups, which he believed would be vital to the success of Test and Trace.
Randeep focused on ensuring the app would work for users with low literacy or limited access to technology, knowing that some communities were hesitant to use Test and Trace or to be vaccinated. He adds: “I was the most senior person of colour in the division, and usually the only person of colour in the room. Inevitably, many of my team have lived experiences that our white colleagues have not, and we were a valuable resource. This is the value of diverse teams! Our job was to understand why these hesitations existed, not to judge them. And where they existed, we needed to see what we could do to overcome them.”
To compound the challenges of the first app, it was piloted on the Isle of Wight, an area not representative of most of the UK, let alone communities most affected by Covid Randeep pushed to get the second app piloted in an area that was more representative of Covid and “more representative of the people dying of Covid”. As Randeep says: “You have to over-index on the communities that are most impacted by Covid. I made sure I had a diverse team, and the team made sure that we had diverse thinking and diverse points of view. We built the app in 12 languages. We did lots of testing for people with disabilities and neuro-diverse conditions. It’s healthcare after all, it should work for everyone.”
But as we now know, it’s a story with a successful conclusion. Randeep and the team he assembled took the app to a working pilot in the east London borough of Newham within five weeks of joining, and then rolled it out nationally six weeks later. The app was downloaded six million times on the first day it was generally available, and within five weeks had been downloaded by more than 19 million people.
There are plenty of other reasons why products fail. For example, SVPG’s Marty Cagan runs through the procedural and organisational reasons for product failure in this talk, The Root Causes of Product Failure, from #mtpcon San Francisco in 2015. Another #mtpcon talk, 10x Not 10%, Product Management by Orders of Magnitude, from Ken Norton, looks at how our instinct for loss aversion can cripple our ability to make good decisions and cause businesses to optimise their way to obsolescence.
Product managers love to launch products, it’s the most exciting part of the job: whether your next launch turns out to be a Google Adwords or a Google Glass is a complex, multi-faceted issue that takes in all the factors above and more. As Winston Churchill may or may not have said: “Success is not final, failure is not fatal: it is the courage to continue that counts.”
Further reading
Explore more Mind the Product content on Product Development, see our Content A-Z or check out these articles on product failure:
- 7 reasons new products fail
- 5 Reasons Why Most Digital Product Launches Fail
- Why Do So Many Online Businesses Fail?
Comments 0