In a world where there’s always too much to do and too little time, how can organisations make time to innovate? (Spoiler: siloes probably aren’t the answer.) In this article we’ll explore practical innovation strategy, exploring how to design an MVP (good), and how to get something for nothing (great!). But before we do, let’s talk about George Washington Carver.
WTF is a Double Win?
You might know of him as the inventor of peanut butter. If we’re being picky, Carver did not invent peanut butter, but he did invent many other, even more useful, things. Carver’s start in life was not promising. He was born into slavery, and lost both his parents before he was a month old. Slavery was abolished when Carver was a child, and his prospects improved significantly. He was able to pursue an education, eventually becoming a professor at Tuskegee University in Alabama.
Carver studied agriculture, and there was a lot to study. At the time, the dominant crop in the US South was cotton, but cotton is famously hard on soil. When the US frontier was expanding, many cotton plantations were worked for ten or fifteen years and then abandoned in favour of fresh land. That strategy, clearly, does not scale once all the land has been occupied. After generations of cotton farming, the soil of the US South was exhausted. The soil was hungry, the animals were hungry, and the farmers were hungry.
Fertiliser improves soil, but it’s expensive. Many of the Southern farmers were barely able to scratch out a living, so manufactured fertiliser was absurdly out of reach to them. Carver worked out that there was another way: peanuts. Peanuts, like peas and sweet potatoes, improve soil by replenishing its nitrogen. Carver developed the technique of crop rotation, in which peanut crops were alternated with cotton. This improved cotton yields wonderfully, but had an unwanted side-effect: peanuts.
At the time of Carver’s work, peanuts were not even considered a food crop. Carver set out to change this. He catalogued over a hundred uses for the peanut, many of which he discovered himself. His efforts convinced the nation that peanuts were both tasty and nutritious. In other words, if farmers ended up with huge volumes of peanuts because of crop rotation, that was a feature, not a defect.
In solving one problem (soil fertility), Carver also solved a second problem (lack of food). I call this ‘the double win’. The invention of the shopping cart follows a similar pattern. An enterprising shopkeeper attached wheels to his baskets, to make shopping more pleasant. Customers loved coming to his store (win), and they also bought more, because they didn’t have to worry about the weight of their basket (double win).
The danger of “Everybody knows”
Great innovations start by up-ending conventional wisdom. When Carver started work, everyone knew that peanuts were barely edible. When Zappos set up shop, everyone knew that you couldn’t sell shoes on the internet.
I’ve experienced a similar thing in my own work. Fifteen years ago, I was working as a performance engineer on the JVM. I spent quite a lot of time explaining to people that although ahead-of-time compilation intuitively seems like a good idea, after the warmup phase, a JIT-compiled application would actually run faster than one that had been pre-compiled. The JIT can use what it discovered at runtime to perform extremely effective optimisations.
That’s still basically true, but now our industry has also discovered that applying build-time optimization to all the other things, like annotation processing, configuration, and classpath scanning, can make an application go dramatically faster. Quarkus (which I work on) is an example of this new model, and it can deliver faster startup, lower memory footprint, and improved overall throughput. That’s a double win. (Quarkus also has a lower carbon footprint and a great developer experience, which takes it up to at least a triple win, or maybe a quadruple win.)
Ideas that go against ‘everybody knows’ seem ridiculous when they’re introduced. (This is where the “WTF” comes in.) But then these ideas become obvious. Some things we take for granted now, such as the lightbulb, laptop and the cheeseburger, famously met significant resistance on launch.
But.
Just because some ideas that initially seem stupid turn out to be world-changing, it does not follow that every apparently stupid idea is world-changing. It may turn out to be a mundane single-win, or perhaps a non-win. Even a celebrated inventor like George Washington Carver had his fair share of misses, including peanut paint, peanut bread, peanut sausage, peanut coffee, and peanut nitroglycerine.
Optimising for feedback
So how do you know if you’ve created the next lightbulb, or the next peanut-based paint? You experiment. You fail, and you learn. (You do have a healthy amount of psychological safety in your organisation, don’t you?)
You build, but you build small and incremental. And you measure.
For an established product with a web interface and many users, A/B tests are a straightforward way of trying out new features, and the success metrics are usually obvious. Well, somewhat obvious. For example, if a search engine returns unsatisfactory results, engagement may increase in the short term, as users try different queries to try and get the results they need. In the long term, “increased engagement through reduced quality” will not be a winning strategy.
For new products, or those without an online interface, experiments may need to be more creative. How do we measure buying behaviours if there’s nothing to sell? How do we measure whether people like a product we haven’t built yet? At this point, we may need to do things a bit differently.
Building small and measuring is all about optimising for feedback. Skilled engineers love short feedback cycles. However, even to feedback-loving-engineers, some of the techniques for getting fast feedback can feel a bit weird. A bit hacky. Perhaps even … dirty. Engineers love feedback, but they also love quality. Getting feedback faster sometimes means cutting a corner – or even skipping half the track.
Here’s an example. My former team in the IBM Garage did a project for a building materials company. The normal ordering process was that a contractor would ring their sales rep and have a conversation about what they wanted, and the seller would then issue a quote. Could this be digitised? Would contractors want to scroll through pages of identical-looking rolled steel joists on a mobile phone, rather than talking to a human being?
In order to find out, we prepared visual designs and conducted user interviews. So far, so typical. Feedback was positive, so we progressed to the next phase, and built the e-commerce site. It was responsive, mobile-friendly, and it looked great. Under the covers, it was built using test-driven development and continuous deployment. But there was something missing. When a contractor clicked ‘order,’ the app didn’t initiate a dispatch from a warehouse. Instead, it sent an email. The sales rep would pick up the email and use the old, manual, process to initiate the order.
We’d built an e-commerce platform with a gaping hole where the e-commerce was supposed to be. In one sense, this was terrible. On the other hand, we got to market fast. The client’s sales team were no worse off than when we’d started, and the users were better off. If buyers didn’t use the app, the clunky email back-end was no problem at all. If people did adopt it, that gave us the information to justify investing in a proper back-end.
The origin story of Zappos followed a similar pattern. When he first built the business, he did not invest in any logistics or warehousing. When someone bought a pair of shoes, he would go out to his local shoe shops, buy them, and post them. He made a loss on every pair of shoes he sold. Eventually, he was selling enough shoes, and losing enough money, that he was able to prove that there was real demand for an online shoe shop.
This model is called a “Wizard of Oz MVP”. The application looks real enough, until you peek behind the curtain. Then you discover two hamsters on a wheel, or a sheepish person where a program should be.
A Wizard of Oz MVP, or any other shortcut to feedback, only works if you can fill in the gaps in the first release before they start to hurt you. That means releasing regularly, and often, which is something many organisations struggle with. Before trying a shortcutty-hacky-incremental approach, you need to make sure you’ve got a handle on both the technical and organisational challenges of rapid release cadences. You also need to have the psychological safety to allow you to deal with data that doesn’t always tell good stories.
Pitfalls of measurement
Feedback only works if you’ve got systems in place to interpret it. What does success look like for your team? How do you know if you’re winning? How do you discover the business mistakes? Are you gathering the most meaningful information?
Many organisations have declared themselves data-driven, but then stumbled straight into the McNamara fallacy (also known as the quantitative fallacy).Numbers give any argument an air of authority, but that doesn’t make it correct. Measuring the wrong thing is worse than not measuring at all.
Beware of optimising for what which you can most easily measure, rather than what’s most important to users and the business. Beware also of vanity metrics, which look impressive and numeric, but which don’t have a meaningful cause-and-effect relationship with what’s important.
Numbers aren’t there just to fill in blank spaces on status presentations. A number should guide decision-making, and that means a number isn’t just there to make you look good; it has to be able to tell you that your decision was wrong.
Measuring is expensive, and it doesn’t make sense to measure every possible metric. It may not even be possible to identify them all. This can be a particular problem for double-win innovations. Often, the second win isn’t expected. If you weren’t looking for it, you may not have the right measurements in place. Sometimes the double win is only identified well after product launch, when users behave in unexpected ways or the business context changes. For example, IBM mainframes have excellent sustainability credentials because of their low carbon footprint. This benefit became interesting to businesses around forty years after the launch of the product. Most businesses can’t wait four decades to discover a secondary win.
So how much should you invest in measuring? This all depends on how certain you are. In environments of high uncertainty, you should focus on small, cheap, experiments, with strong metrics. These experiments should be designed to fail. That is, they should be designed to allow failure. Otherwise, if there’s no learning, what’s the point of an experiment? (Remember the psychological safety?)
Each experiment should lead to a follow-on experiment. Eventually, after enough experiments, you will feel confident enough to switch to a more conventional development flow. If you’re already quite certain of success when you start, you can just jump right into the normal flow. In the normal flow, the aim is to deliver, rather than to learn. Success is never guaranteed, so there should still be a focus on iteration and continuous deployment.
How confident can you ever be about a new idea? Where clear metrics exist, the success rate of new initiatives are, frankly, rather depressing. According to a report in HBR, Google and Bing report that only about 10% to 20% of search engine changes make a positive difference to their business metrics. Microsoft has a mature experimentation infrastructure, and they found that, across their portfolio, one-third of new features were effective, one-third were neutral, and one-third worsened results. If you doubted the value of experimentation and metrics, hopefully this makes them clear.
Funnels, fizzles, and railroads
Building things is expensive. Even throwaway experiments can be expensive, especially if they involve code. How does an organisation prune out the bad ideas early? Many organisations will rely on some form of innovation funnel. The funnel is a series of gates, each requiring more compelling evidence, and unlocking richer funding.
On paper, the idea is perfect; ideas are evaluated by experts, and only the most promising candidates proceed to the next stage. In practice, innovation funnels can be excessively bureaucratic, requiring innovators to fill in too many forms and produce too much documentary evidence before funding is approved. It’s formal, and sterile, and totally unlike the skunkworks which generate so many disruptive products.
Innovation processes can have a second problem, too; no one wants to be in charge of an innovation funnel that’s approving failures. There is often a tendency in the approval board to select for “sure things,” and reject riskier innovations. Creativity, joy, and adventure have little place in many funnels.
The innovation funnel has two sad variations, the innovation railroad, and the innovation fizzle. In an innovation railroad, failure is not an option. This doesn’t mean failure doesn’t happen; it is just deferred until the product release. Delivery is preferred to experimentation. In these organisations, promotions are achieved by shipping products, not by abandoning part-completed projects in order to redirect resources elsewhere. This perverse incentive to appear successful can end up drastically reducing how much actual success there is. We can’t be too judgemental, here – seeking out evidence that proves we're wrong is hard, and giving up on a cherished idea hurts.
The converse of the innovation railroad is the innovation fizzle. In a fizzle, many ideas are prototyped, but none make it to production. Somehow, the organisation hasn’t worked out how to make the leap from the lab to the real world. This often occurs when there is a dedicated innovation team, who are measured exclusively on idea-generation rather than value delivery. In the rest of the organisation, which is only measured on value delivery, there is little interest in adopting any of the wild idea-orphans of the innovation team.
The fauxnovation
What happens if an organisation is measured on both value delivery and innovation? This should be the ideal scenario, surely? Almost, but things can still go wrong. A tempting way to innovate while ensuring success is to keep the innovation shallow. In 2017, it seemed like almost every client who visited the IBM Garage wanted the same thing – a chatbot. When we dug into the underlying pain points, they usually had very little to do with conversational interfaces. In several cases, the actual requirement was a simple password reset flow. This is something any user could trivially do with a button on a webpage, but that wouldn’t be categorised as Innovation in the end-of-year report. In one case, the optimum technical solution for an industrial client whose workers wore heavy gloves and kept getting locked out of their handheld terminals would have been a one-character change to SAP configuration… but the client wanted a chatbot anyway. For other clients, we built chatbots to solve the problem that no one could find anything using internal search systems. Why didn’t we just improve the search? In fact, we did. In order to make the chatbot work, we also had to build a decent search to put behind it.
In 2018, we saw the pattern repeat, for blockchain. I lost count of the number of ‘business process digitisation’ projects we saw, wrapped in a layer of blockchain. Were distributed ledgers required for the solutions? No, a normal database would have worked better in almost every case.
At the time, I was frustrated. Why were we wasting time disguising business-as-usual improvements, things the business should have been investing in anyway, as innovations? Now, I take a slightly more pragmatic approach. These projects were like a sheep in wolf’s clothing. They were sold internally as exciting and edgy, when in fact they were safe and valuable. But the novelty of the ‘wrapper’ technology was what secured the investment. Would it have been better if there had been enough slack in the ‘normal’ budget to fund these improvements? Yes, definitely. But perhaps the most important thing is that necessary improvements were made.
Innovation is great, and innovation needs time, space, and investment. But beware of giving those things only to an innovation team. Normal people also work best if they have time, space, and investment. The daily grind exhausts teams, and play restores them.
Play feels nice, and it has a biologically important function. Why? Exploring things which aren’t immediately necessary for survival helps adaptation. Today’s play can be tomorrow’s skills in a valuable new technology.
Although play is valuable, it’s clearly not practical to play all the time. Play must be balanced against the normal work of keeping the lights on. But consider rotating team members between fun and not-fun assignments, just like George Washington Carver rotated fields between cotton and peas. For both plants and people, a change is as good as a rest.
Sometimes it’s not practical to do formal rotations, because roles are too skilled. In those cases, consider deliberately adding ‘off-plan’ sprints into the schedule. On one product I worked on, the run-up to releases were exhausting, all project-management panic, late-night pizza, and absurd deadlines. As a thanks to the team for (more or less) getting everything into the codebase by the release date, we were rewarded by having a sprint where we could work on anything we liked. It wasn’t a holiday, but it felt like it. Some people cleared up technical debt that had been irritating them, and some took the opportunity to implement pet ideas. Some people just played in the codebase. Some of the features we added in those ‘free-coding’ sprints turned out to be market differentiators.
Play is delightful, and important, but it’s only part of the picture. Meaningful innovation needs a balance between play and rigour, between exploration and measurement. Good innovation is a win, but the best innovation is a double-win. As you develop new ideas, look out for the serendipitous side effects. Failure is a part of innovation, but sometimes you’ll find the neat twist that turns every outcome into a victory.
Previous article
