The three metamorphoses
Early in the book, Zarathustra tells a short parable. The spirit becomes a camel, kneeling to be loaded with the heaviest things it can bear. Then, alone in the desert, it becomes a lion, which fights a great dragon named "Thou shalt" and wins the right to say a sacred "No". Finally it becomes a child: innocence, a new beginning, "a sacred Yes".
It's about how people grow, not about websites. Nietzsche was writing about morality, about the values we inherit and the courage it takes to make our own. But it's hard to read it on a deadline and not recognize the shape of a project.
The camel: carry it all (at first)
Discovery is camel work. You take in every goal, every stakeholder's wish, every "wouldn't it be nice if". That's good. You can't design for needs you haven't heard, and the camel's strength is real: patience, listening, carrying things that aren't yours yet.
The mistake is staying a camel. A project that keeps kneeling for one more load (one more page, one more feature, one more integration) never gets across the desert. Camels are admirable, and they are very slow.
The dragon called "Thou shalt"
In the parable, the dragon's scales are covered in golden commandments, every value that has ever been handed down, each one saying "Thou shalt". The lion can't create anything new while it's still obeying them.
Web projects have their own dragon. Its scales say things like:
- Thou shalt have a carousel on the homepage.
- Thou shalt have a page for every service, even the one nobody buys.
- Thou shalt match what the competitor did.
- Thou shalt add it, because someone important mentioned it once.
None of these are evil. Some are even right, for some projects. The problem is that they arrive as rules instead of reasons. The lion's job isn't to reject everything. It's to ask each golden scale "why?" and keep only the ones that have an answer.
The lion: the sacred no
This is the stage most projects skip, and it's the one that matters. The lion looks at everything the camel carried and asks which of it actually serves the goal we agreed on. Then it says no to the rest, out loud.
Scope creep isn't a villain. It's the natural result of never having a lion. Every request sounds reasonable on its own; only a clear purpose ("why before how") lets you say no without it feeling arbitrary. The "no" usually isn't forever, either. Often it's "not in this launch". (I wrote about where that purpose comes from in Why before how.)
What the lion actually sounds like, on a real project:
- "That's a great idea. It doesn't serve the goal we wrote down, so it goes on the later list."
- "We can do that, and here's what it pushes out of this launch. Which one matters more?"
- "Let's launch without it and see if anyone asks for it."
The lion isn't rude. It's clear. And clarity turns out to be kind: nobody on a project enjoys a scope that keeps growing, least of all the person paying for it.
Designers already know this
Design has its own lions. Dieter Rams, who shaped Braun's products for decades, summed up his principles in three words: weniger, aber besser, "less, but better". Antoine de Saint-Exupéry, a pilot before he was a writer, put it as the idea that perfection arrives not when there's nothing left to add, but when there's nothing left to take away.
Both are lion sentences. They're not against richness; this site has a playable boss fight on the About page, so I'm clearly not a minimalist. They're against things that are there only because nobody said no. Every element that stays should be a choice, not a leftover.
The child: build something new
Only after the no can you really create. The child isn't carrying anyone's leftover burdens. Nietzsche calls it "a wheel rolling out of itself", a first movement, play. With a smaller, clearer scope, the design gets bolder, the build gets cleaner, and the launch actually happens.
I think this is why prototyping feels like play when the scope is right. You're not negotiating anymore; you're making. The best ideas on a project usually show up in this stage, because there's finally room for them. Mercury, Gemini, Apollo is about how I size that first prototype.
In practice
- Write down the goal in one sentence before collecting features.
- Put every request on one list, then sort it against that sentence.
- Ask each "thou shalt" for its reason. Keep the ones that have one.
- Say the "no" early, and kindly, with a "later" list so nothing is lost.
- Protect the build phase from new cargo. New ideas go to the next launch.
Carry, refuse, create. In that order, and not twice in the same week.
(If you've found the boss fight on my About page, you already know what the final boss is called.)