The demo, a cornerstone habit for great products and teams

Build something great using the habit of demoing our work weekly.

The demo, a cornerstone habit for great products and teams

Issue No. 7

πŸ“°
This is a project by Jeremy Brown. I write about topics that I care about, such as building high-performing teams that make great products, culture, leadership and technology.
As I'm building this newsletter (and a podcast and YouTube channel) in the open, you will get updates on this project here from time to time.

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.

🎁 As a bonus, here are the habits that John suggested will help us focus better πŸ‘‡ 

➑️ Saying "not now" all the time (not just at the start of the year or the quarter).
➑️ Aggressive time blocking.
➑️ Planning at the last responsible moment. No earlier.
➑️ Getting the right people in the same room. Work as a team.
➑️ Aggressively lowering work in progress, even if it means more "slack time".
➑️ Less multitasking.
➑️ Working to *really* clarify our drivers and constraints.
➑️ More starting together. Avoid the temptation to do unfocused work in order to keep other teams "focused".
➑️ Making it safe to "stop the line" when focus is waning. Time to do unfocused work and rest your head/brain.
➑️ Know the difference between "efficiency" and "focus". Focus often looks inefficient. Trying to fill every day may feel efficient, but you'll lack focus.
➑️ Time to do unfocused work and rest your head/brain.
➑️ Know the difference between "efficiency" and "focus". Focus often looks inefficient. Trying to fill every day may feel efficient, but you'll lack focus.

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]

Mike Tyson knocking out another boxer with the quote "Everyone has a plan, until they get punched in the mouth"
Everyone has a plan, until they get punched in the mouth

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.

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.