In the vein of learning more from failure than success, a disastrous demo will teach you more than a triumphant one. Don’t get me wrong, triumphant demos are awesome! Triumph as much as possible and then get back to work.
Disasters teach you, or your stakeholders, that something is wrong. Remember, the purpose of a demo is feedback, and the feedback may be that you are on the wrong path.
As a developer, you may be doing a great job at building the wrong thing. You may discover that you don’t understand what you are building or why. The sooner you learn that you are off track, the sooner, and cheaper you can get on the right track.
But there are two sides to a demo.
Demo feedback is about more than just the presenter
I’ve walked into a dozen demos expecting triumph and congratulations only to hear “now that I’ve seen it, this isn’t going to work.”
Stakeholders get off track too.
You can build what your stakeholder asked for, understand everything about the problem, and still deliver something that won’t solve the problem.
Your stakeholder will never know until they can see and touch it. And they will see it, live, in your demo.
The sooner that stakeholders learn that they are off track, the sooner, and cheaper everyone can get on the right track.
Most Demos Aren’t Disasters or Triumphs
Most demos are constructive. You present, you get some feedback, you move on to the next slice of work. You learn a little about the next slice of work.
Disasters are no fun, but they do give everyone a chance to learn from the experience. Demo early, demo often. Demos are for feedback, and feedback leads to delivery.
