“Just because you can doesn’t mean you should”

A few months ago, I was talking to a friend about his new B2B product which was in the process of being prototyped.  The words that tripped out were “Just because you can doesn’t mean you should”.

The product was being centred around insights gathered by the CEO through general conversations with potential end users.  My concerns with this were:

• The potential end users were not budget holders and therefore could not eventually make the decision to purchase the new product.  So in this case, research around the benefits of the product should be also carried out with budget holders – seeing if there is a case to make their organisation more efficient / productive / profitable as a result of adopting this product.
• The potential end users had genuine pain points that needed solutions, but the prototype was a number of months down the line and no one had been back to those potential end users to see if the solution being developed was addressing their need. As I always say, you don’t need to wait for a prototype to continue your dialogue with users. You can talk about what they would want the product do to and why – build up the bank of “user stories” (Scrum reference) and get those prioritised before you begin your build.
• The CEO may well not be the best person to talk to end users. Classically CEOs are strong characters; leaders who are passionate about their product.  An end user may well not be comfortable to say “no” to a person like this!  It takes certain personality traits and practice to be good at gathering user insight.

The very talented developer was building up the prototype from sketchy top line requirements written by the CEO. He was injecting a large dose of filling in the many blanks with clever code that enabled the product to do all sorts of things that had never been done before.  But was this functionality that the user wanted and the budget holders would agree to buy? Nobody knew.

Diving in to the feasibility (technical capability), working up the viability (scale-ability) and then establishing desirability (the user need) is the trap.  This is how many companies end up with a product that may technically work well but does hit the sweet spot with users.  They then often then find that they are continually customising the product for individual clients, which is not cost effective and not scale-able.  Another classic result of this approach is feature overload – features built in to a product that are never used – again resulting in wasted resource.  This model needs to be reversed and you need to start first with desirability.

Point made?!