Managing Sales: Informing Sales about Changes to the Product

It's Tuesday, 9.am. Jason is on a call with a prospective client and he is just about to make a killing. He had led the client thru the sales deck and the client showed great interest in the product. All that Jason needs to do now is to demo the product to the client and the deal will be closed. Jason clicks on a bookmark in his web browser titled "sales demo", the web page starts to load and... shit! Everything looks completely different. The layout of the page has changed, flow of actions is different, and Jason feels completely lost, his sales pitch crumbling. Jason looses his confidence, the client starts doubting the product, and suddenly, instead of arranging the terms of an insertion order, the client asks for more time to think about the deal.

Jason angrily clicks on the red button, thus terminating the call. "F**king engineers! Can't they write an email, for f**k sake!"

Last week at USV product summit we, the product managers from Stack Exchange, CloudFlare, SoundCloud, and Zemanta, were discussing that the story I've just described is happening way too often to sales people in our respective companies. We identified the uncontrolled feature release as the number one source of friction between sales and product development departments and discussed in detail strategies that each of us employ to improve the situation. The most elaborate was the solution of Stack Exchange where Will, their main product manager, developed a feature release matrix defining all the steps that need to be taken for a given type of feature release. For example, a simple bugfix without any changes to the user interface can be deployed anytime without notification, but a release substantially altering the user flow must be discussed with sales people in advance and they must receive a three-day notice before engineers are allowed to release it in the wild.

This is part of series of posts on managing sales.