NOW that our speaker tools have launched, we’re running lots of demos to see what the initial group of users think. We’re doing this in a very carefully managed way so that we maximise the usefulness of the feedback whilst minimising the downside of losing users that don’t see enough immediate value in what we’re doing. Emotionally, after over a year of building this thing, I’m ready to throw the shop doors open, but that would be a mistake. It’s very much like the first big battle scene in ‘Braveheart’ where Mel Gibson keeps shouting “Hold! Hold!” as the enemy charges at full speed towards our heroes.

This is classic startup strategy decision, and as usual recorded in real time in this diary. What have we learned so far? Our sample size is too small to really understand the features that will resonate with large numbers of users, but at least we can validate our basic feature set, and discover any major flaws.

The features that we have at launch for conference speakers are a public profile page, a portfolio builder and a conference planner. We did go a little fancy with a calendar view and a map view – a personal indulgence of mine as I like to see geographically where I’m going to be travelling. This was all well received. The critical thing that is missing is the ability for speakers to highlight what make them special.

This is obvious in hindsight – speakers are trying to get invited to speak at conferences. This is a typical example of the stuff you miss when you build out version one. That’s what you have to launch as soon as you have anything useful. So we’re now adding this feature to public profiles. Speakers can list books they’ve written, awards they’ve won and industry activities they’ve participated in.

We’ve also validated our apps-based approach. Our system is broken into bite-size pieces. This is a user-experience strategy to make it as easy as possible to start using the system. We are building a complex product that lets you manage and plan complex activities, so it’s very necessary to find a way to make this easy for the user.

Everybody “gets” the app model, so we can count that as a win. This is one of those lovely convergences of technical implementation and design – each app in our system is a separate program, a microservice, as they’re called, that we can update and extend in isolation. This keeps the rest of the system safe as we iterate quickly based on user feedback.

As a software developer I’ve given many demos over the years, and it’s a hard thing to get right. The ultimate demos are those given by Steve Jobs – and they’re worth a watch on YouTube, search for “Steve Jobs iPhone launch 2007” to have your mind blown. But Steve’s demos are not appropriate in an individual context. The demos that you give each day to potential users are the hard graft of building a software business, especially in the early days. They are so important for the early feedback that you get, and yet so cringeworthy it’s almost unbearable. Don’t forget that by explicit tactical decision, our product is still rubbish!

I do have one piece of definite advice here – don’t do a product tour. If it’s just you talking and clicking the mouse, you’ve already lost. Your prospect is going to be bored to tears, and will be too polite to interrupt. What you really want is for the prospect to tell you what they care about, and what they need. That can’t happen if you don’t give them airtime.

In a hour-long demo meeting, usually online, I aim to spend the first 20 minutes just talking. You nearly have to push this to the point where the prospect is forced to ask you do the demo. Use this time to get the prospect comfortable and to get them to really open up about their pain points.

You have to do this so that you will know what features to emphasise, and which features to skim through. Demos are hard work, you can only do so many, and you have to optimise the time.

Allowing no more than 20 minutes for the point-and-click bit where you do most of the speaking, use the last 20 minutes to learn. You want to hear things you haven’t heard before. This is where the real value is. The trick is to finish the demo abruptly. Do not ask “so what do you think?”. Just stop talking, and let an awkward silence develop. This is not easy, but you must do it. Sales (and giving demos is sales work) is all about embarrassing yourself in public.

But if you keep your mouth shut, and listen, you’ll get the best information out of your prospect.

Another mistake to avoid at this point is “solutionising”. It’s so tempting, as soon as you hear a feature request, to say, “oh yes, that’s coming next month”, or if your product can solve the problem already, saying “oh that’s easy, let me show you…”. It may seem wrong to avoid an easy win, but you lose the opportunity to get much deeper insight into the customer’s real needs.

The other thing that has been working very well is something I mentioned last week – preloading the prospects data into the system.

It never fails to be a win for someone to see their own problems and context right there in front of them. It takes the abstraction out of the solution, and makes it real. And, of course, they leave the meeting with a ready-to-use username and password. If you do nothing else, do this. We are in fact starting to “operationalise” this part of our demoing process, and setting up an internal workflow to make sure upcoming demos always contain prospect data.

We have also had our disasters. The system has crashed mid-demo. That is par for course. Own it, and try to make lemonade. In our case, we provide the ability to publish content onto other websites. To do this, we use a content delivery network, which is a specialist service that provides very high reliability. Basically, if our site goes down, it does not affect our customer’s sites.

That is a fundamental feature – never make your customers look bad. I used the crash to demonstrate how our published content stayed live and working even when the main site was down. Perhaps not the ideal way to demo that feature, but the prospect still walked away wanting to use our system.

Will we stop demoing once we get big enough? No. I’ll always devote some part of my week to this activity. It gives you a crucial, direct understanding of your customer.

Things change over time, and even when the company is much bigger, and has many customers, the sting of failing to convert a prospect when your demo couldn’t convince them remains a valuable lesson.

Marketing update: speakers newsletter: 5,588 subscribers, open rate of 13pc. EventProfs newsletter: 250 subscribers, open rate of 43pc (down it goes, expected), and the podcast is at 44 downloads. I had to defer podcast activity while we were getting the speaker tools launch done in January, and we’re paying the price now. Startups are a resource allocation game.

Source: Read Full Article