My former manager used to come to all of my team’s product demos. Every time he’d enter the room, he would say: “Demo day! My favorite day of the week.”

There is a lot of truth in that statement. Demos are a pretty critical moment for teams and managers alike. You can find out whether or not a team is working well together from how they demo. You can understand whether or not the manager is implementing clear and consistent processes. More than anything, you can determine whether or not the team is shipping clear customer value on a weekly basis.

I’ve run and participated in several hundred demos over the course of my product management career, and I’ve seen a lot of things that work (and a lot of things that don’t). Maybe you’ve run lots of demos and this will be redundant for you, or maybe you’re looking at your current demos and trying to give them a tune-up. In either case, like any meeting or process, demo meetings need constant re-evaluation in order to remain effective.

This is the first question you should ask yourself before scheduling any meeting, but it’s especially relevant with demos, given their objective and time needed.

Who needs to be at the demo?

I’ve found the DACI model especially useful in this assessment. Who Drives the meeting? Who is Accountable to the meeting accomplishing its objectives? Who Contributes to the meeting’s outcome? Finally, who gets Informed of what happened (but doesn’t necessarily have to be there)?

An engineer from the team (rotated weekly, as we’ll discuss below) is the Driver. They tell the story of what happened during the week and queue up each member of the team to demo progress.

The engineering leader for the team is Accountable. They identify when the meeting is going off-track and bring it back. They make sure the team has a clear narrative and script going in, and that there are not major contentious issues to resolve beforehand. Occasionally this person is a project manager, but my finding is that project managers often lack some of the context and direct management responsibilities of an engineering leader.

There are many Contributors to the meeting, but the ones that I’ve always found to be especially useful are as follows:

• Product Manager and Design: they answer the question “Why did we do this?” as well as tie the work to customer value.
• Customer Support: they are a critical customer touchpoint that can both evaluate issues from the previous week, as well as stay updated on product changes that need to be externally communicated.
• Sales and Marketing: you don’t want to fill the room with folks from these roles, but you should have a technical sales lead and a marketing lead who can leverage demos to know what’s coming and think about how they might want to market it.
• Senior Product Manager and Engineering leaders: this is how the engineering manager and PM are kept accountable to their objectives, and how these leaders get the real truth about what’s going on.

Demos are an area where transparency is key. In my view, the entire product organization (if not the entire company) should be Informed. Oh, that reminds me: record demos and share them.

Here’s a familiar story: an engineer starts demo-ing some changes they’ve made to a core UI component, gleefully stating that they refactored some code with an open-source library they found on Github. Another engineer on the team is giving them the daggers glare. Almost on cue, they say “can we pause for a second and dig into why you chose to do it this way?” Right there, in that moment, the demo is over. Get ready for a technical wrestling match.

This is completely avoidable, but it requires a bit of prep. During your standup, as you’re planning what to demo, ask the team a simple question: “Does anyone have any major concerns with this week’s demo that they want to add to the list for our planning and retro after the demo meeting?” Document the concerns. Make it known that the team isn’t going to discuss those during the demo, but they’ll be brought up once the other stakeholders have left the room.

Another method I’ve found useful to avoiding these kinds of disagreements is leveraging mob programming. Mobbing is a pretty crazy concept in theory, but in practice I’ve found it almost universally increases team throughput and code quality, and creates skillset redundancy within the team. It also means that everyone has a hand in decisions, which means that disagreements get moved upstream to the coding process as opposed to showing up in the demo.

Demos should be 30 minutes. That’s it. Anything longer, and you’re in a brainstorming session.

By setting a hard limit on demos at a half hour, you create urgency to move quickly across topics and take ratholes offline. A huge part of achieving demo snappiness relies on preparation. You should have a really simple document for the demo that the team fills out over Slack ahead of time (you can use a Slackbot like Standuply to do this automatically) to illustrate what they’re planning to demo. If it’s not in the doc, it’s not getting demoed.

What does a good prep doc look like? It should pretty much be a list that matches with what you initially set out to do in your week ahead planning. Basically, who is demo-ing what, and why it matters to the customer. Your PM can help with the context part (also: your PM should be at all standups).

I could write an entire treatise on the importance of building T-shaped people on your team, but suffice it to say that you want people on your team who can do pretty much any job with reasonable aplomb — even if it’s not their core specialty.

Demo leadership is no exception. Just as you might have hero rotation for on-call on your engineering team, you want to have the same rotation for leading the demo. While the engineering manager is ultimately accountable to the demo, you want folks on the team who can shoulder the burden when the EM is out.

This tip is simple: every week, have a different member of the team lead the demo. They introduce each engineer and their work, and keep the meeting moving. This is a great way to get junior engineers integrated into the team, and ensures that you build a team of leaders who all feel a responsibility for running a great demo.

Besides technical ratholes, one of the primary failure modes for a demo is when it evolves into a planning meeting. This is usually where senior stakeholder X asks why the button is green and not blue, or when the team starts solution engineering right before your eyes about an issue they haven’t been able to resolve.

This doesn’t mean you should block all questions or attempts at analysis, but rather than each of those becoming a topic to take offline, instead move them into the actual planning meeting that comes after the demo. This is a primary responsibility of the engineering manager: they jot down notes from the stakeholders in the room, pledge to take those topics offline to the team, and keep things moving along.

A demo provides a ton of context for what’s coming next week. You learn about new issues, new decisions, and new customer needs that should be accounted for in the next week’s plan.

As much as you want to avoid recency bias, you should absolutely be bookending your demo meetings with a quick retro and a very lightweight planning meeting. It’s when the information is freshest and the team is most in-tune with what they just shipped. Budget an hour on top of the demo meeting for this, ideally in the same room.

There are lots of ways to run retros, but I’ve found the most success by making them values-driven. Which means, you make a 3x3 matrix on the whiteboard or in a doc that looks like this:

Each member of the team takes turns adding things they think are good or bad and maps them to Customer Value (things that materially helped or hurt the customer) or Team Value (things that materially helped or hurt the team). By dividing bad and good things across these two vectors, you start to understand some trends from the week: typically, a really good week for Customer Value may end up costing Team Value (e.g., we shipped some code that is going to cause some on-call pain) and vice-versa.

For planning, I’m a big fan of simplicity. List out what you didn’t get done from last week and make that the top things for the coming week, assuming it’s still relevant. Then go to your project plan and work with your PM in the room to decide what’s next and most important. I don’t like to use story points or any kind of estimation system, as I’ve found the team is the best arbiter of what they’re capable of outputting and will figure that out as weeks progress.

Nearly every large organization has some form of status reporting process and toolset. Senior product and executive leaders are constantly trying to figure out what everyone’s working on and whether or not it’s trending in the right direction.

Status reporting relies on consistency. If one team reports their status using pages of text replete with Impact-font memes and another reports it using a spreadsheet filled with SLI metrics, you’re going to have a tough time answering key questions about team health. Above all, one of the major things I believe is that demos need to follow a consistent process across the organization. Doing this accomplishes several things:

• You get a uniform set of data across product teams
• As engineers, EMs, and PMs rotate in and out of teams, they know what to expect
• Demo stakeholders (the HiPPOs who join and love to make the meeting longer) also know what is expected of them in terms of contributions

A great way to accomplish this is to survey your teams and ask them about their current process — keying in on the concepts we talked about throughout this post — and use that as a data source to re-evaluate processes across the organization. Some teams will certainly feel less enthusiastic about this streamlining, but the net benefit to the organization and to the engineers will be positive.

Demos were not only my boss’ favorite day of the week. They were also mine, for slightly different reasons. They were the moments in which I had the most fun doing my job.

Demos are a great place to showcase personality, for the team to feel proud of the work they do, and for creating connections across job functions. The demo should be fun. It should be engaging and energizing. With a lightweight, repeatable, and simple process to carry the meeting, the fun parts become more apparent and realizable.

Want to have better and more productive meetings during the week? Sign up for Reclaim.

Big thanks to PM Insider for their assistance in editing and publishing this post on their blog.

‍