Sales Driven Development

Customers don’t know what they want. Stop expecting customers to know what they want. –Joel Spolsky

A couple of months ago I attended a presentation by the Head of EMEA Sales at Huddle, Neil Ryland. In describing the sales process, one of the most interesting points raised was how feedback from the sales force is incorporated into the development lifecycle.

Huddle’s products are aimed at the enterprise segment. As part of the sales process, there are likely to be multiple conversations between the sales representative and the customer. This direct contact with the client is so valuable that it can be used in planning the next iteration of the product. The process goes something like this:

1. Analyze the failed sales. Could the sale have been closed by offering a slightly different feature set?
2. Analyze the successful sales. Which features of the product were most influential in the customer’s decision?
3. Highlight the most compelling points to the product manager and development team at planning meetings.
   

Note that this is my interpretation of what was stated – I’m not acquainted with Huddle’s internal processes, so don’t assume this accurately reflects the process. Yet the important point is this: sales has a direct line to product development.

Clearly, this only one of the different factors that should be considered when a backlog is written or prioritised. But it is an important one that should not be overlooked.

Out of this process grows the phrase Sales Driven Development. I’m fairly reluctant to use it, since it implies a complete development methodology. It’s not necessarily a driver of product iteration, but behaves more akin to a regulation mechanism.

An interesting facet to this approach is how it interacts with site-specific customisation, practiced by many software firms targeting the enterprise. Of course, with a cloud-based product such as Huddle’s, site-specific customisation makes little sense. Instead of customisation, a feature may be built into the next release. And, of course, these two practices certainly aren’t mutually exclusive approaches.

Returning to the introductory quotes, what we’ve covered so far is certainly no counterpoint. I strongly agree with the notion that it is not the customer’s job to know what they want. But it is interesting to explore how an iteration cycle can incorporate what customers say they want, particularly when they have already encountered the product.

In this sense, software companies with a sales force may well be at an advantage. Why? Because of the dialogue a sales representative can engage in with a lead. In terms of customer interaction, it clearly outstrips a feedback form. But this is a fairly obvious point.

A more interesting question is this: how do we derive frank feedback, and to whom should we listen?

One method is to focus on the sales successes. With many people in an enterprise using your product, their experience of the product is likely to be wider than an individual might achieve. There may be even internal factors that drive how the product is used. Understanding the initial success and following up on how the product is used internally can provide this.

Another approach is to look at the unsuccessful cases that included a trial of the product. This provides the grounding that the potential customer was willing to invest time to assess the product and discover why it wasn’t right for them.

It’s interesting to think how this approach might factor into a different revenue model, such as freemium. But since this is essentially a separate discussion, I will attempt to cover it in a future article. In any case, we’ve covered the main point of this article: examining a case where sales feedback is given a direct line to product iteration.

Source:  http://blueprintforge.com/blog/2011/12/06/sales-driven-development