It looks done
Part 1 of 3: paying attention to where you are on the journey
Sound and vision
I spent a couple of years working in film production. I used to joke that the hardest part of any endeavour was finding something worth producing. Then the hardest part became polishing the screenplay. Then the hardest part was raising finance. Realising the director’s vision from the screenplay in actual production? So much harder than anything else, but an absolute breeze compared to post-production. Then, depending how the finance was raised, you have to sell the thing you’ve made and get it into festivals, which is, as you’ve probably guessed, harder again. You can fail, and your project can die at any of these stages.
I learned that film production is both ruthless and the preserve of wild optimists.
The thing that kept optimism grounded is that you always knew whether you were looking at a rough cut or a finished picture.
It Looks Done
She built it in two afternoons.
It works. You ask it a question in plain English and it answers. It reaches into the right data, comes back with something sensible, and does it while the room is watching. When she finishes, a Senior Director says the hard part is behind us, and everyone believes him. Including her.
The demo is a real milestone. The thing she built in two afternoons would have taken a team a quarter not long ago. It’s a notable achievement.
But the truth is that the hard part is not behind us. It has barely started. The trouble is that the demo was convincing enough that nobody in the room remembers the difficult part is still ahead. There’s a lot of work remaining to turn Pinocchio into a real boy.
The afternoon that looks like a quarter
For most of the history of software, the prototype looked like what it was. A wireframe was obviously a wireframe. A click-through prototype was obviously a fiction in the same way as a storyboard is obviously a guide to how to shoot a particular scene; you tapped the one button that worked and everyone understood the rest was painted on.
You could not mistake the sketch for the building, because the sketch looked like a sketch. Turning it into high-fidelity software was obviously a future step.
Figma started this change. The quality of prototyping Figma made possible is the silent movie era of the current moment. AI has pushed us into Technicolor.
The thing you build in an afternoon now looks like the thing that takes ten weeks. It speaks fluently. It handles the path you walk it down. It makes all the right noises while the room is watching. It does not look like a sketch; it looks like a product.
A convincing prototype used to be expensive, and the cost kept everyone honest. Now the convincing version is an afternoon’s work.
Speed of discovery
The speed at which you can discover if an idea is worth pursuing has always been the part worth speeding up. Learning what might work matters more than the race to market, because most ideas do not deserve to be built and the cheapest thing you can do is find that out early. AI has promised to make that work nearly free. You can stand up something real enough to test a hypothesis in an afternoon.
A demo tells you that you have understood the problem well enough to fake a solution. It tells you that you haven’t failed yet. That is all it tells you. It does not tell you the solution holds when the data is missing half its fields, what happens at scale, what edge cases are going to keep your development teams and support teams awake at night. It says nothing about the guardrails required for operation in the real world, or how a particular experience can be explained to a regulator.
That distance, between a thing that works in the room and a thing that works in the world, is the same size that it has always been. We’ve made getting to the room faster, but the hard part is still ahead of us.
A beautiful prototype is a matte painting. From the one angle the camera is allowed, it is a whole city; step sideways and it is plywood and paint.
The ten months of development work do not vanish. They become a surprise. The surprise becomes a “delay.” The delay becomes a problem that gets escalated. The escalation slows the development team further as they are subject to a cycle of progress reviews. All because an assumption was allowed to take hold that the hard work was already done.
The order of difficulty
I have spent a long time defending discovery, warning about teams that skip the qualifying step and rush to build. Now, something else is happening: the fidelity of the prototype lets the qualifying step be mistaken for the product itself.
There’s still a benefit when the demo is used to inform customer discovery. The discovery and learning are real. The danger is that the demo can enable a room of insiders to talk to itself and call it research. Nobody has been near a customer; the organisation has admired its own reflection and recorded the self-admiration as discovery.
The same admiration then becomes the roadmap. One beautiful thing, standing in for the two hardest conversations there are: the one with your customers, and the one with reality. The organisation mistakes finding something that could work for something that works.
It’s always been hard to understand whether or not to build something, harder still to build it, and harder again to validate the hypothesis that drove you to build it. The demo looks done, the room exhales, and the work that was always hard goes quietly on being hard, somewhere downstream, on someone else’s roadmap.
She built it in two afternoons. It works. It is not yet a real boy.