Prioritization and Scoping

Field notes on deciding what to build and how much of it. Distilled from working as a PM at an early-stage startup.

Go one step deeper than the pain point

Identifying a pain point and ranking it is table stakes. The real work is going one level deeper: map the exact workflow the user goes through, and ask what system should sit where. Don’t just say “checkout is painful” — trace each step, and decide which piece of the product (or which new piece) owns the fix.

One feature per page

A workable structure for breaking down problems (and for vibe-coding them later): a table view where each row/page is one feature, and each feature carries its own:

  • SPP (steps / problems / pain — see SPP-Model)
  • pain points
  • open questions
  • iterations

This keeps features atomic and makes it obvious what’s actually being decided.

Guardrails

Put guardrails on every effort — time and UX. A time guardrail stops a feature from quietly eating a month; a UX guardrail stops it from shipping something that technically works but feels wrong. Decide the guardrails before you start, not when you’re already over.

Build first, then iterate

Great PMs build first, then iterate on customer feedback. Shipping something real generates better signal than another round of speculation. Pair this with customer-request vs. opinionated: build what customers ask for, but hold an opinion — you’re not an order-taker.

Run in cycles

Features run well in fixed 4-week cycles: enough time to ship something meaningful, short enough to force scope discipline and create a natural re-prioritization beat.

End every meeting with a clear set of directions

A discovery or planning meeting that ends without explicit next-steps was half a meeting. Close with: who does what, by when, and what we decided.

The product person is the bottleneck and the enabler

Deciding what gets built is a single point everything flows through. That’s a risk (you can stall the team) and a superpower (you set direction). Scope ahead and decide fast so you stay the enabler.