The Use Case Map (Use Cases, Not Personas)
Define what to build and how to grow from the use case, not the persona.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- —
Balfour argues the actionable meat lives in the use case, not the persona. A use case is a specific combination: the problem, the value prop against it, the alternative the user has, and — most importantly — why they choose you over that alternative. Once defined, the use case's natural frequency (how often someone encounters the problem) drives your retention and activation metrics, and the natural frequency of adoption drives acquisition. Reforge captures this in a 'use case map' — a set of ordered rows developed with Casey Winters and Sean Clause. Define use cases first, then ask who has them (often surprising people you'd never find via persona research). Beware mapping eight use cases — that means you're trying to solve too much.
Origin
Developed in Reforge's retention program with Casey Winters and Sean Clause; Balfour contrasts it with persona segmentation and relates it loosely to jobs-to-be-done.
Core principles
- 01The use case, not the persona, tells you what to build.
- 02Why-you-over-the-alternative is the differentiation core.
- 03Natural frequency of the problem sets retention/activation.
- 04Natural frequency of adoption sets acquisition.
How to run it
- 1
Define the problem
Start the use case with the specific problem the user is trying to solve.
- 2
State value prop and alternative
Name the value prop against that problem and the alternative the user currently has for solving it.
- 3
Nail why-you-over-the-alternative
Articulate why the user chooses you over the alternative — this is the differentiation, and it's the component teams most often skip.
Pro tip This 'why you' is the most important row in the map.
Watch out Mixing up these components leaves the map without a usable differentiation.
- 4
Derive growth metrics from frequency
Use the natural frequency of the problem to define retention and activation metrics, and the natural frequency of adoption to define acquisition metrics.
Pro tip Many SaaS buyers are only in-market once every few years — plan to build a relationship before they're in-market.
- 5
Then ask who has the use case
Only after defining use cases, ask who has them — you'll often find winnable people persona research would have missed.
Watch out If you map ~eight use cases, you're trying to solve too much — narrow down.
In the wild
Because SaaS buyers are in-market rarely, HubSpot built a relationship via inbound content — many people knew HubSpot only as a blog — so when they entered the market for the tool, HubSpot was the first place they went.
→ Reduced acquisition friction by owning the relationship before the buying moment.
Common mistakes
Segmenting by persona first
Leading with personas yields segmentation that doesn't tell you what to build or how the growth model works, and misses winnable non-obvious users.
Solving too many use cases
Mapping around eight use cases signals you're trying to serve too much at once, diluting product and growth.
Is it for you?
Best for
Product and growth teams defining what to build and how to acquire and retain.
Not ideal for
Teams that need persona demographics for brand/creative targeting specifically.
From the episode
Brian Balfour: 10 lessons on career, growth, and life