Back to the Research Roadmap

The last three posts focused on predicting the future. That is only one part of The Research Roadmap. It is time to get back to the research and see how predicting the future fits into the Roadmap Process.

Research Roadmap Process Recap

It seems like ages ago when I first introduced the Research Roadmap Process. The process is designed to ensure that we deliver research results of value. The roadmap has three key phases:

• Phase 1: What Problem Should We Research?
• Phase 2: What solutions can we propose to these questions?
• Phase 3: What experiments do we run?

Phase 1: What Problem Should We Research

We’ve now covered this phase in depth. It is our exploratory research, where we discover what questions we should research. It is based on creating a vision of the future. If your organisation doesn’t already have a definition, then you can create one. We can use some of the common practices that futurists use to create a vision of the future. A good guide is the 6-step process we covered in the latest post:

1. Trend Prediction: Gather Data
2. Trend Prediction: Data Analysis and Trend Spotting
3. Trend Prediction: Culling the unlikely Trends
4. Trend Timing: Calculate a velocity for a trend based on missing elements preventing adoption
5. Scenario Writing: Document Multiple Visions of the Future
6. Critique the Scenarios: Validate that Scenarios, combine and improve them

Chasing the Horse

There is one final tip I’d like to give before we leave our future prediction. The truth about any trend, is that if you study it closely enough you should be able to identify the core driver - the “need” behind any push for a solution or a technology. Once you’ve identified that you’ll be able to make more accurate predictions on what is going to happen next.

That sounds pretty obtuse, I know, but let me give you an example and a famous one at that. Henry Ford is often misquoted as saying :

“If I had asked people what they wanted, they would have said faster horses.”

This line is often used in articles about how customers cannot articulate their need for innovation. Henry Ford didn’t invent the motor car; it had been around for some time. However, what this misquote does point to is the understanding of the core need - that people wanted transportation, an ability to get themselves and their goods from point A to point B conveniently and at a low cost. Anything else that could address the core need would work. The motorised carriage, or motorcar, was one possible solution.

In fact, in his autobiography Henry Ford actually describes the vision of the future he created:

“I will build a motor car for the great multitude. It will be large enough for the family but small enough for the individual to run and care for. It will be constructed of the best materials, by the best men to be hired, after the simplest designs that modern engineering can devise. But it will be so low in price that no man making a good salary would be unable to own one – and enjoy with his family the blessing of hours of pleasure in God’s great open spaces.” – Henry Ford

Ford Model-T Photo by Jack Snell, Used under creative commons.

The Questions

With any vision of the future, there will be a set of problems to be addressed, things that are preventing that future from becoming a reality. For Ford this wasn’t the creation of the motorcar, it already existed, the main driving question was how to manufacture the car at a cost-effective price.

If we look at Ford’s main problem; “How do I produce a cheaper car?”. We can break that initial question into several others:

• How can I reduce the bill of materials?
• How can I reduce the time (and effort) to manufacture the car?

Phase 2: What Solutions can we Propose

It is actually really unusual to need to create a completely new concept / product / product category from scratch. There is almost always a range of existing solutions to the problems we’ve identified in the creation of our vision of the future.

One of the first phases of any PhD, and many supervisors will ask this of their students, is to conduct a literature review. Once you’ve identified the question you want to address in your PhD, determine with clarity what work has already been conducted in this area, and what solutions, if any exist for the problem you’ve identified. This is also, probably, one of the most boring stages of a PhD. Rather than working on an exciting new idea, you are reading a lot of publications and reviewing a lot of past work. This phase resembles the literature review - taking each question in turn and then reviewing the work done in that area.

There is no need for us to write and publish a literature review and we don’t need to spend the year or more a PhD student may spend on this. The goal of this phase is to look more deeply at the questions we need to address, to discover if there are other solutions available and what work, if any needs to be done in that area.

How the Questions Get Addressed

There are number of places we can investigate during our solution search:

• Academic publications
• Start-up companies
• Other adjacent industries
• Existing products or services
• For the software / IT industry:
  • Open source software and the community
  • Forms and message boards

The Types of Answers You Get

Broadly speaking answers fall into one of three categories:

1. It is already solved
2. There are one or more possible solutions
3. There is no solution at all

It is already solved

We are all human, and no one knows the answer to everything. Often, when we sketch out the vision of the future, we’ll see questions which look to us as if they have never been solved, but, upon closer inspection we can find a whole bucket load of solutions. Usually this is because the technology or question area we are looking at is outside our area of expertise.

Charlie Stross wrote a fantastic Sci-Fi Book called halting state. In it he depicts a future in which everyone owns a headset which can connect to each other. Games and applications run across these headsets with no reliance on any central infrastructure. So, this means, no cellular network, no cloud, no AWS or Google cloud service. But, for this vision of the future to work, we’d need a technology which allows these devices to talk to each other without a cellular network. When I first considered this, I thought that would a huge issue to address. But when you look at the literature, and existing products and concepts, you can see a plethora of different solutions, including a collection of “mesh networking architectures” inspired by defence research.

Often what we perceive as an open question, an issue that needs a solution, actually isn’t an open question at all; occasionally there are well defined solutions which meet our specific needs. If there is a perfect fit for our problem, we can select it and move on. However, this is pretty rare. It is more likely that we will have multiple solutions each of which could be a match.

There are one or more possible solutions

This is the most likely type of answer to get. When you dig into a problem you often see that the issue is similar to problems in other adjacent fields, or that similar, but rarely the exact same problems, have actually been addressed in the past. The solutions to these similar problems become candidate solutions for us. In this case our next step, see Phase 3 below, becomes one of technology selection. We need some way to evaluate all of these solutions and to determine the best fit.

There is no solution at all

This is the most unlikely situation. Even in the first post introducing the research roadmap process when we covered Edison and his quest for a longer lasting filament for his lightbulb, we discovered that Edison he had many materials to choose from. He didn’t need to invent a brand-new material. However, there are rare occasions when a solution just doesn’t exist, or an existing solution is not the perfect match. It is clear that here we need to decide what to do. There are three options:

1. Build: We invest the time and create our own new technology and solution.
2. Buy: We outsource the construction of the new technology.
3. Wait: We “keep our powder dry” and wait for the technology to be developed.

The decision we make is determined by our core business need. The classic build / buy is based on return on investment and strategic importance the technology is to the business or organisation you work for. The wait option, well that’s more about understanding the dynamics of the market place.

Waiting is OK

Generally, the hard work we’ve invested in understanding the trends, and industry we are in, and the vision of the future we want to create will have given us this deep knowledge base. But this can also show us which organisations or communities are working on what technologies. Occasionally we will find that a solution to the problems we need to address doesn’t exist right now, but we can also see that others are working on the same problems. It may be strategically important that we get access to those solutions, but we may not actually need to invent them ourselves. In this case we can wait. Alternatively, we can assist these technology creators by offering to be a use case for their solutions. Here working with other organisations via cooperative research agreements might be the way to go. I will discuss more about cooperative research in a future post.

What did Ford Do

Henry Ford had two big questions to answer to help reduce the cost of his car:

• How can I reduce the bill of materials?
• How can I reduce the time (and effort) to manufacture the car?

We most commonly hear about Ford and time and motion studies about how to reduce the labour required to make a car, but actually this was one of the last improvements. The initial improvements were on simplifying the design, removing components and reducing the complexity of the solution. He focused on one base model, the Ford Model T. Once this was achieved Ford went on to change the construction material, opting for a new steel, vanadium steel, which was stronger and lighter than the steel he had previously used. It was this simplification theme that continued in time and materials studies and how to simplify and streamline the construction process.

From Ford to Apple

I know that the Ford Model T is a world away from the computing and technology industry I work in today, but there are lessons here. The simplification of design is a key one. It helps, in general to reduce the cost of both software and hardware.

I started my career as a software developer and it is somewhat ironic that as a developer all you want to do is to create new software, but each line of code you write, each line that goes into production is an extra burden on you. It is an extra weight, an extra task, because each line of code must be maintained, tested, bug tracked and supported.

Steve Wozniak, the cofounder of Apple in his autobiography “iWos” talks a lot about his passion for electronics and reducing the complexity of a circuit design. He’d work hard to reduce the chip count to make the design simpler. This leads directly to cheaper construction, and a lower price point.

Photo of Steve Wozniak, taken by Michael Fortsch and used under creative commons.

Next Time: Phase 3

In the next post I’ll be looking at Phase 3 – determining the experiments we need to run. But in the meantime, I’ve got some homework for you. Is there something in your organisation or daily organisation that can be simplified, a task you undertake, or a product you use? – Let me know you! You can find me on twitter as @mcwoods, or via linked in.