We’re sometimes placed in situations where we need to present our software to stakeholders, business owners or end users. These users may or may not be technical, but they will most likely be the other side of the user interface you are creating. They are the reason you create software and are genuinely interested in the end result. In recent years, with Agile and Scrum, these presentations tend to take place more often and you’re in the limelight presenting the latest and greatest. Many years of honing our skills as software developers have all but prepared us for this challenge, and we may end up getting a response from the attendees along the lines of this:
Too much uptight focus on technical details, digging deep into issues that nobody cares about, discussing the framework, library or platform chosen to solve a particular problem leaves you attendees bored, confused and sometimes feeling dumb since they haven’t got the faintest idea what you’re talking about. This leads to frustration, arguments, cold-fronts or just a general feeling of “meh”, where developers, stakeholders and users just don’t get the value out of this important meeting arena they could.
So what’s a developer to do? Here are some tips and thoughts for preparing for, presenting and participating in more technical presentations.
Practicalities
If you need a meeting room then book this with a half-hour extra before and after the meeting to allow for connectivity / hardware issues and also open discussion after the demo. Be sure to book the room separately from the actual meeting so it’s only visible to the meeting organiser. Use this extra time wisely; you are the technical expertise of the organisation. You shouldn’t be having technical issues (in front of the stakeholders).
If it’s an online meeting, then verify that the meeting url works, and that there are no connectivity issues. Preferably used a tried solution that people are used to. Experimenting isn’t very popular for the big meetings. Try mixing it up; have a physical meeting where it’s also possible to join remotely.
Avoid Distractions
Exactly, turn off you email client. Your corporate messaging client. Make sure Slack is closed. Actually quit Skype, don’t just hide it to the tray. Close all 5 instances of chrome running with 20 tabs open. Close any non-essential programs on your machine. If you have a “Do not disturb”-mode then turn this on on your machine and phone. Even better if you have a dedicated machine for demo-purposes.
All these distractions decrease the value of the presentation, and any interruption is going to kill your flow. Also, given Murphy’s Law, you can bet that this will be the time some random crash happens in the background to break the demo. Or someone starts a /giphy-war on a slack channel.
Developer Tools
There’s nothing that turns a good demo sour than displaying all your code internals. Having to open up your code editor to play around with variables to demo something. Or demoing web-based software with F12-developer tools open. It’s basically exposing all the internals of the lovely piece of software that’s meant to be on display.
Drop the Jargon!
Avoid using technical terms as much as possible. We don’t need to explain which version a framework has. That a shared library has been updated. That you’ve started using a new library. The detailed approach you’e taken and how you needed to do this or that to reach the desired outcome. Why you’ve decided for the one library vs another.
Focus solely on the end value of the changes that are being introduced by doing any of the above mentioned actions. If we’ve done refactoring / technical improvements that don’t really bring any value then don’t even mention it. It’s not important. It’s not like we hear when the CFO gets new excel reports with awesome formulas.
Dont’s |
Do’s |
| Use internal product code-names: Maverick, Tomahawk, Banana | Refer to the projects as what they are or represent. Marketing System, Campaign Manager, Commerce back office etc.
Even though stakeholders / users can learn the codenames, it’s not needed. They don’t need yet another buzzword to stumble over. Either we teach them bad habits, or they stop taking us seriously. |
| We upgraded to version 3.42.3 of <name cms system here>. | We need to update the underlying platform due to security updates. This shouldn’t affect you, but please let us know if you experience any issues.
Gives stakeholders a heads up that maintenance has been done and issues may arises |
| As you can see here (opening F12 developer tools), when I press the button an ajax request was sent to this endpoint and it returns a success = true/false | When I press this button you see a spinner and an acknowledgement when we place the order. If there are some technical difficulties, we show this human-friendly text explaining the situation as best we can.
Offers a simple and expected behaviour that the stakeholders expect. It’s also easier for the dev-team to focus on build wonderful experiences that make life easier for users. |
| We updated an internal reference project “blackbird” to version 3 that contains the detailed themes that we can share for our projects. | We updated our user interfaces look and feel to match our universal product guidelines. You should feel right at home when switching between our products. This should make it a lot easier to read the content for our users. It should also be a lot more intuitive.
Could spawn off a discussion about the general UI. Or maybe people could easily recognise the value and accept this. |
| We had fixed a bug where there was a race conditions that arose when 4/5 users tried updating the same sales document. | We discovered there were issues when multiple users attempted to update the same document, so we’ve limited to be edited by a single user at a time.
Could spawn off a discussion about why more users can’t edit different part of the sales order at the same time.. they are different jobs and expertise => new change that better matches the needs |
These are a few examples, but by focusing on the dialogue in the “Do’s” and less on the “Dont’s” we greatly increase the value for everyone. There will always be some issues where you actually need to dig a little down into the technology, but those should be the exception to the rule.
Make sure the right people are there
This is essential to having a great demo. There’s nothing worse than having a great demo / presentation with the wrong people there! Don’t be afraid to invite more people than necessary. If you do, then stakeholders that might be good to have there, but are unsure may more easily may be convinced of the presentations importance. Frame the demo as an important presentation for the entire business so people feel the need to be present and involved.
By doing so, and delivering on the demo, stakeholders will see more value and want to be present at the next. It becomes a self-fulfilling prophecy. If possible, record it and send it to everyone so those who couldn’t make it have a chance to catch up.
Speak “business”
Use the same terms that the stakeholders and users use. This greatly improves communication by showing that you care about their domain, which will in turn reflect in the software. It also allows for more discussion since they understand whats being presented. This works both ways, and builds trust instead of enforcing the divide between “IT” and “the business”.
The software we create is meant to make their every day lives easier, so shared understanding is paramount.
Get to the point
Meetings are often a waste of time, mostly because there is no clear agenda or end-goal. The demo / presentations end-goal is to showcase your work, gain valuable feedback and give stakeholders a good idea of how things are going. This also often sparks new prioritizations and allow them to “feel” the software.
With this end-goal in mind, prepare well for the demo. Make sure that you don’t go off presenting edge-cases or spend time discussing the details of something that isn’t important. Get to the point, present it well, and create a great relationship with the business.
Don’t hinder dialogue
It’s crucial to have an open arena for discussion, so strive to allow conversation, comments questions during a demo. This will lead to more valuable insights and allow for even more engagement from all parts.
Sometimes dialogue can escalate to accusations or surprise that features were implemented a specific way. Try to be humble and approach this with respect and understanding. Sometimes we oversimplify and the demo is the best place to gather stakeholders to unearth potential problem. It’s also a great place to uncover issues with underlying business problems. Where we’re struggling to recreate the software accurately because the rules are too complicated, which may mean the business problem could be approached completely differently.
Sometimes developers outnumber stakeholders by a large degree. This sometimes doesn’t sit we’ll and create an atmosphere on insecurity for stakeholders and thus hinders dialogue. If this is the case, try having a few developers present and rotate among the team.
Make it shine!
This is the hard one, and also probably the most important since it requires all the others. Presentations don’t have to be boring. Show that you are proud of what you’ve accomplished. Have a light tone and don’t be afraid to smile. Nothing kills a great product (demo) more than a lack of enthusiasm for what is being presented and tailoring it to the audience.
There is another advantage with bringing along some showmanship; namely that this will likely allow attendees to loosen up and be more open to give feedback. So everybody wins!
Moving beyond the demo
Product demonstrations are a great place to gather stakeholders and users from across a business to talk about software that touches their daily lives. It’s an opportunity to create an atmosphere of trust and understanding that continues long after the presentation is complete. By taking the time to nurture this arena, everyone involved wins.
How do you use a product demonstration to better bring you and your stakeholders closer and improve your products?
I would love to hear your thoughts on this matter. Feel free to drop off a comment or reach out to me on twitter.
