Product Management

A roadmap that lists everything anyone asked for is a list, not a plan. Product work is deciding what comes next, writing down the reason, and being willing to defend it when the loudest customer asks about their feature.

The work starts with talking to the people who use the thing, which is where the difference between what customers request and what they need shows up. Requests arrive as solutions. The job is finding the problem behind them, because one problem often sits under five requests.

Then it is scope. Most features can ship at a third of the size and still settle the question they were meant to answer, and shipping the third teaches you whether the rest is worth building.

// what you get

What's included.

  • Customer and user interviews, with the findings written up rather than remembered
  • A prioritized roadmap with the reasoning recorded next to each decision
  • Specifications a developer can build from and a stakeholder can recognize
  • Scope work: the smallest version that answers the question the feature was asked to answer
  • Success measures agreed before the build, and checked after
  • Release planning and the communication that goes with it
// where it fits

The situations this is usually bought for.

A backlog of two hundred items

Nothing has been closed in a year because nothing has been decided. Grouping by underlying problem usually collapses it to a manageable number.

Features shipped and never used

Built because a customer asked, released without a measure, forgotten. Agreeing the measure first changes what gets built.

A founder who is the only product decision-maker

Fine at five people, a bottleneck at twenty. The work is making the decision criteria explicit enough that others can apply them.

Footprints crossing wet sand near the waterline
// say hello

Tell us what you are trying to fix.

Discovery calls are free and usually last 30 minutes. We listen first, and we will tell you honestly if product management is the wrong thing to spend money on.