Product management

Play this lesson

Who decides what we build?

Hyper Shards has hundreds of requests on Discord: co-op, a photo mode, new ships, harder bosses. The numbers say something else: many new players quit in wave 3. The team can build maybe two things this month. Which two?

In bigger studios this is the job of a product manager (PM). A common way to say it: the PM owns the what and the why (which problem we solve next, why it matters, what success looks like), and designers and developers own the how. A PM isn't the team's boss. Their power is evidence.

Discovery, then delivery

Marty Cagan, a well-known product leader, splits product work in two. Discovery is figuring out what to build: is the problem real, and will our idea really solve it? Delivery is building it properly and shipping it.

Discovery is fast and cheap: read player feedback, look at the data, watch playtests, ask players questions, and test sketches or rough prototypes. Cagan warns that building a full release just to test an idea is an expensive way to prototype.

One rule above all: problem first. Players ask for solutions. The PM digs for the problem behind them.

Player message

#feedback, @starpilot
Please add a shield button!! The wave 3 lasers come out of nowhere and I lose every life.

The funnel agrees: many new players quit in wave 3. What should the PM write on the backlog first?

  1. A problem: new players can't see the wave 3 lasers coming in time, so they lose every life and quit
  2. A solution: add a shield button, exactly as the player asked
  3. Nothing: one message is not a pattern
  4. A fix: make every laser in the game half as fast
Show the answer

A problem: new players can't see the wave 3 lasers coming in time, so they lose every life and quit

The message plus the data show a real problem. Writing the problem down keeps several fixes open, like a warning flash, a shield or an easier wave 3, so the team can test which one works best.

The backlog and user stories

The backlog is the ordered list of everything we might build. The Scrum Guide calls it "an emergent, ordered list of what is needed to improve the product": emergent, because it keeps changing. Ours is the To do column of our GitHub board (Stage 2), most important at the top.

Many items are written as user stories, a format from a team at the London company Connextra in 2001:

As a [who], I want [what], so that [why].

Each story gets acceptance criteria: checkable statements that say when it counts as done.

Story check

story_48.md
Story #48As a new player, I want a warning before lasers fire,so that I can dodge them in wave 3. Done when:- A red line flashes 1 second before each laser- The warning feels nice- It works with the sound switched off- Still 60 FPS on our oldest test phone

Which acceptance criterion can nobody check?

  1. Line 6
  2. Line 7
  3. Line 8
  4. Line 9
Show the answer

Line 7

"Feels nice" means something different to everyone, so the story could never be marked done. The other lines can each be tested with a yes or no, which is the whole point of acceptance criteria.

What first, and at what rhythm?

The backlog is always longer than the time. So the PM rates each item on impact (how much it helps the problem, for how many players) and effort (how much work). High impact, low effort is a quick win: do it first. High impact, high effort is a big bet: plan it. Low impact, high effort: usually never. Intercom's RICE score adds reach and confidence: reach × impact × confidence ÷ effort. MoSCoW, from the Scope lesson, does a different job: sorting features for one deadline.

Then the team pulls work in one of two rhythms:

Pick the next card

backlog_wave3.txt
Problem: new players quit in wave 3 Idea                         Impact   EffortA  Red warning before lasers  High     2 daysB  Online co-op               High     8 weeksC  Photo mode                 Low      3 weeksD  Rename the sound files     Low      1 hour

Which idea should the team build first?

  1. A
  2. B
  3. C
  4. D
Show the answer

A

A is a quick win: it goes straight at the wave 3 problem and takes two days. B is a big bet for later, C costs weeks for little gain, and D is quick but doesn't help the problem.

KPIs, a north star and OKRs

A KPI (key performance indicator) is a number the team watches to see whether the game is healthy, like DAU or Day 1 retention (Reading the numbers explains them). A north-star metric is the one number that best captures the value players get. Analytics company Amplitude says a good one is a leading indicator: it predicts future success, while revenue only shows the past. For Hyper Shards: weekly players who finish a run.

OKRs (objectives and key results) set goals. Andy Grove used them at Intel, and John Doerr brought them to Google. A made-up example for one quarter:

Quick check

The objective is "New players enjoy their first week." Which is the best key result?

  1. Day 7 retention rises from 18% to 25% by the end of March
  2. Make the game more fun for everyone
  3. Ship 40 new features this quarter
  4. Everyone works really hard all quarter
Show the answer

Day 7 retention rises from 18% to 25% by the end of March

A key result is a number with a date that shows the objective happened. "More fun" can't be measured, and 40 features or hard work count effort, not whether players enjoy the game.

Everyone wears the PM hat

Our studio is too small for a full-time PM, so we take turns wearing the PM hat. Once a week, for about 20 minutes, whoever wears it reads the new feedback and numbers, updates the problem list, tidies the top stories and reorders the backlog. Then the team decides together.

Wearing the hat means asking "what problem does this solve, and how will we know?" before anyone writes code. You can ask that question any day, whoever has the hat.

Bolt says: Knowing what to build is half the job. Paying for a bigger game is the other half. Next: publishers and crowdfunding.

Fact-checked 9 October 2026