The bottleneck isn’t the PM, it’s who gets to decide

Andrew Ng, who co-founded Google Brain, says the bottleneck in software is now deciding what to build. Plenty of investors have taken the next step: so hire more product managers. When that argument reached r/ProductManagement, the top reply said the real bottleneck is decision rights, not the PM title. It got 240 upvotes from people who do the job every day.

Both are half right. The bottleneck has moved to deciding. But more product managers won’t clear it unless everyone knows who gets to make which decision. We learned that the hard way.

What went wrong for us

This summer, my cofounder Kathryn and I handed our developers a prototype of a new navigation for Grove and said “just build this,” a story I wrote about in our first post. The prototype left a lot of questions open, and we never said who would answer them. So our developer did. Every decision was reasonable, and many of them weren’t the ones we would have made. That wasn’t the developer’s failure. We had kept the decisions in our heads and never said whose they were.

Two weeks in, we stopped and split the work up. Kathryn owned the feature and the vision for the new navigation. The work shipped as twelve projects, each with one product lead making its decisions.

The lesson wasn’t that we needed more people deciding. Every decision needed exactly one owner, and everyone had to know who it was. Here’s how we split that up now. None of it depends on a tool.

Three layers, and who owns each

Most confusion about product roles comes from treating every product decision as the same kind of decision. There are three layers, and each has an owner.

Strategy. Which customers, which problems, which bets. The founder or head of product always owns this. At seed stage, about nine in ten heads of product report to the CEO, according to Pave’s data. That isn’t an accident of the org chart. The strategy is the company.

Features. A bigger effort: a new area of the product, with a vision for how the whole experience should work. Every feature ladders up to the strategy and has one owner, who sets its outcome and decides which projects it needs. That can be the founder or head of product, or a product lead. Size doesn’t decide it. Risk and capacity do: how close the feature sits to the company’s bets, how hard it would be to undo, and who has the context and the room to take it on.

Projects. One piece of a feature, small enough for a coding agent to build and ship on its own. Its product lead owns it end to end: the solution, the scope, the tradeoffs, the questions that come up during the build, and checking what shipped.

A lot of PMs believe they own the strategy for their area. They don’t. Even a PM who owns a whole feature is working inside bets someone else made, and that job is just as hard: find the best way to win the bet within those constraints.

One project, one product lead

Every project needs exactly one person who makes the detailed decisions. Not a committee, and not a rotating set of reviewers. One product lead, who decides most things and brings a decision up only when it would:

• change the outcome,
• cut against the strategy or a past decision,
• be hard to undo, or
• break a promise to customers.

Everything else, the lead decides. In late October, one of my projects raised the question of whether an outside agent, working on someone’s behalf, should be allowed to wipe a strategy document completely. I said yes. An agent should be able to do whatever the person it works for can do. That’s a two-minute decision. Once it’s settled, it goes into the plan, so whoever builds it reads the answer first.

The product lead doesn’t have to be a PM

The qualification for leading a project is customer context, not a job title. A customer success manager who hears the same complaint every week, an engineer who is the target user of what they’re building, a designer who has watched people struggle with a flow: each of them can lead a project well. Our developers lead the projects on Grove’s developer tools, because they’re the users. What used to stop people like them was the legwork around the decision: the write-up, the chasing, keeping the plan current, checking what came back.

The same goes for design. With a design system your team already trusts, the product lead can design most screens themselves, and someone more UX-minded reviews them. Without one, every project becomes a design project.

What to look for in a product lead

A good product lead, whatever their title, has these:

Deep empathy for customers. They get to the need underneath an ask instead of shipping whatever the first customer requested.

Systems thinking. They see how one change touches everything around it, before the build finds out the hard way.

Good instincts. They can make a call on judgment instead of researching every decision. Ng says his own teams increasingly rely on gut, because waiting a week for user feedback is too slow when the build takes a day.

They make hard decisions and hold them. If everything is a priority, nothing was decided.

Honest in every direction. They tell the founder when an idea is weak, and they can say “I was wrong.”

In the interview, ask them to walk you through a project they’re proud of, and keep pressing on the details. People who didn’t really drive the work can’t explain the tradeoffs.

So what’s the right PM-to-engineer ratio?

The old rule of thumb is one product manager for every six to ten engineers, and forecasts now put it at one to three, or even one to one. We think the ratio is the wrong unit. Count your bets: those stay with the founder or head of product. Count the projects in flight: each needs one product lead with customer context, and not every product lead needs to be a PM.

Hire a product manager when you have projects that need a lead and nobody with the customer context to lead them. Nikhyl Singhal estimates that about half of PMs mostly move information between layers. Don’t hire one to do that, because you’ll pay for a relay. Give them the outcomes, keep the strategy, and let them make the calls.

How we do it in Grove

Everything above works with a doc and whatever tools you already use. We built Grove around it, so here’s how it runs for us.

The project lives in Grove, and the build lives in the repo. The product lead owns the plan, its questions and its outcomes. Developers own how it’s built. Their coding agents read the plan from Grove, questions come back as threads, and pull requests are checked against the outcomes.

Questions come to the lead. Over two weeks in late October, three projects I led raised 27 questions, most from Grove’s plan check and the rest from our developers’ coding agents mid-build. I settled all 27, about half within the hour and all but one the same day.

Grove carries the legwork. It keeps the plan current, chases open questions, checks what came back and drafts screens in your own components. That’s why people without a PM title can lead projects here.

One person can lead a lot. As I write this, Kathryn, our CPO, leads 10 features and 41 projects that are being planned or built.