Knowing When to Stop

That phrase “knowing when to stop” has been going around and around in my mind since I read it. Richard is one of those people who have a habit of doing that; an apparently casual remark sends you off on a tangent with escape velocity!

In terms of New Product Development, Christensen talks about this in his books, calling it “Overshoot” or “Performance Surplus”.

This is all very well and helpful in retrospect, but doesn’t answer the question of “knowing when to stop”. He suggests:

“One symptom that these changes are afoot – that the functionality and reliability of a product have become too good – is that salespeople will return to the office cursing a customer: “Why can’t they see that our product is better than the competition? They’re treating it like a commodity!””

That might be so Clayton, but salespeople often make that kind of complaint and there can be many reasons for it from poor sales preparation to unclear messaging in the collateral.

My experience is that organisations simply don’t know when to stop developing a product. Some of the academics tend to talk about product development as a linear process where everything that needs to be known can be discovered at the beginning. You do your market research, design your product, build it, market it, sell it, and move on, because that product is done, right? Not in my experience.

Strangely, the discussion around product development in some organisations is more akin to drug addiction; “they promised that that was all they wanted”, “just one more feature …”, “pleeease…”. Interesting, because a Google search on “knowing when to stop” finds research articles on gambling and alcohol addiction. Perhaps an opportunity for some cross subject learning?

I think one clue is to be found in how users approach new functionality in a product. If that functionality offers them real benefits they will jump through hoops of fire to use it, if it does not they will ignore it or complain bitterly about its poor design. I think this touches upon Richard’s observation “conscious decisions of the producer and the unconscious acceptance of the consumer “. A recent report by MFORMATION describes the frustrations that many mobile phone users have in using the features on their phones “61% have stopped using mobile applications because they cannot solve problems with them”. That could be an indicator of poor design, but it might also indicate overshoot for some customers.

Similarly other indicators could have multiple causes; it is really difficult to separate Overshoot from highly competitive market, or poor performance in sales and marketing. Whether it is resistance to price, falling sales, or user feedback. Christensen gives market education as one strategic response to Overshoot – that makes good sense to communicate clearly how your features are of benefit to your customers.

One clear one is that your customers are prepared to pay a premium for new features above and beyond your core product. You can ask them for as much feedback as you like, but you only find out for sure when you ask them to reach into their wallets.

A second one I’d like to promote is ethnography. Just sitting and watching someone struggle with, ignore, or fail to make use of, your favourite feature is such a great reality check. Supporting this with the ability to automatically log which features are used or not would provide a wealth of quantitative evidence.

If you think you are in Overshoot; I’d recommend returning to the basic question of “what is this product really supposed to offer the user?” If that suggests that you are going beyond the core definition, then consider starting a new product. That has the benefits of:

• Clarity of what products do what – make it easy for customers to find it when they need it
• Duplicate revenue streams – opportunities to sell to current customers again, as well as to new customers
• Focussed usability – a UI tuned to the users tasks, not a “Jack of All Trades, Master of None”
• Pricing flexibility – allowing you to address new markets
• Brand growth and extension – seen as more than a “One Trick Pony”

“Cause the brilliance of a plan is in giving up”

Related posts:

Barnacle, Billow or Barnard’s Star Final Cut Pro Launches a X the Chasm What is a product specification? The devil in the detail of product design Make the tough stuff look simple There is a hole in my product