A product used to be something an organization prepared before it met reality. The sequence was familiar: define the offer, write the internal description, produce the material, prepare the business case, align stakeholders, package the service, and then, eventually, test whether a customer wanted it.
This looked responsible. It looked professional. It created artifacts that could be reviewed, circulated, challenged, approved, revised, and archived. It gave the organization something legible before the market had said anything meaningful. It also made a hidden assumption: that the product or service existed before evidence existed.
That assumption is becoming increasingly expensive.
With AI-augmented development, automation, reusable delivery patterns, and a sufficiently experienced operator, the distance between a credible customer problem and a working service prototype can collapse from weeks to days. Sometimes to one day. A provisional service can be shaped, implemented, tested, bounded, and put in front of a real customer before the old process would have finished debating the first version of the internal slide deck.
This is not merely faster product development. It is a different mode of productization. The product is not defined first and validated later. The product is formed through contact with reality.
This is just-in-time productization.
Artifact-First vs Evidence-First
The old model begins with internal confidence. The new model begins with external evidence.
The old model is artifact-first. It produces the description, the business case, the positioning, the material, and the internal justification before the service has been tested against reality. The new model is evidence-first. It treats the first version as an instrumented encounter with reality. The initial artifact is not proof of product maturity. It is a way to discover whether the product or service should exist in the first place.
In an uncertain domain, a business case before customer evidence is not a business case. It is a forecast wrapped in institutional formatting. A service description before the service has been run is not a product definition. It is a hypothesis in polished prose.
The intellectual ancestry here is not mysterious. Lean Startup framed the minimum viable product as a device for validated learning, not as a small polished product. Pretotyping made the point even more bluntly: make sure you are building the right thing before you build the thing right. Effectuation describes venture formation under uncertainty as action from available means, affordable loss, and committed stakeholders rather than prediction-heavy planning. Scientific entrepreneurship treats entrepreneurial decisions as explicit hypothesis testing. Business model experimentation shows that the business model itself can emerge during experimentation rather than being fully designed in advance.
Those ideas are not new. What has changed is the compression ratio.
A decade ago, even a lean experiment often required meaningful preparation. The cost of building enough to learn was still high. Producing supporting material was often cheaper than producing the thing itself, so organizations naturally spent time on material, positioning, and internal alignment before delivery. That ratio has changed. In many domains, the service prototype is now cheaper than the presentation about the service prototype. The working artifact can be produced faster than the justification for producing it.
This creates a deep process conflict. Organizations built around artifact-first productization will often reject evidence-first productization because it appears to skip the responsible steps. In reality, it skips the steps that used to compensate for expensive execution. When execution was slow, it made sense to invest heavily in prior justification. When execution is cheap and fast, excessive prior justification becomes inventory. It delays learning, converts uncertainty into internal theater, and protects the organization from the discomfort of reality while consuming the very time that could have produced evidence.
Time-to-Evidence
The metric underneath just-in-time productization is time-to-evidence.
The old process optimizes for internal readiness. It asks whether the offer is described, whether the deck exists, whether the business case is presentable, whether stakeholders have been aligned, and whether the service can be made legible inside the organization. Those things can be useful, but they are not evidence. They are often preparation for evidence, and in many cases they become a substitute for it.
The new process optimizes for the fastest responsible path to reality. It asks what must be true for this service to matter, what smallest serious version can test that, what risk boundaries are needed, what customer contact would produce useful evidence, and what result would cause us to continue, change, or stop.
That is a different professional discipline. It does not treat speed as the goal. It treats learning as the goal, and speed as the removal of avoidable delay between hypothesis and evidence.
Not Speed, Compression
This is not a generic argument for moving fast with AI. The faster execution becomes, the more important judgment becomes. AI compresses the cost of producing the first serious artifact. It does not compress the cost of knowing whether that artifact should exist, what it may safely touch, which risks are material, what evidence would count, or how the result should be interpreted.
AI does not create trust. It does not create domain knowledge. It does not create commercial judgment. It does not make unsafe work safe. It does not turn an unclear problem into a clear one by generating more output around it. It changes the cost of reaching reality. That is enough to disturb the old sequence.
The research on AI-assisted development is still young and mixed, which is exactly what we should expect. One controlled experiment on GitHub Copilot found that developers completed a constrained programming task 55.8% faster. A later METR study of experienced developers working in mature open-source repositories found the opposite: with early-2025 AI tools available, developers took 19% longer to complete tasks. This is not a contradiction so much as the actual shape of the problem. AI is not a universal acceleration function. Its effect depends on task shape, available context, verification quality, codebase maturity, operator judgment, and the organization’s capacity to absorb faster output.
The newer generation of agentic coding tools makes this compression more concrete. OpenAI’s Codex Goals can be described as persistent objectives with completion conditions, verification surfaces, constraints, and evidence-based continuation. From extensive use of the /goal feature, I can attest to its effectiveness under the right conditions. It makes the execution loop longer-lived, more auditable, and more capable of carrying a bounded implementation through several rounds of test, repair, and verification.
This is why just-in-time productization only works under specific conditions. The problem must be bounded. The domain must be understood. The operator must be competent. The risk surface must be constrained. The evidence loop must be real. Without those conditions, compressed productization becomes compressed waste.
The New Sequence
The compressed sequence looks different.
A credible problem appears. A bounded service hypothesis is formed. The smallest useful version is built or assembled. The risk surface is constrained. The thing is tested against reality. A real customer interaction produces evidence. The parts that survive are packaged. The parts that fail are discarded.
This does not mean improvisation without discipline. It means the discipline moves. The discipline is no longer primarily in the pre-production ritual. It is in the quality of the hypothesis, the containment of the experiment, the technical judgment behind the implementation, the test evidence, the control of blast radius, and the ability to interpret what happened.
That requires experience. It is not a junior-friendly fantasy where speed replaces competence. AI does not remove the need for judgment. It increases the return on judgment. A capable operator can compress the cycle because they know what must be tested, what must be bounded, what must not be touched, what failure would look like, and where the real risk lives.
Without that judgment, the same compression becomes dangerous. The organization is right to fear machine-speed nonsense. But the answer is not to force every experiment back into a slow artifact-first process. The answer is to distinguish between reckless acceleration and evidence-first formation under competent control. Most organizations are poor at making that distinction. They know how to recognize process compliance. They are much worse at recognizing situated judgment.
The Trust Problem
Evidence-first productization depends on judgment that cannot be fully captured in a template. An organization that does not know how to evaluate that judgment will fall back to process artifacts: business cases, decks, approvals, formal descriptions, staged preparation, and committee-shaped caution.
That is understandable. It is also limiting. The organization is not only protecting itself from reckless speed. It is also protecting itself from competent speed.
This is where the old model becomes structurally conservative. It does not merely prevent bad ideas from moving too quickly. It also prevents good experiments from becoming legible until after the opportunity to learn cheaply has passed. Trust cannot be replaced by process. It can only be approximated by process when the organization lacks a better way to evaluate judgment.
That approximation is sometimes necessary. No organization should grant unlimited authority to anyone simply because they claim competence. But if every high-tempo experiment must first be translated into the old artifact sequence, the organization has already decided which tempo it can operate at. It has chosen the tempo of approval over the tempo of evidence.
Professional Theater
The resistance usually presents itself as responsibility.
Where is the business case? Where is the material? Where is the service definition? Where is the formal offer? What if something goes wrong? What if someone asks why we allowed this? What if the wrong story is told afterward?
Some of these are valid questions. Real responsibility is not optional. Bounded experiments need controls. Customer-facing work must be honest. Technical systems must not be put at risk by enthusiasm disguised as innovation. But there is a difference between risk management and risk theater.
Risk management asks for the concrete failure mode. What can happen? Through what mechanism? With what probability? Under what permissions? Against what constraints? With what test evidence? What is the blast radius? What stops the experiment? What proves that it is safe enough to proceed?
Risk theater asks for the frightening headline.
It replaces engineering judgment with reputational imagination. It treats the ability to imagine embarrassment as equivalent to the ability to analyze risk. It sounds serious because it speaks the language of caution, but it often prevents the one thing that would reduce uncertainty: a bounded encounter with reality.
Professional theater has the same structure. It rewards the visible symbols of seriousness: decks, business cases, approval paths, polished descriptions, stakeholder choreography. Those artifacts are not useless. They become useful when there is something real to package. Before evidence, they can become a substitute for thinking.
The organization then mistakes legibility for maturity. The service that has not yet met a customer looks more professional than the rough service prototype that has already produced evidence. The business case built on assumptions looks more responsible than the experiment that would test them. The old process produces confidence before learning. The new process produces learning before confidence. That inversion is the heart of the conflict.
The Coordination Shift Reaches Productization
AI does not only change coding. It changes the coordination economics around coding, service formation, and operational experimentation. When production gets faster, the bottleneck moves. It moves from making the thing to deciding what should be made, how it should be bounded, how evidence should be interpreted, and how the organization absorbs the learning.
This is the coordination shift applied to productization.
The limiting factor is no longer the ability to produce a first version. The limiting factor is the organization’s ability to tolerate an evidence loop that runs faster than its approval loop. That is where many companies will struggle. They will claim to want innovation while preserving a process designed for a world where execution was expensive. They will adopt AI tools at the individual level while keeping product formation, service packaging, governance, and commercial validation in the old tempo.
The result is predictable. The capable operator can produce evidence in days. The organization still asks for the artifacts that used to precede evidence by weeks. The tempo mismatch then gets interpreted as immaturity, recklessness, or lack of professionalism. In many cases, it is the opposite. The immature response is to spend weeks packaging an assumption because that feels more orderly. The professional response is to reduce uncertainty as early as possible, with appropriate controls, and then package what has earned the right to be packaged.
Productization After Proof
Just-in-time productization changes what a product or service is allowed to be at the beginning. At the beginning, it is not a finished offer. It is a bounded claim: we believe this problem exists, we believe this intervention may help, we believe we can deliver it safely enough to learn, and we will use the evidence to decide what it becomes.
After the first real run, the shape changes. The language improves. The service boundaries become clearer. The risks become concrete. The delivery pattern either stabilizes or breaks. The customer value either appears or it does not. Only then does packaging become useful.
Packaging before evidence is often premature convergence. Packaging after evidence is compression of learning into a repeatable form. This is especially important for services, where the product is often not the tool, the artifact, or the document. It is the repeatable operational pattern: diagnosis, intervention, judgment, tooling, reporting, follow-up, and customer decision support. Much of that cannot be properly designed in isolation. It must be discovered through execution.
The first version should therefore be treated less like a launch and more like an instrumented encounter. The goal is not to look finished. The goal is to learn what should become finished.
The Organizations That Will Adapt
The organizations that adapt will not abandon governance. They will change its timing and its object. They will govern the experiment, not demand a fictional product before the experiment. They will ask for constraints, evidence, test coverage, customer framing, safety boundaries, and decision criteria. They will allow small, competent teams to move quickly when the blast radius is controlled. They will distinguish between a polished assumption and a rough but evidenced service pattern.
They will understand that productization can now happen after the first proof, not before the first conversation.
The organizations that fail to adapt will continue to demand business cases for things that could have been tested faster than the business case could be written. They will reward internal legibility over external evidence. They will call this maturity. They will experience it as lost tempo.
Just-in-time productization is not a rejection of professionalism. It is a rejection of professional theater. The standard should not be whether the idea has passed through the old sequence of artifacts. The standard should be whether the team has found the fastest responsible path to evidence.
In a compressed world, that is the new professional discipline.