One of the stranger side effects of AI-assisted development is that it made some people think planning matters less.

I had the opposite experience.

The more useful AI became, the more I needed clarity before I asked it to build anything.

That is why I start every AI-built product with a Product Requirements Document “PRD”. I will use the term once here, but what I really mean is something simpler: a clear product definition. A brief. A spec. A document that forces me to stop pretending the idea is finished when it is still half-baked and wearing confidence like a costume.

I am not doing this because I enjoy documentation. I am definitely not doing it because I miss corporate ceremony. I am doing it because I want better output, fewer wrong turns, and a product that behaves like something I actually meant to build.

In my workflow, this step happens before Codex.

Always.

I do not want the coding tool to invent the product for me

When people talk about building with AI, a lot of the conversation goes straight to prompting the coding tool.

That makes sense on the surface. If the tool writes code, then the obvious question is how to talk to it.

But for me, that is already too late.

Before any implementation starts, I need to know what I am asking for. Not in a vague “I have a direction” way. I mean clearly enough that the system is not quietly making important product decisions on my behalf.

Because that is what happens when the brief is weak.

The tool still produces output. Sometimes a lot of it. Sometimes surprisingly good-looking output. But under the surface, it is filling gaps with assumptions. It is choosing scope, making tradeoffs, inventing behavior, smoothing over ambiguity, and guessing what matters.

That may be acceptable for a quick experiment.

It is not how I want to build products.

I do not want Codex, or any AI coding tool, deciding what version one should include, what edge cases matter, which features should wait, what happens when something fails, or how the product should behave under real constraints. Those are product decisions. I want to make them before I get to the implementation stage.

That is the real reason I start with a product brief.

The document is not the goal. Clarity is the goal.

I think this is where people misunderstand the point.

The goal is not to produce a polished document for its own sake. The goal is to reach a level of clarity that makes implementation reliable.

Sometimes that clarity ends up in a clean PRD. Sometimes it is a technical spec. Sometimes it is a plain-language product brief with enough structure to remove confusion. I do not care too much what label it gets.

What I care about is whether it answers the questions that would otherwise get pushed into the coding phase.

What is the product?

Who is it for?

What problem is it solving?

What does the first version include?

What is explicitly out?

What should happen when something fails?

What constraints matter in the real environment?

If those answers are still fuzzy, then the coding stage becomes more expensive than it looks. Not always in money, but definitely in time, rework, review effort, and product drift.

You feel like you are moving fast because code is appearing quickly.

Then you discover you have been building motion, not clarity.

Why this matters even more with AI

With human developers, unclear thinking is already expensive.

With AI, it gets expensive faster.

That is the part I learned very quickly.

If the product definition is weak, AI does not pause and say, “This is still not thought through properly, maybe let us step back.” It usually goes ahead and builds something. That can create a very convincing illusion of progress.

And honestly, that illusion is dangerous.

Because now you have screens, flows, database structures, API logic, and implementation details growing around assumptions that were never properly decided. You are not just missing clarity anymore. You are missing clarity with momentum.

That is why I do not see the product brief as optional overhead. I see it as protection against fast confusion.

The clearer the product is, the more useful AI becomes.

It guesses less.

It drifts less.

It makes fewer wrong assumptions.

It becomes easier to review.

It becomes easier to refine.

And the gap between what I meant and what gets built becomes much smaller.

That is a very practical payoff.

I use ChatGPT first because I need pressure before I need code

This is also why my workflow starts in ChatGPT, not in Codex.

At that stage, I am not asking for implementation. I am asking for pressure.

I want the idea challenged.

I want missing decisions exposed.

I want vague language forced into specific language.

I want the comfortable illusion that “the idea is clear in my head” to be tested before the coding starts.

That is what ChatGPT is useful for in this part of the process.

I use it to discuss what already exists in the market. I use it to brainstorm the shape of the product. I use it to narrow scope. I use it to discover what I have not yet decided. And very often, the value is not in the answer itself. The value is in the next question it pushes back at me.

That interaction helps me move from “I think I want this” to “this is what I am actually building.”

Only after that do I want the coding tool involved.

What I put inside my product brief

I do not treat this like a giant enterprise artifact. I keep it practical.

At a minimum, I want these things clear before I start implementation:

1. The purpose
What the product is supposed to do, in plain language.

2. The user
Who it is for and what real need it serves.

3. The first version
What version one includes, and just as importantly, what it does not include.

4. Core flows
What the user actually does and what the product needs to support.

5. Constraints
Technical realities, hosting limits, security concerns, operational conditions, or anything else that changes design decisions.

6. Failure behavior
What should happen when something breaks, times out, gets interrupted, or loses access.

7. Boundaries
What I am consciously postponing so the first version stays focused.

That last part matters more than people think.

A good product brief is not only a description of what I want to build. It is also a written record of what I am refusing to build right now.

That saves a lot of pain later.

A real example from my backup plugin

One public example I can talk about is a WordPress backup plugin I am designing for Google Drive backups.

If I had started directly in a coding tool, the request could have been one sentence long: build a WordPress plugin that backs up a site to Google Drive.

That sounds reasonable until you realize how much product thinking is hiding inside that sentence.

What exactly gets backed up?

Should it create large temporary ZIP files locally, or should it upload directly?

Should version one support restore?

Should it support migration?

Should it support multiple cloud providers?

How should it behave on shared hosting with limited resources?

Without a clear product definition, the coding tool would still start building. But it would be building around guesses.

In my case, working through the brief changed the shape of the product in important ways.

For example, I made an explicit decision to keep version one focused on Google Drive only, instead of trying to support multiple storage providers immediately. I also made a clear decision that automated restore would be out of scope for version one. That kept the first release much tighter and much more realistic.

Those are not small details. They shape architecture, user expectations, support burden, and implementation complexity from the beginning.

That is exactly why I want those decisions made before code starts, not discovered halfway through it.

This step saves me from fake progress

One reason I value this part of the workflow so much is that it protects me from fake progress.

Fake progress is when implementation starts quickly, output appears quickly, and the whole thing feels productive, but the actual product is still not defined properly.

That kind of speed is seductive.

It feels efficient.

It looks efficient.

But later it usually turns into revisions, corrections, backtracking, and the awkward realization that the tool did not misunderstand me. I just had not finished understanding the product myself.

The product brief helps me catch that earlier, when the cost is still low.

It is easier to fix vagueness in a document than in a growing codebase.

It is easier to challenge scope in a discussion than after features have already started multiplying.

It is easier to decide what matters before implementation than while reviewing output shaped by assumptions I never meant to approve.

I do not see this as documentation. I see it as leverage.

That is probably the simplest way to put it.

I am not writing a product brief because I enjoy preparing documents before the “real work” begins.

For me, this is the real work.

This is where the product becomes concrete enough to build well.

This is where ambiguity gets reduced.

This is where version one becomes realistic.

This is where the coding tool becomes more useful, because it is no longer being asked to fill in the product thinking for me.

The better this stage goes, the more value I get from AI later.

That is why I start here every time.

Not because it looks organized.

Not because it sounds professional.

Because it works.

And when I am using AI to build real products, “it works” is a much better standard than “it felt fast at the beginning.”