One of the coolest parts of working on CommandBar is the quality of our customers. We’re often asked how we were able to “go up-market” so early on and work with companies like Gusto, Hashicorp, Launchdarkly, Freshworks being a young and unproven company.
“How did you get their attention?”
“How did you get them to try you out?”
A lot of my answer is just luck and path dependence. Once you win a couple of impressive logos, your brand and product unlock a halo effect that makes everything easier. Even if someone doesn’t understand exactly what you do or how your product can help them when they see impressive logos, some of them will think, “I should double click on this — there must be something interesting here if [so and so] is using this.” This is especially true for products where logos are inherently harder to earn. In our case, earning a logo means we’ve earned the trust of a company to put us in front of their users, versus having a single person at the company use us for some internal task.
One weird GTM hack: hackathons
However, we did have one hack early on (that continues to work for us) — hackathons. A substantial portion of our ARR has been earned from trials that start as part of hackathons.
The first hackathon — a victory in disguise
During YC S20, when our company was just a month old, a YC grad who was working at a unicorn SaaS company emailed us out of the blue (I think after discovering us at YC’s B2B preview day) and told us he wanted to try us out during a hackathon. My co-founders and I (was just us at the time) were delirious. We’d gotten a few of our batchmates to use CommandBar, but this company was way, way bigger. If we got them to use us, we would 100x our end-user numbers.
We got them into a Slack channel, and he quickly added a bunch of teammates, who started asking a ton of questions about how they could use CommandBar, how to create specific commands for use cases, etc.
Early sales conversations we were having at the time felt slow, like we were fighting for every email response and every 30-minute meeting. This felt so different. We were being inundated with questions, requests to Slack huddle to debug stuff. It seemed like we had their undivided attention because we did — the hackathon started on Monday, and the presentations were on Friday. This momentum carried us through tons of bugs and growing pains, given we were a 3-person team working on a product that was 2 months old.
At the end of the week, the team packaged their CommandBar (which was glorious, the best implementation we’d ever seen) into a presentation. And lo and behold, they won! Huge Slack emoji fest.
I got a DM from the YC founder — “Let’s find some time next week to talk pricing”. We headed into the weekend thinking we’d caught our first big break.
But we never found time to talk pricing. The meeting got pushed by one week and then another. After the third time, I got a classic response “A bunch of stuff has come up, so I think we need to table this — the team is still very interested, though!”.
We were super bummed. How could this not be prioritized? The team had set up a perfect CommandBar implementation — entry points to the main features of their product, workflows for paths that involved a lot of user friction, user-specific recommendations, etc.
While we didn’t get a contract out of the experience, we got something much more valuable — a glimpse at a weird-but-potentially-repeatable GTM channel.
Who can use this strategy?
Hackathons work best for “SaaS for SaaS” tools (aka “embedded SaaS”) because they often focus on features that could make their way into a product (versus general-purpose tools).
Why hackathons work
Before talking about how we’ve process-ified hackathons-as-GTM-channel, here are a few words on why hackathons work for us.
First, urgency.
Any salesperson will tell you this is the lifeblood of a deal. This is why companies (like ours!) run limited-duration trials. We want to make sure teams have the headspace to fully vet CommandBar in the time they have. Hackathons create this by design since they’re inherently time-bound and usually a sprint to the finish.
Second, hackathons often bring together teammates from across teams.
Engineering, product, CS, marketing. They’re often a way to create camaraderie among groups that don’t always work together. CommandBar, in particular, is a product that thrives when multiple teams are using it. Product is using it to smooth out the most friction-fun flows users encounter; CS creates a solution in CommandBar for the most common sources of tickets; marketing shows off the most interesting features in the product to new users during onboarding. This type of cross-functional usage can be hard to create in the early days of a customer rollout since, usually, a single team is the initial buyer of CommandBar and wants to solve just their problem. But in a hackathon setting, we’re able to get everything all at once.
Third, and this one is subtle, hackathons are a great way to make your prospects look good.
The secret of hackathon marketing is that during a hackathon, it’s way more effective to deploy an off-the-shelf solution than to build everything from scratch. It’s not always totally clear what the vendor made vs. what the team made. When one of our hackathon teams shows off the full glory of a complete CommandBar implementation — HelpHub trained on their content, nudges for the most common high-value actions, questlist walkthroughs of secondary use cases to expand customer engagement or Magic Tour Links for CS teams. This results in teams being inherently interested in exploring and turning on all the features we have to offer.
Becoming an off-the-shelf hackathon project
To get teams to try us out during hackathons, you had to solve an awareness problem. We had to make people aware that we were offering “win-your-hackathon” as a service.
Of course, one way to solve this is with general awareness. But at this stage, very few people knew about CommandBar.
So we decided to do an email outbound campaign specifically focused on making engineers (not usually our buyer/champion) aware that they could try out CommandBar off-the-shelf for their next hackathon.
Playbook for a successful hackathon sales cycle
Rule 1: Create a Slack channel to increase communication bandwidth
This is critical. A good hackathon only works if (1) you can squash bugs/misunderstandings quickly and (2) you have a way to guide the team’s implementation towards high-value stuff (versus just wow factor — see below).
We actually make this a condition of using us for a hackathon. It’s that important.
Rule 2: Shape the buying journey before the madness starts
Before the hackathon, you have leverage; after, you have little. So as a condition of getting full access to CommandBar for the duration of the hackathon, we ask to schedule a meeting with an exec the week after the hackathon, before the team has even gotten access. This might seem pushy, but we rarely encounter resistance.
“We want to support you fully during the next week, and in exchange just want to make sure you don’t forget about us once you win :)”
Rule 3: Push the most valuable use cases (even if the team isn’t as excited about them)
Most hackathons prioritize flashy features and sex appeal. And thankfully CommandBar has lots of that. A superfast command palette with shortcuts for power user actions makes for an awesome demo. But often, the flashiest features aren’t the ones that someone will eventually pay for.
So during hackathons, we steer teams toward features that are going to create value for users after the hackathon. Things like:
- Connecting their help center to show it in-product with HelpHub
- Wiring up commands for hard-to-find settings
- Creating nudge tours for the flow where users encounter the most issues (and create the most support tickets)
Rule 4: Craft the presentation around value, not just wow factor
The hackathon presentation isn’t just an opportunity to show off what was built. It’s also the chance to make your case to the entire company about why you should be used after the hackathon and how you create value for the whole company (not just the team implementing the project).
So we always offer to help with presentations and give teams a template they can work from that showcases ways in which CommandBar can move metrics that matter for every company:
- User conversion
- User retention
- Ticket deflection
