Recently, I visited a one-day conference sponsored by a tool vendor. The talk I most vividly remember was given by Professor Gassmann from the University of St. Gallen, Switzerland. He broadly talked about innovation and argued: to survive in the long run and to let your company flourish, you have to ignore the customer’s explicitly expressed requirements and instead search for their latent needs.
He further argued, that customers and users can’t think out of their box. That they live in the current state, can only express their wishes in terms of that state and therefor are unable to leave it by themselves. And finally that, to develop something truly innovative, you have to take a broader approach, look at different business areas for inspiration, or other cultures, the natural sciences, in your neighborhood, the government, whatever.
Find out the users underlying motivation and address it properly.
You might have guessed that he was referring to Steve Jobs a few times. But besides Jobs, he chose BMW as a second example.
„Unsere Aufgabe ist es,
dem Kunden etwas zu geben,
was er haben möchte,
von dem er aber nie wusste,
dass er es suchte
und von dem er sagt,
dass er es schon immer wollte,
wenn er es bekommt.“
Roughly translates to:
Our mission is: giving the customer something he wants, but he was never looking for. And that he will say about: I was ever longing for it, when he finally has it.
At the same time Professor Gassmann constantly cautioned, that unleashing the engineers, giving them the freedom to build whatever they imagine, will lead to products with no market.
I have wondered since: where is the line? Looking for latent needs, means basically ignore explicitly stated requirements. That leads to: give the developers the authority to decide what the users truly want. That leads to: let them do what they think is right. Unleash, or empower the developers. Who might be able to decide when they have crossed the line and might actually miss the target market or any substantial amount of customers a new market might provide? No manager can do this. There are no real numbers available supporting any decision.
Going a step upward, I asked myself: is there actually a line, a true difference? Isn’t it the same thing? The only distinction I could come up with was, some were successful, others not.
I developed the following thesis: lucky unleashed programmers address latent needs of many people and become stars and billionaires. Whereas unlucky unleashed programmers address anybodies needs, latent or explicit and will be ironed out, or if they have the stamina become castaways or rogues in a small niche.
But luck might play only a small role. There are other factors to consider. How well is the individual developer (the core inventor, if you will) attuned to some big enough market and has, at the same time, the necessary distance to come up with a disruptive solutions? That seems to be important. In the create-a-new-market case: does the developer have the ability to imagine, create and address a truly new market?
Marketing skills play a big role. The presentation. The package. The design. The time. The market entrance strategy. First receptions. Early adopters. Connections to important companies and the relevant media.
All this can not be managed in the classical sense. Managing is keeping the current state and concentrate on making the operations more efficient. Optimizing locally.
To make true innovation happen, you have to keep the managers out. Instead there has to be a really small number of unleashed people: coders, developers, business analysts, testers, whatever their role is, that have a shared understanding of their product in development. The catch is, that the product is new in some major way, it’s not existing, it’s purely imagined, and cannot be easily explained.
To achieve a shared understanding, it seems necessary that people know each other really well, that they trust each other, that they have faith in each others abilities, in the product idea and in the person that initially brought the idea up. Everyone has to adopt her brainchild, care for it as if it’s his own and raise their princess to a beautiful and strong queen.
Product development is the art of creating something that many people are eager to buy. Initially attract them is only one side of the coin though. Equally important is, that your customers are happy to use your product. You have to give your customers reasons to come back and look for more products you offer. Your goal should be, building up a reputation of having magnificent products. Well done Mr. Jobs.
As an aside I used the terms: programmer, coder, developer, engineer, … somewhat interchangeable. Even if there is a slight distinction, I’m almost always talking about the person with the initial product idea and the skills (technical and/or people) to make that idea happen.
Professor Gassmann was actually talking about real engineers that build complete and tangible products. I feel more comfortable in the software world, so I have narrowed the focus. I’m hesitant to use the term engineer though, software development isn’t engineering.