The Purpose Of A Demo Is Feedback

Internal tech demos exist so that stakeholders can see and comment on the work being delivered.  Hopefully the demo produces smiles, cheers, and high fives.  Often, the stakeholders will ask questions and make objections that take everything off of the rails.  These can be painful moments; they are also extremely valuable.

Disastrous demos give you at least one of two great pieces of information:

You learn that you were building the wrong thing.  

Having bug free, highly performant code doesn’t matter if it is correctly doing something other than what stakeholders want.  The longer it takes to learn that you’re building the wrong thing, the more time and money you’re wasting.

It sucks to hear you spent a week or two building the wrong thing and need to scrap some work.  It sucks much harder when you’ve spent 6 months heading in the wrong direction.

You learn that you can’t speak to the business value

How you demo reflects your understanding of the software.  I’ve seen many demos where the developers have delivered the right thing, but they don’t understand why.  Software development in knowledge work; “I built what I was told” is the wrong answer.  

You need to know why stakeholders want the software, and speak to it in your demo.  When you have the value wrong the stakeholders will tear the demo apart looking for their business value.

Remember, demos are for feedback

Disastrous demos suck.  Disastrous demos are also successes – you learned something critical about the project that you didn’t know.

Don’t let disappointment distract from learning and improving.