I used to believe that effective prioritization is the hardest part about being a product manager. I don’t think that’s true any more. I now believe the hardest part about being a PM is that there is no way to shorten the time and dedication it takes to become your product and its industry’s most knowledgeable and empathic expert.

But I kind of skipped over some things there. Let’s step back a bit.

Realization 1: it’s not about prioritization

If you put a bunch of product managers in a room it won’t take long for them to start talking about their favorite prioritization methods. And you’ll find me in that conversation as well¹. But after working on a fairly small team for over three years, I realize that I’ve been stressing out about prioritization too much.

First, when you’re on a small team there are only so many things you can work on in a (let’s say) 12-week period. In fact, you can do one or two big things, and maybe a couple of smaller ones.

Second, when you can only work on a very limited number of things — and provided your team is engaged in customer and business insights — the most important problems to work on are felt, not calculated. I truly mean that. When we go into planning for a new period of work we keep our business goals close, and the projects we need to work on to deliver on those business goals are in our bones. We talk about it, and debate specifics and implementation details. But when it comes to the problems we need to solve there is very little disagreement.

There’s a caveat: even though the “big rocks” of what we need to work on are well known, the tiny pebbles are not, and that’s where prioritization comes in. Figuring out which bugs to fix, which small annoyances to focus on, which tasks to work on to fill in the time gaps — that takes a lot of work, and that’s where prioritization frameworks can be extremely important and useful. But again, if you’re a small team, you’re not going to have a lot of time for those smaller things, and even then the most important “small tasks” are easy to spot too.

So that’s my first realization: product managers make too big a deal out of the importance of prioritization. Usually the biggest problems to solve are well known, and not in need of constant calculation, mapping, and scoring.

Realization 2: but it is about stewardship

My second realization is this: the hardest thing about being a product manager is that there are no shortcuts to gaining the knowledge and experience we need to be effective stewards of our products. Getting steeped in a product’s functionality, uses, customers, industries, tangential industries, business ebb and flows… those things can’t be rushed. Maybe part of the reason so many product managers feel “crazy-busy” is that they are trying too hard to take shortcuts in this regard.

What does it mean?

I think these two realizations are related. We rely so heavily on prioritization frameworks when we haven’t taken the time to inhabit our products in a way that will give us confidence in the problems we instinctively know that we need to address. There’s obviously an organizational aspect as well — with buy-in, trust, and all the complications around that. But when we become true stewards of our products — steering our teams with care and empathy — not only will we find ourselves in a more relaxed state, we’ll also have more time to solve the problems we focus on and improve our product through the feedback we get from customers.

So I guess if there’s some learnings or advice out of this, it’s simply that the most important thing we can do for our product, our customers, and our business, is to do the work that it requires to become product stewards (that is, “the careful and responsible management of something entrusted to one’s care”) as opposed to just product managers. Instead of relying on short-term crutches like business canvases and prioritization frameworks, let’s take the time it requires to get to know our product, the market, and our business inside and out. It will make every single part of our job easier.