At Mixmax, our engineering team strives for a bottoms-up culture of product ownership. This means that anyone on the team, not just the founders or our product leads, can contribute their great ideas! We believe that all of us is smarter than some of us. ;)
One of our strongest mechanisms for bottoms-up product ownership is our weekly Demo Hour. Every Thursday at 2:00 PM Pacific (when all of our remote employees are online at the same time :P ), we all hop on a Google Hangout to demo the cool things we’ve been working on. Things an engineer might show off at Demo Hour include a recent feature release, an impactful UX tweak, or a “cool idea” prototype. Many of our bestselling features, from our rules engine to our recommended send times, began life in this way - as prototypes and product pitches.
But of course, anyone who’s pitched anything will tell you that having something great is only half the battle: you also have to communicate what it is that you’ve got. To that end, this blog post will give you a few of my learnings from my first year at Mixmax on how to give an effective engineering demo!
Choose What To Demo
Early in my Mixmax career, I rewrote a big legacy view into React. At demo hour, I hopped on the Google Hangout, shared my screen, and clicked around in the newly rewritten view. “Look!” I said. “You can click here, and it’ll make a folder, and here will add recipients to the sequence…” After thirty seconds of this, I trailed off. “And, uh, that’s all exactly the same as what you could do before. But it’s all completely rewritten in React now!”
Everyone laughed, said “good job”, and we moved on. But what I’d realized thirty seconds into my demo was that this work was not very demo-able. Not all work is! And that’s OK - some of the most important work an engineer can do isn’t a flashy new feature. But when showing something off to the whole team, it’s important to consider what makes a good demo.
Some rules of thumb: new features make great demos, while bugfixes generally don’t. Frontend work tends to be more impactful to non-technical employees than infrastructure improvements. Lastly, don’t underestimate the value of tiny UX improvements. The best reaction I’ve ever seen at demo hour was for a three-liner that an engineer coded up to make it easier to copy an email address - but it resolved a huge pain point for everyone who was using our product.
Invest in Impact
Here’s a secret about internal prototypes: your demo doesn’t actually have to work.
“Wait, what?” you may be asking. “How can you demo something that doesn’t work?”
Let’s return for a moment to the purpose of a prototype demo. The purpose of a demo is to convince people of the potential for your cool idea. But building really impactful features is hard! If we insisted that our demo prototypes be ready to ship before we demo them, we’d never spend any time working on actual features. Sure, we want to show off our cool ideas, but we also don’t want to invest too much time into building something that the team may decide we don’t want to ship. How do we balance our time while showing off big, blue-sky ideas?
The solution is to invest wisely when building prototypes. Instead of focusing on internals, invest your effort in the parts of the demo that you think will be impactful to your audience. Practically speaking, this typically means that you should focus on visual ideas. Many demos at Mixmax consist of mostly frontend work with mocked out backends and internals. Don’t be afraid to hardcode data or stub out API endpoints, either!
Tell the Story of What You Made...
The goal of a demo is to engage your audience, and convince them that what you built is awesome and useful. Humans naturally engage with other humans - not with buttons. So, turn your demo into a story.
Let’s say you built a new feature that lets users send messages instantly when they complete a Salesforce task. Which presentation would you find more engaging?
I made this new view in Mixmax where you can type in a subject and a body. Later on, when you complete a task in Salesforce, Mixmax will send that message to someone.
OR
Let’s say I’m Kendall. Kendall is a salesperson, who uses Salesforce tasks to log calls that she completes with clients. She wants to send follow-up messages after her calls. Today, this means switching over to her inbox to manually type out a message to the person she just called. But with this new feature I built, the instant she logs the call, her message is sent for her!
...Not of How You Made It
A really common pitfall when presenting your work to other people is overexplaining how you did it. Try to avoid this! Remember, your audience is not you. For you, the most memorable part of the project may be the really hard technical problem that you solved. But for your audience - especially non-technical folks - “how hard the engineering was” isn’t very interesting. People on your team want to know things like what value your work delivers to users and how it can be effectively pitched, not how many lines of code it was. Of course, you can always leave time for folks to ask you how things work afterwards!
Prepare for the Worst
There are three inevitable things in life: death, taxes, and your live tech demo not working.
Of course, you should absolutely practice your demo exhaustively! Every time you show something off, you’re investing your teammates’ time in the presentation, and presenting without practicing isn’t often a good investment. But all the practice in the world won’t make your demo bulletproof. Any number of things can go wrong, from outages to unexpected corner cases to the internet cutting out. This is why you need to prepare for your demo to fail.
How can you do this? When practicing your presentation, you might leave some test data around to show what things would look like if they worked. Or you might keep design mocks open in another tab. Just don’t try to fix your code live - if something goes wrong, instead of investing your team’s time in watching you try to live-debug, fall back to your pre-planned backup. And keep in mind: if things really aren’t working, there’s always another demo!
Conclusion
Want to have product impact on your team and keep everyone in the loop? You too can give a great demo! Just remember: choose your demo wisely, built it efficiently, tell a story about what you made (not how you made it), and be ready for when it inevitably breaks.
Or, if you really want to learn to give great demos, come join us at Mixmax! We’re hiring!
