Level 1: Defining Problems in Words

When you ask AI to build something vague, you get something vague back. Then you ask for changes. Then more changes. Then you start over. Hours lost.

This isn't AI's fault. It's a clarity problem.

Vague requests fail because they force AI to guess. And AI's guesses are based on averages—what most people probably mean, what the most common version looks like. Your idea isn't average. It's specific to you, your users, your context.

When you say "build me a website," AI doesn't know: - Who is this website for? - What should visitors do when they arrive? - What information needs to be on it? - What should it look like? - What definitely should NOT be on it?

So it guesses. And you spend the next hour correcting guesses instead of building.

The fix isn't learning to write better prompts. The fix is learning to think more clearly about what you actually want before you ask for anything.

You don't need technical vocabulary. You need to answer five questions clearly:

1. Who is this for? Not "users" or "customers"—be specific. "Busy parents who meal prep on Sundays." "Freelance designers who invoice clients monthly." "Me, personally, to track my reading habit."

2. What is the one main thing it does? Not a feature list. The core action. "Lets people book appointments." "Shows my work to potential clients." "Helps me remember what I need to do today."

3. What does someone do when they use it? Walk through the experience. "They land on the page, see available times, pick one, enter their info, and submit. I get a notification."

4. What information is involved? What goes in, what comes out. "They enter their name and email. They see a confirmation message. I receive an email with their details."

5. What is explicitly NOT part of this? This is the most important question. "No user accounts. No payment processing. No mobile app—web only. No admin dashboard for now."

Answer these five questions and you have a description clear enough to build from.

Big ideas are exciting but unbuildable. Small pieces are boring but shippable.

Your job at this stage is to take your vision and find the smallest version of it that still delivers value. Not a watered-down version—a focused one.

Scope is the boundary around your project. Inside the boundary: what you're building. Outside: what you're not building (yet).

Clear scope prevents two disasters: 1. Scope creep: Adding "just one more feature" until the project never ships. 2. Misaligned expectations: Building something different from what you imagined because you never defined the edges.

The trick is to be as specific about what you're NOT building as what you ARE building.

Now you put it all together into a single document. This isn't a business plan or a technical spec. It's a clear, plain-language description of what you want to build—something you could hand to AI (or a developer, or a friend) and they'd know exactly what to create.