SCOTSMAN for sales qualification

My previous blog post about communicating the commercial imperative of products was originally prompted by how frequently I, as a Product Manager, have discussed sales qualification of a prospect with respect to product differentiation and competition.

Frequently I had shared my insight with the sales teams:

• "If customers says their problem is this, then this implies that they have solved this, this and this problem with  an alternative solution. As a result, they aren't a good prospect unless they have this characteristic."
• "If a customer is asking about this feature, then that implies that they are currently used competitor X's product, as we know that this is their weakness. It would be best to differentiate our product by talking about this business problem."
• "Competitor Y is particularly strong in that market, that prospect looks tough to bring over the line."

This often leads to a conversation about sales qualification in general. Here's a mnemonic called SCOTSMAN from salesplusprofit.com:

Sharing the commercial imperative of our products

I find that as a Product Manager or a Product Marketing Manager, we spend a lot of time communicating the value of our proposition's features, differentiating capabilities, value and how one's solution moves our customer's business forward to our sales and customer service teams.

But this message needs to be widely understood across the company.

Scenarios that I have frequently encountered:

• Software Engineering develops features because they are 'cool' or based on the CEO saying, 'Wouldn't it be great if ....'
• Software Engineering spends ages crafting out a solution to a long-tail problem where an 80/20 approach would be much more valuable
• Testing validates the product feature based the product specification from Engineering (see previous point), not based on how the product would be used in an operational environment. 
• As a tester in Dallas, Texas, I recall spending days testing a product feature only to be told that this particular narrow shard of functionality gets used about 5 times a year and only as a tool of last resort and only by highly experienced users who didn't need all the defensive protection from poor data entry or illogical data flows that had been tirelessly testing.
• Research teams working on the functionally interesting problem and NOT on the biggest risk to the overall commercial success of the suggestion - which is frequently customer adoption in a competitive market. Poor research (or usually no research) is a HUGE waste of Development's team - a topic worthy of another blog post.

So whenever I see a specification or a proposition, I do my best to make sure it is crystal clear to the reader (whoever the intended audience is) how the proposed functionality will make our customers more money or save money or make our solution more compelling.