Product Managers: Delivering vs. Gatekeeping vs. Orchestrating

Like any function in a growth stage Product company, the product team frequently needs to wear multiple hats until growing revenue allows for a more scale. Despite this being a reality, product managers can get stuck and never get to their real mission of orchestrating product success.

Let's look at a couple common modes that many product managers can never escape:

Delivering: In this affliction, the Product Manager is seen (and sees itself) as running delivery of development output. However running delivery of development output is a full time endeavor which means that the Product Manager isn't doing effective Product Management (see below for what this is!). And because Product isn't "doing Product", what ends up happening is that they deliver endless "feature factory" releases that create the illusion of progress but go nowhere.

Gatekeeping: In this misapplication of Product Management, someone else is responsible for development delivery as a whole (such as an engineering lead, a scrum master, agile project manager, or release manager) but Product is seen (and sees itself) as the gatekeeper to access development capacity (Gandalf: "you shall not pass!"). Same result as above, when the Product Manager is Pidgeon-holed into gatekeeping, they aren't doing all the aspects of Product Management that allows them to actually manage the product. They just robotically reply "Yes we have the capacity to take on that next project you want" or "No, we don't have the capacity at this time".

Either/both of the above result in the Product Manager being little more than what SVPG calls a "Backlog Administrator"... taking orders from the rest of the organization with little ability to question or add value to prioritization.

So if these are regrettably common roles which end in failure, what is the right role for a Product Manager?

Orchestrating: Effective Product Management means orchestrating an ongoing process of how the company sets a product vision, crafting ongoing roadmaps that move the product toward that vision, grooming a backlog that applies the direction agreed upon in the roadmap, meeting directly with customers/prospects to understand their problems to solve, constantly aligning and realigning with stakeholders, building trust based relationships with all adjacent functions, quantifiably measuring product success metrics, etc.

If you know your product team isn't doing this role, your next thought might be "we just don't have the luxury for that product expertise right now". I'd say that reaction is completely understandable since budgets are always tight but then my recommendation would be to get creative with how to fund this using the existing Product Development investment. Put differently, while the clear ideal is to build the "right things quickly", when forced with a choice, I'd rather build the right things more slowly than the wrong things quickly...