"It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so."
- Mark Twain

The Program Demo

During a Program Demo, we get to showcase our work and get input from other program participants and our stakeholders. This demo is important when creating a new product because features are constantly being refined and redefined based on all the new information we uncover as we implement them.

The Program Demo is different from the regular product demo held by the team with their Product Owner. At a Program Demo, you get to see the latest feature increments that will be rolled out in the next day or so, the designs for upcoming features and the latest version of product priorities. You should also hear from other participants who work outside the immediate team but are key to the success of the product. Do we have the latest content available yet? Have we identified the first beta users? How are we doing with those contracts? This demo is particularly effective (and efficient) at helping everyone see their contribution in the context of the product. This ritual might be especially critical under some organizational characteristics (eg very large, hierarchical, siloed or bureaucratic) that would more naturally direct people’s work than keep them informed and involved.

The frequency of these demos depends on your pace of change and the risk of whole-team divergence or misinformation. We tend to do them on a weekly basis. Our time box is no more than an hour and we aim to be done in 30 minutes.

If the team only typed faster…

Although they are the exception, we have had cases where we’ve been asked to stop wasting software developers’ time on the Program Demos. Whatever the motivation, this request is at least consistent with a belief that time spent TYPING is a constraint to product development, which it is not. FEEDBACK is the constraint. Such requests are also characteristic of “Software by spec” management, which relies so heavily on divination-disguised-as-conviction that we might as well request that the project be managed by astrology. The reality is that the spec is to product development as the game plan is to the game. It was great to help you prepare but as soon as the game starts, reality trumps the plan every time.

The net effect of canceling the regular product demo is a not-so-slow train wreck:

• Developers have a couple more hours a week they can spend typing, but with less feedback, they are much more likely to be “typing” the wrong thing. They may be delivering the requested features, but the outcome is the product getting increasingly worse.
• The broader team (marketing, content, creative, legal, compliance and anyone who had previously come to the demo) no longer gets to see and react to evolving product features. This will increase the problem of groups working IN A VACUUM.
• Developers do not get to see the reaction from the broader team, which means they will not have a chance to course-correct until something stops working for one of the teams. Or for a user. In production.

This is a particularly hard request for us to take because we want things to go exactly the opposite way. The broader group would benefit from making this demo more effective, but also hearing about the the team’s direct interaction with users.

What are we optimizing for?

A common reason that the demo does not work for some folks -- even most of the attendees -- is when we continue to allow each functional silo to define their success as independent groups. This pattern is invariably linked to concepts such as "division of work", "management by accountability”, “specialization”, “optimizing utilization" and any/all other techniques rooted in industrial and manufacturing practices. However, these don’t support the things that are required by product development and software: knowledge, innovation and discovery. No group should be allowed to optimize for their own functional area and that is exactly what we promote if we cancel (or otherwise “minimize”) the product demo.

On one project, we needed a lot of new content for a product. The content group was its own unit rather than part of the team, so we asked them to check their content through the product. This process yielded more interaction and a clear acceleration, as reported by both content and software folks in this particular example.

All about the feedback

When you feel completely certain about the product direction and just want to get those developers to type faster to get you there, refer to Mark Twain because that certainty probably “just ain’t so”. Feedback is how you stay out of trouble in product development. Your product development team needs to make small tweaks and course corrections, and that relies on access to empirical evidence directly from users. The broader program team needs to keep up with what should be a steady flow of small changes in direction. That wouldn’t matter If your direction were constant, but if it is, that is more likely an indicator you are failing to learn as you build. Sponsors, stakeholders and leaders did not and cannot divine the product, but they can set its boundaries and offer testable hypotheses for the team to validate or invalidate. For that, they need context and all the emerging information that becomes available through the build-measure-learn product cycle.

Here are three things that help your product team be successful:

1. Get everyone on the program together regularly, show them the latest version of product and ask for their feedback.
2. Ask everyone on the program to show the impact of their work through the product itself and give them feedback.
3. Give the team direct access to actual users of the product they are building and invite those users to the Program Demo so they see all the moving parts. Listen to users’ feedback.

Tell us what you think. Give us feedback: info@labzero.com