Internal Product Demos — Why They’re So Important

Nathan Rhodes
Nov 9, 2017 · 7 min read

I’d like to talk about something that I’ve seen used to great benefit during my career building products — internal product demos. It’s something that I establish with any product development team that I work with because it’s so important. But, it needs to be implemented properly or it can become a major time-waster.

I’ll attempt to explain why product demos are so important, then give you some do’s and don’ts when establishing them and finish off with some pointers on how to scale product demos as your company scales, because — trust me — this is where it can become an expensive time-waster.


What Are Internal Product Demos?

Its important to define what I mean by internal product demos before moving on because its a fairly ambiguous term. What I’m talking about is a demonstration of a product or feature right after its completed to stakeholders within your organization — anyone who has a vested interest in what you’ve just built. This means more than just your product manager, but you should be demoing to them as well. Members of this group include:

  • Your fellow team members
  • Your product manager
  • Your designer
  • Key decision makers
  • The CEO
  • Your legal team
  • Sales, marketing and customers success teams

An internal product demo of this type achieves two objectives:

  1. It ensures everyone is in the loop on what you’re about to release
  2. It gives you one final defence against releasing a bad release to your customers

Your sales team can now sell what you’re about to release, your customer support team isn’t surprised with new support requests because they’re prepared for your new product release, and your decision makers are on board that’s its something they want to release.

Tip: You can also hedge your feedback risk on larger projects and conduct these demos before the product or feature is done, but when a significant part of it has been completed. This is especially valuable for multi-week or month long projects so that you can ensure that your key stakeholders are in agreement that you’re on the right track.


Why Demos Are So Important

If your product team knows that stakeholders are expecting a live product demo, they’ll work hard to ensure that they deliver. If a team is unable to demo at the end of a sprint, its creates a feeling of failure and a drive to improve the next sprint. Hint: continuous improvement.

I’ve seen it time and again, product people are proud of what they build. If they aren’t then you have larger issues to tackle. An internal product demo gives them an opportunity to show their coworkers what they’ve built and gives them a sense of pride.

By demoing what you’ve built to a cross section of stakeholders across your organization its an efficient way to communicate what you’ve built, what’s changed, what customers are going to see, the increased value this will provide, and it gives them an opportunity to ask questions and hear answers from other stakeholders that they may not have thought about themselves.

You may find that depending on who you talk to you get a different answer of what ‘x’ feature that you’re about to release will actually do. Its amazing how quickly seeing a live demonstration (and corresponding Q&A) of that feature clears everything up.

As mentioned above, this is one more set of eyeballs on your new product or feature before it gets released to customers. Its one last chance to potentially learn something you didn’t know about your product and pause the release before making a big mistake.

If you follow the above guideline then you’re going to release better product, and better product = happy customers.

Many times a divide can form between your product development teams and your sales, support and marketing teams. Narrow that divide by including them in your product demos and asking for their feedback. They’ll appreciate the inclusion and reciprocate it by selling, supporting and marketing it better.


Tips for Organizing

I’d like to take minute to share some actionable tips that I’ve learned through implementing these myself.

Try to have all different stakeholders types present at the same time. It cuts down on repeat demos and it exposes each stakeholder to the views of other stakeholders who have different priorities. If you go from one stakeholder to another you’ll get a multitude of feedback that is oftentimes contradictory. If everyone is in the room at the same time they’ll understand why you did something to appease the requirements of another stakeholder.

There are different ways you can hold product demos:

Whenever something is completed, gather the required stakeholders together and give a live demo. Your product manager can be tasked with ensuring the right stakeholders are present. Do it right in the development team’s room, or designate a “demo room” in your office if you value impromptu attendees to your product demos. I’ve seen both options work great. It depends on what you’re building and your ability to control the agenda. The more attendees, the more off track the demo can go, but you may get some valuable feedback that you weren’t expecting.

Set a time each sprint where everyone in the organization can expect demos to happen. Share a quick demo agenda. Anyone can attend. You can usually capture a larger audience this way and communicate your new product or feature to more people. But this can get unruly fast. Ensure you have a strong meeting facilitator to keep everyone on track.

I’ve seen a combination of the above structures work quite successfully. The ad hoc demos are to key stakeholders who have veto power over your product release (execs, legal, product manager, etc), and the formalized demo time is where you can live demo to a large audience ensuring everyone is one same page.

  • Do require live demos. A live demo means that product is actually working. Its hard to hide things in a live demo.
  • Do make sure you have key stakeholders present at the demo. These are stakeholders who can veto your product release.
  • Don’t bring in irrelevant stakeholders to your demos. They can waste time and provide irrelevant feedback.
  • Do ensure someone is keeping the demo on track. Its easy to dive into old features or decisions that aren’t relevant.
  • Don’t have your product manager demo every time. Let the team members demo the work they’re proud of.
  • Do keep the product demo process as light as possible. The more structure added, the higher chance they won’t happen.
  • Do keep experimenting with demo format, time, audience, etc. Always look for ways to continually improve.

An example of when product demos get too big.

Scaling Product Demos

This is one of the hardest things to do with internal product demos. When you only have one or two product teams its fairly easy to fit demos into everyone’s calendar. 15–20 minutes for each demo isn’t much time out of someone’s week. What if you have 10–12 teams? That’s now up to half a day of demos each sprint!

Not only that, you probably now have hundreds of employees spread out across a huge office or multiple office who don’t talk to your product teams as often and aren’t in the loop of what they’re building. As the company grows you need to evolve your product demos.

Here’s what I’d recommend:

  • Keep the team-level ad hoc demos the same. Only involve your key stakeholders at this level. Once you have sign-off from this group then you can demo it to the entire company.
  • For company-wide demos, host them in a large common area where anyone can and should attend. Host them at the same time each sprint. Film them, record each demo for those that can’t attend, and live-stream the demos to remote staff. Use microphones and have a mic ready to pass to everyone who has a question.
  • Consider a science fair style of demo. Each team sets up a screen and attendees can walk from one to the other getting demos and asking questions. This style is great for more intimate demos with a smaller group of people watching, but it does mean that the team will have to demo the same thing multiple times. This style only scales to a certain size. At some point the logistics of moving everyone around will become unmanageable.
  • Another option could be to ask each functional division to send a representative to the company-wide demo with questions to ask from their division, and ask them to report key points of interest their division.

Conclusion

Hopefully this has sold you on the value of internal product demos and convinces you to keep pushing for them in your organization. I’ve implemented and scaled all the concepts mentioned in this article before. Some worked well, and some didn’t. My final word of advice: always keep experimenting and find the format that works for your organization.

Always keep experimenting!

Continuous improvement is key.

Intrface

Saskatoon’s leading community for Product Managers, Designers, and experience enthusiasts.

Nathan Rhodes

Written by

Product Manager at SolidoDesign.com, Board Member at @SRCnews and @SYPEsaskatoon, ICD.D at @ICDcanada, love great product design, avid mountain biker

Intrface

Intrface

Saskatoon’s leading community for Product Managers, Designers, and experience enthusiasts.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade