We all know that demos are a great way to show potential clients some of the more unique features/functionality of the product or service you are trying to sell. The issue is to what extent do you know the audience's concerns? If the audience is a pharma, do you focus on compliance and retention policy or do you focus on converting their paper process to electronic forms? If the audience is finance, do you show them an AP solution or an integration with ERP? The bottom line is the related experience you bring to the demo. To really be able to talk about the pain points and show how the product solves them.
The days of a dog and pony show are over. Today's audience are made up of business savvy folks who not only want automation, they want someone who know's what the hell their talking about. If you don't have an analyst who is part of the demo, the demo will look like this:
Realize that your audience will most like sit through a few demos from other EMC partners, open source alternatives, competitors, etc.
Here is a list of key areas and questions to focus on when designing and developing a demo (or prototype):
Who is the audience?
It used to be IT only, not it is a mixture of IT and business, so make sure the has plenty of meat on it.
Detail the Requirements
If the demo is for an Accounts Payable scan solution, make sure to focus on the inconsistencies of invoices, the exceptions that happen, why payments are held up, etc. Do not promote that everything can be done with configuration unless you are absolutely sure: if you make this mistake and get the contract, good luck extending it after blowing deadlines and coming in over budget.
Audience Push back
Be prepared to defend automation and new ways of looking at old software solutions. Most clients want to design a solution which mimics what their sneaker process, which includes design electronic forms that look exactly like their paper forms. Be prepared to explain advantages of perhaps splitting up the forms for security or signoff reasons, or for reasons of sustainability as the process changes over time.
This is my JOB!
You might be showing a demo to someone who sees it as obsoleting their job. They will pick the demo apart for its shortcomings. They will feel compelled to prove their worth with the knowledge. Take the opportunity to more fully understand their issues and undermining techniques. Be sure to respond with assurances that this will not take their job. If the demo is a workflow, the "big brother" aspect may enter into their minds. The point should be that automation frees up knowledge workers to think and innovate more...
Reports
Business folks love reports. They have the knowledge to interpret them and need to Powerpoint them to the higher ups.
Technical Architecture
Make sure you know how the demo can scale with number of users, the expected performance, levels of security and encryption. Again, if you promise what you don't really understand this will come back to bite you later if for example the encryption level that is required is not fully supported with the OS and software implemented.
Stories
Be sure to have someone who can tell battle stories and how this demo's solution succeeds. It helps to drink your own Koolaid, but how many EMC partners use Sharepoint? A lot. Why? because it is easy to setup. Why aren't all EMC partners required to only use EMC products? Good question, try creating a demo of a break/fix system like Jira and you'll know what I mean, but seriously, if you took the time to use the products that you design solutions for you'd feel more of the pain that your audience goes through.
The days of a dog and pony show are over. Today's audience are made up of business savvy folks who not only want automation, they want someone who know's what the hell their talking about. If you don't have an analyst who is part of the demo, the demo will look like this:
Realize that your audience will most like sit through a few demos from other EMC partners, open source alternatives, competitors, etc.
Here is a list of key areas and questions to focus on when designing and developing a demo (or prototype):
Who is the audience?
It used to be IT only, not it is a mixture of IT and business, so make sure the has plenty of meat on it.
Detail the Requirements
If the demo is for an Accounts Payable scan solution, make sure to focus on the inconsistencies of invoices, the exceptions that happen, why payments are held up, etc. Do not promote that everything can be done with configuration unless you are absolutely sure: if you make this mistake and get the contract, good luck extending it after blowing deadlines and coming in over budget.
Audience Push back
Be prepared to defend automation and new ways of looking at old software solutions. Most clients want to design a solution which mimics what their sneaker process, which includes design electronic forms that look exactly like their paper forms. Be prepared to explain advantages of perhaps splitting up the forms for security or signoff reasons, or for reasons of sustainability as the process changes over time.
This is my JOB!
You might be showing a demo to someone who sees it as obsoleting their job. They will pick the demo apart for its shortcomings. They will feel compelled to prove their worth with the knowledge. Take the opportunity to more fully understand their issues and undermining techniques. Be sure to respond with assurances that this will not take their job. If the demo is a workflow, the "big brother" aspect may enter into their minds. The point should be that automation frees up knowledge workers to think and innovate more...
Reports
Business folks love reports. They have the knowledge to interpret them and need to Powerpoint them to the higher ups.
Technical Architecture
Make sure you know how the demo can scale with number of users, the expected performance, levels of security and encryption. Again, if you promise what you don't really understand this will come back to bite you later if for example the encryption level that is required is not fully supported with the OS and software implemented.
Stories
Be sure to have someone who can tell battle stories and how this demo's solution succeeds. It helps to drink your own Koolaid, but how many EMC partners use Sharepoint? A lot. Why? because it is easy to setup. Why aren't all EMC partners required to only use EMC products? Good question, try creating a demo of a break/fix system like Jira and you'll know what I mean, but seriously, if you took the time to use the products that you design solutions for you'd feel more of the pain that your audience goes through.
No comments:
Post a Comment