Deciding what to build

At a lot of companies, "deciding what to build" is a PM privately ranking a backlog and handing down the top of the list. That's not how it works here, and the difference follows directly from what product managers are for. The decision is the team's, made out of a shared understanding of users and the numbers. The PM's job is to make that understanding rich enough that the decision is close to obvious.

The inputs, not the authority

Good prioritization comes from holding a few things at once:

• What users actually need, from the standing habit of listening to them.
• How the product is doing, from the metrics and where they're pointing.
• Where the company is going, from the strategy and who we build for.

A team that genuinely holds those three rarely needs a ranking exercise to know what matters most. When the inputs are clear, the priority usually is too. When the team can't agree, it's almost always because one of the inputs is thin, and the fix is to go get it, not to escalate to whoever has the most authority.

Validate by building small

We don't try to prove an idea is right before we build it, because that mostly doesn't work. The cheapest way to test most ideas is to ship the smallest real version and watch, which is the whole argument in ship the smallest useful change. So "deciding what to build" is less about picking the one perfect bet and more about choosing the next small, reversible step that will teach us the most.

Mature products need different questions

A young product is asking "does anyone want this at all." A mature one is asking something else, and the prioritization changes to match. Here the useful questions are about deepening rather than proving: where are users hitting friction, what's quietly holding back retention or expansion, which rough edge would most repay polish, what complexity has accumulated that we could now remove.

Removing things belongs on this list. A feature nobody uses is a cost the whole team keeps paying, so cutting it is real work worth prioritizing, not cleanup you get to someday. The best thing to build is sometimes the thing to delete.

What we don't do

We don't build for internal alignment over user need: shipping something because it's easier to agree on than the thing that would actually help. We don't spend six months on a big feature before a user can touch any of it. And we don't treat the backlog as a promise. It's a list of maybes, weighed fresh against what we currently understand, not a queue we're obligated to work through in order.