How To Get the Most Out of a Software Demo

Overview

After sitting through many software demos over the years and having now led hundreds of them, I’ve made some observations of how to get the most out of them from both sides, but especially from the perspective of the buying team – the potential users. The bigger and more complex the organization, the more steps in the evaluation cycle, but the more impactful the software would probably be to everyone.

If I had to summarize what makes for successful demos and software evaluations in general, I’d say it’s alignment. Alignment on the buyer side amongst the evaluation team and other departments they interact with, alignment within the seller team, and alignment between the buyer and seller teams. The most important alignment is with those that make the final call and sign the checks (hint: it’s mostly about reducing time, cost, or risk). I’ve seen way too many groups get excited, see huge potential in a product, and the evaluation goes nowhere because they struggle to “sell” internally. Alignment is the key!

By the time you’re at the demo stage of a software evaluation, you should be relatively serious. If you just want to “see the possibilities” or “kick the tires,” there are more appropriate ways to do this. Field events, webinars, pre-recorded videos, talking with colleagues – these are all easier settings for you and the seller team. If your organization has no serious intention of considering buying, you’re probably not ready for a demo yet. Being honest about this will help the seller team act accordingly.

Here are ten considerations as you look to best leverage a software demo, and below are thoughts expanding on those considerations, separated into three sections: planning the demo, attending the demo, and demo aftermath.

Planning the demo

1. Share your challenges and goals and prioritize them
2. Do some initial research
3. Provide crucial requirements
4. Invite the right people

Attending the demo

5. Show up to the meeting
6. Keep an open mind
7. Ask meaningful questions
8. Highlight the day-to-day stuff most

Demo aftermath

9. Focus on the value
10. Provide timely, honest, and specific feedback

Planning the Demo

Share your challenges and goals and prioritize them

You wouldn’t be looking at software if you didn’t have some challenges and goals to overcome those challenges, right?  Discuss those internally, prioritize them, and share with the seller team.  This helps them focus on what means most to you and others in your organization.  Look for the specific ways the product can help solve your challenges and achieve your goals by answering three questions:

• Why should we change?
• How should we change?
• Why should we use this product?

If the seller team can’t clearly answer those three questions, it’s time to move on!

Do some initial research

The internet has changed the game for buyers and sellers.  There is more information available than ever before.  That’s mostly a good thing.  But don’t let that take away from your evaluation.  After all, things change, and only you know the exact environment with which you work.  Initial research is great for that first level of qualification – to see if a product fits what you’re looking for.  Ask colleagues about their experiences.  This is where social media shines!  This helps educate you sufficiently to provide crucial requirements and ask meaningful questions (see below!).

Provide crucial requirements

Put together a thoughtful list of your requirements, and ideally tie them to your goals.  Prioritize them and label them as mission critical, need to have, and nice to have.  Chances are no product will meet 100% of all of your requirements, so be okay with that.  Include this in your vendor evaluation file.  If you don’t have a vendor evaluation file, ask the vendors you’re evaluating – they should be able to provide a good template.  Providing both of these in advance also helps focus the demo and other conversations on what matters to you.  Solicit requirements from different levels and functional groups (especially the technology group as likely the software will need to integrate with other products).  Revisit these requirements after all the software demos you attend.  Chances are you’ll want to add or revise some items.

Invite the right people

Include a mix of people in the demo meeting.  Various perspectives (doers, reviewers, and others) help you evaluate the way those people work and how the software would support them.  If the group is small enough to warrant introductions, have the user team share any prior experience with the software and one thing they are looking forward to seeing or learning (again, helps with alignment!).  Unless the software has a heavy amount of administration, generally including IT in the demo is not necessarily.  I’ve seen many meetings get sidetracked by several IT questions that are best suited for a technical meeting and not the general potential user base.

Attending the Demo

Show up to the meeting

It may seem blatantly obvious, but you’d be surprised how many times people no-show software demos even despite solid qualification beforehand.  Things come up and that’s expected from time-to-time, but the more advance notice you can provide, the less disruptive that is.  Resources can be reallocated.  The more notice you give, the better your reschedule timeslot will be!  If nothing else, remember this: not respecting people’s time is a great way to kill some negotiating leverage!

Keep an open mind

This might be the most important consideration.  You came to the table with some challenges and goals from your company.  Throw in your historical experience and that of your colleagues, and you’ve got some good context.  But consider the seller team.  Unless they’re at a startup, they’ve likely worked with hundreds or thousands of paying customers, and exponentially more prospective customers.  And they probably had a good amount of experience outside of their current role.  That is a LOT of experience you can leverage!  Think about all the insights from things you haven’t even considered!  There are likely several other direct and indirect challenges and goals you might want to consider.

Here’s an example.  I often share a McKinsey study fact about how much time people spend looking for information.  Why?  Because people often don’t realize that it’s almost 25% of their working hours, compounded by the number of team members they work with.  They may not have started thinking that organizing things better is a goal, but now it elevates the value of keeping things organized without a lot of effort.

Ask meaningful questions

There is a direct correlation between questions asked during demos and other conversations, and the success of the related projects.  When team members are engaged during the evaluation, they tend to be engaged during the setup and usage, and that’s what makes projects successful!  Good seller teams will answer a lot of your questions as you go, but feel free to stop them here and there to elucidate.  Write down questions you didn’t get to – they can be answered via email or later sessions.  Many vendor websites have lots of FAQ’s (frequently-asked questions) – take a look at those to answer some or yours or help you think of others.  Outside of specific features and functionality, common software questions you might want to ask often revolve around:

• Set-up, ongoing administration, and maintenance
• Integrations with other software
• User training and support
• The product roadmap

Highlight the day-to-day stuff most

I’ve been on many software demos that get side-tracked too much on one-time setup discussions.  I don’t want to undercut the importance of quality setup steps as often software is only as good as how it is implemented, but those are often questions better suited for a separate discussion with the setup and administrative users that will handle such tasks (ideally much of the ongoing admin and maintenance is automated!).  The general users may only get one chance to attend a demo where they can ask questions about the “day-in-the-life” experience.  The day-to-day stuff happens, well, every day.  The team will spend a LOT more time on this than the setup, so it makes sense to navigate the demo conversation that way.

Demo Aftermath

Focus on the value

Value is one of those abstract things that means different things to different people.  You probably had one idea of value at the beginning of a software evaluation, and another idea at the end.  Ideally that value increased as you discussed the implications of using it.  This relates back to keeping an open mind.  The seller team will likely share many insights you hadn’t considered – filling in the blanks when you don’t know what you don’t know.  Don’t discount these value points that come throughout the evaluation.  I think back to what was most valuable to me as a software user, and it was the other insights we learned – the stuff we weren’t even thinking about.  Whether that’s a short-term or long-term play, it’s important to consider.

Here’s an example.  When you automate the mundane work that team members don’t like, you clearly save them time, which has a direct, tangible cost savings.  But when they have time to build additional skills, they tend to be more engaged.  That leads to less turnover and in turn, less recruiting and training expense, which can often be a whole year’s salary.  It’s also less chaos for leaders to manage.  When you think about all the value there, it’s pretty compelling, right?

Provide timely, honest, and specific feedback

Most teams will meet internally to discuss what they saw in the software demo, then re-group with the seller team a week or two later.  Some buyer teams disappear into the ether.  Some buyer teams provide specific, candid feedback, and others are extremely vague.  A lot of work goes into coordinating and hosting a software demo, and in return, the buyer team should be expected to provide timely feedback, whether it’s positive or negative.  Seller teams have thick skin.  They take tough news much better than no news!  Remember, they are real people with management breathing down their necks (just like you probably), and they need to know where you’re at so they can best support you and communicate that upwards.  Companies plan their resources based on their expected sales!  They also take (and often prioritize) your feedback seriously, so share as much as you can!  It’s the least you can do when they sent you cookies or scones, right?!?

Feedback should generally fit into these categories.  The earlier you can provide it, the better.  If it’s not the third option, be prepared for a rebuttal – seller teams take pride in what they do!

• This product doesn’t meet our needs, and here’s why.
• We’re interested, but not right now (and here’s why), and the best time to follow up is [3-6 months later].
• We’re interested, and here are the steps we need to complete to make a decision.

Summary

It’s pretty clear as with most projects that planning, alignment, and communication are key.  Some of the best sales reps I know use a mutual action plan to guide prospective customers through the buying process.  I love it because it holds everyone accountable to the intended milestones.  It really is mutually beneficial – after all, sellers tend to be a part of the buying process a lot more than buyers do.  As a buyer, you’re right to be skeptical, so take the “trust but verify” route.  Keep an open line of communication and you’ll quickly realize that most sales reps do care about your success – it affects theirs as well!

Whether you’re on the buying side or selling side of software demos, what’s the biggest thing you think sets apart a successful demo and product evaluation?  Share your thoughts in the comments below!