Everything you already know about shipping games — translated into the language of software product management.
↓ scroll to begin
Here's the thing — product management isn't a foreign discipline for someone who's been a creative director. It's the same job wearing different clothes. The vocabulary shifts, the cadence changes, but the core work is eerily familiar.
Let's prove that. Below are eight terms from your world on the left, and their PM equivalents on the right. Click one from each side to match them. You'll probably get most of these on instinct alone.
In games, you "find the fun" during production — it's a years-long discovery process woven into building. In software PM, discovery and delivery run as two parallel tracks, all the time. This is probably the single biggest mindset shift.
The discovery track asks: "Are we building the right thing?" It's user interviews, prototypes, data analysis, and assumption testing. The delivery track asks: "Are we building the thing right?" It's sprints, code, QA, and shipping.
Both run simultaneously. Neither ever stops. The trick is keeping them in balance. What happens when you don't? Play with this:
The dual-track model isn't about having separate teams. It's about the PM holding both questions in their head at once. On Monday morning, you might be reviewing last sprint's user engagement data (discovery) and also grooming the backlog for next sprint (delivery). This back-and-forth is the heartbeat of the job.
You know this problem: everyone on the team thinks their idea should be the priority. The CEO has a vision, sales has customer requests, engineering wants to fix tech debt, design spotted a UX issue. How do you decide what comes first?
In game dev, the creative director often has final say — the vision is the tiebreaker. In PM, you need something more transparent, because you don't have that authority. You have prioritization frameworks, which give you a shared, defensible way to rank competing ideas.
The most widely used one is RICE: Reach × Impact × Confidence ÷ Effort. Each feature gets scored, and the math does the arguing for you. Try it below — you have eight feature ideas for a fictional P2P chat app (sound familiar?). Adjust the sliders and watch priorities shift in real time:
| Feature | Reach | Impact | Confidence | Effort | Score | # |
|---|
RICE isn't the only framework. ICE (Impact, Confidence, Ease) is simpler. MoSCoW (Must have, Should have, Could have, Won't have) is more categorical — great for defining MVPs. Opportunity scoring compares how important a need is versus how satisfied users currently are.
The framework matters less than the discipline of using one. What it really gives you is a language for trade-offs — a way to say "I hear your request, and here's where it sits relative to everything else, and here's why" without it becoming a power struggle.
If RICE decides what to build, sprints decide when and how. This is the operational engine of software PM, and it's what the Holepunch job listing is explicitly asking for: "Establish and maintain sprint cadence driving predictable delivery."
A sprint is a fixed time box — usually two weeks — during which the team commits to completing a specific set of work. It has a rhythm of recurring events (called "ceremonies," which sounds more dramatic than it is):
Sprint Planning — The PM and team pick items from the backlog for this sprint. Each item has a size estimate (in story points). The team has a known capacity. You fill the sprint until it's full, but never overfull. This is where the PM's prioritization work pays off — you already know what matters most.
Daily Standups — 15-minute sync. Each person: what I did yesterday, what I'm doing today, anything blocking me. The PM listens for blockers and dependencies. Not a status report — a coordination tool.
Sprint Review — Demo what was built. Stakeholders attend. This is your playtest moment — real reactions to real work.
Retrospective — What went well, what didn't, what to change. This is how the process improves over time. The PM usually facilitates.
Backlog Grooming — The PM refines upcoming work: writing user stories, clarifying requirements, splitting large items. This feeds the next sprint planning.
Try running a sprint yourself. Drag cards from the backlog into the sprint — but watch your capacity:
In games, the ultimate metric is often a gut feeling backed by playtests: "Is this fun?" In software PM, you still need taste and judgment — but you also have a continuous stream of real user data that can tell you whether a feature is actually working.
The key shift is that you define success before you build. This is done through OKRs — Objectives and Key Results. An Objective is qualitative ("Make onboarding feel effortless"). Key Results are measurable ("Reduce onboarding drop-off from 40% to 15%", "Increase Day-7 retention from 25% to 40%").
After a feature ships, you watch the metrics. But here's the interesting part — the data is almost never black and white. Explore this fictional scenario:
Scenario: Your team just shipped "Rooms" — a group chat feature for the P2P app. It's been live for 4 weeks. Look at the metrics and decide: was it a success?
The metrics that matter most depend on your product stage. For a growing product, you'll focus on activation (do new users "get it"?) and retention (do they come back?). For a mature product, engagement depth and revenue per user take over. The PM needs to know which game they're playing.
Some key metrics you'll encounter:
DAU/MAU ratio — Daily active users divided by monthly active users. Shows how "sticky" your product is. 50%+ is exceptional (people use it almost every day). 10% is typical for most apps.
Retention curves — What percentage of users come back on Day 1, Day 7, Day 30? A steep early drop is normal. The question is whether the curve flattens (some users stick) or hits zero (nobody stays).
NPS (Net Promoter Score) — "Would you recommend this to a friend?" on a 0–10 scale. 9–10 are promoters, 7–8 passive, 0–6 detractors. Score = % promoters – % detractors.
As a creative director, you probably had a fair amount of authority. You could make the call on art direction, narrative decisions, or gameplay feel. A PM typically cannot. They don't manage anyone. They don't have hire/fire power. They influence through evidence, relationships, and the quality of their thinking.
This is called influence without authority, and it's the single most talked-about PM skill. It means your power comes from:
Being the person who most deeply understands the user and the market. When the team debates which way to go, the PM's opinion carries weight because everyone knows they've done the research.
Being the person who connects the dots. The PM talks to engineering, design, sales, support, and leadership — nobody else has the full picture. That makes the PM the natural decision hub, even without formal authority.
Being the person who writes things down clearly. A well-crafted one-pager or PRD (Product Requirements Document) becomes the single source of truth the whole team rallies around.
Here's a scenario to practice with. You're proposing end-to-end encrypted file sharing for the app. Four stakeholders have different concerns. Choose your approach for each:
The document that makes all of this concrete is the one-pager (or brief, or pitch). It typically includes: the problem you're solving and for whom, why now, proposed solution, success metrics, risks and open questions, and a rough timeline. It's like a game pitch document, but shorter and more data-driven.
Here's everything from this guide in a searchable reference. Each entry includes the PM definition and — where applicable — the game development equivalent. Bookmark this for your interview prep.
One last thing. The Holepunch role specifically calls out sprint management, stakeholder communication, debugging workflows, and cross-team coordination. That maps almost perfectly to your experience running production on large game projects. The vocabulary in this guide will help you speak their language, but the substance? You've been doing that for fifteen years.
Go get it.