4 Ways Confident Product Managers Deal With Failure
You have the greatest job in the world. You are a product manager. How many people get the opportunity to truly build something and champion a product to greatness? Each new day is an adventure.
There has never been a better time to lead product — if you are up to the challenge.
Every team from Engineering to Marketing depends on you. They are counting on your product leadership to set the vision for the product and keep shipping features that add value. The requests never end from customers, sales, and executives in your company — and you even keep an eye on the competitive landscape too.
It is a humbling moment when you realize you have helped build a great product and a loyal customer base. You never want to screw that up.
But even the best product managers fail at some point. Maybe you were a few weeks late on a release and you lost a big customer because of it, or perhaps you approved a new feature launch that was full of bugs and not ready for prime time.
Failure at some point in your product career is inevitable. When it happens, your first instinct may be to run and hide out rather than face your mistake. Or worse, maybe you are starting to point a finger at others. But you are better than that — and there is too much at stake.
Before I became CEO of Aha! I spent over 15 years leading cloud-based products at multiple technology companies. I understand how difficult leading product can be. I learned this lesson the hard way. I made mistakes. And I realized that when I did make a mistake — it never helped to wallow in a puddle of regret.
Here is what I did and how I suggest you pick yourself up and make your comeback with confidence:
Set realistic goals
You have a perfectionist streak that drives you toward excellence, but are you setting unrealistic goals for yourself and your team? The product manager must consider available resources as well as goals. Better to establish goals that your team can reasonably achieve within the release time-frame than to seriously overshoot and miss the mark. By all means, set stretch goals, but be realistic about what’s possible.
Stop over-analyzing
Self-introspection is a healthy habit for product managers, but it is easy to go overboard, especially when your teams are depending on you for strategy and vision. Quit overthinking about what happened. Get back to your plans. Let your strategy be your guide as you move forward and continue to be responsive to customers.
Accept blame
Great product managers take responsibility when things go wrong. Resist the temptation to point around the room, even if you know that someone dropped the ball. Take on the criticism for yourself. Your team will respect you and want to do a better job next time, especially if they know they played a role in the failure.
Embrace learning
Look at the failure objectively. Where did you and the team start to go wrong? Were you trying to pack in too many features that you could not deliver? Did you underestimate how long testing would take? Did you over-complicate what you were trying to do? When you figure out what went wrong, you can pay special attention to avoiding the same problems next time.
The product manager role is tough and often lacking in guidance. But remember — you are in this job for a good reason. It’s a privilege and you have proven that you are up for the task.
Not everyone can talk shop with engineering, help the sales team focus on selling value, and truly understand and communicate where the customer is coming from — all while being the champion of the product.
Your job requires mental toughness. That means that when failure threatens to beat you down, you must come back swinging.
How have you come back from failure?
__________________________________________________________________
ABOUT BRIAN AND AHA!
Brian seeks business and wilderness adventure. He has been the founder or early employee of six cloud-based software companies and is the CEO of Aha! -- the world's #1 product roadmap software. His last two companies were acquired by Aruba Networks [ARUN] and Citrix [CTXS].
Signup for a free trial of Aha! and see why 20,000+ users on the world's leading product and engineering teams trust Aha! to build brilliant product strategy and visual roadmaps.
We are rapidly growing and hiring. Product Marketing Manager. Rails Developers. Customer Success. Join a winning team -- work from anywhere in the US and be happy.
Global Product Manager at Ricoh Global Software
9 年Thanks for some excellent reminders !
TVA @ ClickUp
9 年Hi Brian, great article as always! Further: - Fail fast, faster. Failing is a part of doing new things. If what we're doing was easy or predictable, somebody else would have done it before. So work to introduce even _more_ opportunities to fail and learn. I know, sounds funny right? Here's one example: work in a handful of smaller improvements to your user acquisition funnel instead of redesigning the whole thing for the third time. One of those will have the required effect, but most importantly you're guaranteed to learn from all of the failed ones. - Work on gradual exposure Sometimes well... stuff happens. Work to introduce gates that limit the exposure of features to users. This can be done with process (dogfood, shipping in the app store in Ireland first) or by introducing feature flags (aka canary flags) in the software that are only enabled for specific accounts or customers. - Hold on to the kill switch We all know the deal. The unexpected happened, and customers are now stuck without access to something they use every day. Eg on mobile, I'm sure users hate it when they updated their favourite app just to find out it crashes on start. So work to always have the kill switch in your hands. Examples of this in mobile are: a way to reset the user's application server side, to turn on/off specific problematic areas server side, or a setting in preferences that resets the application to it's start state - Up, up, down, down, left, right, left, right, B, A, start Great coders learn to code 'defensively'. No this doesn't mean holding a sword while they crack on with writing code, it just means adding parameters to tweak and change the flow of execution depending on external configurations that have not necessarily been specified in the requirements. This for example means allowing a registry key to configure the refresh interval of the data in your application, even though the spec insists it's every 30 minutes. The point here for product managers is that opportunities like these exist at a feature level too. Work to introduce ways, by design, to change how users experience your application depending on external parameters. Bonus points if these are associated with cohorts and can be set server side. An example: on mobile, a secret tap in settings allows access to a menu that in turn allows support folks to recover the user out of a bad situation. Sounds complicated? tools like mixpanel allow a/b testing with cohorts on the server side with just a couple of lines of code. Hope this helps, RC
Policy Analyst and Project Management Extraordinaire
9 年Take responsibility for mistakes, even when you're not the only one responsible. Good point.