The demo, a cornerstone habit for great products and teams

Issue No. 7

Who would've thought a three-year-old kid's birthday party would've tired me out so much! This newsletter is coming to you a day late (I usually write and publish it on Sunday nights) because I need a bit more time to put the finishing touches on a thought that has been rattling around in my head for the last week.

This week I'm writing about a topic close to my heart - weekly demos. I have already posted about what I think about demos:

📺 A short word on demos
I believe strongly in "show, not tell", as I wrote earlier. Showing our work is inextricably linked to the act of building. Showing the results of our work via demos and storytelling is more powerful than telling. Demos are compelling.
Teams should ideally use weekly demos to show their work to their stakeholders. Ideally, the person who did the job should do the demo.

💬 In this issue, I cover:

• Demos as a cornerstone habit in product development.
• Why demo or show our work every week?
• What should we demo?

🧱 Demos as a cornerstone habit in product development

John Cutler is one of my favourite writers on product development. He recently tweeted how focus should be a set of habits we cultivate rather than trying desperately to prioritise whatever we are trying to achieve.

Check out the thread.

In the same way, developing great products requires us to cultivate a set of habits.

I believe one of the cornerstone habits to building something great is to show our work, at least every week.

❓ So why demo or show our work weekly?

🔬 Focus

It is immensely clarifying for our goals when we know that we will give a demo to our stakeholders at the end of the week. The team tends to focus and collaborate better when we know what we want to demo at the end of the week.

💕 User-centric

We start to think outside in. We put the needs of the user first. We force ourselves to think about the impact we will have on the user's behaviour (what I call an outcome) which I believe will yield better business results.

For example, I once binned a feature I was developing. I realised that what I wrote was unusable for a non-technical user. So I ended up making something much simpler for the user (even though I had to write a lot more code to hide the complexity from them).

💬 Showing leads to a better conversation.

When a reporter asked Mike Tyson whether he was worried about Evander Holyfield and his fight plan, he answered, "Everyone has a plan until they get punched in the mouth." [BTW, Tyson certainly upset Evander Holyfield, but he also lost]

Building things in an agile, iterative way is about trying to have the highest quality conversation as early as possible. Showing our work allows us to get to the moment we are "punched in the mouth" sooner. It leads to those breakthroughs and truth moments faster.

Having a goal of shipping and demoing a product increment every week provides us with a simple plan and quality conversations with our stakeholders.

🎉 Celebrating progression 📈

StackOverflow recently published a report entitled "New data: What makes developers happy at work". They found that (emphasis mine):

When we dug deeper, we found that salary (60%), work-life balance (58%), flexibility (52%), productivity (52%), and growth opportunities (49%) were the top five reasons for developers to be happy at work. [...] Similarly, the inverse of these reasons were the top five reasons developers are unhappy at work: a low salary, no work-life balance, feeling unproductive at work, and the absence of growth opportunities. Feeling unproductive at work was number one (45%) among the factors that cause unhappiness—even above salary, which slipped to fourth (37%).

I believe that demos are a powerful way to show our progression and celebrate the impact of our work.

A team that shows (and celebrates) what they are shipping week in and week out can become a happy and productive environment.

🤷 What should we demo?

It is easy to demonstrate the "sexy" user-facing work we have done and avoid telling the whole story. But unfortunately, there is a temptation in every team I have worked with to skip the "techie" stuff. I think this is a huge mistake.

One of the things I learnt from my friend and fellow pirate from the Red Hat Open Innovation Labs Donal Spring was that you can, and should, demo all of the technical work done in the product increment.

Now not all of us are masters of demoing all of these things as Donal would, but I believe we really should demo all of the work we have done:

• our CI/CD pipelines that allow us to deploy our app with confidence,
• how our shiny new API works,
• our epic code refactors that improved the team's life,
• the new Helm Charts we built to simplify the deployment of all of our apps,
• the acres of Terraform code we wrote to remove manual toil,
• the fixes we did to prevent the recurrence of the last production incident.

There are some ways that we can tell (and celebrate) the story of all the hidden, below-the-line work we have done:

• Show how the work we have done has improved a developer's life.
• Use visuals and funny stories like Derek the DevOps Dinosaur (if you don't have Donal's drawing skills, even though they are not that amazing, why not work with a creative colleague?)
• Last but not least, segment the audience for the demos. I did this when I was the CTO of OCUS. We held a weekly company-wide demo of all the "shiny" bits and then a smaller Product & Tech session where we covered more technical demos.

🔗 Related links

I would not have been able to form my opinions without standing on the shoulders of giants. Here are some of the best resources I have collected in my library about this subject.

Demo-driven development by Jade Rubick.

The Biggest Mistake I See Engineers Make by Zach Lloyd

Demos Over Deadlines by Eric Elliott

That's it for this week folks. I've exceeded my timebox (again) and need to run. I have in mind to write a follow-up on how to plan and run these demo sessions now that I've, hopefully, convinced you that you should be doing them.

If you have any thoughts or tips on doing a great demo, please do get in touch.

Have a great week!

Jeremy (he/him)

Don't ignore your dreams, don't work too much, say what you think, cultivate friendships, and be happy.

📌 Follow me on LinkedIn and Twitter.