The Playbook for Finding Your Minimum Viable User

Not the smallest product you can ship — the smallest group of people you can serve repeatably with the same thing. A six-step playbook for finding that group before you build for anyone.

I recently watched a YouTube video from Harvard Innovation Labs called Create a Product People Will Actually Buy. In the video, the speaker introduced a concept I had never heard before: Minimum Viable Segment, or MVS.

He defined it this way:

We talk a lot about MVP — the minimum viable product. Build the smallest version, test it, learn from the market, and iterate. But this idea of MVS made me pause, because it shifts the question from "What is the smallest product I can build?" to "Who is the smallest group of people I can repeatedly serve with the same product?"

A product does not become viable just because it is small. It becomes viable when it meets a real need for a specific group of people with enough consistency that the same solution can work more than once.

Since watching that video, I have gone down a rabbit hole of reading and watching resources around customer discovery, Jobs to Be Done, early adopters, user interviews, and product-market fit. This post is the result of that research — a playbook for finding that person, in six steps.

Start with the smallest audience worth serving

One of the most useful starting points is Seth Godin's idea of the minimum viable audience. He argues that two things will happen when you delight your minimal viable audience: first, you discover that this group is much larger than you expected. Second, they start telling others.

If you try to make everyone happy, you end up making no one truly happy. A smaller audience forces clearer decisions: who the product is for, what problem matters most, and what language resonates.

Kevin Kelly's 1,000 True Fans extends this from another angle — a creator or independent business does not need mass attention to be sustainable; a smaller group of deeply engaged people can create momentum if the relationship is direct and valuable: "It's a much saner destiny to hope for. And you are much more likely to actually arrive there."

For founders, the practical lesson is that "everyone" is rarely a useful starting point. Even labels like "founders," "creators," or "small business owners" are usually too broad to guide product decisions. A more useful starting point might be: solo founders who have spent several months developing an idea but still don't know whether the core problem is strong enough to support a product. That level of specificity makes the user easier to understand, reach, and learn from.

Move from audience to user

An audience and a user are related, but they are not the same. An audience consumes content, follows updates, or expresses interest. A user interacts with a product in order to accomplish something — they bring expectations, constraints, existing habits, and alternative solutions.

This distinction matters because early product feedback is only useful when it comes from people who are close to the problem. General encouragement creates the appearance of interest, but it doesn't reveal whether the product solves a meaningful problem. A strong early user has context: they've already experienced the pain, attempted to solve it, and can compare your solution against their current behaviour.

It's also worth naming a trap here. It's tempting to assume your early adopters are your high-expectation customers (HXC), but that's not always true. Failing to draw the distinction can quietly hurt a young company. Julie Supan's work defining the target user for Airbnb, Dropbox, and Thumbtack pushes for identifying the most discerning person who gets the product's greatest benefit, rather than whoever happens to show up first. The earliest, loudest users and the users you're actually building for are not automatically the same people.

A minimum viable user can therefore be defined as the smallest, most specific group of people who experience the problem frequently enough, painfully enough, and urgently enough that they are willing to engage with an early solution. They don't need a perfect product. The right early users are often willing to tolerate rough edges if the product addresses a problem they genuinely care about.

Understand users through situations, not demographics

Many early product descriptions lean on demographic or professional labels: founders, creators, parents, students, freelancers, coaches, consultants. These are useful for orientation, but they rarely explain why someone would adopt a product.

The Jobs to Be Done framework offers a more precise lens. Clayton Christensen's milkshake example shows that people don't simply buy products because of who they are demographically — they "hire" products to make progress in a specific situation.

So instead of "founders," it may be more useful to say: founders who are unsure whether an idea is strong enough to justify further investment of time, money, and energy.

Learn how to talk to users without collecting false validation

Once the user is clearly defined, the next challenge is learning from them without distorting the signal. Early conversations mislead when the questions are too hypothetical or too focused on your idea.

Rob Fitzpatrick's The Mom Test is the most practical resource on this. The central argument: people give supportive or speculative answers when asked directly about an idea. This isn't dishonesty — the question simply makes it easy to respond politely without revealing real behaviour.

YC's guidance reinforces the same principle: strong user conversations focus on past behaviour, current workflows, existing alternatives, and concrete examples. Instead of asking whether someone would use a product, ask when they last experienced the problem, how they handled it, what tools they used, what they disliked, and whether they've paid to solve it before.

This matters because early-stage founders are surrounded by weak signals. Compliments, signups, free trials, and casual interest indicate curiosity, not urgency. Behavioural evidence is stronger. If someone has already spent time, money, or repeated effort trying to solve the problem, their feedback is far more likely to reveal a real opportunity.

Find first users by doing things that do not scale

After defining the user and improving the quality of conversations, the next question is how to find the first ones. At this stage, scalable channels matter far less than direct access to the right people.

Paul Graham's Do Things That Don't Scale remains the clearest explanation of this phase. Early growth usually requires manual, personal, unglamorous work: direct outreach, individual onboarding, detailed follow-up, and close observation of how people actually use the product.

Lenny Rachitsky's research shows the same pattern at scale — many successful products began with highly manual acquisition. The first users came from communities, personal networks, niche groups, direct conversations, or carefully chosen environments where the problem was already visible.

The goal isn't to increase traffic. It's to get close enough to the right users to understand their context, language, objections, and existing habits.

Evaluate whether early users are the right users

Not all early users are equally informative. Some are curious but not committed. Some like the category but don't feel the problem strongly.

So it's important to distinguish general interest from strong user pull. Superhuman's product-market fit framework is useful here. Rahul Vohra's team surveyed users with one question — how would you feel if you could no longer use the product? — and treated the share answering "very disappointed" as the signal that mattered.

But the most instructive part isn't the question; it's what they did next. When the first survey came back at 22%, they didn't rebuild anything. They segmented the responses by persona and recalculated the score counting only the segments that already loved the product. It jumped from 22% to 32% without a single product change — purely by getting more precise about who the user was. That's the whole thesis of this playbook in one data point: defining the user is itself a lever, not just preparation for building.

For an early product, you can apply the same principle more simply. Useful questions: how would you feel if this product disappeared; what type of person would benefit most from it; what is the main value you receive; what almost stopped you from using it; and what would make it significantly more useful? One of the most valuable questions may be: "What type of person do you think would benefit most from this?"

The early goal is not to prove that everyone wants the product. It's to find a small group of people whose needs are clear enough, whose current workarounds are visible enough, and whose feedback is specific enough to guide the next version. That, in the end, is what the Minimum Viable Segment was pointing at all along: not the smallest product you can ship, but the smallest group of people you can serve repeatably with the same thing.

Before building for a market, it may be better to find the first few people who can teach you what the market actually is.