The dreaded demo?

Nothing is more scary than the words “live demo.” As developers, designers and product managers – we all focus on how they fail. But what if –  and hear me out – we thought of demos as the mechanism by which we succeed? Whether you are presenting a new feature or in the development process, demos should be thought of as the forcing function to highlight what your product CAN do, and if done right, can be the way your team is brought together.

Let’s take a step back. What makes the live-demo occur? 

• A customer wants to see the first iteration of a new feature that just was pushed out.
• A product manager or upper management asks to review the latest build (which may or may not be stable)
• An investor wants to know what you are doing with all their money

All of these demos make the assumption of a completed “something.” The demo is thought of as a culmination of some work, effort, and time. And, in many situations, it is the ONLY manifestation of  various components coming together.

During the panini press of a product, the team uncovers challenges with integrations, missing testing, edge-case checking, scripts and use-cases that have not yet been considered. Teams often find out that, yes, the spec could have been better, and yes communication with testing could have been better – but they weren’t and it wasn’t. Inevitably – unfortunately sometimes with some sleepness nights – these issues do get resolved.

Now imagine that instead of the external requirement for “live demos”, these were integral development process steps. What if every sprint’s goal was a fully integrated, front-to-back, live demo? This may mean that at the end of the sprint, your team MUST show a widget, for example, working in a real flow. If you are in middleware, the UI must consume your output, and you must handle real data from the backend. UI components must be able to be handled by someone that is not you. Back-end teams must handle real (not synthetic) data, with real parameters. And this must be done IN PUBLIC. This must be shown-off to both your peers and leadership.

Your testing and integration work has been amortized. People do not have (as many) sleepless nights. And your estimates for completion time now are more realistic as the explicitly factor in integration, testing, etc from the start. 

Jump 6 weeks in the future to the inevitable request to see the latest and greatest. You can dust off the latest build with confidence:you know it is stable, you know it is tested, and you know it will impress.