The words you need to know

The point where your product solves a real problem that enough people have, and they're willing to pay for it. Before PMF you're searching. After PMF you're scaling. Most early-stage product work is really about finding it.

The smallest, simplest version of something you can put in front of real users to learn whether the idea works. Not the worst possible version. Just the minimum needed to test the core assumption. If nobody uses the MVP, building more won't fix it.

The clear statement of what problem your product solves, for whom, and why it's better than the alternative (including doing nothing). If you can't state it in one sentence, you haven't found it yet.

A way of thinking about why people use products. Instead of asking "who is our user?" you ask "what job are they trying to get done?" People don't buy a drill. They buy a hole in the wall. Understanding the job helps you build the right thing.

A specific problem, frustration, or inefficiency that a user experiences. The best products solve real pain points rather than creating solutions looking for problems. If you can't name the pain, you probably haven't talked to enough users.

The research and thinking phase: figuring out what to build before you build it. Involves user interviews, data analysis, competitor research. Good discovery means you build the right thing. Skipping it means you build fast and find out later it was wrong.

What makes a business hard to copy. A company with a moat can defend its position even when competitors try to replicate it. Common moats: network effects, switching costs, brand, scale, proprietary data. The question "what's your moat?" reframes how you think about competitive strategy.

When a product becomes more valuable as more people use it. WhatsApp is useless with one user. With a billion, it's indispensable. Network effects are one of the strongest moats because they're self-reinforcing: growth makes the product better, which drives more growth.

A self-reinforcing loop where growth feeds more growth. Amazon's flywheel: more customers attract more sellers, which improves selection, which attracts more customers. Once a flywheel is spinning, it gets harder to stop. The opposite of a funnel, which is linear.

Not what your product does, but where it sits in a customer's mind relative to the alternatives. Positioning answers: who is this for, what does it do, and why is it different? Bad positioning means customers can't figure out what you are. Good positioning means they instantly know.

Building something genuinely new, as opposed to improving on something that already exists. Peter Thiel's framing from his book of the same name. Going from 0 to 1 is invention. Going from 1 to n is scaling. Most companies do the latter. The hard work is the former.

A product that other products are built on top of. Stripe is a platform: developers use it to handle payments in their own products. Distinct from a product, which is built for end users. Platforms create ecosystems. Getting platform strategy right is one of the hardest and highest-value things in product.

The core building blocks of a system, designed to be combined in different ways. Stripe's primitives are charges, customers, subscriptions, invoices. AWS built an industry on infrastructure primitives. Thinking in primitives means designing for composability rather than fixed use cases.

A plan showing what the team intends to build and roughly when. Not a contract. A direction. Good roadmaps show priorities and reasoning, not just dates. A roadmap that never changes is a sign nobody is learning anything.

The list of everything the team could work on: features, bugs, improvements, ideas. It grows constantly. The PM's job is to keep it ordered so the most important things are at the top, not just the most recently requested.

Deciding what to work on next, and what to not work on. The hardest part of product management. Every yes to one thing is a no to everything else. Common frameworks: RICE (Reach, Impact, Confidence, Effort), MoSCoW (Must, Should, Could, Won't).

A goal-setting framework. The Objective is the qualitative thing you want to achieve ("make onboarding delightful"). The Key Results are the measurable signals that tell you if you got there ("70% of users complete setup in under 5 minutes"). Popularised by Google.

A metric that tells you whether things are going well. Conversion rate, churn, daily active users. All KPIs. The problem is most teams track too many. A good KPI is one you'd actually change your behaviour to improve.

The single number that best captures the core value your product delivers to users. For Spotify it might be time spent listening. For Airbnb, nights booked. Everything else is secondary. Having a clear North Star stops teams optimising for the wrong things.

A way of working that builds in short cycles rather than planning everything upfront. The idea: ship something small, learn from it, adjust. Opposite of waterfall. Most software teams use some form of agile, though how strictly they follow it varies wildly.

A fixed time period (usually two weeks) in which the team commits to completing a set of work. At the end of every sprint there should be something shippable. The regularity creates rhythm and forces prioritisation.

A specific agile framework with defined roles (Product Owner, Scrum Master, team) and ceremonies (sprint planning, daily standup, retrospective). Many teams use some bits of Scrum without following it strictly.

A way of managing work using a board with columns (To Do, In Progress, Done). Work moves across the board. The key rule: limit how much is in progress at once. Simpler than Scrum, less ceremony, often better for ongoing support work.

A short daily team meeting, usually 15 minutes standing up. Three questions: what did I do yesterday, what am I doing today, is anything blocking me. Purpose is coordination, not status reporting to a manager.

A regular team meeting to reflect on how you're working. Not what you built but how you built it. What went well, what didn't, what do we change. Happens at the end of each sprint in Scrum.

The traditional approach: plan everything, build everything, test everything, ship everything, in sequence. Contrasted with agile. Works for some things (construction, surgery) but poorly for software where requirements change as you learn.

A short description of a feature from the user's point of view. Standard format: "As a [type of user], I want [to do something] so that [I get some benefit]." Keeps the focus on the person using the thing, not the technical implementation.

A large body of work that can be broken down into smaller user stories. "User can manage their account" is an epic. The individual stories inside it (change password, update email, delete account) are the pieces you actually build.

The specific conditions a feature must meet to be considered done. Written before building, checked after. Good acceptance criteria removes ambiguity about what "finished" means, for both the person building and the person requesting.

A document describing what a product or feature needs to do and why. Includes the problem, the users, the requirements, and sometimes the constraints. Some teams use them extensively; others rarely write them. The value is in the thinking, not the document.

The team's agreed list of criteria that must be met before any piece of work is called complete. Code reviewed, tested, documented, deployed. Whatever the team has agreed. Prevents "it works on my machine" being called done.

The practice of talking to and observing real users to understand their needs, behaviours, and frustrations. Qualitative (interviews, observation) or quantitative (surveys, analytics). Without it, you're building for an imagined person who may not exist.

A fictional but representative description of a type of user: their goals, frustrations, context, behaviour. Useful shorthand for design decisions: "would Sarah use this?" Less useful when teams treat them as real people rather than models.

A map of all the steps a user takes to achieve a goal, from first becoming aware of a problem through using your product to the outcome. Shows where things work and where people drop off.

Showing two versions of something to different groups of users and measuring which performs better. Version A gets shown to half your users, version B to the other half. The data tells you which to keep. Requires enough users to get statistically meaningful results.

The rate at which customers stop using or paying for your product. High churn means you're losing customers as fast as you're gaining them. Often more important to fix than acquisition. It's cheaper to keep a customer than find a new one.

A measure of customer loyalty. One question: "How likely are you to recommend us to a friend? (0–10)." Promoters (9–10) minus Detractors (0–6) = your NPS. Widely used, widely criticised for oversimplifying, but gives a quick read on sentiment.

The series of steps a user takes from first contact to completing a goal (signing up, buying, etc.). Called a funnel because users drop off at each step. Fewer at the bottom than the top. Analysing where people leave tells you where to focus.

The moment a new user first gets real value from your product. Not signing up — that's acquisition. Activation is when they do the thing that makes them likely to come back. Finding and shortening the path to activation is often more valuable than increasing sign-ups.

Whether users come back. The percentage of users who are still active after a given period (day 7, day 30, etc.). Retention is the foundation everything else is built on. High acquisition with low retention means you're filling a leaking bucket.

What it costs, on average, to acquire one paying customer. Total sales and marketing spend divided by number of new customers. On its own it means little. Compared to LTV, it tells you whether the business model works.

The total revenue you expect to earn from a customer over the entire time they use your product. The ratio of LTV to CAC is one of the most important numbers in any subscription or recurring business. A rough rule of thumb: LTV should be at least 3x CAC.

The person responsible for defining what gets built and why. Not a manager of people. A manager of the product. Sits between the business, users, and engineering team. Decides priorities. Does not usually write code or design interfaces.

Anyone with an interest in or influence over the product: executives, sales, customer support, legal, customers. PMs spend a lot of time managing stakeholder expectations, making sure people understand what's being built and why, and handling requests that compete for the same finite time.

The senior engineer who leads the technical decisions for the team. The PM decides what to build; the tech lead decides how. A good PM/tech lead relationship is what makes a product team actually work.

The person responsible for how the product looks and feels to use. UX (User Experience) focuses on the interaction: flows, information architecture, usability. UI (User Interface) is the visual layer. Often the same person in small teams.