How to learn to deal better with uncertainty?

I love PM due to the excitement to work cross functionally, work with clients and engineers to build the right solution. I struggle however with uncertainty/issues/bugs/delays/angry customer and have very high personal standards on myself and others.

Is there a magical way to grow in PM and getting less absorbed by my discomfort? Thank you

4 Likes

This is worth talking about as it is at the core of product management.

Uncertainty.

Like, heaps of it.

Imagine a situation where you put together your roadmap, updated leadership and then delivered everything on time, under budget and met quality.

It sounds appealing but you’d probably be the worst PM I could ever imagine. How? Let’s think this through.

The only roadmap leadership would simply go along with would be the one they drafted. Yes, they should drive the strategy and vision but they lack the detail to know which exact initiatives would best drive that strategy. Maybe at a portfolio level yes, but not at the specific feature level.

You should be talking to customers and working with your triad to figure out ideas that are better than what the company assumed was best and that requires that you sell it in. This puts a big question mark on what you’re working on.

And maybe you then find out the better solution which looked small is actually huge. Management expects results this quarter and you’re going to have to convince them to double their investment for half the return.

And the only way the timelines just work out and your team hits every milestone is if you either aim low or overestimate work effort beyond what is reasonable (or both). So the plan will fall off the rails and you’ll have to pull a rabbit out of a hat to convince them you and the team aren’t incompetent.

So, i see that ambiguity as what the role is. If it wasn’t there, they probably wouldn’t need you. And if you didn’t set high standards for yourself you’d probably not push the team hard enough to find the best approach and get people over the line.

But it’s natural to feel daunted by this, it may not be your background (it wasn’t really mine). I’d focus on learning how to deal with these situations and make that your skill set.

The plan starts off with high expectations and your job is to keep the dream alive as the proverbial hits the fan.

Does this resonate? What do you think? I hope I’m not just telling you what you already know. It was an adjustment for me too!

3 Likes

Wonderful analysis and explanation @Naomi.

Here’s my piece of advice if you would like to take it positively.

Read Thinking, Fast and Slow and Thinking in Bets.

As a PM your job is to make good decisions at the earliest reasonable juncture. Every extra week spent collecting data is another week without product in the hands of your customers. There is always uncertainty - what if there’s another pandemic? What if there’s a financial crisis? What if your industry shifts dramatically? People usually refuse to accept these inherent risks and instead over-control small details.

Don’t focus so much on outcomes - they are driven by factors other than your decisions, and way too far down the road to provide good learning feedback. Focus on how you reach decisions, and when you hit a disappointing outcome, reflect on whether your decision-making process could reasonably be tweaked to avoid it. If you can constantly improve how you make decisions, you’ll become sooooo much more comfortable with yourself as a PM, and forgiving of mistakes.

Hope this helps.

2 Likes

I’d disagree to a certain extent. In Enterprise product management, there usually isn’t a negative impact of something releasing a sprint later than it would have if you’d have made a decision sooner, and there usually isn’t a positive impact of something releasing a sprint earlier than it would have if you’d have made a decision later, but usually there is a positive impact of gathering more certainty, within reason of course. Your clients already under contract aren’t going to leave if a new feature releases 2 weeks later then it could have been had you made a decision earlier. And any client in the later stages of contact discussions have probably already seen the new feature in a lower env or prototype mocks and they know it’s currently being developed.

You should always focus on outcomes of your decisions, that way you learn if your decision making is strong or flawed, and can learn what went wrong and how to fix it. Success isn’t measured simply on how fast you make decisions, it’s measured in successful outcomes.

2 Likes

Time spent confirming the same decisions you were already going to make so that you feel better is time not spent on building even more features for customers.

This attitude is part of why so many enterprise companies are so slow. It’s death by a thousand cuts. Obviously 2 weeks doesn’t matter, but stretching out work that doesn’t need to be prolonged because you can adds up over time and results in inferior products.

1 Like

I would once again disagree to a certain things.
First, you don’t know if it would be the same decision you would have already made once you got additional information.
Second, your statement about releasing features is why so many enterprise product have a glut of useless features that only a couple clients actively use. Features factories are stupid. I think…

1 Like

No. Uncertainty is part of real life. You literally cannot predict the future, you can only set guard rails to help you deal with certain scenarios.