Does the solution have the right to live?
Microsoft Spot, Google Glass, Amazon Fire Phone. If you never used these products, you are by no means alone. In other words, these are products that did not catch on and that cost the companies that developed them dearly. It is of course a dangerous exercise to criticize three of the world's largest and most successful tech companies for a lack of knowledge about product and service development. Obviously, they can.
But these products and the teams behind them still illustrate problems that often arise and that lessons should be learned: Not doing the necessary testing, spending too little time on prototyping, and having too little insight into users' actual needs, challenges, and preferences. The result is that you develop products and services that no one wants.
As a consultant, I have unfortunately experienced that an inordinate amount of time is spent on developing digital products and services that end users neither like, need nor understand. One of several reasons for this, and which is still widespread, is that people think they know what the customer needs. In other words; You think you know what features the customer wants in a digital solution. The problem with such an approach is that you rarely have good enough insight into what the end user actually wants. It is a very risky way to build digital services, both in terms of time spent and costs.
A better approach is to build, test and experiment through early and ongoing customer involvement to a product that actually delivers on both the end user's needs and business goals. What is it that is absolutely critical to get an answer to in order to see if the solution has the right to live? It is only when this is answered that you can spend time on details in the solution. It's about testing things as cheaply and as early as possible so that you can make decisions that keep costs down and that ultimately become a product that end users are interested in.
Most people who work in roles with an innovation responsibility today are well acquainted with Osterwalder's methodology and message. But very few people live up to the principle of a high "kill ratio". Not because there is a lack of knowledge about the methodology, but because it can be perceived as unnecessary and not least unpleasant to shelve a new product or service you have really fallen in love with. and which you have spent a long time and considerable resources developing.
Freeing yourself from this approach can be challenging. Working in a structured way with innovation and new development requires both time and capital investment – it is not something that can be solved in a workshop or in a design sprint alone.
A necessary process
For many, it may seem unnecessary to spend a lot of time, money and resources working with innovation in this way. However, it is an absolutely necessary process. The fall of resting on your laurels (especially in good times) When the business side seems to be running smoothly is great, as you are not equipped for new disruptive forces, new competition and changing demands in the market.
We all know the most thinly worn examples such as Kodak, Blockbuster and Myspace. They experienced painfully the consequences of the lack of cannibalization and good innovation processes. Their fate, however, is not an indication that disruption is beyond the company's control.
Innovation is largely about about navigating this uncertainty and, not least, constantly reinventing one's own business. By working in a structured way with hypotheses, testing and validation – at an early enough stage in the innovation process – you get to know how to make sure that you are able to make a difference. Overcome with uncertainty. This is how you ensure that the service, business model or concept has the right to live." What's your kill ratio?" is our return question to managers and sp; decision-makers who want to work smarter and more structured with innovation.
Get out of the office!
Take a look at your calendar and be honest with yourself. How much time has your team spent in meetings over the past six months discussing features and customer needs? Take another look - when was the last time your team was in contact with real end-users of the service?
There is a lot of talk about customer orientation, but there is a big difference between thinking about customer needs in a meeting rather than prototyping and testing something on actual end users. Digital service development is business development, and to reduce the risk of building the wrong things, you need to get out of the meeting room and meet the users of the service.
My message to those who recognize themselves in the above description is simple: Get out of the office - out of the meeting rooms and meet the real end users. This is how you can create the good digital solutions that are developed on the end users' terms.
In other words: 4 hours of prototyping and testing can save you 40 hours of meetings.
