Product managers make all the decisions… right?

Around 10 years ago when I fell into product management, I thought it was my job to decide everything.

There would be a line at my desk with questions that my team had for me. I was answering questions about what to build, how to build, who to build it for.

I thought that this must be proof that I was doing an amazing job… right!? Wrong!. Everything was waiting for me. I wasn’t the superstar juggling everything, I was the bottleneck.

And, as things got overwhelming, I was no longer spending time on the important questions — why are we doing what we are doing? what happens next? how do we win? what’s our north star? Instead, I was in the weeds… all the time.

At this stage of my career, I recall sitting down with my manager at the time. You know those 1–1’s have with your manager where they look like they’re listening but they’re not? Yeah, this was one of them. After ranting about all the things I had on my plate she said: “You know, Sherif, I think you need to make more time on more strategic things”.

I just couldn’t picture it. What kind of product manager has all the time in the world to think of strategy?! This person surely doesn’t exist.

You don’t own making all the decisions, but you do own decision making velocity

As product managers, it’s easy to get stuck in making all the decisions. The questions keep coming in and it can feel great to help move your team forward by making the decisions, but they quickly pile up and leave you with no time to consider the bigger picture.

We need to switch our mindset about decision making — instead of owning all the decisions, we should own the velocity of decision making.

Now there are lots of decision-making frameworks such as Amazon’s famous one/two-way door framework or the tree framework. They can all be helpful in making better decisions. But what’s one thing we can do to improve the velocity of decision making for everyone in the team?

If there is one thing that I’ve seen that works consistently, it’s this: Shared understanding massively multiplies decision-making velocity. Instead of making the decision yourself, take the time to develop your whole team’s understanding of the customer, the vision, and the strategy of your product.”

It’s worth noting here, it’s not just the decision making activity, it’s a lot of things about the product craft — everything from maintaining the roadmap, breaking down a problem to owning your backlog.

As a product manager who works for Atlassian, I’ve interviewed a lot of customers (who are also product managers) and I’m always mind-blown at the number of hours product managers spend on things like the Jira backlog. So here we go:

Product managers, stay away from your backlogs!

Let me be very clear: this is not because you’re more important than the rest of the team, but because if you spent that time helping your team build a shared brain you can empower everyone else. Your team will be able to take on the day-to-day work themselves and make faster decisions.

So how do you build a shared understanding?

This is where your toolbox of plays, frameworks and practices that most of you will build over the years help. Things like customer research, concept exploration, interviews, data analysis, experimentation and so on. The important thing here is that you’re doing these things as a team, never by yourself.

As a simple example, it’s a personal policy of mine never to do customer research by myself. Try to take as much of the team with you to these activities. Every time you do, team members will have more context, build more empathy for the customer and, most importantly, be empowered to take on decisions themselves.

How do you know when you’ve reached a shared understanding?

I don’t know if we ever do — there is always more we can be doing to learn. But what you can do as a product manager is to identify where your gaps are, and then work on improving everyone’s knowledge. We’ve created a simple framework to help you get started. It revolves around asking your team three simple questions around the who, what and most importantly, the why. ➡ Try the framework here.

Shared understanding: it’s hard to do. Instead of taking the next decision, pause for a moment and ask yourself what context did you have that your team didn’t? Then work on building that shared knowledge. The reward is often deferred. But I can assure you every time you do, it will payback in long-run. After all, building a great product is a team sport.

This blog is based on my Mind the Product talk “Popular misconceptions of the Product Craft”.