You have made something.
Perhaps it is still rough, but it exists. You have a few pages of the book, a first version of the workshop, a prototype of the tool, a sample offer, a draft website, a short course, or a process you believe could make someone’s work easier.
You can see everything that still needs improvement.
The wording could be tighter. The design could look better. The instructions need another pass. The workshop could use another example. You have already spotted three things you want to add and five things you are not completely sure about.
So you keep working.
That feels reasonable. You care about the work, and you do not want to waste anyone’s time with something unfinished.
But there comes a point when another hour of private polishing teaches you less than ten minutes with the person you hope to help.
That is when the question changes.
Not:
What else should I improve before anyone sees this?
Ask:
Who can use this now?
One real person is enough to begin.
The work changes when another person enters it
When you build alone, you know too much.
You know what every button is supposed to do. You know why the third step comes before the fourth. You understand the framework because you created it. When you read your own paragraph, your mind supplies meaning that may not actually be on the page.
You cannot unknow what you know.
This is why private evaluation eventually reaches a limit. You can ask whether your idea is clear, useful, easy, relevant, or valuable, but you are still answering as the person who built it.
Then somebody else enters the work.
They pause where you expected them to continue. They skip the explanation you thought was essential. They misunderstand a phrase that seemed obvious to you. They immediately use the part you almost removed. Sometimes they find a use you never imagined.
That moment is not an interruption in building.
That moment is building.
The work is finally meeting a mind, situation, and set of assumptions that did not help create it.
Reality has entered the design.
You are not looking for an audience yet
There is a reason I want to keep the number small.
If I told you to launch, publish publicly, or gather an audience, the problem would immediately become larger. You might start thinking about a website, an email list, social media, promotion, branding, reputation, and how hundreds of strangers might respond.
Those are legitimate challenges. They belong later.
Right now, visibility is not the goal.
Learning is.
If you are writing a guide for newly promoted supervisors, you do not need five thousand supervisors. You need one supervisor who is currently living through the situation your guide is supposed to help with.
If you are creating something for parents of teenagers, you do not need an online parenting community to vote on the idea. One parent facing the actual moment can teach you something.
If you are developing an exercise for a workshop, you do not need a conference room filled with participants before you can learn. Let one person try the exercise instead of spending another hour adjusting the slide.
The first person gives reality a seat at the table.
Waiting until you are proud of it makes sense
The Familiar Play is to wait until the work feels presentable.
There is good reason for that. Nobody wants to look careless. If your name is attached to something, you want it to reflect what you can do. You may also believe that early criticism could damage an idea before it has had a fair chance.
Sometimes waiting is responsible. If people can be harmed by a bad first version, test carefully. If the work involves safety, health, legal commitments, money people cannot afford to lose, or consequences that cannot easily be reversed, “just ship it” is poor advice.
But many projects do not carry that kind of risk.
The guide can be revised. The exercise can be changed. The draft can be rewritten. The prototype can be replaced. The service can be delivered manually before a permanent system exists.
In these situations, waiting has another cost.
You are delaying the learning that only use can produce.
Suppose you spend three months building a course. You create twelve modules, dozens of slides, videos, exercises, templates, and assessments. Then the first group arrives and you discover that participants already understand most of the content. What they actually struggle with is one difficult conversation they keep avoiding.
You could have discovered that much earlier.
Every private assumption that could have met reality earlier creates a kind of design debt.
The more you build on an assumption, the more expensive it becomes to discover that the assumption was wrong.
I look for first listeners before the book is finished
I learned this through writing.
There was a time when I thought a book should be completed before readers encountered it. The writer writes. The reader reads. That seemed like the natural sequence.
I work differently now.
When I am developing an idea, I often look for a first listener before the book is finished. I talk to someone I hope the idea will serve. I tell the story. I explain what I am trying to say. Sometimes I show a page or a rough section and ask a simple question such as, “Does this make sense to you?”
Then I listen.
A question can expose a gap I could not see. A story the person tells may show me that I have described the situation too abstractly. Something I thought needed three pages of explanation may already be obvious. Another idea I considered obvious may need much more care.
The person is not writing the book for me.
But the conversation changes what I can see.
Over time, this has changed the way I think about authorship. When I write for people, I share what I know. When I write with people close enough to the work, I often discover what I did not yet know.
The same principle applies to almost anything you build.
You do not have to finish the thing before reality is allowed to participate.
Praise can keep you ignorant too
Showing your work to another person is not automatically useful.
You can show a friend your idea and hear, “This is great.”
You can present a framework and receive compliments.
Someone can tell you the workshop sounds interesting, the business idea is clever, the website looks professional, or the book will surely help people.
It feels good.
It may also tell you almost nothing.
A person can admire a framework and never use it. They can praise a presentation and forget it tomorrow. They can tell you they would buy something and behave very differently when buying becomes real.
The purpose of the first encounter is not approval.
You are trying to discover what happens when the work is used.
Instead of asking, “Do you like this guide?” give it to someone facing the problem and see whether the guide helps them make the decision.
Instead of asking, “Is this workshop activity good?” let someone try the activity.
Instead of asking, “Would you use this tool?” put it in front of them when the relevant moment arrives.
Use gives you information that opinion often cannot.
The real enemy is protecting the idea from evidence
Fear of criticism is part of the problem, but I think something deeper often keeps builders hidden.
We are protecting the story we currently believe about the work.
In that story, the book makes sense. The product is useful. The offer solves the problem. The tool is simple. The framework is easy to understand.
While the work remains private, that story can survive almost anything.
Actual use is less cooperative.
If someone cannot find the next step, perhaps the next step is not clear. If they repeatedly ignore the feature you love, perhaps the feature matters more to you than it does to them. If they solve the problem without the part you thought was essential, perhaps the design can become much simpler.
A harsh opinion is surprisingly easy to dismiss.
You can tell yourself the person did not understand. They were not the right audience. They were having a bad day.
Behavior is harder to explain away.
That is what makes unfinished work uncomfortable to show. The risk is not only that someone will judge what you made.
The evidence may force you to change what you believe about it.
Reality is useful because it does not have to preserve the builder’s assumptions.
Change the question
The Familiar Play asks:
Is this ready for people to see?
That question can delay you indefinitely because “ready” keeps moving. There is always another sentence to polish, another feature to add, another example to improve.
Try another question:
Is this useful enough for one real person to try?
Now the standard becomes more concrete.
Perhaps you have only the first three pages of the guide. Are those three pages enough for someone to make the decision they are designed to help with?
Perhaps the workshop is still mostly a sketch, but one exercise is complete. Can someone run it?
Perhaps your service does not yet have packages, automation, or a beautiful website, but you understand the problem and can serve one person manually. Can you help them?
You are not asking the first encounter to prove the whole project.
You are asking it to teach you something the next version needs to know.
Choose someone close to the problem
Not everyone is equally useful as the first person.
You do not necessarily need an expert. Experts sometimes understand too quickly because they already know the concepts you are trying to explain.
You need someone close to the person the work is meant to serve.
If you are building for first-time supervisors, find someone who is actually learning to supervise. If you are creating something for people trying to find their first consulting client, a consultant with forty regular customers may understand your method but no longer experience the same problem.
The first person does not have to represent your whole market.
In fact, do not ask them to.
They only need to make the problem real.
That also protects you from an easy mistake: showing the work only to people who understand you rather than people who need it.
Watch before you explain
Builders have an instinct that can ruin a useful test.
We help.
The person pauses, so we explain. They misunderstand a sentence, so we tell them what it means. They cannot find a feature, so we point directly to it. They skip a step, so we show them the correct sequence.
Soon the test works beautifully because the builder is doing half the work.
Stay quiet a little longer.
You are not trying to make the person fail, and you should never turn the test into a trick. Help when help is genuinely needed. But before you rescue the experience, notice what happened.
If they ask a question, where did the question come from?
If they skip a step, was the step unnecessary or merely invisible?
If they use a different word from yours, listen carefully. Their language may describe the situation better than yours does.
If they cannot proceed without you, do not immediately blame them for misunderstanding.
You may have learned something important:
the work still depends on the builder.
That is exactly the kind of thing a first test should reveal.
Look at what they do before asking what they think
After the person uses what you made, ask questions.
But begin with what happened.
Did they complete the task? Where did they stop? What did they reach for first? What did they ignore? Did they return to an earlier section? Did they improvise? Did they change the thing to make it work? Did they use it again without being reminded?
Behavior can reveal value that people struggle to describe.
Someone may tell you the entire guide was clear while repeatedly returning to only one page.
A participant may say every part of the workshop was helpful but photograph only one template.
A customer may praise five features but keep using one.
Do not treat those behaviors as a final explanation. You still need judgment and conversation.
But notice them.
Comments tell you what a person can report. Behavior shows you what the work caused them to do.
Both matter. They are not the same kind of evidence.
One person is enough to learn, not enough to declare victory
There is an important boundary here.
One person can expose a broken instruction.
One person can reveal language that makes no sense.
One person can show you that a feature you considered obvious is invisible.
One person can discover a use you never imagined.
That is valuable evidence.
But one person cannot tell you that everybody wants the thing, that you have discovered a market, that the design will work everywhere, or that the project is now proven.
Do not turn one encounter into a universal claim.
One person is enough to make the work more truthful. One person is not enough to make the truth universal.
Eventually another person should enter. Then another.
You begin looking for patterns: where people hesitate, what they repeatedly use, which questions keep returning, and where contexts differ.
But you have to earn the pattern.
For now, one person is enough to stop guessing entirely in private.
Try the One Real Person Test
Take something you are building that is useful enough for another person to experience. Then run one small test.
- Choose someone living close to the problem. Do not choose them because they will be kind. Choose them because the situation is real for them.
- Give them something they can actually use. A page, play, tool, exercise, prototype, conversation, manual service, or other Minimum Lovable Version is enough.
- Watch before you rescue. Give the work a chance to show where it is clear, where it creates friction, and where it still depends on you.
- Ask about what happened. Ask what they were trying to do, where they hesitated, what they expected, what they found useful, and what surprised them. Do not spend the conversation defending the design.
- Write down one thing you now know that you did not know before the encounter. That is your first win.
Notice what is deliberately missing from this play.
You are not yet deciding which feature to add. You are not rebuilding the entire product based on one opinion. You are not asking one person to design version two for you.
Those questions belong to the next stage.
For now, let the encounter produce evidence.
The first win is not praise
The person may like what you made.
Wonderful.
But praise is not the most useful outcome of this article.
The first win is discovering something about the work that you could not have learned while building alone.
Perhaps the person solved the problem faster than you expected.
Perhaps your instructions confused them.
Perhaps they ignored half the thing and got the result anyway.
Perhaps they asked a question that changed the way you understand the problem.
Perhaps your test shows that the work still depends too heavily on you.
Any of those can be more valuable than “This is great.”
Before the first real person enters, version two usually comes from imagination.
You add more polish, more explanations, more features, more content.
After the first person enters, version two can finally have a reason.
Follow the proof
Sometime in the next seven days, put one piece of unfinished but usable work in front of one person who genuinely lives close to the problem.
Do not ask them to validate your ambition.
Watch what happens.
Pay particular attention to the moment you feel the urge to explain, defend, or rescue the work. That moment often contains useful evidence.
Then write down three things: what the person actually did, where the work needed you more than you expected, and what surprised you.
Do not rush to change everything.
One person gives you a clue, not a command.
The next article, Let Feedback Change the Work, Not the Purpose, will help you decide what the evidence deserves to change and what should remain protected.
For now, your job is simpler.
Stop asking whether the work looks ready from where you stand.
Let someone else stand in front of it.
See what the work can do without you.
Then let what happened make the next version more truthful.
Continue the Path
Return to Build Something when you want to see where one real person fits in the larger movement from idea to evidence.
Go back to Build the Minimum Lovable Version when the thing is still too large or incomplete for another person to experience one useful win.
Continue to Let Feedback Change the Work, Not the Purpose when several comments, requests, and observations begin competing for your attention.
And later, use Create Your Stage when the work has learned enough from small encounters that the challenge is no longer private testing but helping more people discover, experience, and trust what you have made.
Do not ask the first person to prove the idea. Let them make the idea more truthful.