You may have started with something simple.
A short guide for people who keep asking you the same question. A workshop around one recurring problem. A small service for one kind of customer. A tool that makes one frustrating task easier. Perhaps you want to write a book, organize an event, start a community, or turn an idea you have been carrying into something other people can finally use.
Then you begin thinking seriously about it.
The guide needs more chapters. The workshop needs another module. The service needs packages, forms, and a website. The book needs research, stories, illustrations, exercises, a launch plan, and perhaps a companion workbook. The event needs speakers, sponsors, registration, publicity, and a program people will remember.
Nothing you are adding seems foolish. In fact, most of it makes sense.
That is what makes the trap difficult to see.
The thing becomes more complete in your imagination. It also becomes harder to put into the world.
When something matters to us, we do not want to give people weak work. We want the first version to represent what we are capable of. We want people to understand the whole idea, experience the full value, and perhaps even say, “This is impressive.”
Care is good.
But there is a point where care makes version one so large that nobody gets to use it.
That is when I want you to build a Minimum Lovable Version.
Your first version has a smaller job than you think
Version one does not have to prove the entire idea.
It has to create one useful enough experience that you can discover whether the idea deserves another version.
That is a much smaller job.
Suppose you want to build a leadership program for first-time supervisors. You know they need help with communication, delegation, feedback, coaching, motivation, accountability, decision making, and team leadership. You could build six or eight modules, and every module could be defended.
But the supervisor does not experience “leadership development” at 10:15 on a Tuesday morning.
She experiences a moment.
She gives someone an assignment, assumes the instruction was clear, and discovers several hours later that the work went in the wrong direction. Now she is frustrated, the employee has to redo the work, and both of them have lost time.
You could build something for that moment.
Perhaps the first version is one simple play: state the expected result, show what good looks like, then ask the employee to explain back what they understand before the work begins.
That is not a complete leadership program.
It does not need to be.
If supervisors can use it and reduce avoidable rework, something useful has happened. Now the larger program has evidence to build from.
I learned this from an imperfect newsletter
When I sent one of my first email newsletters, I felt proud for about two minutes.
Then I started worrying.
Did I misspell something? Was one sentence too long? What would real writers think if they read this?
Later, I discovered that I had indeed missed a few commas. Some of the sentences were not exactly literary masterpieces.
But something else happened.
A manager printed the emails, compiled them almost like a small book, and shared them with his team. Readers wrote to me and told me about ideas they had used. That little newsletter eventually helped create paid workshop opportunities.
Meanwhile, there were other newsletters I kept revising because I wanted them to be better before I sent them.
Those accomplished nothing.
They remained perfectly invisible.
The newsletter that entered the world was rough enough for me to notice everything that could still be improved. But it was useful enough for somebody else to keep, share, and use.
That difference matters.
The lesson is not that bad work is better than good work.
The lesson is that usefulness can survive imperfection, but an idea cannot learn while it remains invisible.
Start ugly does not mean ship careless
For years, I have kept a notebook in Evernote called Crappy First Drafts.
Workshop designs begin there. Books begin there. Speech outlines and strategic plans begin there. I expect those first versions to be rough because their job is to help me see the work.
I call this starting ugly.
When I write, I sometimes talk through an idea before trying to make the sentences elegant. I allow fragments, awkward phrases, incomplete thoughts, and things I will probably remove later. There is a time to create and a time to edit. Trying to do both at once can stop the work before it has anything to say.
That rough draft is useful.
But notice who it is useful to.
The ugly draft is for the builder.
It gives you something you can see, question, cut, rearrange, and improve.
A Minimum Lovable Version has a different responsibility.
The Minimum Lovable Version is for the user.
It may still look simple. It may still lack features. It may still be far from the version you eventually imagine. But somebody should be able to use it and experience enough of the promise to decide whether it helped.
That gives us an important boundary:
A Minimum Lovable Version is allowed to be ugly. It is not allowed to be useless.
Your first move is not always your first version
There is another distinction worth making.
In Move First, the challenge is often to make the beginning small enough that you can actually enter reality. A first move should be possible with the resources you have now and meaningful enough that something becomes different.
If you want to write a book, your first move may simply be writing one rough page.
If you want to build a workshop, your first move may be writing the one question participants should be able to answer differently.
If you want to start a business, your first move may be talking to one person who experiences the problem.
Those moves matter because they get you moving.
A Minimum Lovable Version asks for something slightly different:
What is small enough for you to build, but useful enough for someone else to use?
Your rough page may get you moving.
A twelve-page guide that helps one reader solve one complete problem may be your Minimum Lovable Version.
The distinction is simple:
A first move must be possible. A Minimum Lovable Version must be usable.
More is not the same as more useful
Builders often know too much.
If you know leadership, you can name twenty ideas that belong in a leadership program. If you understand strategy, you can explain models, tools, planning processes, execution rhythms, scorecards, and reviews. If you have spent years learning a craft, almost everything feels connected to everything else.
That makes subtraction difficult.
We start thinking that leaving something out means giving people less value. So we add another chapter, another activity, another feature, another worksheet, another explanation.
The thing gets larger before it gets wiser.
But the person using what you build does not encounter your whole field of knowledge at once. They encounter a particular situation where something needs to become easier, clearer, faster, safer, more useful, or newly possible.
Build for that moment.
The first version does not need to represent everything you know.
It needs enough of what you know to help create one meaningful win.
Define the first useful win
Before deciding what version one contains, name what the person should be able to do because it exists.
Try completing this sentence:
The first useful win is when ______ can ______ in the moment when ______.
A first-time supervisor can confirm that an employee understands the expected result before work begins.
A reader can choose the next move on a project she has delayed.
A small-business owner can send a clear quotation without rebuilding one from scratch every time.
A teacher can help students publish one piece of writing for real readers.
A parent can create one uninterrupted family meal during the week.
Notice what happens when the win becomes clear.
You now have a way to judge what belongs in version one.
Not:
Is this a good idea?
Many things are good ideas.
Ask:
Does this help create the first useful win?
If it does, it may belong now.
If it does not, it may belong later.
And some things may not belong at all.
Minimum protects scope
Minimum does not mean doing the least work possible.
It means refusing to make the first useful win carry everything the future may eventually require.
If the book can create its first win with a short guide, do not make twenty chapters the entrance fee for learning.
If five people can test the community experience, do not wait for five hundred members.
If a manual service can solve the customer’s first problem, you may not need automation yet.
If one sixty-minute session can help participants practise one important play, do not make a two-day program necessary before anyone can experience it.
But be careful here.
Do not shrink the version by removing something the useful win actually requires.
If three moves are necessary for the person to complete the task well, removing one simply because you want the version to be smaller does not create a minimum version. It creates a broken one.
Cut breadth. Protect the useful path.
Minimum protects you from overbuilding. It does not protect you from doing the essential work.
Lovable protects the user
I use the word lovable deliberately.
Not because version one needs beautiful packaging.
Not because people need to fall in love with your logo.
A lovable version earns affection through usefulness.
People keep it because it helps. They return because it makes something easier. They tell another person about it because it solved a real problem. They ask when the next session will happen. They request another copy. They bring the practice into another situation.
Lovable is visible in behavior.
The first newsletter was not lovable because every sentence was polished. It became lovable because somebody printed it, shared it, used it, and wanted the ideas to travel further.
That is the standard.
You are not asking:
How little can I get away with?
You are asking:
What is the smallest version that can create a real win for someone?
Version protects learning
The third word may be the most important.
Version.
Version one is not a declaration that you have figured everything out.
It is a form the idea takes long enough for reality to answer it.
That means it is allowed to change.
The guide may become shorter. The workshop may become longer. The course may become a coaching service. The event may become a community. The tool may become a checklist. A feature you thought essential may disappear after nobody uses it.
That is not necessarily failure.
It is what the word version gives you permission to discover.
So I think about a Minimum Lovable Version this way:
Minimum protects scope.
Lovable protects usefulness.
Version protects learning.
Hold all three.
Without minimum, you may spend too long building before you learn.
Without lovable, you may call careless work an experiment.
Without version, you may become so attached to what you made that new evidence feels like an attack.
Do not make version one prove who you are
There is another reason we overbuild.
Sometimes version one is carrying our identity.
The trainer wants the first workshop to show how much she knows. The consultant wants the methodology to look substantial. The writer wants the book to prove he is a serious author. The entrepreneur wants the first customer to see a business that looks much larger and more established than it really is.
I understand that instinct.
We want people to trust us.
But the more version one has to prove about the builder, the less freedom it has to learn from the user.
This is what I was doing when I kept some newsletters in drafts. I wanted the sentences to protect me from being judged as an inexperienced writer.
The newsletter that I actually sent did something more useful.
It helped somebody.
We ask version one to protect our identity when we should be letting it teach us what the work needs to become.
Your first version does not have to prove that you belong among experts.
It has to be useful enough to deserve another encounter with reality.
Three thresholds can help
It helps to know what stage of the work you are actually in.
The Ugly Draft is useful to you. It gets the idea out of your head and into a form you can examine.
The Minimum Lovable Version is useful to someone else. The essential path works well enough that a real person can experience the first useful win.
The Next Version is earned by evidence. Actual use begins telling you what should be strengthened, removed, changed, or expanded.
Do not demand that the ugly draft already be lovable.
And do not demand that the Minimum Lovable Version already look like the final product.
Each version has a job.
Confusion begins when you ask the first one to do the work of all three.
Try the One Win Version Play
Take the project you are building now.
Do not ask what the complete version needs. Start with the person and the moment.
Write:
The first useful win is when ______ can ______ in the moment when ______.
Then look at everything you currently think version one requires.
Run each item through one question:
Does this help create the first useful win?
You may discover three kinds of things.
Some are needed now because the win cannot happen without them.
Some are useful later because they may improve, expand, automate, explain, or scale something that first needs to work.
And some are simply not needed. They entered the project because they were interesting, impressive, familiar, or expected.
Remove what version one does not need.
Then build the useful path all the way through.
Do not leave the user halfway to the result just so you can say you launched something small.
Minimum Lovable does not mean half-working.
It means narrow enough to learn, complete enough to help.
The first win belongs to the user
Builders naturally celebrate builder milestones.
The website is live.
The book is finished.
The workshop slides are complete.
The app is working.
The event happened.
Those milestones matter. You made something real.
But they do not yet tell you whether the thing mattered.
A website matters when the person who arrives can find what she needs and make the next decision.
A book matters when a reader understands something differently or makes a move because of what she read.
A workshop matters when somebody can use the play after the workshop.
A tool matters when it makes the work easier, clearer, faster, safer, or more reliable.
The builder produces the thing. The user produces the proof.
That is why the Minimum Lovable Version needs one useful win.
Without it, you can finish version one and still have no idea whether anything became better because it existed.
Let one real person answer
Once the version is usable, your next temptation may be to keep improving it privately.
Resist that.
You have reached the point where more private thinking may teach you less than one real person’s experience.
This is the handoff to Show It to One Real Person.
Do not ask the first person to tell you whether the whole idea will succeed. One person cannot prove that.
Watch something smaller.
Could they use it?
Where did they hesitate?
What did they understand without your help?
What did they ignore?
Did the useful win happen?
Did they do something differently because the version existed?
Now version one has done its job.
It has allowed reality into the design process.
Follow the proof
For the next seven days, choose one project that has become larger than necessary.
Name the first useful win.
Then reduce the project until the version is small enough for you to build soon, while preserving everything the user genuinely needs to experience that win.
Do not spend the week making it look complete.
Make the useful path work.
Then put the version where reality can answer it.
If the person cannot use it, that is evidence. If they misunderstand an important part, that is evidence. If they use one piece immediately and ignore everything else, that is evidence. If they return, request another version, share it, or ask how they can continue, that is evidence too.
Do not demand a final verdict from the first test.
Ask what version one has taught you about version two.
That is the deeper reason to build a Minimum Lovable Version.
Not because small is fashionable.
Not because speed is always better.
Not because quality no longer matters.
Build it because an important idea deserves the chance to become useful before your desire for completeness makes it too heavy to enter the world.
Start ugly enough that something exists. Make it lovable enough that somebody can use it. Keep calling it a version so reality is allowed to make it better.
Continue the Path
Return to Build Something when you want to see the larger movement from a problem worth serving to something real, useful, valuable, and shaped by proof.
Read How Small Should My First Move Be? when the difficulty is not designing version one but getting yourself to make the first meaningful move.
Go next to Show It to One Real Person when you have something usable and need reality to enter the design.
And return to Start With a Promise, Not a Product when you are still unsure what useful result the first version is supposed to create.
Do not ask version one to look complete. Ask it to create one useful win and teach you what deserves to become next.