Product

For a long time the work of deciding what to build had no name. A company had people who sold things and people who built them, and what got built was mostly whatever the selling side wrote down and handed over. When software was sold once and installed on a customer's machine, that worked well enough. Deliver what the contract listed by the date it named and the deal was finished.

Subscriptions broke the arrangement. A customer who pays every month can stop paying every month, so the thing being sold has to stay worth using long after the first sale. Copying down requests doesn't get a team there, because the person making the request is describing a problem from one seat and cannot see the forty other seats the same product has to serve.

The meetings of that era all looked alike. Sales would write "this account wants an Excel export," engineering would build requests in the order they arrived, and six months later three customers would be using the feature. Everyone had done their own job correctly and the result was still wrong, because nobody owned the step in between — gathering the requests and judging which ones to build first and which ones to leave alone.

Product is the name that got attached to that empty seat. It pulls the deciding out as work in its own right and gives it an owner, a basis for judgment, and a paper trail. None of those three pieces is optional: an owner without a basis is guessing, and a basis nobody writes down is forgotten by the next planning meeting. That's why most of the terms on this axis describe a way of deciding rather than a way of building.

This axis holds 52 terms in eleven groups, and the groups follow the path a decision takes. Who decides (roles), where the product is headed (strategy), whether that direction is real (discovery), writing the decision down (definition and documents), putting the list in order (prioritization), building something small first (early forms), shipping it (launch), measuring it (metrics), charging for it (monetization), and then the shape the product takes (product structure) and where it sits in time (life cycle).

Roles sort out who carries the work. At the center sits the product manager (PM), and on teams running Scrum — a way of working in short fixed cycles — the product owner holds the final say over the order of the list of things to build. The rest are variants named after the territory they cover. A technical product manager owns products other developers use, such as an application programming interface (API); a growth product manager owns signup and return-visit numbers; a platform product manager owns internal tools other teams build on. A product analyst digs through data to give those decisions a basis, a product marketing manager shapes how a launch is described, and a chief product officer (CPO) runs the whole product organization.

Strategy is about where to go. The distant goal written as one sentence is the product vision, and the choice of what to do and what to skip on the way there is product strategy. A strategy needs someone to aim at, so it comes with a target market — the slice of customers being pursued — and competitive analysis, which lines up rival products by feature and price to find the gap. When the aim lands and the market wants what got built, that state is called product-market fit (PMF). Laid out over time so people can see what arrives roughly when, the same strategy becomes a product roadmap.

Discovery checks whether something is worth building before anyone builds it. The whole activity goes by product discovery. Its basic instrument is user research, meaning interviews and watching people work, and three tools organize what comes back. Jobs to be Done reads demand by asking what task a customer hires the product to finish, a persona compresses a scattered group of users into one described individual, and a customer journey map draws the path from first hearing about the product to leaving it. Complaints and requests that already arrived on their own are handled under voice of customer (VoC).

Definition and documents cover writing a decision in a form someone else can act on. The largest container is the product requirements document (PRD), which records what is being built, why, and what counts as finished. Inside it, a user story is one requirement phrased in a single sentence from the user's side, and the product backlog is the ordered pile of candidates nobody has started. Written down far enough to implement screen by screen it becomes a specification; written as a rule about how the product must behave in a given situation it becomes product policy. A one-pager compresses background and proposal onto a single page and a decision record preserves why a choice was made, while release notes and a changelog carry the same information outward to users.

Prioritization is what happens because there is always more to build than time to build it. The group holds one term, prioritization, and it is where the job gets uncomfortable. With forty items in the backlog and room for six this quarter, explaining the thirty-four that slipped takes longer than picking the six. Most of the methods in the group exist to make that explanation repeatable rather than personal, by scoring candidates on the same few questions every time.

Early forms are the small things built before the finished one. Four of them differ by size and purpose. A minimum viable product (MVP) is the smallest version that can test one assumption, and it goes to real users to collect a real reaction. A prototype exists only to provoke a reaction, so pressing its buttons doesn't have to do anything. A proof of concept (PoC) checks in a small way whether something is technically possible, and a pilot opens a finished product to a handful of customers before everyone else.

Launch is putting the work in front of users. One act of shipping is a release, and opening it to one percent first and widening the door only if nothing breaks is progressive delivery. The wider plan covering who hears about it, through which channel, and on what date is go-to-market (GTM). At the far end sits sunset, the deliberate end of a feature or product nobody uses enough to keep, announced early enough that the customers still on it can move somewhere else.

Metrics ask in numbers whether what shipped is working. The umbrella term is product metrics, and usage metrics sit under it to describe how much the product gets used. Read in order of time, activation is the moment a new user first feels the product do something useful, and retention is how many keep coming back — a hundred signups with thirty still active four months later is thirty percent retention. What numbers can't reach, satisfaction metrics ask users directly through surveys.

Monetization is how money comes out of the product. Setting the number on the page is pricing, and the structure behind it — per person, per usage, per tier — is the billing model. The point where a free user has to pay to continue is a paywall, and revenue that grows because existing customers add seats or move up a plan is expansion revenue.

Product structure describes the frame the product hangs on. Software reached through a browser and paid for monthly instead of installed is software as a service (SaaS), and business type splits products by who buys them, individuals or companies. Product form factor names the surface users actually touch — web, mobile app, or API — which is a different question from the early forms above, even though both sets of words sound like shapes.

Life cycle places the product on a timeline. Arriving, catching on, settling, and fading is the product life cycle, usually cut into introduction, growth, maturity and decline. Early on there is a stretch where the few people who try new things have already tried it and the mainstream buyers who only want proven tools haven't arrived yet, and demand drops out. That gap is the chasm.

"That's a product call. Let me hand it to Mia."

Someone specific owns the judgment about whether and when a thing gets built. Product here means the people holding that decision, not the software itself.

"The product goal this quarter is activation. Revenue comes after."

One number has been chosen as the quarter's standard. Saying the order out loud in advance saves the argument about what to cut later.

"The requirements doc isn't ready, so design starts next week."

Deciding has to finish before building starts, which also means a slip at the front pushes everything behind it.

At Pagedeck the word comes up most in the quarterly planning meeting. Grace, the CEO, sets the direction — this quarter, move more free users onto paid team plans — and Mia turns that direction into things a team can actually build. She brings what customers said in interviews alongside the numbers on where people drop off, picks four items out of fifteen candidates, and writes down why the other eleven wait.

After that the work splits. Noa draws the screens, and Theo reads the four items to work out how much of each is realistic inside the quarter, which usually sends one of them back to be cut smaller. Sofia checks when enterprise accounts can be told, since a contract signed against a promised date turns a slip into a refund conversation. Ravi lines up which users hear about it first on launch day. When someone in that room says product, they mean the front of this whole sequence — not any one of the jobs downstream of it.

The most common mistake is reading product as a synonym for building features. Features and screens are the only visible output, so the assumption makes sense. But deciding not to build something is output of exactly the same kind. Choosing six requests out of forty puts most of the weight on the thirty-four that were declined. Miss that and the product organization turns into a desk that takes down orders, and the roadmap stops being a plan and becomes a queue of unprocessed requests. A team in that state still ships constantly and still loses, because the six things it finished were the six that got asked for loudest.

The other one treats product decisions as a contest of instinct and clever ideas. Famous products get retold as founder intuition stories, which makes the work look that way from outside. In practice there's a procedure for building a basis: check with users before building, then watch activation or retention afterward to see whether the call held. Skip it and the loudest voice in the meeting wins by default — and when results come back poor six months later, nobody can name what was wrong, so the same judgment gets made again. Intuition does show up in the work, but it shows up as a guess worth testing, not as the answer.