Demos are one of the most important tools we use when building custom software. It is our opportunity to check progress, explain the value behind new features, and most importantly, make sure you are building the right thing.
To make sure you squeeze all of this value out of your software demo, keep a few key things in mind. Make sure you have the right people in the room, only show things that are ready to be shipped, and create an environment where you can get open and honest feedback.
Check progress.
This is not a meeting to make sure that work is getting done. Demos are not the time for management to decide if a team is making enough progress. Treating the demo meeting as an evaluation of a team’s productivity will almost certainly lead you down the wrong path.
Instead of fostering an open dialogue where team members feel comfortable seeking feedback and being honest about their progress, you will get demos that obscure the readiness of features and discourage important questions that may be uncomfortable to ask.
The important aspect of progress is not the quantity but the quality. This is the first opportunity stakeholders outside of the team get to see the work that’s been done since the last demo. It’s an opportunity to show off any new features, and shed light on the direction the project is heading.
From this meeting, people should get an idea of where the team is focusing their efforts and what the priorities are. Also, the team gets an opportunity to celebrate and show off what they’ve accomplished.
Show the value.
This is also an opportunity to explain why the work was done and how it benefits the user. We know that users can be resistant to change, even if it’s for the better. So the demo is a great opportunity to show people what the value is behind the change.
Of course this meeting is not only a demonstration of value, but an opportunity for the user to ask questions of the people that know the most about how the software works. Documentation and tool tips help, but it’s hard to compete with a person to talk to.
Make sure you’re building the right thing.
At the end of the day, we are trying to build something that provides value. And all the cool features in the world, can’t make up for delivering something that does not fit the need. While nothing will compare to getting your product in the hands of users, the demo is the next closest thing.
Not only is the demo the opportunity for the stakeholders to ask questions of the team, it’s also the team’s opportunity to ask questions of the user, or at least their representatives. The first time they get to show off a feature and see if it will actually be useful.
This is another reason it is important not to treat demos as a measure of productivity. To build the right thing, you need to create an environment where people will feel comfortable throwing something out if it’s the wrong direction. Being able to admit you built the wrong thing is a key component of building the right thing.
Get the right people in the room.
To get the most out of your demos, you have to make sure you are demoing to the right people. The best people to demo to are always going to be the ones who’ll be using your software. If that is unrealistic, then you want to find a representative who talks to those people directly and knows what they value.
Ultimately, we are building software for our users. With that in mind, no feedback should be more important than theirs. If you don’t have them in the room as you are building the project, then you likely won’t know if you built the right thing until it is far too late.
Not only do you need to make sure the right people are in the room, but you also need to ensure there are not too many people in the room. The group needs to be small enough where everyone is comfortable speaking their mind. Whether you split the demo by team or individual feature, make sure you only include the people that need to be there and have a vested interest in the features being shown.
Only demo what you are ready to ship.
While there can be some exceptions, most of the time, you only want to demo what’s ready to be shipped. This is important because it accurately represents your team’s progress and the effort that went into the work. It also helps establish trust with the stakeholders, knowing that what they are seeing is coming now, and not some time in the future.
It also reduces the time from when something is demoed to when it gets into the hands of the user. You want your stakeholders to walk away thinking about how they want to use this new functionality. And, you want to let them to do this before they lose interest or forget.
Demoing work that’s not ready to ship not only does a disservice to the user, but to the team. It will build resentment with users, who will wonder why the feature they saw working is not yet in their hands, and it will force the team into a position where they are constantly trying to catch up.
More often than not, this happens when demos are treated as a check-in to make sure work is getting done. A team that feels pressure to deliver will make the work they demo seem more complete. Then, after the demo, instead of acting on feedback, they will instead spend finishing the work they demoed as “complete”.
A common exception to this rule is when you need feedback on something especially risky. Sometimes we come across work that is big and hard to predict. The safest route is to demo an idea and get feedback before embarking on a large, unpredictable feature.
Create a safe environment.
Everything I’ve talked about so far is in the interest of gathering honest, meaningful, and actionable feedback. That is where the true value of a demo comes from. Getting the most important people in the room, showing off the work, and making sure you are building the right thing.
Without creating an environment where people feel comfortable speaking their mind, you run the risk of losing the value of one of the most important tools in building great software.