How to be the most expensive product on the market

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.

How to build a checklist

CM Crossroads just published my article on how to build code review checklists. Half of which is, how not to build one.

It's not about in-scope/out-scope

The software project is behind schedule. The deadline is looming and everything finally acknowledges -- too late -- that we have to start making concessions.

So there are two choices, right? Release later, or reduce scope by throwing out features.

Not so fast.

"Remove from Scope" is not the answer
Too often we developers are stuck on this "remove it from scope" mantra. Yes, completely throwing out features is a way to get to the release date, but this isn't necessarily the best thing for the product or the customers.

Ultimately our job as engineers and not just worker-bees is to make trade-offs. Not just in design or algorithms, but in the end user use-case and, yes, even to support marketing and sales with their promises and messages.

Not cutting, but changing
Five years ago I was on a project with an impossible deadline. We had to get a complete custom reporting system integrated into a project for their v3.0 release, and for uninteresting reasons we had just four months to do it. There was a spec that couldn't possibly be completed in time, but the deadline was firm because a customer contract was in place.

The project ended up a complete success. The system was demonstrated to the customer on time and was accepted. It was so popular, it became the "big finale" for product demos.

The reason it was a success is because we never posed the question: "What parts of the spec do you want to throw out?" Instead we would ask: "How can we allow the user to accomplish what the original spec wanted him to accomplish, but in a different, simpler way?"

Sure that means less "stuff" -- fewer absolute number of features and fewer choices. But it doesn't mean tossing items J-M -- it means reevaluating the entire spec from the point of view of the use-cases and marketing requirements.

Happy days
There's another benefit to this approach.

We're all used to the tension between development and sales. Sales wants more, faster. Requirements pushed from the outside are ambiguous, and when you deliver it's never the right thing.

The normal reaction from development is: "You're changing the rules, therefore we simply refuse to give in. Either stop changing the spec or change the deadline. It's a zero-sum game, and we won't be responsible if you make the sum larger."

But that's not helping sales OR the hapless customer. (Customers don't have hap, apparently.)

What helps is arriving at a better solution. The project drivers will be more willing to negotiate if you're going to meet them halfway. They know they've added to your schedule. If you show the genuine desire to get their root problems solved, they'll be more willing to bend on exactly how you're going to solve their problems.

Besides, we can all agree that "Customer Success" is the ultimate goal, and clearly negotiating for their success is better than cutting them off.