Home / Guides / Product Management
// The guide · Pillar 03

Product Management

A board full of tickets, ordered by whoever escalated hardest, shipped steadily, and measured by "did it go out?" — that's a feature factory with a stand-up. Product management is deciding what's worth building and knowing whether it worked. This guide is how to get there.

Pairs with the Product Management Maturity check · ~10 min read · slides (.pptx)

Haven't taken the check yet? Do that first — 14 questions, about four minutes. It scores you on the three areas below and tells you which one to fix first. Already have your result? Jump to your weakest area: Roadmap · Prioritisation · Product ownership.

01The model

Three things decide whether the product lands. A great roadmap with no method is a wish list; a tight method with no ownership optimises the wrong things, precisely.

01Roadmap — outcomes not features, adaptive when reality shifts, a vision the team can repeat.
02Prioritisation — a consistent, evidence-led method — and the ability to say no to a stakeholder.
03Product ownership — someone owns the problem, not the ticket. Discovery happens; misses get reviewed.

The check scores each and gives a combined grade. The engagement, in a sentence: find the weak one and fix it first.

02Roadmap

A roadmap is a list of outcomes — features are options for getting there. The test: can the team state where the product is going and why, without the slide?

What good looks like
  • It's a list of outcomes — features are options for getting there.
  • Confidence decreases the further out you look. Nobody pretends month nine is fixed.
  • The team can state the vision — where this goes and why — without the slide.
  • It's revised on a cadence, deliberately, not when someone panics.
  • One person owns it, and is trusted to decide.
Common failure
  • Roadmap as a promise — dated commitments that reality keeps breaking.
  • Feature factory — steady output, no line back to an outcome.
  • No repeatable vision — everyone would describe the direction differently.
Your first move
If you're just starting

Start with the outcome, not the feature list. Write a one-line product vision the team can repeat, tie the next few roadmap items to a business outcome each, and give one person the mandate to own the roadmap. A dated feature list is a plan to be wrong on schedule.

If it's partly there

The roadmap exists — now make it honest. Shift it from features to outcomes (features become options), decrease the confidence you signal further out, and revise it on a deliberate cadence rather than when someone panics.

If it's already strong

Protect the vision as headcount grows, keep confidence decreasing with time horizon, and don't let a stakeholder quietly turn it back into a feature list.

Go deeper

  • Rewrite the top of the roadmap as outcome statements (“reduce onboarding drop-off”), with candidate features listed underneath as options.
  • Draw the roadmap in three confidence bands — now / next / later — and stop putting dates on “later”.
  • Put a standing monthly slot on the calendar to revise it, so change is routine rather than a fire drill.

03Prioritisation

Prioritisation is having a method the team trusts more than the loudest voice. The point isn't the formula — it's a defensible reason to say no.

What good looks like
  • One lightweight method — value, cost, confidence, or cost-of-delay — applied out loud.
  • Real evidence in the call: usage, value, effort — not just gut and volume.
  • The cost of delay and the cost of building the wrong thing both count.
  • The team can say no to a stakeholder — with a reason — and it's expected.
Common failure
  • HiPPO priorities — the highest-paid person's opinion wins the backlog.
  • Method on paper — a framework exists; the real calls ignore it.
  • Volume beats value — whatever has the most tickets gets built.
Your first move
If you're just starting

Pick a lightweight method (value / cost / confidence, or cost-of-delay) and apply it out loud for a month. The point isn't the formula — it's having a defensible reason to say no.

If it's partly there

A method exists but isn't consistently used. Make it the default for every "what's next" call, bring real evidence — usage, value, cost — into it, and start weighing the cost of delay, not just the cost of building.

If it's already strong

Keep the evidence current, keep pruning stale backlog items, and watch for the method getting overridden "just this once" under executive pressure.

Go deeper

  • Score the next ten backlog items with the method in a shared doc, in the meeting, so the reasoning is visible.
  • Add a “cost of delay” line to each — what it costs per month to not have this — and let it reorder the list.
  • When a stakeholder ask jumps the queue, write down why. Three of those tell you whether the method is real.

04Product ownership

Ownership is someone on the hook for the problem behind an initiative, not the ticket — and a habit of checking whether shipped work moved the needle.

What good looks like
  • A named owner for the problem behind each initiative — accountable for the outcome.
  • You look at real usage or talk to users before committing to a build.
  • When something ships and misses, you review it — and sometimes kill or pivot.
  • “Done” means the outcome the work was for — not that it merged.
Common failure
  • No discovery — build first, find out if anyone wanted it later.
  • “Done” means shipped — nobody checks whether it moved the needle.
  • Owner of the ticket — accountability for delivery, not for the result.
Your first move
If you're just starting

Name an owner for the problem behind each significant initiative — accountable for the outcome, not the ticket. Do at least light discovery before committing to build, and when something ships and misses, review it instead of moving on.

If it's partly there

Ownership and discovery happen for the big bets — extend the habit down. Make "did it move the needle?" a standing question after every meaningful release, and give owners the mandate to kill or pivot.

If it's already strong

Keep discovery routine rather than reserved for big bets, keep the review-and-kill discipline, and keep "done" meaning the outcome — it's the first thing to slip back to "shipped" under delivery pressure.

Go deeper

  • For each live initiative, write the problem statement and the name of the person accountable for solving it.
  • Add a one-week discovery step before build for anything above a set size — five user conversations or a usage pull.
  • Put a 15-minute “did it work?” review 4–6 weeks after each meaningful release, feeding the next priorities.

05Do this in the next two weeks

  • Take (or retake) the maturity check and note which of roadmap, prioritisation or ownership scored lowest.
  • For roadmap: write the one-line vision, and convert the top three roadmap items into outcome statements.
  • For prioritisation: pick one lightweight method and score the next ten backlog items with it, out loud.
  • For ownership: name the accountable person for each live initiative, and add a discovery step before build.
  • Schedule a "did it work?" review for the last meaningful release.
  • Pick the single weakest area, put a named owner and a date on its first move, leave the other two as "next".

Still stuck?

If the weak area won't move — the roadmap keeps reverting to a feature list, priorities keep going to whoever shouts, nobody quite owns the why — that's the point to bring Jon in. A short look at the roadmap, the backlog, and how priority calls really get made, then the specific move: a roadmapping clinic, a prioritisation method, or a fractional product hand.

How Jon helps → Start a conversation

Related