Personas & Jobs

Building for everyone builds for no one. The car-plane hybrid is the classic demo: it tries to serve the driver and the pilot and ends up useless to both. Every strong product is sharp about who it’s for, and that sharpness is the first thing the symptom-collector skips. “The search bar is too narrow” names no one. The word “users” is where product thinking goes to die.

Before you judge a screen, you name the people who use it, understand what each is trying to get done, and decide which one you’re building for right now. That’s this doc.

Name the Personas#

What’s expected: For any product or module, you can name the two to four distinct people who use it, described by their situation and their goal, not by a job title alone.

What good looks like: Each persona is specific enough that you can picture their day. You know how often they show up, what they came to do, and what “a good day” with the product looks like for them. You are not listing everyone who could theoretically touch the product; you’re naming the ones whose success the product exists to create.

Every product has a small cast like this, usually two to four people. A food-delivery app has the eater who wants a good meal fast, the courier who wants efficient routes and fair pay, and the restaurant that wants orders without hassle. A messaging app has the sender and the recipient. Name yours before you judge a single screen.

We’ll ground the rest of this group in one running example, the Storefront, an online store whose goal is completed orders, the same store the Strategy group uses. The symptom-collector treats it as one undifferentiated surface. A product thinker sees three people with different jobs, different frequency, and different definitions of success:

Notice what naming them does. “The search bar is too narrow” now has an owner: it’s the shopper’s problem, on the path to finding a product. “The filter forgets my selection” is the shopper’s problem too, mid-browse. And an entire category of problems the original list never mentioned, the shopper who abandons at checkout rather than re-type an address, suddenly has a seat, because nobody was walking the store as a shopper trying to pay.

How to get there: Walk the customer journey for each persona and ask, at each step, who is on the screen and what they came to do. If you can’t tell one persona’s day from another’s, you haven’t found the personas yet; you’ve found roles.

Jobs, Not Features#

What’s expected: For each persona, you can state the job they hire the product to do, in the form of an outcome, not a feature.

A persona wants an outcome. They “hire” your product to get it. This is the idea of jobs-to-be-done: people don’t really buy products, they hire them to make progress on some job in their life, and they’ll fire yours the moment something does the job better. The classic example: a fast-food chain found people bought morning milkshakes not for the taste but to have something to do during a long, dull commute. The job was “make my commute bearable,” and the real competition wasn’t other milkshakes, it was bananas, radio, and boredom. The feature is your answer to the job; it is never the job itself. Confusing the two is how you end up widening a search bar while the shopper is quietly failing at the thing they actually came to do, buy.

• Feature framing: “The checkout form should remember my address.”
• Job framing: “As a shopper, I want to pay and be done in seconds, so a full cart doesn’t turn into a chore I abandon.”

The job framing is bigger, and it’s more useful, because it admits more than one solution. Remembering the address is one answer. One-tap express pay is another. Guest checkout with no account at all is a third, and probably the one that wins. You only see those options if you framed the job instead of the fix. Write jobs as user stories: as a <persona>, I want <outcome>, so that <benefit>. Three to five per persona is plenty; if you have twenty, you haven’t prioritized.

One tip that separates good from great: once the basics work, aspirational needs beat more pain relief. Fixing what’s broken keeps a persona from leaving; giving them something they couldn’t do before is what makes them stay and tell others. So the strongest jobs to aim for are often the ones the persona didn’t know to ask for, “buy in one tap,” not “make the form less annoying.” One caveat we’ll return to in Prioritization: a broken basic still jumps the queue, because trust breaks faster than it builds. Aspiration wins after the table stakes are solid, not instead of them.

Pick the One That Matters#

What’s expected: You’ve chosen one persona to build for right now, and you can defend why over the others.

Time and capacity are finite. You cannot advance three personas in one initiative without doing all three at half strength. So you choose. The rule is simple and it’s the same rule that governs everything else in product: pick the persona whose success moves the goal the most.

How to get there: Weigh the personas against a few dimensions and let the goal break the tie:

• Impact on the goal. The Storefront’s goal is completed orders, and the shopper’s checkout is that number. Their friction is costing us orders directly. That’s why the shopper is the prioritized persona here: they sit on the exact step the goal is made of.
• Volume and frequency. The operator lives in the admin all day, so a small improvement compounds across every product and promo. The shopper visits briefly. Frequency changes the math for whose small wins add up.
• Connectedness to the mission. If the store exists to make buying effortless, the shopper is the center of gravity. Build outward from them.
• Who’s underserved today. Sometimes the highest-leverage move is the persona nobody has built for yet, the shopper trying to pay, not browse, is exactly the one the cosmetic list forgot.

Choosing does not mean the others don’t matter. It means you’re honest that this initiative serves one of them best, and you sequence the rest. A product that claims to serve everyone equally in every release is a product with no point of view, which is a product that loses to one that has.

The Anti-Patterns#

Next: Pain Points & Winning