PORABLES — FROM DEADLOCK TO POSSIBILITY
The Engineer Who Asked for a Worse Demo
By Ravindra Dastikop
The story
Every Friday, Dev’s AI demonstration impressed the client.
Every Monday, someone explained why it wouldn’t work in their department.
Dev was a forward-deployed engineer. He worked alongside the client’s staff to turn AI capabilities into a system they could depend on.
But the project had become a procession of successful demonstrations and postponed decisions.
“Make the next demo more convincing,” his manager said.
Dev polished the interface. Improved the examples. Rehearsed the presentation.
Then he stopped.
“What if the next demonstration looked worse—and helped us move forward?”
He opened a blank document.
What could “worse” mean?
More interruptions, perhaps. More unanswered questions. A system that stopped instead of confidently completing everything. A meeting in which customers explained their work while the engineer listened.
One possibility caught his attention.
What if the demonstration’s purpose was to uncover what they still didn’t understand?
At the next meeting, Dev made an unusual request.
“Bring a difficult case that represents your actual work. Use synthetic or appropriately sanitised information. Before we run it, tell me what a useful result would look like.”
The operations lead brought a request with missing information.
“We need the missing details,” she said. “But we shouldn’t have to start the whole request again.”
A specialist brought two documents that contradicted each other.
“Show me the disagreement and where it comes from. Don’t quietly choose one.”
A supervisor brought a case requiring approval from someone outside the room.
“Prepare the recommendation,” he said. “But only the authorised person can approve the action.”
They ran the cases.
The assistant stopped without explaining what information was missing.
It overlooked the contradiction.
Then it proposed an action the user wasn’t authorised to approve.
Dev’s demonstration had never looked worse.
For the first time, the team could put precise requirements beside the failures.
Each case received an expected outcome, an owner and a repeatable check.
Dev began drawing.
Incomplete requests would become requests for specific missing details. Conflicting documents would be surfaced with supporting passages. Restricted actions would become approval requests.
The AI could prepare those requests, but the execution service would act only after verifying the approver’s authority.
“Will this make it ready?” the supervisor asked.
“It gives us something concrete to build and test,” Dev replied.
Over the following days, they tested ordinary requests alongside difficult ones. They repeated trials and reserved additional cases that hadn’t been used while developing the system.
They measured useful completions, missed exceptions, unnecessary escalations and review time. They checked that unauthorised actions remained blocked.
Some changes helped. Others created new problems.
The team revised the workflow and tested again.
When the agreed criteria were met, they began a narrow, monitored pilot.
At the next demonstration, the assistant asked for missing details, highlighted a disagreement and paused for approval.
It looked less effortless.
It looked more like the work the client needed done.
The PO behind the story
“PO: A worse demonstration is progress.”
The provocation did not make failure desirable. It opened a different purpose for the demonstration: discovering requirements rather than displaying effortless success.
The demonstration looked less impressive because it had become more informative.
↑ Back to contentsSpot the lock
Dev assumed that a more convincing demonstration would resolve the client’s hesitation.
What does your demonstration leave out to keep everything running smoothly?
↑ Back to contentsFind the gateway
Dev explored several meanings of “worse” before choosing one to pursue.
The resulting shift was from “Watch what our AI can do” to “Help us discover what this work requires.”
Difficult cases became shared design material. Expected outcomes turned them into evaluation cases.
↑ Back to contentsTry the move
Choose one prototype and invite intended users to contribute three difficult, representative cases using synthetic or appropriately sanitised information.
Before running each case, agree:
- What should the system complete?
- What should it flag or ask?
- Which actions require authority?
- How will you check the result?
Test ordinary cases too. Repeat trials and include cases not used during development.
Treat the exercise as a starting point for learning—not proof of deployment readiness.
↑ Back to contentsResearch note
This is an original, source-informed fictional POrable. Its depiction of customer collaboration, evaluation and controlled execution draws on published engineering practices.
The characters, dialogue and outcomes are invented. The PO is a modern adaptation, not a quotation from Edward de Bono. The story does not establish that these engineering practices are new or that worse demonstrations inherently produce progress.
↑ Back to contentsFurther reading
- OpenAI: What FDE means at OpenAI
- Anthropic: Demystifying evaluations for AI agents
- Microsoft: Authorisation in Microsoft Entra Agent ID
- Edward de Bono, Serious Creativity (1992), discussion of stepping-stone provocations, printed pages 168–169.
