Multi-intent model
The multi-intent model is the observation that users don't all show up to an offering for the same reason, and that a single offering usually serves several of those reasons at the same time. Two people opening the same project management tool might be there for completely different things (one keeping a solo side project on track, another coordinating a cross-functional launch), and the tool does its job for both. Treating the user base as if everyone wanted the same outcome collapses this, which is what the model exists to keep visible.
Definition
A model of user-base composition in which a single offering serves multiple distinct intents simultaneously.
Different intents, served at the same time
Users arriving at an offering aren't pursuing the same thing. They share enough surface behavior to look unified — sign up on the same page, hit the same first screen, fire the same analytics events — but the intents driving those behaviors cluster into distinct groups, each with its own sought state and its own evaluation of whether the offering is working. The multi-intent model names this composition so framework apparatus can act on it.
The intent-clusters are already present in the user base whether or not the team has surfaced them. The model describes the population that's there and supports apparatus that detects, qualifies, and serves it.
Measurement and routing under multi-intent
A framework assuming a single intent loses resolution in two places: measurement and routing.
In measurement, a singular milestone — one aha moment, one activation metric — computes correctly but its referent goes fictional under multi-intent. The number keeps moving while the intent the team theorized as anchoring it drifts away from what's actually driving the firings. Portfolio of milestones is the apparatus response: one milestone per theorized intent, so each cluster's progress can be read against its own resulting state rather than blending into an aggregate that no longer has a coherent referent.
In routing, a one-size-fits-all path serves whichever intent the path was implicitly built around and underserves the rest. Multi-intent is what justifies paths matched to theorized intent categories — and intent detection, the runtime operation that sorts arriving users into those paths. Neither apparatus has a reason to exist without multi-intent as a recognized condition of the user base.
Intents shift over time
Multi-intent isn't only a cross-sectional claim about who's in the user base. The same user holds different intents across time horizons: a first-session intent (complete first workout), an arc-level intent (build a fitness habit), a long-term intent (get fit). Each is a real intent with its own sought state, not a fragment of the others. Activation work targets the first; lifecycle work targets the others.
Within a single session intents can also shift — a user who came to set up an account can decide mid-flow to try the feature they came for, then return to setup afterward.
Example
A budgeting app's signups contain at least three distinct intent-clusters: users trying to get out of debt, users trying to save for a specific purchase, and users trying to track spending without changing it. Each cluster has a different sought state, responds to different parts of the offering, and has a different signal of success.
A single activation metric like "linked one bank account" collapses all three clusters into one fraction. Designing around that metric optimizes for whatever intervention moves the average. Per-intent milestones (debt paid down to threshold X, savings goal Y% reached, weekly spending categorized for four weeks) give the team three referents to track and design against independently.