Browse Business Software Categories

Close  

What If Making a Business Case Is Not Possible?

What If Making a Business Case Is Not Possible?

Innovation is a high-risk activity. You invest in something with the only certainty that you know (some of) your costs and none of your future revenues. Traditional wisdom tells managers to focus on a business case. If the business case is more positive than the other alternatives and gives a good return-on-investment, then you should invest. However this approach is flawed when dealing with innovative projects. There is no reference to calculate future revenues.

Yes you can “guestimate” and make nice assumptions. However no business case would have indicated that you should invest in a 23 year old that puts photos of his fellow students online. Some years later that photo page is worth many billions. For every positive example unfortunately there are a long list of failures.

The Solution: Focus on Incremental Innovation. Or Not?

Nokia is the best example of this strategy. They made the best hardware platform — a relatively easy software — and ensured people could reliably make calls and send messages. Every investment decision had a positive ROI and positive margins. Unfortunately, now Nokia’s stock is close to becoming junk.

Can You Make a Business Case for Highly Innovative Projects?

Yes you can make a business case. Costs especially can be estimated as well as some high-level revenue estimates. As long as this business case is used to validate if the project is economically viable, there is no problem. The major problem is when this business case is compared with incremental innovation projects or investments in the core business. The outcome will always be negative. Disruptive innovations tend to go for lower margin business with inferior offerings that often cannibalize the core business.

Over time the disruptive innovation will move up the value ladder and will be able to substitute the core business. Unfortunately the Innovator Dilemma, in which you attack your core business and substitute it with an inferior margin business, is difficult to accept by conventional managers. There are some companies that have excelled at this. The best example is Amazon that is seeing its core business of book sales being threatened by electronic books. The answer has been to provide e-book readers and tablets below the hardware costs with the idea to dominate the electronic book market by offering a total solution to easily buy books.

Ostrich Techniques

The technique used by most companies when faced with disruptive innovation attacks is to consider them inferior and to ignore them. Unfortunately over time these solutions will substitute the existing offerings. This process is currently happening: e.g. SMS versus Whatsapp, LBS versus Mobile Phone location, calls versus Skype or Voxtrot, etc.

Unlike incremental innovation, being first in the market for disruptive innovation is key because the winner takes most of market. Number two can still take some market share but number three is no longer profitable. Examples: Google Search/Adwords/Youtube, Facebook, Linkedin, Twitter, etc.

The worst strategy for operators is the ostrich technique because implementing LTE will offer disruptive innovators all the tools they need to offer voice services over the top.

Discovery-Driven Planning Versus Business Cases

In 1995 Harvard Business Review came up with discovery-driven planning. The idea has been successfully implemented by venture capitalists. You do not give money to a new venture to develop a new product, launch it and expand globally. You give money to develop a prototype in a few months. If this goal is met, you give money to validate the prototype with early adopters, etc.

Operators should start using discovery-driven planning to introduce disruptive innovations. Employees, partners, customers, etc. can “complain” about inefficiencies in the current offerings. The most urgent “inefficiencies” are selected, for instance via voting. Afterward, small innovation groups, made up out of experts in different domains, are formed to find solutions on paper for these “inefficiencies.” These paper-based solutions are presented to selected early adopters. Via continuous feedback the solution can be designed, the future price can be determined, the costs can be estimated and a high-level business case can be made. Early adopters are asked to find beta users. If a certain number of beta users express interest in the solution then the team will receive funding for a prototype.

Beta users are able to see the prototype come to live and to give continuous feedback. The prototype should evolve from paper to a real service in as few months as possible, 2-6. Afterwards the beta users get a limited amount of time to start subscribing to the real service and to extend the number of beta users. If a certain limit is reached within a certain time frame, then the beta product will get a next investment round. This investment round will bring the product from closed beta to a public launch. The last stage is expansion. If the public launch is successful then the last round of funding is provided that allows the service to expand, e.g. within all markets of the operator.

Any idea/service that does not make a stage gets killed. The complete disruptive innovation program should get a budget and should be initially independent from the core business. Direct support from the CEO and other senior executives is a must. Business cases are used to set prices, etc. but not to compare disruptive innovations with core business investments.

[This post originally appeared on Maarten Ectors’ Telruptive blog and is reposted with permission.]

  • Consultant

Maarten Ectors

Cloud & Disruptive Innovation Thought Leader, Telruptive
Expert in Telecom and Disruptive Technologies
Maarten Ectors is the Head of Cloud and Disruptive Innovation in Europe at Nokia Siemens Networks. Maarten helps telecom operators to understand disruptive technologies (SaaS, PaaS, IaaS, mobile SaaS, big data, NoSQL, predictive analytics, machine learning, collective intelligence, M2M, ...