There is a popular version of product development that sounds wonderfully clean.
First, define the product. Then design it. Then build it. Then ship it.
That sequence is tidy enough for a diagram. It is rarely how a complex product actually becomes good.
The difficult systems I have worked on tend to emerge through a much less theatrical process. You establish a direction, build enough of it to expose reality, discover where your assumptions were wrong, and then adjust both the product and the way you are building it.
That can look messy from the outside. It is not the same as working without discipline.
There is a major difference between an iterative workflow and making things up as you go. One relies on evidence, bounded changes, explicit decisions, and continuous review. The other is just a series of reactions.
The goal is not to avoid change. The goal is to make change survivable.
A product is not hiding inside the first specification
I recently built an experimental Twitch game called SIGNAL INTERUPT. It began as a damaged terminal sitting in the basement of Twitch, waiting for someone to notice it.
The first version was mostly atmosphere. A sickly CRT display. Corrupted characters. A blinking cursor. Old machinery that looked operational but abandoned.
That was enough to test the central idea: would the artifact itself be interesting before anyone understood how to use it?
Once it existed, the next problem became visible. Watching a strange terminal is interesting for a while, but discovering that Twitch chat is secretly its keyboard is much more interesting. That discovery turned the visual artifact into an interaction.
The interaction then exposed another limitation. A single puzzle is a curiosity, not a durable experience. That led to a persistent campaign with multiple stages, shared progression, commands, failure states, restart behavior, and server-owned state.
Once the game could run, a new problem appeared. It could operate, but it could not yet be performed. A live experience needs pacing, intervention, recovery, and the ability to respond to an audience without giving away the machinery behind it.
That produced an operator-facing control system. Then a narrative system. Then distinct entities with competing goals. Then rules governing what those entities knew, how they spoke, when automation could act, and how the story could respond to a puzzle without becoming a hint engine.
The product moved through several identities:
- A visual artifact.
- A hidden interaction.
- A collaborative puzzle.
- A live performance system.
- A governed narrative world.
None of those later forms was fully visible in the first plan.
That does not mean the first plan failed. It did exactly what it needed to do. It created enough reality to reveal the next important question.
Iteration is a method of product discovery
Review is often treated as quality control. Someone checks whether the implementation matches the requirements, identifies defects, and sends the work back for correction.
That is necessary, but it misses the more valuable role of review.
Review is where product discovery happens.
A feature can be technically complete and still reveal that the original idea was incomplete. The interface may contain every requested control but organize them in a way that makes no sense to the person operating it. A narrative system may generate perfectly acceptable text while failing to create a meaningful relationship between its characters. A workflow may function while asking the user to think like the database instead of thinking like themselves.
These are not always implementation failures. Sometimes the implementation is the evidence that the product model was wrong.
My working loop generally looks like this:
- Define the experience or outcome.
- Translate it into a bounded implementation plan.
- Build the smallest meaningful version.
- Review the actual behavior, not just the checklist.
- Identify the difference between what works and what feels true.
- Convert that criticism into observable requirements.
- Update the system without discarding what has already proved useful.
The important part is the return from step five to step six.
“This feels wrong” is valid product feedback, but it is not yet an implementation instruction.
It has to be translated.
If a control panel feels confusing, the correction may be clearer state ownership, better grouping, fewer modes, or language that matches the operator’s mental model. If a system feels generically ominous, the correction may be that each narrative voice needs a specific objective instead of a different visual style. If an AI response feels disconnected from the experience, the correction may be a tighter relationship between current state, permitted knowledge, and publication authority.
Subjective criticism becomes useful when it produces an explicit behavioral contract.
Durable does not mean finished
People often confuse durability with rigidity.
A durable product is not one that never changes. It is one that can change without invalidating everything beneath it.
That requires a few stable things.
Stable system boundaries
Campaign state should not depend on how the terminal renders it. Narrative generation should not own puzzle progression. An operator control should not bypass the same authority rules that protect the public interaction. AI output should not become a hidden source of irreversible state.
The implementation can evolve inside those boundaries. The boundaries prevent each new idea from becoming an architectural invasion.
Explicit authority
Complex systems become fragile when several components can decide the same thing.
Who owns progression? Who can publish? Who can reset the system? Which state is canonical? What happens when two inputs arrive at the same time?
These questions are not glamorous, but answering them is what allows the visible product to remain flexible.
Observable state
If a system is expected to evolve, the people operating it need to understand what it is doing.
Hidden behavior makes iteration dangerous. Visible state, journals, event histories, queues, and clear lifecycle transitions make it possible to change a system without guessing whether it still works.
Current truth
Fast iteration creates historical debris.
Old plans remain useful because they explain why decisions were made. They become dangerous when an old decision and its replacement appear equally authoritative.
A durable workflow needs a compact record of present truth:
- current terminology;
- current state model;
- active behavior;
- accepted decisions;
- superseded decisions;
- deferred ideas.
This does not need to become another enormous master specification. It needs to function as an authority map.
The workflow must evolve with the product
One of the less discussed parts of iterative development is that the development method should change as the product becomes more real.
Early in a project, the work may be deliberately exploratory. The questions are experiential:
- Is the central idea compelling?
- Does the visual language communicate the right thing?
- Is there enough here to justify building the machinery behind it?
At that stage, excessive specification can be wasteful. You are defining rules for a product that has not yet proved what it wants to be.
As the product gains real behavior, the plans should become more exact. State ownership, data contracts, failure behavior, concurrency, persistence, and acceptance criteria begin to matter. The work moves from “build this interface” to “implement this behavioral contract.”
Once people must operate the product, another layer appears. The workflow has to account for recovery, visibility, permissions, intervention, and what happens when the system is left unattended.
If the product includes automation or AI, the process needs another degree of governance. What can the model propose? What can it publish? What context can it use? What must remain deterministic? What happens when it fails, stalls, contradicts the current state, or produces something merely mediocre?
The answer is not to begin every project with maximum process.
The answer is to increase precision as uncertainty decreases.
I think of this as progressive commitment:
Commit strongly to the intended experience, lightly to the first implementation, and more precisely as evidence accumulates.
That preserves the room needed for discovery without allowing the system to become arbitrary.
AI makes judgment more important, not less
AI-assisted development accelerates this workflow, but it does not replace it.
I use ChatGPT to reason through product intent, challenge assumptions, organize systems, and translate criticism into implementation plans. I use Cursor to work against the codebase, implement bounded changes, and test those plans against the software that actually exists.
The tools are fast. That is both the advantage and the risk.
AI can produce code faster than an organization can understand it. It can also produce convincing specifications for ideas that have not earned the right to become features.
The discipline is not in generating more. The discipline is in deciding what should survive.
In practice, the useful division of labor looks something like this:
- I own the intent, the criticism, and the final product judgment.
- ChatGPT helps turn incomplete thoughts into structured options and bounded plans.
- Cursor works with the implementation and exposes the consequences of those plans.
- The running product provides evidence that none of us had before it existed.
AI is not the source of product judgment in this arrangement. It is an amplifier inside a review loop.
That distinction matters. A weak idea can now become a large codebase with remarkable speed. Faster execution does not rescue unclear thinking. It compounds it.
Plans should create leverage, not sediment
Planning is essential to this workflow, but plans have different jobs.
Some establish a foundation. Some define product rules. Some introduce a new subsystem. Some correct an implementation that is functionally right but experientially wrong.
Treating every plan as a permanent constitution creates its own form of fragility.
The plan should be detailed enough to produce coherent work, but narrow enough to be reviewed as a single change. It should distinguish between:
- required behavior;
- creative direction;
- examples;
- non-goals;
- acceptance criteria.
That separation is particularly important when working with AI. An evocative example can communicate tone beautifully, but the model may treat it as mandatory copy. A broad ambition can inspire the right direction, but the implementation still needs to know what it owns and what it must not change.
The best plans do not attempt to remove every uncertainty. They isolate the uncertainty that matters and protect the rest of the system from it.
What this approach prevents
This workflow does not eliminate rework. Any honest process for discovering a product will produce some rework.
It prevents the more expensive forms of it.
It reduces the chance that:
- a prototype becomes an accidental permanent architecture;
- a new feature quietly acquires authority it should not have;
- an interface reflects internal implementation instead of user intent;
- AI-generated behavior becomes an unauditable black box;
- old decisions remain active because nobody recorded that they changed;
- every discovery triggers a rewrite of the system beneath it;
- shipping more is mistaken for learning more.
Most importantly, it keeps the product connected to reality.
Complex software rarely fails because nobody could write the code. It fails because assumptions remain hidden, ownership is unclear, ambition exceeds what the system or team can support, or everyone keeps building after the product has stopped making sense.
Iteration helps only when each cycle produces better evidence and sharper decisions.
Build the ability to continue
The real output of a good development workflow is not merely the current release.
It is the ability to make the next release without fear.
That means the product can discover a better identity without discarding its foundation. The interface can evolve without corrupting the state model. Automation can become more capable without quietly taking control. New ideas can be tested without being mistaken for permanent truth.
The strongest systems are not built from perfect foresight. They are built by people who know which decisions must remain stable, which ones are still bets, and how to learn from working software without surrendering the architecture to every new possibility.
Durability is not resistance to change. Durability is the capacity to change deliberately.