Define Your Product

“The beginning of wisdom is the definition of terms” - Socrates. Probably.

The early biblical account of humanity uniting to build a city and tower on the Shinar plains of ancient Mesopotamia has made the "Tower of Babel" an enduring reminder of the difficulties of achieving a common goal without a common language. For those unfamiliar, the HPV (Highlights Package Version) goes like this:

Now the whole world had one language and a common speech...
They said to each other... “Come, let us build ourselves a city, with a tower that reaches to the heavens, so that we may make a name for ourselves..."
But the Lord came down to see the city and the tower the people were building.
The Lord said, “If as one people speaking the same language they have begun to do this, then nothing they plan to do will be impossible for them. Come, let us go down and confuse their language so they will not understand each other.”
So...they stopped building the city. That is why it was called Babel - because there the Lord confused the language of the whole world.
From there the Lord scattered them over the face of the whole earth.

Tellingly, when the Lord "confused the language of the whole world", what happened? They STOPPED BUILDING!

At a slight stretch of the principle, software development has long suffered from a similar disconnect between product managers and software developers on what exactly the thing to build is. At best this hinders the software building effort, and at worst actually stops the building a la Babel in that the business or software production endeavour fails to the point of extinction, an error of biblical proportion.

Context

In marketing, content is king. In AI, context is king. You've heard about it, experienced it; everybody's trying to solve it—good context. Memory systems, optimized retrieval, embeddings, increased context windows, etc.

Without good context management, agents:
(a) just plain don't have what they need to complete a task well, or
(b) they do get it, but in a time- and token-expensive manner

A complete product definition is also a great additional piece of context to draw from for your agent.

But AI agents are exposing something that has quietly existed—or indeed not existed—in software development for decades: Most organisations do not actually maintain a coherent definition of their product.

Instead, the product definition is scattered across Jira tickets, Slack conversations, onboarding calls, stale documentation, chat sessions, meeting outcomes, and some would argue the most important place: Git commits and the memories of long-serving engineers.

Humans compensate for this remarkably well. To the point where it often didn't even seem like a problem. We're good at asking questions, inferring intent and filling gaps. AI agents tend to be less forgiving.

An AI agent would typically do an inferior-to-human job in distinguishing between:

• the current architecture and the old architecture,
• a real business rule and an obsolete one,
• the desired process and the "temporary" (3-year-old!) workaround.

Undefined products produce undefined AI behaviour. And AI agents are not slow. If your product definition is vague, inconsistent or fragmented, the agent will operationalise that confusion faster than a developer can say "It Works On My Machine."

A human developer might misunderstand a requirement and lose a day. An autonomous agent with unclear context can generate entire forests of beautifully written, confidently incorrect implementation. And human-in-the-loop can catch that eventually, but we're still wasting tokens, time, money and sanity.

Historically, ambiguity reduced productivity. In the AI era, I'd argue this dynamic only intensifies.

Folklore

Many software organisations don't really run on documentation so much as accumulated folklore.

• "Ask Sarah how deployments work."
• "The billing service is weird around month-end."
• "Don't ever touch that Terraform module."
• "The wiki page is mostly right."
• "We tried that in 2022 and it broke reporting."

For years, software teams have tolerated this because humans are remarkably adaptive, and, importantly, have the ability to socialize. "I'll call Dan about this billing issue—this is absolutely his area". But AI systems can't phone-a-friend. They depend entirely on the quality and consistency of the context they receive.

Which means our beloved software industry is starting to encounter a new constraint: Before AI agents can reliably build software, organisations must first reliably define it.

Spec Driven Development

One of the more interesting responses to the intent problem recently has been the rise of "Spec Driven Development" (SDD).

The basic idea is solid: before implementation begins, define the intended behaviour clearly enough that humans and AI agents alike can work from the same understanding. Instead of vaguely gesturing toward "the thing we want", produce an explicit specification first, then build against it.

This is a meaningful improvement over pure "vibe-driven" development.

A good spec reduces ambiguity, improves alignment, and gives AI agents something far more stable than fragmented chat history and half-remembered meeting discussions.

But there is still a problem.

In many implementations of SDD, the specification itself is ephemeral. A spec gets generated, refined, implemented against, maybe referenced during code review, and then quietly abandoned. Six months later the code has evolved, the business has evolved, the architecture has evolved, but the specification has not. The intent evaporates back into folklore.

The spec becomes less like infrastructure and more like scaffolding: useful during construction, then discarded once the building is standing.

Which means organisations and their AI agents often end up recreating the same understanding repeatedly:

• re-explaining requirements,
• re-discovering assumptions,
• re-building context,
• re-learning intent.

This is where permanent product definition starts to become interesting. Instead of specification as a temporary implementation artifact, we maintain a continuously operational asset. Something durable enough to survive individual implementations, staffing changes, architectural rewrites and waves of AI-generated code. In fact, it not only survives those changes, it actively guides them.

In a world increasingly built by agents, this kind of durable institutional memory probably needs to become both machine-readable and human-readable.

Product Definition As Infrastructure

This is the idea behind DefProd. It's a system I've been building that treats product definition as permanent infrastructure, rather than just ephemeral documentation. And that's what you build against.

Instead of requirements and intent being distributed across disconnected systems and human memory, the product itself becomes a continuously maintained definition shared by product managers, developers and AI agents alike. A durable, evolving, machine-readable definition of the thing being built.

The software industry has spent decades improving source control, CI/CD pipelines, cloud infrastructure and observability. Those systems became powerful—at least in part—because they established shared operational truth.

AI development may require the same transition for product intent itself. Because as AI capability increases, the cost of ambiguity increases with it. Better models and better prompts can move the needle a long way in agentic development, but successful organisations will also have clearer definitions. Shared definitions, shared intent, shared context.

Because for humans and AI agents to build the same thing, they need a strong shared meaning of that same thing.

Shared, explicit product definition is poised as a promising solution to the software Babel problem. But to what degree are AI agents about to compel the industry to take product definition much more seriously? I'm not sure...