Why there is more to innovation than just tech

I was co-organising an innovation senior management offsite of a major logistics company. Hundreds of thousands of employees. Yes, even C-level management needed a few floors in a hotel to get together, the company was that big.

It was remote, sunny, and balmy. Weaving in and out of the main collection area on one of the floors, I discovered stylized pictures of drones, funky vehicles with happy people, and other things in the same note hanging on hotel hallway columns.

“What’s this?” I asked a colleague.

“They’re inventions that have come out of their R&D department.” with a wry smile.

“So they have come up with some cool gadgets, clearly.” I commented.

We both knew what was missing, just looking at this funky little shrine to this company’s innovations. Just because they funded amazing technical breakthroughs, there wasn’t enough to really move ahead with a fully commercialized innovation. That said, we were clearly happy for them. It’s to their credit that they had the self-awareness to explore how to commercialize what they’d created. And to explore what that meant in an offsite.

For true innovation to happen, 3 factors need to be in place and internally consistent:

1. The technology
2. The market
3. The delivery process

And in all three cases, there are usually risks which will could block or derail the innovation, either before or after it’s launched.

The approach for dealing with this is fundamentally similar, regardless of risk type: validation.

Technology Risk: can it be built?

This is the domain of the engineers. Actually, it’s usually where they feel the most comfortable. First they come up with a theory of how something complicated could work. Then, bit by bit, they build out a system or a prototype. They focus on the biggest unknowns first–to “front load” the learning.

As they do this, there are usually a bunch of surprises (if it’s a big enough technical breakthrough & departure from the current state of their awareness). But surprises are an expected part of the process.

Finally, once the approach is fully validated, they can quick fill in any remaining gaps–now that they are clear exactly how their product needs to be built.

I’ve experienced this many times on software engineering teams.

If my team and I would have known exactly how to build something, the amount of time it would take to “fill in the gaps” would be relatively minuscule and easy to estimate. On a small scale, I experienced this a few times when I spent a few days figuring out how to approach a specific technical problem, found one I liked, and then lost the code due to a merge conflict where the saving of my work messed it all up. As I’d already done the hard work of figuring out how to do it, retyping the same code took an hour. Not a few days again.

The biggest bottleneck in early stages of a technical project is learning. And the ability to figure out exactly how to build the product, so that it works well and solves the customer’s problem. That’s pretty much the essence of technology risk. This applies to both prototyping, as well as figuring out how manufacture the product cost effectively if it’s hardware.

Market Risk: is it worth building?

The next big innovation area which requires deliberate focus is the market. Without a market, an innovation can’t happen. It’s just a clever invention.

Here’s what I mean:

Last night I went to a blockchain meetup where two startups presented what they were up to. The standard type of networking gig in a startup environment.

1. One of the startups, Arteia, was a blockchain for art collectors startup. The idea was that blockchain could be used by 600000 wealth art collectors to sell, value, or liquidate tokens on the specific works they hold. The CTO presenting it clearly had done his homework with respect to the market. He knew the market structure, the main players, he’d established contacts there and even self-funded by selling directly to these wealthy connoisseurs. In other words, he had clear market segments and knew exactly what value propositions would excite each of them. Even though the entire technical vision was still far from implemented, market risk had been taken seriously in addition to technical risk.
2. The other startup (which I won’t name) was a tool for remote video streaming in the travel industry. The idea is that you can connect with locals in a country where you are about to travel for specific advice. The expected revenue in the first year was $12mln, selling information about both sides to the travel industry players. Here, the startup CEO was gushing about technical possibilities of the technology in this space. Yet he seemed as though he had little contact with the actual surfer dudes in Thailand he wanted to target. He claimed he’d done interviews to determine that people were willing to spend up to $15 on a service like this. But most of his presentation was about a wooly business model and very little evidence about market interest or alternatives…are they using skype? What exactly does video chat give them in this case? Who is the actual target early adopter who has a really serious need? It doesn’t make a difference how good his technology is if this market risk isn’t addressed head on.

In a corporate environment, the innovation equivalent takes a slightly different form.

There are strong incentives to show J-curves in revenue, ideally topping out in the billions for a new product idea…even before anything is really known. Eric Reis writes about an example of this at GE in his book The Startup Way. These curves look great, but are actually highly uncertain one way or another. They’re based on assumptions that are typically completely unproven. If data is explicitly gathered to prove the key assumptions behind such a graph, then at least you can increase the probability of the billion dollar cash flows a few years out. But frequently this is the domain of a few highly-placed people making a big bet on a hunch behind closed doors.

In addition the above, in high tech markets there are other factors which need to be considered:

• Are there any disruptors with a different value proposition which could show up and wipe your market clean in short order? Think of the iPod appearing when there were a lot of big companies with mp3 players. Or the iPhone and smartphones.
• Even if you get a bunch of early adopters, who will your adjacent market segments be? It’s one thing to say that you’re after 35% market share based on a top-down estimate. It’s a completely different thing to figure out how you go from your beachhead market to winning the war–to steal the D-Day analogy in Crossing the Chasm.

Process Risk: Can you make it happen?

This is what fascinates me about innovation in big companies. Effectively, if you are an established company:

• You have easy access to credit so your budget is theoretically unlimited.
• You can afford, hire, and retain the best talent in the world if you decide to.
• You potentially have deep pockets when launching a new product

And yet despite these significant benefits over scrappy startups in your industry, you have a serious chance of being disrupted. And there are collections of historical quotes by CEOs (like this one) who were about to get disrupted and thought otherwise.

In short, how you go about delivering on an innovation matters. A lot.

The most common anti-pattern I see in big companies is that they come up with a delivery plan at the beginning, communicate it to oodles of stakeholders, and then heavily negotiate any variance to that plan. This works well for an established product line.

In a new product context, the approach chokes your ability to discover the best possible approach to delivering a specific innovation:

• You commit to a structure and plan when you know the least about what needs to be done to achieve business milestones–at the beginning.
• Then you disincentivize the project team to introduce changes to that plan, because it will mean that you need to renegotiate with lots of stakeholders.
• Often this product needs to “compete” internally with other products and projects for staff, executive attention, and budget.
• Finally, this approach gives you little ability to change direction if the market’s requirements do change as per market risk. For example, in the 17 months it takes to build out a technology, customers needs can change. A competitor launches something. A new type of product overtakes the market.

And note how all of these are internal challenges to the company, which typically wouldn’t exist at a startup, simply because they are small and must be focussed if they want to win in the market.

There’s an additional type of external process risk in certain industries: regulatory risk.

While this usually isn’t a concern for consumer tech startups from Silicon Valley, for many industries, regulation is a necessary evil: energy, transportation and finance come to mind.

For example, you need $5 mln seed capital to open a new bank or insurance company before you can offer any financial service in the UK. This significantly changes what is required to experiment in this space. Complying with any current requirements can tie your hands, or it can create opportunities like tax breaks that wouldn’t otherwise exist.

Sometimes regulations are unclear. In that case, officials can subjectively choose who to favor and who to punish. For example, a lot of the regulations around MIFID and securities regulation can’t have a 100% certain interpretation by legal experts because a lot of it is still being formed.

And finally, regulation can change quickly with serious implications. In some cases this means entire business lines can be wiped out overnight, if getting them to compliance would cost more than it’s worth. For example, I’ve spoken to banks which prefer to close entire divisions in order to be compliant, than to figure out how to continue delivering a service.

Discovery driven planning

Personally, I prefer the term “discovery-driven planning” to describe how to approach new products.

Instead of making big time & money allocations, you focus on maximizing learning until you are confident that you have a good handle on technical, market, and process risk. You keep time allocations down by focussing on what you can validate over shorter time blocks of a month at the most. While keeping the bigger vision in mind, what can you validate about whether it can be built technically, whether it’s worth building, and whether your company as the ability to make it happen. During any given month, you will likely learn something surprising if you are going after an ambitious vision. The more ambitious your vision, the more likely it is that you’ll be surprised. If a particular idea looks like it won’t pan out…kill it early before you allocate a lot of resource.

Ideally this validation applies the same approach used for technical risk to market and process risk. You validate your assumptions in market and process risk. The ones in your spreadsheet with a financial model. The ones related to whether or not your customers will care about what you’re creating.

Learning is your biggest bottleneck, when launching a new product.

It’s very possible to overcommit resources to an underdeveloped idea. This is called premature scaling in a startup context. If you don’t have the right market segment, technology, team, funding level, or ability to deliver, then just throwing more resource at the problem typically makes it worse. For example, in a software context, adding more developers to the team in the middle of a long project will actually lower team productivity in the short term as they need to train up. And it might lower productivity in the longer term, if there is lot more “communicating” which needs to happen because you have more team members.

It’s also possible to starve a great idea of resources. There are many front-line employees who interact with customers and know what their frustrations are. Or who know the technology trends and what is easily achievable. Or who are great at creating alignment around a validated goal. But they don’t have enough budget to go make it happen, or aren’t given enough leeway to try something outside their daily routine.

Optimize resource use for learning

First and foremost, make it possible to fully change direction on a monthly basis. Anything longer than that make it difficult get feedback and iterate. And this is crucial. This may require difficult decisions around priorities and disentangling current work to align around true priorities.

Once you have this ability to work on an adaptive basis, figure out what you need to learn. Identify your biggest risks for the current innovation projects you’re working on, and go after them. Go interview customers. Figure out how that new software architecture would need to work.

Finally control your risk by baking in profitability from the start

As a term, discovery driven planning originates from Rita Gunter McGrath, where she bakes in profitability using a technique called a reverse income statement. Essentially you make forecasts, based on assumptions, and then you go and test all of the underlying assumptions. More on that later.

You got this!