What are the most important rules of product management?

Solve the problem rather than the request, own decisions rather than delivery, treat every feature as a bet against something else, and measure impact rather than activity. Underneath all of them is one skill: deciding what not to build. If everything is a priority, nothing is.

Why is product management harder now that building is faster?

When building gets cheaper, the costly mistake shifts from building slowly to building the wrong thing quickly. AI tools speed up delivery, but they don't decide what matters. That makes a product manager's judgement about problems, priorities and trade-offs worth more, not less.

Do product managers own delivery or decisions?

Decisions. Delivery belongs to the team building the product. The product manager's job is making sure the right decisions get made, clearly and by a named owner, so the team isn't left waiting on a call nobody holds.

What is a kill condition in product management?

A kill condition is the evidence that would make you stop working on a feature, written down before the work starts. Setting it in advance stops a team from defending a bet just because time has already gone into it. It turns "should we keep going?" into a check against something agreed.

How do you decide what not to build?

Treat every feature as a bet against something else and ask what it displaces. Put the customer value in one sentence, and drop anything that's hard to explain. Removing one roadmap item every planning cycle builds the habit, because a roadmap is shaped as much by what you leave off as by what you keep.

What does measure impact, not activity mean?

It means judging work by the change it creates for customers, not by how much was shipped. Activity is features launched, tickets closed and releases out. Impact is the behaviour or number that moved because of that work, which is the only proof it worked.

The 16 essential rules of product management

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

Two-panel comic: friendly robots build at warp speed on a conveyor under 'Building got faster.', then cartoon Nicola stands at a fork in the road with a map while the robots wait, under 'Deciding what matters didn't.'

Building got faster. Deciding what matters didn't.

That gap changes the economics of the job. The cheaper it gets to build, the more your judgement is worth, because the expensive mistake is no longer building slowly. It's building the wrong thing quickly. AI tools made the building part faster. They did nothing for the deciding part.

The product managers I see winning are masters of choosing the right problems, quickest to kill the feature early, and excellent at getting people aligned around value. These 16 rules are the ground under those three habits. They're grouped into six themes below, with a practical habit for each.

Solve the problem, not the request

The default is to ship what was asked for. The request is specific, it has a sponsor, and delivering it feels like progress.

Rule 0 says stop shipping and start solving. Rule 1 says stop building what customers ask for. Customers describe the fix they can imagine, which is rarely the best one available. Rule 6 explains why: customers don't hire features, they hire outcomes. The feature is only the means.

Rule 9 is the test. If you can't explain the customer value in one sentence, you don't understand it yet. The habit: put the customer value in one sentence before anything gets scoped. If it's hard to explain, it's usually hard to justify.

A request tells you where the pain is. It rarely tells you what to build.

Own the decision, not the delivery

The default is to measure a product manager by what the team delivers. Tickets closed, dates hit, releases out.

Rule 2 turns that around: product managers own decisions, not delivery. Delivery belongs to the team. The product manager's job is making sure the right things get decided, clearly, by the right person. Rule 11 adds that influence is your unfair advantage, so use it. You rarely have authority over the people who build, fund or sell the product. Influence is how decisions get made anyway.

Rule 15 finishes the theme: great products come from empowered teams, not approval chains. Every approval step is a place where a decision waits. The habit: make it clear who owns the decision, not just the delivery. Teams move faster when the call has an owner.

The call needs a name on it. Otherwise it waits.

Every feature is a bet against something else

Whiteboard drawing of a slip pinned over a spec reading 'write the kill condition before the spec', above the line 'A list with no losers is a list, not a choice.'

The trap is treating each feature on its own merits. Looked at alone, almost everything seems worth doing.

Rule 3 says every feature is a bet against something else. The time spent on one thing is time not spent on another, so every yes carries a hidden cost. Rule 10 names the hard part: the hardest decision is what not to build. Rule 12 says what happens when nobody makes it: if everything is a priority, nothing is.

The habit: write the kill condition before the spec. Decide what evidence would make you stop, before you start. A bet with no exit is just a commitment you haven't admitted to yet.

Choosing is the job. A list with no losers is a list, not a choice.

The roadmap is a strategy, not a shopping list

Comic headed 'a strategy, not a shopping list': stakeholders pile boxes into an overflowing trolley pushed by a frazzled colleague, while cartoon Nicola calmly holds one short list and a pair of scissors beside the caption 'A plan that cuts nothing hasn't chosen anything.'

The default roadmap collects requests. Each stakeholder gets something, the quarter fills up, and the document reads like a plan while deciding very little.

Rule 4 says your roadmap is a strategy, not a shopping list. Rule 5 goes further: the best roadmap item is often the one you remove. Taking something off frees the team for the work that matters and tells everyone what the priority really is.

The habit: remove one roadmap item every planning cycle. A roadmap is shaped as much by what you leave off as what you keep.

A plan that cuts nothing hasn't chosen anything.

Learn faster, with evidence

The trap is spending months building on an assumption nobody checked, then defending it because of the time already spent.

Rule 7 says your job is to learn faster than everyone else. Rule 8 says validate assumptions before you waste months. Rule 13 settles the argument: evidence beats opinions. Always. When a decision is contested, the fastest way through is usually to go and find out, not to debate louder.

The kill condition from earlier helps here too. If you wrote down what would make you stop, the evidence has something to be measured against.

Speed of learning is the advantage. Speed of building alone is not.

Measure impact, not activity

Whiteboard split in two: a stack of ticked shipped boxes captioned 'Output proves you were busy.' beside a happy stick figure zooming on a scooter captioned 'Outcomes prove it worked.'

The default is to report what shipped. It's visible, countable and easy to celebrate.

Rule 14 says measure impact, not activity. Output proves you were busy. Outcomes prove it worked. A launch is the cost of the bet, not the result. The result is the change in what customers do.

The habit: track the behaviour you wanted to change, not the features you shipped.

Busy is easy to prove. Impact is the only thing worth proving.

Judgement is what compounds

Read the 16 rules together and they describe one skill: choosing well. Choose the problem over the request. Choose who owns the call. Choose what to bet on and what to drop. Choose evidence over opinion. Choose impact over activity.

The tools will keep changing. Building will keep getting cheaper. The judgement behind your decisions is what compounds, and it's the part of the job no tool does for you.

Download the one-page version and keep it where you plan.

Questions people ask

What are the most important rules of product management?: Solve the problem rather than the request, own decisions rather than delivery, treat every feature as a bet against something else, and measure impact rather than activity. Underneath all of them is one skill: deciding what not to build. If everything is a priority, nothing is.
Why is product management harder now that building is faster?: When building gets cheaper, the costly mistake shifts from building slowly to building the wrong thing quickly. AI tools speed up delivery, but they don't decide what matters. That makes a product manager's judgement about problems, priorities and trade-offs worth more, not less.
Do product managers own delivery or decisions?: Decisions. Delivery belongs to the team building the product. The product manager's job is making sure the right decisions get made, clearly and by a named owner, so the team isn't left waiting on a call nobody holds.
What is a kill condition in product management?: A kill condition is the evidence that would make you stop working on a feature, written down before the work starts. Setting it in advance stops a team from defending a bet just because time has already gone into it. It turns "should we keep going?" into a check against something agreed.
How do you decide what not to build?: Treat every feature as a bet against something else and ask what it displaces. Put the customer value in one sentence, and drop anything that's hard to explain. Removing one roadmap item every planning cycle builds the habit, because a roadmap is shaped as much by what you leave off as by what you keep.
What does measure impact, not activity mean?: It means judging work by the change it creates for customers, not by how much was shipped. Activity is features launched, tickets closed and releases out. Impact is the behaviour or number that moved because of that work, which is the only proof it worked.