PMs make tons of decisions, they are sure to make mistakes, and the difference between good PMs and great PMs is if they show vulnerability and take accountability?
I am about to tell you about one of the darkest periods in my career. There are usually two reasons to pull a feature out of a release. One is of pure Engineering perspective – code quality issues or even a security vulnerability that has to be dealt with. On the PM side, there are many reasons to pull features out, usually revolving around feature completeness and market fit.
Vulnerability and Accountability
Tying Back to the PM Role Basics
Enabling Risk Taking in the Days of Agile
We live in times where so many companies are using Agile methodologies to research, to find out the right thing. “Fail soon, succeed sooner” (or another version of it) is one of the slogans used by Agile consultants and coaches. PMs actually aren’t future-teller-wizards, and some of their decisions will reach fail. Aren’t we pulling away from innovation by requiring so much accountability? Haven’t we killed creativity by asking for accountability? Aren’t we putting the PM in a place where they will be afraid to take creative, innovative, risky decisions?
We’re not. We’re actually enabling creativity by ensuring that things will be tried out when it makes sense and it is reasonable. Investigating a specific route for a product or a feature must be along a path of benefits. A Product Manager must be able to say something like “I have decided route A instead of route B because route A costs less and BELIEVED to deliver better results”. Agile was never created to try crazy ideas that would never work, and Product Managers are part of the control mechanism to ensure it will never go that way. Hey – there’s a reason why a “Product Manager” has the word “Manager” in their title!
Is it OK to Fail?
In the journey between good PMs to great PMs, there’s the point of showing accountability and vulnerability. PMs should be spending the time to run a post-mortem, prep seriously for those retrospectives. PMs should stop using the “but that’s what Agile is all about” phrase when asked about a feature that isn’t delivering to its expectations. Failure because of an calculated risk-taking is not the same as a failure because of “sounds right, let’s try it”.
The tech space is full of people with room-filling egos. Such people usually can tell you war stories only about their successes, never about a failure. These people are toxic and you should get away from them. If they are in your management chain, you should be concerned.
Identifying Vulnerability-ness Early On
I always ask “tell me about a giant mistake you made” when I interview. “Such a mistake that make you really feel physical pain when you talk about it”. I also tell them that it could be a professional or a personal mistake, as they see fit. Applicants give different types of responses and I use their response as a touchstone – are they made from the right type of PM material? If an interviewee gives me a dismissing answer, or “can’t remember such a situation”, or if they pick something small and meaningless, they are probably not.
On the other side of the scale, I had an interviewee once asking to turn off the video during an interview. The vulnerable person on the other side of the video call had tears in their eyes. They were talking about putting their career in front of personal life, not spending enough time with their dying dad.
It is ok to be vulnerable even in a professional setting. It is perfectly fine to say “I frankly don’t know, I’ll have to think about it and get back with an answer”. A good answer might also be “this is something that we would need to research in order to find the answer”. It is also fine to say “I don’t know the answer but I think that the risk here is low enough to make an educated guess”. Anything but “yeah, sounds right” with nothing to back this up.
Strong Decision-Makers vs. Laggards
In a Business Insider article about the most important manager traits found by Google, the last trait is “Be a strong decision-maker”:
The alternative is indecision, which paralyzes an organization, creates doubt, uncertainty, lack of focus, and even resentment. Strong decisions come from a strong sense of self-confidence and belief that a decision, even if proved wrong, is better than none.
Not always you have all of the required information to make a decision, and in that point in time a Product Management should first decide how much risk is there in a bad decision. If there isn’t much, go ahead, experiment. If you do believe that the wrong decision might lead to a devestatious result, you might want to gather more information. A word of caution is suitable here: if you feel yourself leaning towards “insufficient data coming through” too often, ask yourself – are you too afraid to take risks? It might be an organizational issue if your organization or management doesn’t allow you to make mistakes. It might be a personal fear of yourself which you have to take care of. Don’t be the laggard of the organization, slowing down the entire organization by getting everyone to “analysis-paralysis” state.
Think differently? You’re in agreement? Don’t be stranger – leave your thoughts in the comments below!
