10 Tips for Not Giving a Sales Pitch at a Meetup
How do you give a sales pitch at a developer meetup? Don’t.
Developer meetups are technical, so it can’t seem like a sales pitch. Even if you paid for the pizza and beer and everyone knows you are there to pitch them on something with commercial upside for you, they want to feel like it is a technical community event where valuable information is being shared. This is the epitome of the evangelical or educational sale.
I’ve attended dozens of these and done a few myself. In watching others, and especially watching for signs of audience engagement, I’ve come away with ten recommendations:
- Don’t have a non-technical executive give the presentation. Ideally your presenter should be as technical as the audience, or slightly more technical than the audience. A less polished speaker with more credibility is fine. In fact, meetups are a great place to get your chief architect more public speaking experience. If you are a less technical person presenting, just accept that. Mention your role, but don’t call attention to it. There is no benefit to being self deprecating. If you get questions that exceed your depth, take them offline and have someone follow up in email.
- Do know your audience. If they are developers, don’t talk about not needing developers. if your tool isn’t for developers, talk about who does use it and where developers would find such people. If your tool is about enterprise, talk about key characteristics of organizations or people who benefit from your tool, don’t just assume people understand enterprise.
- Don’t spend one third of your time on background. Throw away your corporate pitch template. We don’t need to know the geography of your company, your target industries, the biographies of your executive team, who the investors are, how nice your office space is, or your mission statement. If you are going to try to recruit people, leave it to the end.
- Do talk about the changing context. Each time you say something has changed the the world spend time on that. If your tool depends on YARN, don’t assume people know what YARN is, or how the world was before. Help people understand how the world is different. Your audience is looking for new things, and hoping to adopt them. They will want to be able to explain to their colleagues why your technology is a logical move, not just a new shiny.
- Don’t talk about how long it took you to get there. The long-slog-through-the-woods part of any innovative technology is like your vacation photos: most interesting to the people who were there. Talk about the world as it is today, and let people assume you were so brilliant that you literally thought it all up last weekend – unless there are particular things people will want to know.
- Do talk about your mistakes, and what you learned that does not work. These are mistake that people can learn from. This may be a way to de-position your competitors as well, if what you learned was that the standard or obvious solutions to problems don’t work. Talk about why they don’t work. Imagine you are arming an audience member to have a technical discussion with their boss about why they need your technology instead of using the established offering. But don’t turn this into competition bashing, talk about it as things you tried that didn’t work.
- Don’t focus on customer validation or analyst recommendations. Logo slides say very little to a meetup audience. I’m probably not from your target vertical, I might recognize some fortune 500 companies on your list, but I know that fortune 500 companies are big enough to make plenty of bad choices in corners of the organization. Without more depth than a logo and a quote, there really isn’t validation here.
- Do show real architectural diagrams from real deployments, not marketecture. Even if they are ugly. In fact, between a black and white boxes and lines diagram someone just whipped up in Omnigraffle, and a polished marketing diagram, use the less polished one. It will enhance your credibility. And most importantly, these diagrams should correlate with real deployments that you’ve actually done, if at all possible. They aren’t just wallpaper, use them in your talk and call attention to how they are real by saying things like “This customer used nginx for the front end, but we can also use Apache” or “this bit here was custom code for this deployment, but in an upcoming release it will be part of the product.” If you aren’t comfortable drawing pictures, I recommend The Back of the Napkin.
- Don’t focus on competitors. Often times the meetup has a very broad range of topics, and people won’t know your competitors. If you start comparing feature lists, it will become an inside-baseball conversation and you will lose the audience.
- Do say what is hard. Each time you say something is hard, so people should use your product, be super detailed about why it is hard. When you mention something clever that you did, go at least one level deep, if not two. Ideally give people enough information they could imagine replicating your work. They are very unlikely to actually replicate your work, but they will then remember these parts and use them to argue why your solution is required.
Meetups are a great opportunity. Whether you are invited to present or sponsoring, you will have an audience that is technically engaged, wants to learn about new technologies, and more often than not wants to bring that information back to their day job. To make it work, know the audience and present in ways that resonate with this audience. The results can be amazing.