“In the end, these projects are all business model problems.” That’s what I said to my friend Steve Adelman about the projects we collaborate on as part of the Wharton-UQ Global Consulting Practicum program.

“Why aren’t they market entry problems?” he replied.

I was stumped by his question for a couple of days. Then I realised what was going on.

GCP is a program where teams of 10 MBA students, 5 from Wharton and 5 from UQ (or other partner schools), work on a project for an Australian organisation that is trying to increase their business in North America. The program was originally designed as part of Wharton’s marketing program – so the projects were conceived as market entry problems, exactly as Steve said. However, out of the fifteen projects that we’ve run so far, only about three have been market entry problems, the rest have been business model problems.

What causes the difference?

It comes down to discovery versus execution.

Steve Blank framed this problem as: existing firms execute, startups have to search before they can execute.

This includes Steve’s resources that go with each part of the process – and you can see that the tools that go with search/discovery are very different from those suitable for execution.

Since all of our project organisations already exist, it’s natural to treat expansion as an execution problem. However, it’s not so simple. Product-Market Fit does not map across borders – which means that market entry becomes a discovery problem again. Our least successful GCP projects have been ones where we’ve treated discovery problems as execution problems – and it’s a common issue for existing organisations.

All this is another way of saying that existing organisations need to be able to do both: discovery and execution.

Blank originally looked at the two as either/or, and the big problem that he identified was startups trying to act like established firms. In other words, if they skipped discovery and went straight to execution (e.g. writing a business plan first), it increased the chance of failure.

As he’s been working more with established firms trying to innovate, his view has evolved – now he shows how discovery and execution integrate:

This, of course, is another version of the ambidextrous organisation issue that Ralph Ohr has been digging into deeply.

In my work on the GCP projects, as well as with CSIRO and in consulting with private firms, I’ve seen that the problem of treating discovery like execution is pervasive in all kinds of organisations.

With the lean startup movement, we now have a set of tools that startups can use to make sure that they do discovery first, then execution. The toolkit for established organisations is still being put together. Here are some thoughts to help with that:

• Discovery is a lot messier than execution. Business-as-usual works for execution problems, but for discovery problems we have to invent a new business-as-usual. This means that uncertainty is much higher, because we don’t know what will work. This is fine to admit within a startup, but often dangerous in established organisations, where giving the illusion of false certainty is often viewed as less risky than honestly discussing the likelihood of success. Consequently:
• Discovery processes can look like incompetent management. We’ve run into this on some of our GCP projects. The team asks what seems like a straightforward question about expected returns, competitive advantage, or supply chains. When the client doesn’t have an answer, the team often loses faith in them. Not knowing these things is indeed a danger sign for an execution project, but it’s completely normal for a discovery project. That’s why it’s critical to understand what you’re working on.
• Business-as-usual metrics will kill discovery projects. I frequently see organisations go through a discovery process to build a new business model to support a great new idea, then blow the whole thing when they plug the result into their normal measures of success. In an execution project, we can use all the normal accounting tools – return on investment, expected margins, etc.

This last point is crucial, and possibly the biggest issue for established firms that are looking to add business model innovation to their toolkit. Fortunately, there are some good thinkers working on this.

Start by looking at Ralph Ohr’s work on ambidextrous innovation – this has been a top agenda item for a few years now.

Paul Hobcraft just wrote a great post on building innovation metrics.

The article that I still use on this topic is by Geoffrey Moore in the Harvard Business Review. It’s from 2007, and one of the first (and still one of the best) applications of the three horizons framework that I’ve seen. Includes a number of very practical steps for established firms to use to support innovation in H2 and H3 projects.

One deceptive issue in discovery projects is that the initial target market looks a lot smaller than established firms might be used to. Even firms that are used to targeting a mass consumer market need to think about Product-Market Fit for a small niche for ideas that are potentially disruptive. New business models start in niches – ignoring small initial markets is one of the most effective way to kill a discovery project.

This means that even for established organisations, tools like lean analytics and pirate metrics for startups are essential. These focus around issues like traction, retention, and other measures that indicate that we’ve hit the target for our niche. These metrics look very different from execution metrics – using multiple sets of metrics is an essential element of ambidextrous innovation.

The project that Steve and I just finished working on was definitely a discovery project. If we had realised this from day one, it would have made the team’s job easier.

To succeed at innovation, we need to stop treating discovery like execution. They’re two different things, and we need to be good at both of them to thrive.