There is a kind of product spec that opens with the words "Sarah is a 34-year-old marketing manager." We have all read them. We have all written them. They are almost always wrong, and they are wrong in a specific, expensive way: they let you rationalise any decision, because there is always a Sarah who would be fine with it.
The studio's pattern, looking back across four projects, is the opposite. Every system we have shipped or are shipping started with one named, real, reachable human and their actual problem. Not a persona. Not a segment. Not a market. A person, with a phone number.
This isn't a methodology we set out to follow. It's something we noticed after the fact. Once we noticed it, we stopped fighting it.
The four times this happened
Here is what we mean, with the four projects abstracted to roles:
The learning platform was built around the first learner — one specific young adult whose mum had explained the situation to us in two paragraphs. We did not start from "the un-self-motivated young-adult learner segment." We started from this learner. His habits. His attention span. The specific kind of nudge that works on him. The platform is subject-agnostic — it can teach anything — but the first version of it was shaped, opinion by opinion, by the question "would he finish this lesson?"
The personal-archive system was built around the family archivist — one specific person trying to reconstruct one specific parent's life from forty years of unsorted files. The architecture has implications for any family with a hard drive of old photos and screenshots, but the first cut of it was shaped by the question "does this archive surface what this person hopes to find?"
The job agent was built around the senior pharma professional — one experienced candidate whose previous job hunt had produced fifty applications and zero relevant offers. The system can serve any pharma candidate, and it will eventually serve other industries, but the first edition was tuned to the kind of mistakes he was making and the kind of jobs he was missing.
The auto-services booking system was built around the pilot shop owner — one specific auto-body shop, one specific roster of mechanics, one specific list of the things that go wrong on a typical day. The product is a per-shop SaaS, designed to be deployed at any independent shop, but every QR-flow, every handoff, every screen exists because this shop's owner pointed at something on the wall and said "this is the part that breaks."
The obvious point and the subtle one
The obvious point: building for a real user gets you a better product than building for a fictional one. This is not news. Anyone who has spent ten minutes near a real customer will agree.
The subtle point is the one that took us longer to see, and it is the reason we now refuse to start any new build without a named first user.
Building for a real person forces editorial restraint. When the user is a persona, every product decision is negotiable. You can rationalise any feature — "but some Sarah will love this" — because there are infinite Sarahs and they have infinite preferences. Persona-driven product is, structurally, a system for never having to say no.
When the user is a real human, you can't do that. The first learner won't open a course you would not actually want him to open. The pilot shop owner won't pay for a screen he doesn't need. The senior pharma professional will throw out a cover letter that doesn't sound like him. They will not "love it because they're a Persona B" — they will just close the tab and not come back. The system either works for the person whose name is on it, or it doesn't.
Which means: every feature now has to be argued for against a real human. Every flourish has to earn its place. Most don't, and most get cut. The product gets sharper. Not because you got better at design — because you can no longer hide behind anyone.
"A persona never closes the tab on you. A real first user does. That is the difference."
What the first user is not
It is worth being precise about this, because the move is easy to misread.
The first user is not a focus group of one. We are not asking the first learner what features the platform should have. He doesn't know. We are designing the platform; the first learner is the test surface.
The first user is not the only user. The systems are designed, from day one, to be subject-agnostic, multi-tenant, role-pluralised. The platform that motivates the first learner has to be able to motivate any learner. The shop's booking system has to work for any independent shop. The first user is the proof — they are not the boundary.
The first user is not a friend doing us a favour. They are someone with a real problem they are paying us, in time and trust, to remove. That changes everything. A friend will tell you the product is fine. A user with a problem will tell you when it isn't.
And finally, the first user is not a substitute for thinking. The thinking — the architectural choices, the ethical choices, the cost choices — is still on us. The first user shows us where our thinking is correct and where it is, with no malice, wrong.
Why this works at the studio's scale
This pattern is unfashionable in venture-funded product work. Most playbooks tell you to start with a market, build for an averaged target, ship to ten thousand at once. We are not doing that, and we are honest about why.
We are a small studio. We don't have product managers writing personas, and we don't have a pre-launch list of ten thousand prospects. What we have is the next person whose problem we are about to take seriously. The cheapest way for us to ship something good is to ship something good for that one person, and only then start to ask whether the same engine could serve more people. (We've written about that abstraction step — engine, first instance, market — in a separate note.)
The corollary, which we did not appreciate at first, is that this approach makes the studio's work feel honest. There's no "launch playbook," no "growth-hack roadmap." There's a person whose problem we promised to take seriously, and a system that — when it works — actually does that. It is impossible to fake.
The risk we accept
The honest objection to this pattern is that you can over-fit to one person. You can build a product that is genuinely brilliant for the first learner and that nobody else wants. We accept that risk. The way we manage it is to be deliberate, every time, about which decisions are about this user and which decisions are about people who look like this user.
"Doesn't like reading walls of text" is about people. "Likes the colour green" is about this user. The first goes into the system; the second does not. The discipline is in the difference. It is harder than persona-driven product because there is nowhere to hide — you have to actually decide, every time, whether a constraint is universal or particular. But the answer is usually clearer than you'd think.
What to do with this if you're building something
Three things, if any of this resonates.
Don't start your next build with a persona document. Start it with a name. If you can't name a real person whose problem this product is going to remove, you're not ready to build it. You're ready to keep researching it.
Pick someone whose problem is real and slightly inconvenient to you. The temptation is to pick someone easy — a friend who'll be polite, a teammate whose problem is well-bounded. Those are the wrong choices. Pick someone whose problem is genuinely difficult, who will tell you when the thing is broken, and whose use case will stretch your assumptions. The discomfort is the value.
When the time comes to abstract upward, do it deliberately, not by accident. The move from "this works for one person" to "this works for many" is its own design problem. It requires knowing which choices were universal and which were particular, and re-examining each one. It is a different skill from the first build — and it is not where the first build should rush to.
The final thing we'd say is this: be willing for the first version of your product to be slightly embarrassing in its specificity. The first learner's name, the first shop's quirks, the first archivist's family — those things show up in the early versions of every system we've built. That's the right shape. Sand them off too early and you've sanded off the spec.
If you're sitting on a project that doesn't yet have a name attached to it — that's the kind of conversation our 30-min calls are for. Book one.