# Why I Build Before I Write Requirements (And Why AI Makes That Smart)
*Published: 2026-03-27*
*Tags: insights, ai, product-work*
*Source: https://chrislema.com/ai-prototyping-before-requirements*
---I used to feel guilty about my process. I'd start building, hit a wall, throw it away, start again. No requirements doc. No product spec. Just exploring.

The product manager in me said I was being undisciplined.

They were wrong.

## Draft 20

I'm currently on draft 20 of a new version of our core product, the Motivation Code Assessment. The current product is great. It works. There's nothing wrong with it. But that hasn't stopped me from trying to figure out a different way to deliver it.

And I don't mean draft 20 in two days. I've been at this for more than a year.

Each draft has been a serious, different iteration. Not little tweaks—if we counted those, I'd be on draft 300. I've thrown away every single version.

And each time I sit down to work on it again, I have new requirements. Not because the product changed. Because *I* changed. I learned something from the last version that I couldn't have learned any other way. I had to build the wrong thing to understand what the right thing looked like.

You might wonder: why didn't I have these requirements when I started?

Because I hadn't reacted yet.

## What You Don't Want

Early on, most of my learning was about features. What should the assessment include? How should scoring work? What output should the user see? Standard stuff. The kind of thing you *could* put in a requirements doc.

But the important learning—the stuff that actually shaped the product—came from a different place entirely. It came from building something and feeling the wrongness.

Like: "The assessment can't take longer than 10 minutes." Easy to say. But I didn't know I cared about that until I built a version that took 25 minutes and felt it in my gut. No amount of whiteboarding would have surfaced that constraint. I had to sit with the wrong version to understand why it was wrong.

Or: "The assessment should be translatable into 40 languages, but not at runtime—in advance." That one came from seeing a prototype that handled translation a different way and immediately knowing it wouldn't scale. The requirement didn't come from thinking. It came from seeing.

I've started keeping a running list. Not of what I want—of what I *don't* want. What felt off. What confused test users. What made me wince. What took too many clicks. What was technically possible but experientially wrong.

That list is the most valuable document in the entire project. And I couldn't have written a single line of it before I started building.

## The Negative Space

There's a concept in sculpture: you don't carve the statue. You remove everything that isn't the statue. The form was always there. You just have to take away enough marble to find it.

That's what 20 drafts taught me. I wasn't building toward something. I was cutting away everything that didn't belong. Each failed prototype was marble on the floor. Each wince was a chisel strike.

And the thing is—you can't skip the marble. You can't sit in a conference room and reason your way to the negative space. You have to hold the wrong thing in your hands and feel it.

This is where AI tools changed the math. When spinning up a prototype took days or weeks, cutting marble was expensive. Each draft cost real time, real money, real opportunity cost. So we front-loaded the thinking. Requirements docs. Product specs. Design reviews. All of it was an attempt to avoid the cost of being wrong.

But when you can spin up a prototype in minutes? The economics flip. Being wrong becomes cheap. And if being wrong is cheap, and being wrong is how you learn what you actually want—then the fastest path to a great product is through a lot of bad ones.

I wrote about this same shift from a different angle in [How Estimating Changes in an AI World](https://chrislema.com/how-estimating-changes-in-an-ai-world/)—the same force that makes prototyping cheap also changes how we should think about sizing and scoping work. When execution is fast, the risk isn't in the building. It's in the understanding.

## The Guilt Problem

I want to name something that doesn't get discussed enough: the emotional weight of working this way.

Twenty drafts over a year. All thrown away. If you've been trained in any kind of formal product development—and I spent years doing exactly that—this feels like failure. It feels wasteful. It feels like you don't know what you're doing.

My anxiety about the project was highest at the beginning, when I was trying to get the requirements right *before* I built anything. Every decision felt heavy. If I got it wrong, everything downstream would be wrong too. The pressure stacked up at the front of the process.

Something shifted when I stopped trying to be right and started trying to learn. When draft 7 went in the trash, I didn't feel defeated. I felt informed. When draft 14 revealed a constraint I hadn't considered, I didn't feel behind. I felt like I was making progress—the only kind of progress that matters.

The pressure distributed across the whole process instead of concentrating at the start. Every prototype became an experiment, not a commitment. Every pivot was learning, not failure.

## When to Write the Spec

I'm not saying never write a spec. I'm saying: write it last.

After 20 drafts, I know things about this product that I could never have known on day one. I know what confuses people. I know what excites them. I know what they ignore. I know the constraints that matter and the features that don't. I know the ten-minute threshold and the translation requirement and the scoring approach that felt right versus the three approaches that felt wrong.

If I sat down today and wrote a requirements document, it would be sharp. Specific. Grounded in evidence. Not because I'm smarter than I was a year ago. Because I've been wrong enough times to know what right looks like.

There's a difference between a spec written from imagination and a spec written from experience. One is a guess. The other is a record of everything you learned to get there.

## The Spec You Earn

So here's what I'd say to anyone staring at a blank requirements document, feeling the pressure to get it right before they write a line of code:

Close the document. Open your tools. Build something. Not the right thing—you don't know what that is yet. Just *a* thing. See how it feels. Notice what you don't like. Write that down.

Then build again.

The spec you produce at the end won't be a guess. It'll be something you earned—one bad draft at a time.