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.

Common sense methodology (not Agile)

Oleg Vishnepolsky, Global CTO at DailyMail Online and Metro.co.uk, writes Agile does NOT work.

It's obviously a bit of rant, but he lists some issues that Agile struggles with:

1. Short-term thinking that results from following short iterations and daily stand-ups
2. Architecture that often times can not be deployed piecemeal
3. Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?

From Product Manager to CEO

We know that the Product Manager is sometimes labelled the CEO of the Product. It's not the best definition, in my opinion, but I have become interested in the similarities between the role of the Product Manager and that of the CEO.

Warning: As one of the founders of the Cambridge Product Management Network, I'd love to find a speaker on this topic!

What's the difference?
Gregg Johnson was a Product Manager for 10 years and moved to Product Marketing at Salesforce and then joined Invoca as CEO. He comments that "product management is a great training ground for becoming a CEO. The very nature of the PM role requires building the skills you need to be a successful executive" in this article Want to Be a Great CEO? Be a Great Product Manager First.

Here's a summary of his reasoning:

1. Create a compelling vision for your teams and company
2. Make the hard investment decisions.
3. Navigate between the 30-day and three-year levels.

I can summarise (1) & (3) as translation  - translation based on your audience: your conversation to a developer is different to that with a sales guy, which is different to that with a customer or a partner.

But even each one of those conversations has a time consideration: if you're talking to customer in pre-sales, then you want to discuss the business benefits of your current solution. If you're inviting an existing customer to participate in your beta programme, then you'll be laying your vision for the future and how your product in beta is an important building block for the future.


McKinsey in this article Product managers for the digital world list  Sundar Pichai, Satya Nadella, and Marissa Mayer as product managers and are now CEO to Google, Microsoft and (recently departed) Yahoo!

What’s more, product management is emerging as the new training ground for future tech CEOs.

McKinsey  reports that there are 3 types of 'mini-CEO' product managers in Silicon Valley:

1. Technologist
2. Generalist
3. Business-orientated

McKinsey insightfully states:

Any critic of the analogy between product managers and CEOs will point out that product managers lack direct profit-and-loss responsibilities and armies of direct reports, so it is critical for product managers with ambitions for the C-suite to move into general management to broaden their experience.

Generally true!

Software Internationalisation & Localisation

My first job out of university translating software from English to French. In theory, globalisation of the software had already been done (ie making the software being able to support more than one language) and all was needed was localisation (the actual translation from English into the local language).

Needless to say that globalisation wasn't done perfectly. During testing, it was discovered that the additional language meant that all store orders were doubled, for example.

One of the UI designers for Dropbox, writes the following advice in Design for internationalization:

1. Leave room for longer translations
2. Avoid putting text in narrow columns
3. Don’t embed text in images
4. Don’t create sentences with UI elements
5. Watch out for metaphors
6. Use descriptive feature names
7. Provide alternates for translation

Even big companies mess up. The translation of ebay's site struggled. In the violation of number 4 above the phrase "10h left" in the auction, then left was translated as a direction - oops!

Product Management analogies with American Football

Pragmatic Marketing interviews Neil Baron, lifelong New England Patriots fan and founder of Baron Strategic Partners in their podcast series.

Neil draws parallels with the scripted plays in American football and the instructions embedded in an orchestral score.

There are some great analogies:

• Product Management or Product Marketing orchestrate the play for the rest of the organisation
• Effective PM are the quarter back of the organisation to execute strategic role for the organisation, but don't be the water boy /girl that is waiting for others to tell them what to do, when to run onto the field and play a relative minor role.  (Approx at 24:30mins)

Conclusion: Be proactive or else you'll be reactive (like a water boy!)