Seth posted a short, great article about how to completely win your space. It totally transformed the way I think about marketing. It’s just a few paragraphs — go read it and meet me back here.
A shallow interpretation of Seth’s point is that “service makes the difference,” but that just leads to the usual phrases that have been repeated so many times they’ve lost meaning. “We put customers first.” “Except the best, both before and after the sale.” “We believe our role is to serve our customers.” “Our customers are buying a solution, not a technology.”
Blah blah. Everyone says that. What does it really mean?
Let’s take that last vapid statement and make it concrete. It’s true that no one wakes up in the morning and says, “Gee, I wish I could purchase, install, learn, and train my people on a new software tool!” Tools suck – they’re confusing, they rarely do exactly what you want, and tech support is often a nightmare.
In our case, our customers have one of several specific problems that they’d like to make go away. Perhaps they spend 20% of their time in code review on boring, wasteful chores like collecting and sending diffs around or scheduling meetings. If it’s something this specific, perhaps the tool can sell itself –- if it clearly removes the drudgery and during the trial the developers feel it saves more time than it wastes with its own idiosyncrasies, then it’s worth it.
But usually our customers are in a more difficult spot. They need to reduce bugs or work with offshore teams, so they know code review is necessary. But how to do it?
This question -– how to do it -– is what keeps them up at night. They know they could easily blow 30% of their developers’ time on this process. What if it doesn’t result in reducing bugs? What if their developers hate it so much they revolt? How can they tell whether it’s really working?
In fact, most people rightly believe the hardest thing about code review isn’t the process, isn’t metrics, isn’t reports, isn’t communication –- it’s about (a) how do we make sure we’re not wasting time and (b) how do we deal with social effects of ego-full, sensitive geeks critiquing each others’ work?
This is where your “customer service” comes in. At this point it’s not about tech support, it’s not about what features your tool has, and it’s not how good your salesguy is at “closing.”
I often sit down with a customer for a few hours. I help them as them the right questions of themselves. I help them determine which code they’ll get the most bang-for-the-buck on so they can see some immediate results. I give them stories and even presentations about how gratifying code review can actually be, how to foster an environment where code review is genuinely about mentoring, learning, and getting rid of bugs together.
No tool will do that, and I also think no on-line form, Wikipedia page, or case study will do that either. Yes, our tool is important in removing drudgery and making reports, but it’s a means to an end.
The interesting part is all this mentoring stuff we do completely for free. If you tried to objectively quantify the true value to our customers of this advice and direction next to the tool, the advice is probably more valuable.
Maybe that’s why it’s the reason we consistently win over all other tools in the market. Because we’re the only ones that can provide that service, and we do it for free. It tangibly demonstrates that we really do want our customers to succeed, not just buy some seats.
And of course when they do succeed, why go purchase something else? The free advice alone is worth any price difference.