Product management · Entrepreneurship

As a product manager, how do you deal with failure?


July 29th, 2015

Much like being a founder, the product manager role is one where you require mental toughness. You're constantly making big decisions and your colleagues and customers are counting on you. No matter how great of a product manager you are, it's inevitable that you're going to experience failure at some point

My CEO put together this post which discusses failure and ways to handle it so that you can pick yourself up and come back with confidence.

What are some lessons that you've experienced when you've failed in the past?  What are your suggestions for the best ways to deal with failure?

Logan Kleier

July 29th, 2015

I have two suggestions on how to deal with failure:

1) Forgive yourself 
We are human. Mistakes are inevitable. The important part is to not fall into the "downward spiral" where you obsess over the mistake or compound the mistake by not learning from it and moving on. 

It's also important to understand that mistakes are not reflection on your self-worth or "smartness". It's more productive to think that a mistake is a function of lacking the skills to know better. Skills can be taught and the mistake avoided in the future. 

2) Understand not all mistakes are equal
Some mistakes require more debrief time to understand why they happened. Figure out which mistakes are the "big" one that require more reflection and learning. 

3) Ask for help
Swallow your pride and ask others for help on how they would avoid the mistake you made. Don't spend all your time trying to DIY your mistake resolution. Others have made the same mistake and you can learn from them. Find someone you trust and just ask for help. 

Diego Fiorentin

July 29th, 2015

1- I review the decisions I took and evaluate why I took them.
If I made a good decision given the information I had available at the moment I would rest in peace.

2- I think how can I improve, learning form the mistake made. Each failure is an opportunity to improve and grow stronger. 

3- Products EVOLVE! 
I have Engineering background, meaning that in my mind, everything is a sub set of components that can be crafted and aligned to create something bigger. however my wife (who is a doctor) teaches me that some things evolve, meaning that you have to let them grow, make mistakes, and cannot be speed up.

4- Be patient, and dont try to make it up
if you made a mistake, face it and adapt to it. you wont be able to make up for the lost time.

Peter Baltaxe Consultant, product leader, serial entrepreneur

July 29th, 2015

If you are following lean startup principles and using agile development, there shouldn't be big failures.  You test a hypothesis, e.g. "people are going to love this feature."  If the hypothesis is incorrect, you haven't "failed", you have learned more about your customer and how they want to use your product.  Ideally you did that without investing engineering resources actually building it, because you showed customers mockups, etc.

On the other hand, if you pound that table and say "my gut tells me that search is the future of this product and this company and we're are going to spend 6 months building the best darn search feature and back it with a big marketing campaign," and it flops; then you have failed to use lean and agile, etc.  And you should go back and read some books, blogs, etc.

All that said, there are lots of ways to fail outside of product decisions.  You hired the wrong person, you didn't motivate the engineering team enough to hit the goal, you didn't plan far enough ahead with the marketing department, you invested engineering resources in advance of a partnership that didn't materialize, and so on.  There is always more to learn from the failures than the successes.  So take that approach: understand the root cause, be objective, and focus on what you can learn from it.

Mike Rozlog Advisor at TechColumbus

July 29th, 2015

I always keep in mind that Failure is subjective, just as success is.  I feel this way with many things... including development and product management and marketing.  Many times we are trying to reinvent the wheel, we ask developers for instance to create something that has not been created (maybe parts have) and then we apply a date for when they are supposed to create magic.  They miss the date and they have failed... really?  PM's look at the available information, isolate a feature that will separate their product from the pack and after it is shipped the feature means nothing, or customers did not see the value, we label it a failure.  PMM(s) come up with a great GTM message, it has been tested, looks great, but the product does not connect with the general public or sell, the PMM(s) GTM was a failure.

Anybody that has been in a startup knows, we all make our best estimates / guesses on the information we have and how we perceive that information as it pertains to the market and our products.

I've used this to explain "failure" a few times, maybe it will sound right.  Think of all the MP3 players on the market when Apple joined the market... all the other products became failures to some extent.  Why did X company, not know about Apple?  Why did the next rev not address what Apple was doing?  To this day there were great MP3 players with tons more features, better capabilities, and a better price point... but the market did not care, it wanted Apple.  That made the apple people winners and everybody else failures.  I don't think that is right, there was a market shift, and the Developers, PMs, and PMMs did not stand a chance and no real strategy has worked since that shift when it comes to MP3 players.  So in the end, there are a lot of things that have to go right to have success and very little has to go wrong to have a failure.  However, that is the life we picked (I would not want it any other way) and it is always fun trying to figure out what we don't know, we don't know... 

Murali Neelameghan creating hethi-digital business process platforms & RPA

January 2nd, 2016

Xtream will be helpful.In the current process we went beyond agile and modeled an XP and named it as ABS (yes, Anti break locking system as a  model)

Very short code 2 days, integrate 3 days helps you fail more than 60% in each minute steps to recover

I suggest to start with a failure - Test Driven Development