We all have slightly different ideas about what a business case for innovative services look like, but I think the one thing all our definitions will have in common is some sort of cost-benefit analysis. The problem is, this is really hard in the tech world!
Following the waves of Agile
Innovation done well typically comes in waves or cycles. It can start at various points - an exciting technical breakthrough, spotting a gap in a market, or most commonly someone saying something like "what if we…?" What comes next is some sort of cycle of product-market fit exploration, and this is where different organisations may have wildly different approaches.
The "old skool" approach is a big development cycle - build an impressive, fully-featured "version 1" to wow the world and win over the masses. This approach is by no means dead or defunct - just look at Dyson to see it in action, or think of the first iPhone. Dyson specialise in dramatic product launches, and their robot vacuum cleaner was over 10 years in the making before it was revealed to the public. Sure, there were undoubtedly several development cycles that led up to the first product, but James Dyson seems to deal in big blocks of commitment to his products.
By contrast, the modern lean startup approach to software is small but frequent cycles, following the agile methodology with relatively little commitment at any stage - the "fail fast" mentality. Build something small that doesn't really work properly and see how people react.
Spending to avoid mistakes
So the first question to ask is "what is the business case for?" That might sound obvious, but think about your milestones and your budget approval points. Quite often the initial business case is just to validate the opportunity through some sort of discovery process.
So now we know our desired output, the next question is - how do we assess the value of that output? This is especially hard when the output may just be some learning, rather than a revenue stream. I don't have a firm answer for you on that, but I would encourage you to value the learning higher than you first think you should - building something even slightly off the mark can be exceedingly expensive, so think of it as spending to avoid mistakes, rather than spending to make mistakes!
Solving the Software-Cost equation
We've looked at the value of the output, now how about the cost? Well, depending on how you've defined the output that could be an easy or impossible job! The secret here is to commit to the right thing - some things are easy to cost, for example going through a design and/or market test process and delivering some learning. Similarly, it's easy enough (so long as you ask the right people) to cost up building something that does certain things. However, the cost of getting the right result is almost impossible to predetermine! You may need to go through several cycles of design and market test to come up with the right product-market fit, or if you build with a lot of technical or market uncertainty then you may have to rework things extensively.
So now we have the value and the costs, what makes a winning equation? Again I don't have a firm answer for you on this, but I can give you a couple of rough rules of thumb: for a discovery project, you should expect the benefit of the successful innovation over the first 5 years to be at least 20-50 times the discovery cost. For a software build project you should expect the 5-year return to be at least 2-5 times the build cost. The numbers you use should be based on your confidence, though - if you're super-confident then 2 could be too high and it may be fine to not expect any net return at all until after 5 years; or if it's a real unknown then you should work off a higher expected failure rate.
The cost of standing still
So that's it, right? Easy, yes? Well actually there's another ingredient that's missing - the cost of NOT doing something. So far we've been thinking in terms of a static environment, one where all other things remain equal. But of course they don't. One of the biggest drivers for innovation at the moment is survival. Your competitors are moving on, and if you don't stay ahead of them then you're going to lose out. This means the cost of inaction is high - but please don't confuse this with the cost of failure; the cost of failure is only high if you're not innovating enough. You should have several innovation projects on the go at any one time so that you can afford (or better still plan) to have some fail.
So the final, and crucial, factor for your business case is the cost of not acting. What does the future of the business look like without this innovation? And how does that future compare with the board's vision? This provides a useful sense-check to the business case and thinking about it could reveal that you're missing something from the value proposition. Without knowing anything about your situation, I'm going to guess that it's more important than you initially thought!
