Learning from Failure: Product Manager Style
Every seasoned product professional knows that success only comes after a series of failures. To innovate, we have to try new things, not knowing 100% if they will work or not.
We should embrace failure, and that starts with learning from error.
When Products Fail
Every PMs worst nightmare! It’s one thing when a new feature doesn’t quite go to plan, or a few bugs needing to be ironed out after launch. But to have an entire product go down the drain…the thought is cold-sweat inducing.
Let’s look at 3 of some of the biggest flops in product history:
1. E.T. the Extra-Terrestrial by Atari
Famously known as the worst video game of all time, E.T. has not only been the standard for how not to make a game, but has also been credited as being a major contributing factor for the crash of the gaming industry in 1983. When was the last time your mistake brought down an entire industry? The game was slated by players and critics at the time as being incredibly boring, with words like disappointing, primitive, and inane being thrown around. The game, naturally, didn’t live up to Atari’s expectations, and so unsold cartridges were dumped into a New Mexico landfill, unable to be sold even at the lowest of prices.
What went wrong?
The problem here is time. Many product people know that rushed development can kill the final release. In this case, negotiations between Atari and Universal Pictures/Steven Spielberg over the rights to the film were only completed in July 1982, leaving only 5 and a half weeks for development in the push to release the game in time for Christmas.
Atari also elected to skip audience testing due to the time constraints, trusting instead that the popularity of the IP and a timely seasonal release would boost sales.
Another hit against the game was that part-way through development, Spielberg was presented with the gameplay and was “less than enthusiastic”, asking for a change to something similar to Pac-man. The developer refused, sticking to his original vision. He only admitted after the game was universally panned that Spielberg’s idea would probably have been better.
What can we learn?
- Time is everything. There’s a balance to be found when it comes to plotting the lifecycle of a product. Many product evangelists now agree that it’s better to ship an innovative product without a few non-vital features, than to wait for absolute perfection and potentially miss your moment in the market. That being said, sacrificing the integrity and quality of your product just to meet a specific deadline can be catastrophic. Give your teams enough time to do their thing.
- Assume nothing, and listen to customers. It’s true that product managers have to anticipate what the customer wants before they even realise, but it has to be based on data. Without customer interviews/feedback, your decisions are based purely on assumptions, and then you’re really playing with fire.
- You are not the CEO of the product. Had the developers listened to Spielberg, perhaps E.T. would have gone home instead of into a landfill. Of course, there’s always a time to influence your stakeholders over to your point of view, but there’s also a time to concede. The best product managers know which is which.
2. Twitter Peek by Peek
A $200 portable device designed solely for Twitter. Doing one thing and doing it well can actually be very useful. The original Peek Pronto designed solely for email was refreshing and innovative when it came to market in 2008. It was a sleek, low-cost version of smartphones that allowed people to access their emails on the go. Thanks to the success of the original Peek, TwitterPeek was released shortly after in 2009 receiving a much frostier reception.
What went wrong?
The main problem was that Twitter Peek was a product with no customer. The idea was the Twitter addicts without smartphones would have the perfect low-cost device. The two problems with this are:
- What Twitter addict doesn’t have a smartphone?
- In what world is $199 plus considered low-cost for something that just tweets?
There were also a few design flaws. The home screen only showed the first 20 characters of a tweet, with the user needing to tap twice — once to select the tweet, again to select ‘view tweet’. Users also reported problems with the browser, so tweets linking to websites became either useless or frustrating.
Naturally we’d assume that anyone who uses a device just for Twitter must be a pretty heavy user. Unfortunately if they stepped away from the device for a period of time and came back to it, Twitter Peek could only deliver the most recent 10 tweets, asking users to view the rest online, which would have to be done on a different device.
What can we learn?
- If you’re only going to do one thing, do it well. The V in MVP is pretty important.
- Customer research is everything. It’s unclear how much research was put into the Twitter Peek, but the history of this device just goes to show that it always pays off to know your customers!
- Look for Product Market Fit. Start by defining your Minimum Viable Customer who you can use as a focus group to start the feedback loop. You need to do this for every new product you plan to launch, instead of relying on customer insights from your previous product. They may be similar, but the smallest difference can make the biggest difference!
The Edison Machine by Theranos
Most of us have heard of Elizabeth Holmes and her infamous con. Spawning numerous articles, news featurettes, books, and documentaries, the promise of fast, cheap, lifesaving health tech proved too good to be true.
In brief, Holmes trained as an engineer before dropping out of college with little medical knowledge, using her tuition money to fund her consumer healthcare tech company. The Edison Machine was supposed to run a few blood tests using only one drop of blood, with Theranos offering a ‘menu’ of over 240 tests which could be ordered by the patient independently from their doctor. You could even give your loved one a Theranos gift card. Politicians and tech giants alike revered her as the next Steve Jobs, even the next Archimedes. The medical community who had actually completed their education…less so.
What went wrong?
What didn’t go wrong with this product?
Ex-employee and whistleblower, Tyler Shultz, went to the press stating that pieces of the machine would fall apart in your hands, technicians would find themselves exposed to used needles, and the results themselves were wildly unreliable.
With nothing but faulty machines and the Silicon Valley dream, Theranos placed Wellness centres in Walgreens, promising super-easy blood tests to customers using only a single drop of blood. In reality, they were using machines from other companies while waiting for the numerous issues with their own to be fixed, leaving customers wondering why their test felt exactly like a traditional blood test. “Fake it till you make it.”
The results given by the machine were also inaccurate, with some patients being told there were signs of their cancer returning, and others receiving false-negatives. It is hardly difficult to see why the situation quickly became dangerous.
Elizabeth Holmes was, at one point, the world’s youngest female self-made billionaire, and a focus point for the fall of Theranos. Her partner, Sunny Balwani, was famously quick to fire people who came to her stating problems with the technology, branding them non-believers. In meetings, conversation would move very quickly from ‘how do we fix this?’ to ‘what shall we name our cloud?’.
“The way Theranos is operating is like trying to build a bus while you’re driving the bus. Someone is going to get killed.”
John Carreyrou, Bad Blood: Secrets and Lies in a Silicon Valley Startup
What can we learn?
- Some knowledge can’t be faked. Sometimes it’s ok to admit that you don’t know something. New technologies and practices come about all the time, and some of them simply can’t be learned on the fly. You have to be taught. Seeking training is a smart move, not an admittance of weakness. Failing that we can surround ourselves with people who have the knowledge we lack, and listen to them. A key skill for PMs.
- Image is nothing without substance. Too much focus on how people talk about your company/product, and less on the quality of your offering is a recipe for disaster. You job is to make sure that the customer finds value in a product that fills their needs/solves their problems. Everything else comes second.
- Focus on the right things. Prioritization is a huge consideration for any PM. Learning how to do it well will save you many headaches further down the line.
- Listen to the things you don’t want to hear. Your engineers are not telling you that a feature won’t work because they want to upset you or derail the project. They care just as much as you do! Act on unpleasant news rather than ignore it.
Learning from Personal Failure
While there are plenty of lessons to learn from product failure, it’s incredibly unlikely that these failures rest on the shoulders of one person.
We asked our community on Facebook to share their most memorable failures, and more importantly what they learned from them, with us:
“Not validating a deliverable before delivering. I let the pressure to deliver quickly take over and told myself we didn’t have time to validate. This lead to reworking.
I always try to validate now in some form or another based on the size of the project.
Time spent early on validating with the team, focus groups or our users, means less time reworking down the line.”
“I was leading an implementation and as a very junior product manager I really struggled to realise that I was serving two senior stakeholders one of who I didn’t update as much as I could, I later realised she preferred regular updates. It was a chaotic experience and I wish I had more confidence in some of the direction I was trying to set, and used the BAs at my disposal more. What I learnt was that stakeholder management is a skill that is not to be played with and regardless of my position in the hierarchy I should have not shied away from setting the direction I knew was right.
It really broke my confidence but I’m now in a very safe team where my manager sees a lot of me in her — this is really pushing my confidence.”
“Making a product GA even though it didn’t meet release criteria at a major software company. From a business perspective it was the right thing to do, but I put my management in a horrible position. Luckily nothing happened! I learned to think about all impacted stakeholders before making big decisions and to be more patient with bureaucracy.”
“One time I tried to “help” during release crunch time by doing some of QA tasks myself. The two QA people went to their manager asking if they should start looking for new jobs since I’m trying to do theirs. Ouch! Lesson learned — always ask if if your help is needed and don’t make assumptions. It took a lot of apologizing to rectify that situation.”
“I’ve made mistakes not raising issues I see in other teams soon enough. At the time, our dev velocity was very low and I assumed engineering management would fix this. The result was we weren’t able to build product fast enough to meet market demands.”
“My first week as a PM, I panicked and made a promise to a stakeholder that I later had to walk back. Lesson learned: always get buy-in from all parties involved before committing to deliver!”
“I thought that as an early stage startup we wouldn’t need a 1 year roadmap as things would change very frequently but it turned out the entire team’s biggest concern was that we did not have any idea about the direction we were headed in.
I’ve learnt since then to make and maintain at least 3–6 month roadmap to show direction to the team.”
When was the last time you failed? Did you learn a valuable lesson? Share it with our Facebook community, where you’ll find 40,000+ likeminded product managers!
I’m Carlos González, CEO at Product School, and I enjoy sharing weekly tips for Product leaders!
Are you interested in Product Management? Check out our certifications here.
Looking for a good read? Because we’ve launched “Ship It” as a free resource.
This article was also published on The Product Management Blog.
