"Descriptive, not prescriptive"
"Descriptive, not prescriptive" is the commitment to describe what users actually do, in the order they do it, rather than laying out the sequence a team wishes they'd follow and treating that wish as a description. Teams naturally have a preferred order (sign up, fill in a profile, invite coworkers, upgrade), and it's easy to sketch that order on a whiteboard and start calling it the way users move. The descriptive stance treats the whiteboard sequence as a plan, not an observation, and holds that the thing worth describing is the messier reality of what people are up to and why.
Definition
The commitment to describe what users are actually doing on their own timeline, rather than organize the work around the provider's preferred sequence of what they should do.
The provider's preferred sequence
Every provider has a sequence it wants users to move through — acquire, activate, retain, convert, refer — and its metrics, design decisions, and routing get organized around that sequence. Funnels, AARRR, and journey maps with provider-defined stages are the standard forms it takes. Providers are entitled to a preferred sequence; the prescriptive error is presenting that sequence as a description of what users are actually doing and then measuring against it. A metric like "Week 1 retained" or "activated user" doesn't sit anywhere on the user's own timeline. It sits on the provider's, organized around what the provider needs users to do.
Describing the user's actual timeline
The user is on their own timeline, driven by their own reasons for engaging. The descriptive commitment is to observe that timeline and describe what's happening on it in the user's terms. Asked what they're doing, the user wouldn't say "I'm in the retention phase" — they'd say "I'm trying to send an invoice" or "I'm getting ready for a trip." That's the timeline the framework describes. Abstractions of it — funnels, journey maps, Pirate Metrics — are always models, and the map is not the territory.
Description comes first because everything downstream is built on it. Design serves the activity you've described, and commercial returns get correlated against the value the user produces. Describe the wrong timeline and every layer above it aims at the wrong target.
Following the tracks in design
The same distinction runs through how a team decides what to build. Provider intuition about what users should incorporate is the prescriptive default: the team reasons from its own plan and builds affordances that make sense inside the offering. The descriptive correction is following the tracks — observing where users actually go, where they find affordances that fit their route and where they route around them, and shaping the offering against that. The trajectory data is the description; the design work follows it rather than the plan.
Example
A team's activation dashboard shows users stalling before "activated." The prescriptive read: users aren't completing the sequence, so push them through it with more onboarding prompts, a checklist, an email nudge toward the next provider-defined step. The descriptive read starts from what the user is trying to do. For an invoicing tool, the user isn't trying to get "activated" — they're trying to send an invoice and get paid. Watching the trajectory shows they stall at the point where they have to enter a client's payment details, because they don't have them yet. The provider frame can't see that; it only knows a stage isn't completing. Describing the user's actual timeline locates the specific transition where the user is stuck, which is the thing worth designing against.