Start here: who this track is for and how it works

This track is written for three groups of people, and you may be in more than one.

• You want to become a PM. You may be a student, an analyst, a support or operations lead, or someone switching careers. Take the courses in order. Each course ends with a capstone project, and together they become a portfolio you can show in interviews. Interviews themselves are covered in Breaking into product.
• You are an engineer moving into product. You already understand how software is built, which covers one of the four risks you will meet in How products create value. The usual gaps are finding the real problem, measuring value and writing for decisions. Don't skip Problems before solutions or the Discovery course.
• You already work as a PM but never had training. Many working PMs learned on the job, often on internal tools for operations teams. Use each course's final exam to find your gaps, and go deep where you score lowest.

The eleven courses follow the same loop a product team follows, from finding a problem to proving the fix worked and leading others.

If you follow the Product Manager path, it adds four technical courses (How the Web Works, SQL & Data Modeling, GitHub for Teams and System Design Case Studies) so you can follow engineering discussions with confidence. If you arrived through the Career Starter path, this course is its product step.

Every lesson has the same shape: an everyday picture, the mechanisms with quick checks, a worked example, a Do it section with a template you can copy into your own work, practice tasks with model answers, a short quiz, flashcards for review and a podcast episode for listening on the move. Each course ends with a capstone and a final exam with a 70% pass mark.

All examples happen at Mangrove Market, a fictional grocery chain with about 320 stores in 6 cities, 4 distribution centres, a customer app with about 2 million registered customers, about 1,800 independent partner shops that order wholesale through the Partner app, and about 600 delivery riders. You will follow Imran, the PM for the Store app (used by store staff on handheld scanners) and the Partner app. In the podcast, Nadia, an experienced product lead, coaches him.

The job: make the right thing happen, and prove it helped

A product manager is accountable for whether the product solves a real problem in a way that also works for the business. Marty Cagan of the Silicon Valley Product Group puts it this way: the PM "needs to ensure a business outcome, not just ensure a product gets defined" (2016). Ben Horowitz's well-known memo Good Product Manager/Bad Product Manager says a good PM defines "the 'what' (as opposed to the how)". Engineers decide how to build it. Designers decide how it works for the person using it. The PM makes sure the team is solving the right problem and can show that it worked.

In practice the work repeats in a loop, every week:

1. Understand. Talk to users, watch them work, read support tickets and data. This is discovery.
2. Decide. Choose which problem to work on now, and which requests to turn down. Saying no, with reasons, is a large part of the job.
3. Make it clear. Write down the problem, the goal, what is in and out, and what is still unknown, so engineers, designers and vendors can make good decisions without asking you every hour.
4. Help it ship. Answer questions, cut scope when estimates grow, unblock decisions with other teams. This is delivery.
5. Check it worked. Look at whether user behaviour changed. If it didn't, find out why and go round again.

The difference between an output and an outcome sits at the centre of this. An output is a thing the team makes: a feature, a screen, a release. An outcome is a change in what people do or in a business result: deliveries received in 15 minutes instead of 24, more partner shops ordering in the app, fewer customers cancelling. Many teams track outputs because they are easy to count. A team that only counts outputs becomes what Melissa Perri calls a feature factory: it ships a lot and nobody checks whether anything improved.

One more thing surprises new PMs. You usually manage nobody. Engineers report to an engineering manager, designers to a design lead, and store staff to their store manager. You lead through clear goals, good evidence and decisions people can follow. When a team trusts that you know the users and the numbers, they follow your priorities. When they don't, no job title helps.

PM, project manager, product owner, and the product trio

These titles get mixed up, and in small companies one person may do all of them. Knowing the difference helps you see which part of the work nobody is doing.

A project, in the Project Management Institute's definition, is temporary and creates a unique result. A product keeps living after the project ends. The project to roll out new handheld scanners finishes when every store has them. The Store app on those scanners keeps changing for years.

Scrum is a common way to organise a team's work into short cycles called sprints. The 2020 Scrum Guide says the product owner "is accountable for maximizing the value of the product resulting from the work of the Scrum Team" and for managing the backlog, and that the product owner "is one person, not a committee". In many companies the PM is also the product owner. In larger companies, and often when an outside vendor builds the software, the two split: a product owner works day to day with the developers, and the PM spends more time on discovery, strategy and stakeholders. If you have both, agree in writing who decides the order of the backlog.

Modern product teams are built around a product trio: a product manager, a designer and a tech lead who decide together what to build. Teresa Torres describes the trio as the part of the team that leads discovery: they interview users together, choose which problem to tackle and test solutions together. Each brings one kind of judgement. Cagan's split, which How products create value covers in full, is useful: the designer covers whether people can use it, the tech lead covers whether it can be built, and the PM covers whether it is worth building and whether it works for the business.

On internal tools the trio often stretches. At Mangrove, the Store app trio regularly pulls in a store operations lead, because nobody understands receiving like someone who has done it at 6 am. When a vendor builds the app, the vendor's tech lead and project manager join, and your job includes making sure the vendor understands the problem and the outcome as well as the list of screens.

Five kinds of PM job

The core loop is the same everywhere. What changes is who the users are, whether they can leave, and how you see value.

Internal tools and operations. A large share of PMs build software for their own company's staff: store apps on handheld scanners, warehouse and dispatch screens, field-agent apps, loan-approval screens in a bank, bed-management boards in a hospital, back-office dashboards. The users can't switch to a competitor, so the usual warning sign of people leaving is missing. Problems show up as workarounds instead: paper sheets, side spreadsheets, photos sent to a chat group. Value is measured in minutes, errors and money, and the work often involves an outside vendor, old systems you can't replace and rollouts to hundreds of sites. Course 8 is devoted to this, starting with Product management for internal tools.

Consumer. Users choose you every day and can leave in seconds. You often have enough traffic to run experiments. Duolingo is a good example of the business side: in its 2024 annual report it said more than 100 million people used it each month, about 9% of them paid, and only about 7% of its revenue came from advertising. Most of the money came from the minority who pay for a subscription.

Platform. Your users are developers or other teams who build on what you provide. Stripe offers payment APIs that other companies put inside their checkouts. Ride and delivery apps commonly show maps through services like Google Maps Platform. Inside a company, a platform PM might own the order service that the customer app, the Partner app and the POS all call. Success is measured by how quickly other teams can build on you and how rarely you break them.

B2B. You sell to businesses, and the person who pays is often not the person who uses the product. An IT or finance team signs the contract while staff use the tool all day. Slack's pricing shows how B2B products care about real use: under its Fair Billing Policy, a member who hasn't used Slack for more than 28 days stops being billed, and the account gets a credit. Square, founded in 2009, sells to sellers: the owner chooses it, staff use it at the counter, and shoppers see the screen.

AI. A model does part of the work: writing, answering, summarising or suggesting. GitHub Copilot suggests code inside a developer's editor, and ChatGPT answers questions in conversation. The PM's new jobs are deciding where AI beats simple rules, measuring answer quality with evaluations, designing for answers that are sometimes wrong, and keeping the cost per answer affordable. AI is quickly becoming a layer inside all the other kinds, which is why the track has a full course on it from How AI features work.

The product lifecycle

Every product goes through a life, and the PM's main question changes along the way. Knowing the stage stops you from doing the wrong kind of work, such as polishing settings screens for a product nobody has adopted yet.

• Problem. Is this problem real, frequent and costly enough to solve? (Problems before solutions)
• Discover. What would solve it? Interviews, observation and cheap tests come before code.
• Build. What is the smallest version that solves the problem for real users?
• Launch. Who gets it first? For internal tools this is a pilot store, then waves of stores.
• Grow. Is it used and kept? Now adoption, retention and scale matter.
• Mature. Growth slows. You improve what matters, cut what doesn't, and look for new problems, which sends you back to discovery.
• Sunset. When the product no longer earns its cost, you retire it well: move users, keep their data, switch it off.

A living product is in several stages at once. The Store app as a whole is mature, while its new expiry-check feature is still in discovery. That is why good teams run discovery and delivery side by side every week, instead of one long phase of each.