Living Product Vision
Because the demo never had to hold up in production, AI made it cheap enough to keep. Something with proven value to the business became affordable at our size.
What I introduced
At a recruitment technology scale-up, we had a separate demo version of the product: a fully front-end, live mock-up of where the product was heading, running alongside the real platform. It already existed before I joined, and it was valuable well beyond product. Sales used it to show prospects something real. Leadership and the board used it to react to ideas in something far less abstract than design drawings.
The problem was cost. Keeping a second version of the product current, in parallel with building the real one, took more resources than a company of our size could justify. Its value was clear, but it wasn't sustainable.
What changed that was bringing AI-assisted building to it. Because the demo only had to look and behave right, not run in production, it didn't need the safeguards the real product needed: extensive testing, hardening, code reviews and long-term maintainability. Without those requirements, the work no longer had to sit with an experienced engineer. With AI, it was within reach of a talented designer, and that's the direction we had started taking it.
What it revealed
The value was never the problem. Everyone agreed the demo was useful. It was at risk simply because it was too expensive to keep up. AI didn't create new value here. It made existing value affordable.
The right standard depends on the purpose. The real product needed every safeguard a production system needs. The demo didn't. Matching the level of rigor to what each one was for, rather than applying the same standard everywhere, is what made the demo affordable, and it widened who could work on it.
People respond differently to something real. With prospects, leadership and board members, conversations about direction moved from interpreting drawings to reacting to something they could click through.
When everything looks finished, each artifact's role has to be explicit. AI makes it possible for a rough vision to look polished, so the line between vision and specification gets easy to blur. We were deliberate about it. The demo was the vision: low fidelity in what it committed to, even though it looked high fidelity. The design files were the source of truth for engineering. And the product increments shown at sprint reviews were what we judged for correctness.
What it means for a product organization
Most organizations have a list of things that are clearly valuable but have never been affordable: demos, internal tools, prototypes, alternative versions to test with customers. AI changes that list. It's worth revisiting what was ruled out on cost alone.
It also makes quality standards a leadership decision. The standard should be set by an artifact's purpose and lifespan, not by the tool used to build it. AI-assisted building can meet production standards when the work calls for it, and it can also deliberately skip what a throwaway or short-lived artifact doesn't need. Treating everything as if it needs production quality wastes one of the biggest advantages AI offers. But the boundary has to be explicit, especially the rule that demo code never quietly becomes product code. Otherwise, shortcuts meant for a demo end up in the real product.
And when AI makes rough work look finished, organizations need to be clear about what each artifact is for: which one shows direction, which one specifies what to build, and which one is judged for correctness. Without that, people end up giving feedback on the wrong thing, or treating a vision as a commitment.
What I'd test next
Letting design own the working vision directly, and testing whether some of the early work done in design files today could start there instead, without blurring which artifact is the source of truth.
See the other things I've built to test how AI changes product organizations.
Back to Fieldwork