Product Management · A Learn course
Product management is the job of figuring out what to build, proving people want it, and making it work for the business. Five-minute lessons, real stories, and something to play with in every one. Built for high schoolers who’d rather build than wait to be told. No business degree needed.
On iPhone, iPad and Android now. Part I is free.
Product management is the job of deciding what a product should do, checking that people want it before it gets built, and making sure it works for the business that builds it. It sits between the customer, the engineers and the company, and it owns the decision about what gets made.
A product manager finds a problem worth solving, talks to the people who have it, works with a designer and engineers on a solution, tests that solution before it ships, and measures whether it changed anything. They don’t manage people and they don’t write most of the code. They are responsible for the product being valuable and viable.
Try it · Module 11 · Opportunity assessment
The cafeteria manager wants a pre-order app by spring. Before anyone builds anything, a product manager asks four questions. Answer them and you’ll have the one-pager at the bottom.
What you were told
“Kids hate the lunch line. Build an app where they order from their phone and skip it. Every school will want this.”
1What problem are we solving? (How do we know it’s a problem?)
2Who are we solving it for?
3What are we trying to change?
4How will we know we succeeded?
Your opportunity assessment
0 of 4 answered.
Talk Card · Module 11
When someone hands you a solution, find the problem behind it, the people who have it, and the number that would prove it’s fixed.
Module 2 · The four risks
Every product idea can die four different ways. Tap each worry into the bucket it belongs in.
Will they use it?
Can they figure it out?
Can we build it?
Does it work for the business?
Talk Card · Module 2
Before you build, ask four things: will they use it, can they use it, can we build it, and does it work for the business.
Module 14 · Minimum viable product
MVP stands for minimum viable product: the smallest version of an idea you can put in front of real people to learn whether they want it. It is not a worse version of the product. It is an experiment, built to answer one question as cheaply as possible, so you find out before you spend months building the whole thing.
The crew listed twelve features for the lunch app. The question they need answered first: will students pre-order lunch at all? Cut the list down to what it takes to learn that, and nothing else.
The one question
Will students pre-order lunch at all?
Talk Card · Module 14
An MVP is the smallest thing you can build to learn one thing. It’s an experiment, not a discount version of the product.
Module 16 · Demand testing
You don’t need an app to find out if people want one. Put a sign-up on the cafeteria door and count. Pick a pitch, send 200 students past it, and see who bites.
Pick the sign on the door
Talk Card · Module 16
A fake door test measures interest in something that doesn’t exist yet, so you find out before you build instead of after.
Modules 3 and 6 · OKRs and outcomes
OKR stands for objectives and key results. The objective is the problem you are trying to solve, in words. The key results are the two or three numbers that would prove you solved it. Good teams get handed an objective and choose their own key results. It is how a company says “fix this” without saying “build that.”
An output is a thing you made: a feature, an app, a report. An outcome is a change in the world because of it: shorter lines, more people coming back, fewer support calls. Shipping an output is easy to measure and proves nothing. Products are judged on outcomes.
The cafeteria manager wants the line fixed. Build the OKR the crew should take on: pick the objective, then the two key results that would prove it.
Step 1 · Pick the objective
Step 2 · Pick two key results
Your OKR
Talk Card · Module 6
An objective is the problem to solve. Key results are the numbers that prove you solved it. Neither one names the feature.
Module 13 · User story mapping
A story map lays out what a person does, step by step, left to right, with the things the product could do for each step stacked underneath. A line drawn across it marks the first release: the thinnest slice that gets someone all the way through. It turns a flat list of features into a picture of a day, which is why it finds the holes a list hides.
Here is a student’s lunch as a backbone, with ideas under each step. Tap the cards that go in the first release. The rule: someone has to get all the way from arriving to eating, and it has to be small.
First release above the dashed line · Later below
Talk Card · Module 13
A story map is the user’s day left to right, ideas stacked underneath, and a line across it for the first release.
Real people, real products
Every module carries a true story from a product you already know. Not the founder-on-a-stage version. The version where somebody with the job was in a room with people who said no.
Kate, product manager
Stuck at 300,000 customers
Netflix was renting DVDs by mail, one at a time, and people rented once and forgot. The team tested a flat monthly subscription and customers loved it. Then the problem moved: everyone wanted the new releases, which cost the most to stock. Unlimited new releases would have bankrupted them.
The queue, the star ratings and the recommendation engine were all invented in three months to solve that one problem. They weren’t features on a roadmap. They were how the business survived.
Module 3
Jane, product manager
The product that almost wasn’t allowed
The sales team thought self-service ads would undercut what they sold. The engineers thought ads would wreck the search results they’d worked so hard on. Jane sat down with each of them and listened until she understood the objection underneath.
The answer was a design: put the self-service ads to the side, not the top, and rank them by price times how often people clicked. Bad ads sank even if they paid more. Both teams could live with it, and it became the business that funds Google.
Module 5
Martina, product manager
Two minutes to open a document
Microsoft shipped the biggest Word ever on a shared code base, and on a normal Mac it crawled. Mac users decided Microsoft was trying to kill the platform. Bill Gates forwarded the hate mail to the team with “fix it.”
The team stopped chasing feature parity and measured what Mac users cared about: startup time, font loading, and Word Count, which reporters used ten times a day. Version 6.1 went out to every registered user with an apology letter, signed by Martina.
Module 2
Kevin and Mike, founders
Cut everything but the photo
Instagram started life as Burbn, a check-in app with game mechanics, and it was cluttered. When the founders looked at what people used, it was the photos, the comments and the likes. They started over with only those.
Product-market fit often means removing things. Burbn had more features. Instagram had the one people came back for, and it was bought for about a billion dollars eighteen months later.
Module 19
Alex, product manager
Screens in a city center, playing the wrong thing
Four years before the iPhone, the BBC could syndicate content over the internet and almost nobody there knew why that mattered. Alex noticed the big video screens in city centers were showing the same feed as your living room, to a completely different audience.
She ran experiments: editorial teams made content for a specific venue, and she measured reach. The results earned her the standing to propose “BBC Out of Home,” as an individual contributor, and that work became the basis of BBC Mobile.
Module 11
Lea, product leader
Moving half the company’s revenue on purpose
Creative Suite was about $2 billion a year in licenses, roughly half of Adobe. Lea believed the annual-upgrade model was pushing the product in directions that were bad for customers, and that subscription across every device was where it had to go. Finance, engineering and sales each had a good reason to be scared.
She and the CTO built a stream of prototypes showing what the new foundation could do, and she communicated until it felt like too much. Adobe passed a billion dollars in recurring revenue faster than anyone had, and stopped releasing the old suite.
Module 21
The whole course
Every module is four five-minute lessons, about 20 minutes, with something to play with in each one and a Field Card at the end.
Part I · The lunch line
Why every app is a pile of decisions, and the four ways any of them can fail.
Part II · The crew
Who does what on a product team, and why the good ones get problems instead of feature lists.
Part III · The cafeteria
Customers, jobs, numbers, and the ways your own brain gets in the way.
Part IV · The first idea
Framing the problem, mapping the options, and faking the product before you build it.
Part V · The fake door
Finding out if people want it, if they can use it, and if the business can stand it.
Part VI · The pivot
Knowing when you’ve found it, saying no to almost everything, and telling the story so it sticks.
Part VII · The next thing
What changes when the product has a model inside it, and what you build with the tools you have now.
How a lesson works
Scene
A quick story sets up a decision somebody has to make.
Play
You make the call with your hands before anyone names the technique.
Name it
Then it gets its proper name.
Details
A couple of short cards, each one tied back to the decision.
Back to it
You answer the question from the story.
Say it
You leave with a Talk Card: one sentence you could say in a meeting.
Every module ends with a one-page checklist for a situation you’ll meet on the job: your boss hands you an idea, you need to test whether something matters, you have to say no to a stakeholder. Print it. Keep it. Use it the day it happens.
Every module also ends with a Dinner Table Challenge, one question to ask whoever’s across the table. It works the same for a teenager and a parent who’s been in the meetings, and explaining something out loud is the fastest way to find out you get it.
Dinner Table Challenge · Module 1
Pick one app on your phone and ask someone at home: who do you think decided that button goes there, and what do you think they were worried about?
There’s a story running through it
The line at their school takes 12 minutes. Maya wants to build an app. Over 24 modules the crew frames the problem, times the line, tests a paper sign-up, gets told no by the cafeteria manager, and ships something that isn’t the app at all. The app comes later, and by then they know why.
Two more you’ll hear
Product-market fit is the point where a product satisfies a real market well enough that people keep using it and tell others without being pushed. You can feel it as retention that flattens above zero instead of falling to it, and you can measure it with one survey question: how would you feel if you could no longer use this? When more than about 40% say very disappointed, you are close.
Module 19
Jobs to be done is a way of asking why someone uses a product: what progress are they trying to make in their life at that moment? People don’t buy a drill because they want a drill. They hire it to make a hole. Ask what job a product is hired for and competitors stop being the obvious ones. A morning milkshake competes with a banana and a bagel, not other milkshakes.
Module 8
Field Cards
These are the situations product managers get thrown into with no warning. Each module ends with one. Here are three in full.
Field Card · Module 11
The likelihood the idea is exactly right as handed over is low. The likelihood there’s a real problem underneath it is high. Go find that.
Field Card · Module 15
Most ideas don’t work. The point of the plan is to find out cheaply, then iterate on the ones that show a pulse.
Field Card · Module 9
A product that matters is one people would miss. Everything else is a feature that shipped.
Part VII · Product management in the AI age
A product with a model inside it doesn’t give the same answer twice. That changes how you test value, how you earn trust, what it costs, and who’s responsible when it’s wrong. Two modules on this, built from the same frame as the rest.
A feed that gets one recommendation wrong is fine. A tool that gets one insulin dose wrong is not. Matching the technology to the problem is the first decision, and it’s the product manager’s.
People need to know what the thing can and can’t do, and roughly how it works, before they’ll rely on it. That’s a design job and a product job at the same time.
What went in decides what comes out, including the biases. Knowing the data is now part of knowing the customer.
The tools now let a designer, an engineer or a teenager with a weekend build the thing and test it. The title matters less. Tackling the four risks is what makes you the product person.
The same job as any product manager, on a product with a model inside it: find the problem, prove people want the solution, make it work for the business. The extra work is knowing the training data, deciding how much wrong the product can afford to be, designing for trust, and watching the cost of every answer. Most product managers will be AI product managers within a few years.
Talk Card · Module 23
An AI product still has to be valuable, usable, buildable and good for the business. The model just makes each of those harder to prove.
Who’s building this
Product leader · Data, analytics and AI
I’ve spent twenty years as a product manager and product leader, building AI, data and analytics products and the teams that ship them. This course is the one I wish someone had handed me at sixteen. It’s built on SVPG’s books and workshop, which I’ve taught from, plus the twenty or so other books that changed how I work. It’s a Pettigrew Lab project, so it’s a family one.
Read my resumeBefore you ask
A product manager is responsible for whether a product is worth building and whether it works for the business. They figure out which problem to solve, work with a designer and engineers to find a solution people love, test it before it’s built, and then measure whether it changed anything. They don’t manage people and they don’t write most of the code. They own the decision.
Yes, that’s who it’s written for. You don’t need a business class, a job or a startup. You need one problem you’ve noticed and the patience to find out if other people have it too. The lessons use a school lunch line as the running example because everyone has stood in one.
No. Product managers work with engineers, and the course teaches you enough to have that conversation with respect. The last two modules do have you build something small with AI tools, because in 2026 that’s a thing a curious sixteen-year-old can do in a weekend.
It overlaps. Founders do product management whether they call it that or not. The course covers the parts that are the same, like finding a problem and testing demand, and the parts that only show up inside a company, like objectives from leadership and stakeholders who can say no.
Every one. They come from the books the course is built on, mostly the profiles SVPG published of the product managers behind Netflix, Google AdWords, Word for Mac, the BBC, iTunes and Adobe Creative Cloud. Where a number is quoted, it’s the book’s number.
A product manager decides what gets built and why, and is judged on whether it worked for customers and the business. A project manager gets an agreed piece of work done on time and on budget, and is judged on the schedule. One owns the decision, the other owns the delivery. Small companies often ask one person to do both, which is how the two get confused.
Mostly. Product owner is a role from the Scrum process: the person who keeps the team’s backlog in order and answers the engineers’ questions day to day. Product manager is the wider job, which includes that work plus talking to customers, finding the problem and deciding whether it’s worth solving. A good product manager does the product owner work as part of the job.
If you like figuring out what people need, arguing from evidence, and seeing a thing you decided on show up in the world, yes. It pays well, it doesn’t require a specific degree, and it is one of the few jobs where you touch the customer, the design and the engineering in the same week. The hard part is that you get the responsibility without the authority: nobody reports to you, and you still own the result.
Most product managers came from somewhere else first: engineering, design, support, marketing, or starting something of their own. The fastest way in is to do the job before anyone gives you the title: pick a problem, talk to the people who have it, build the smallest thing that tests your idea, and write down what you learned. That story is what gets you the first associate product manager role, and it is what this course teaches you to do.
A product manager decides what gets built and why, and owns whether it works for the people using it. A project manager owns how and when it gets built: the schedule, the budget, who’s doing what by Friday. On a small team one person often does both. The quick test is where your job ends. If it ends when the thing ships on time, that’s project management. If it ends when people are using it and the problem is gone, that’s product.
The outline and the three lessons on this page are free right now. The app is free to download and Part I is free inside it. Everything from Module 4 on is a one-time unlock, same as Data to AI. No subscription.
It’s out. Get it from the App Store on iPhone and iPad, or from Google Play on Android.
Pick your door
Start with the boss’s idea up top. Four questions, about two minutes.
Try the lessonPart I is free in the app, so a kid or a whole class can start without buying anything. The Field Cards work as a class exercise on their own.
Get the appThe Field Cards are the useful part for you. Tell us which situation you wish there was a card for.
Suggest a Field CardRead the long version
This course leans on a shelf of them, and these are the six I’d hand you first. Start with Inspired. It’s the spine of the whole thing.
Marty Cagan
How the best tech companies decide what to build. The four risks, product discovery and empowered teams come from here.
Find the bookEd Catmull
How Pixar built a place where people tell each other the truth about unfinished work, and why the Braintrust works.
Find the bookPeter Thiel
Why building something new beats copying, and why you start by owning a small market instead of chasing a big one.
Find the bookTeresa Torres
Talking to customers every week, and the opportunity solution tree for keeping your first idea from being your only one.
Find the bookMelissa Perri
Why shipping features isn’t the same as making progress, and how a company gets out of measuring the wrong thing.
Find the bookTony Fadell
From the person behind the iPod and Nest: how to make things worth making, from your first job to running the company.
Find the book