Image Sources: Reddit, WiWo, Heidenheimer Zeitung, Rainbowknight at Wikipedia, Xelibri 4 Mobile Phone, Collage, CC BY-SA 3.0
The Déformations Professionnelles of Engineers and Business Economists
Do you also know this situation? A new product is launched. Everyone pats you on the back for all the great features the team has been able to integrate into the product. With these functionalities and this product quality, it must be easy for marketing and sales to make the whole thing a big success. After all, a lot of technical brainpower and a considerable amount of development time went into it, right?
What may enrapture an engineer, techie, and lowbrow manager at the launch party would more likely create a sense of cringe for seasoned startup entrepreneurs and agile product managers. Why? Because with feature-rich big-bang launches like this, too many signs point to dispersal and unclear focus. They can already see in their mind’s eye all the problems down the road, such as more dependencies and tech debt, more costly maintenance, lots of change requests, high push marketing and sales training efforts, etc.
When you ask the product team why all these gimmicks and functionalities were built in, the unspoken truth is often: “Because we can.” For example, German B2C cleantech manufacturers are incorporating space and racing technologies into their home equipment. The minimal gain in efficiency is disproportionate to the cost of the increased complexity of the device. None of the Chinese (or American) competitors would do this even if they could because, for customers, this is simply not a buying criterion. One of our major German industrial customers calls this behavior “happy engineering” – more widely known as “over-engineering.” In the IT context, people also like to talk about bloatware and featuritis.
And waterfall-like over-engineering is also one of the basic problems of technology-driven innovation, where a solution seeks a problem. Its inventors often don’t yet know which customer and application they are actually building for and therefore have a hard time estimating which features and “delivery forms” of your solution will add the most value. That’s why you put in what works – everything is based on your own assumptions about what the world might need. And even if they don’t fall into the trap of over-engineering, they traditionally interact with customers only through outdated, classic market research methods and then build products that may resonate with a selective focus group but miss the real market.
For a long time, this is how it worked in the startup world of Silicon Valley. The recipe went like this: Get a degree from an elite university; raise a bunch of money with a great tech (idea); go full throttle and build the whole thing; then proudly present your baby to the world and let marketing do the rest. Guiding motto: “Build it, and they will come!” Large corporations and mid-sized companies do this with the usual tendency in Germany towards particular thoroughness and “quality.” In most cases, however, this bet doesn’t work out because founders or product teams come up with great technology, but there are no customers willing to pay for it, or they are not willing to bear the so-called “switching costs” for it.
For every one of our failures, we had spreadsheets that looked awesome.
Scott D. Cook, Founder of Intuit
In such a situation, it doesn’t help to have a perfectly executed business plan or investment case in which market potential has been extrapolated from studies and desk research based on assumptions. Juggling with historical data is like driving a car with a rear-view mirror. You can only perfectly measure and quantify what was in the past. Other people’s data (OPD) is often problematic because it is collected in irrelevant contexts. What product teams need more are early market signals and context-specific data collected by themselves, “Your Own Data (YODA)” . Writing a business plan too early in the privacy of one’s own home, without having gone out to customers and users, ensures that one’s product is built past the market. Because as Helmuth v. Moltke said so well: “No plan survives the first contact with the enemy”. You could also say: No business plan survives the first customer contact. [ continue reading … ]
