Ed Catmull, co-founder of Pixar, said something that changed how I think about building products: “All our movies suck at first.”
Toy Story sucked in its first version. Finding Nemo sucked. Up sucked. Wall-E sucked. These are some of the most beloved films in cinema history, and every single one began as a version so rough that it would have been embarrassing to show anyone outside the studio.
This is not a flaw in Pixar’s process. This is Pixar’s process. They call it “going from suck to not-suck.” They expect the first version to be terrible. They plan for it. They budget for it. And they build a system — their Brain Trust, their iteration cycles, their willingness to throw out entire story arcs — specifically designed to transform terrible first drafts into masterpieces.
Your product works the same way. The first version will be bad. Not might be bad. Will be bad. And the sooner you accept this, the sooner you can build something great.
Why First Versions Are Always Bad
There is a structural reason why first versions cannot be good, and understanding it removes the shame.
When you build version one, you are making decisions based on assumptions. You assume you know what the customer wants. You assume you know which features matter. You assume you know the right price, the right messaging, the right design.
Every assumption is wrong in some way. Not wildly wrong (usually), but wrong enough that the gap between what you built and what the customer actually needs is visible the moment real people start using it.
This gap is inevitable. No amount of research, planning, or customer interviews can eliminate it. Interviews reduce the gap. Prototypes reduce it further. But only shipping a real product to real customers reveals the full gap.
The first Vulpine Creations product had a mechanism that worked technically but was harder to learn than I expected. The instructions were clear to me — I had designed the thing — but confusing to someone seeing it for the first time. I did not know this until customers told me.
Version two addressed the learning curve. Version three refined the instructions further. By version four, customers were calling it “intuitive.” It was not intuitive. It had been iterated until the friction was invisible.
That is the Pixar principle. You do not create something great. You create something terrible and then improve it until it is great.
The Permission to Ship Ugly
The biggest barrier to shipping version one is not technical. It is emotional. You look at what you have built and you see the flaws. The design is rough. The copy is imperfect. The experience has gaps. You know it could be better, and shipping something that could be better feels irresponsible.
It is not irresponsible. It is necessary.
Every day you spend polishing version one is a day you are not learning from real customers. When good enough is perfect, you ship. Not because you do not care about quality. Because you understand that quality comes from iteration, not from extended development.
Here is the question to ask yourself: “If I ship this today, will any customer be harmed?” Not disappointed. Not unimpressed. Harmed. If the answer is no — if the product works, delivers some value, and does not break anything — ship it.
Disappointment is addressable. A customer who says “the instructions could be clearer” is giving you a specific, fixable piece of feedback. A customer you never had because you spent four more months polishing gives you nothing.
The Iteration Math
Let me make this concrete with numbers.
Founder A spends six months building a polished version one and ships in July. By December, she has one version in the market, with six months of customer feedback.
Founder B ships a rough version one in February. She iterates every month. By December, she has ten versions in the market, with ten months of customer feedback.
Same amount of total development time. But Founder B has learned ten times as much because she had ten cycles of real-world feedback. Her version ten is almost certainly better than Founder A’s version one — not because she is more talented, but because she has made more contact with reality.
Speed compounds. Each iteration makes the product better, which makes customers happier, which produces better feedback, which makes the next iteration more targeted. The cycle accelerates.
What “Terrible” Actually Means
I am not advocating for shipping broken products. There is a difference between terrible and non-functional.
Non-functional means the product does not work. The payment fails. The course videos do not play. The physical product arrives damaged. This should not ship. Fix the basics.
Terrible means the product works but is rough. The design is basic. The onboarding is clunky. Some features are missing. The copy has room for improvement. This should ship. Because “terrible but functional” is how every great product started.
The minimum bar for shipping:
- The core promise is delivered (the main thing works)
- Payment and delivery work end-to-end
- The customer can get value without help from you
- Nothing is broken, dangerous, or misleading
Above that bar: ship. Everything above the bar is version two territory.
The Brain Trust Model
Pixar’s specific innovation was the Brain Trust — a group of peers who review work-in-progress with the explicit mandate to be honest. Not supportive. Honest.
You need your own Brain Trust. Three to five people who will use your product and tell you the truth. Not friends who will be encouraging. Not family who will be supportive. People from your target market who have no emotional investment in your feelings.
Interview them after they use version one. Ask specific questions: “Where did you get stuck? What was confusing? What would you change?” Listen to the feedback without defending. Write it down. Use it for version two.
The Brain Trust does not make the decisions. You do. But the Brain Trust gives you the data to make better decisions than you could make alone.
Applying This to Your Business
Whatever you are building right now — stop trying to make it great before it ships. Instead:
Accept that version one will be embarrassing. Plan for it. Budget for the improvements that will follow. Tell yourself, explicitly: “This is the Pixar phase. It is supposed to be bad.”
Set a ship date that is uncomfortably soon. Two weeks from now. Four weeks from now. A date that forces you to cut features, simplify, and subtract everything non-essential.
Define the minimum bar. What does the product need to do — at minimum — to deliver value to one customer? Build that and nothing more.
Prepare the feedback loop. Before you ship, set up the mechanism for collecting feedback. A follow-up email. A survey. A scheduled call. The feedback is the point of shipping early.
Iterate with discipline. After shipping, resist the urge to fix everything at once. Pick the one or two most impactful improvements. Ship them. Collect more feedback. Repeat.
The Pixar principle is not about lowering your standards. It is about sequencing your effort. Great things start terrible and become great through disciplined iteration, not through extended development in isolation.
Your first version will suck. That is not a prediction. That is a requirement.
Ship it anyway. Then make it better. Then make it better again.
That is how everything worth making has ever been made.
