The innovation process dismantled (part 4)

To conceptualize, prototype, and prepare your ideas for production

Generating and validating brilliant ideas is highly important, but at that stage they are still merely fairly abstract ideas. To fully grasp how they will generate value, ideas must be concretized for us to comprehensively understand how they generate the proposed benefits. It includes visualizing the idea, testing it with users, and designing a value proposition.

This is a crucial phase where the idea gets substantiated both technologically and commercially. The criticality lies in avoiding getting stuck in the “Valley of Death” when ideas transfer from the knowledge economy (research and discovery) to the commercial economy (incubation and production). In practice it means to vindicate design, functionality and commercial applicability to iteratively adjust the solution to enhance its maximum market potential. We will bring the idea from the perspective of the creators to that of the expected market audience without losing its original core purpose.

The purpose of technology demonstration in the Valley of Death.

The conceptualization process consists of two main sub-phases where the first phase aims to further concretize the idea into more tangible output with much more detailed components, and the second phase aims to prepare for the commercialization of the concept. Note that in reality these phases are not sequential, but rather highly intertwined. But for ease of presentation they are here exhibited in a linear manner.

  1. Concept development. Monitoring strategic alignment, defining detailed functionality and requirements, designing mockups and prototypes, and performing user tests.
  2. Incubation. Company administration, setting up administrative and legal support, business development, networking and collaboration, and funding.

Let’s take a look at both of these sub-phases individually.

1. Concept development

This is the concretization phase where the initial idea is brought to become a functional and validated prototype. The purpose is to embody the idea in such detail that it can be tested with users, fine-tuned, and iteratively redeveloped. It requires strategic calibration and a methodological approach to be successful.

1.1 Monitoring
First we must set the criteria with which to measure the innovation’s success rate. These are generally obtained from the innovation strategy or any other similar document that helps to set strategic preferences. By choosing the right criteria for evaluating the concept we are preparing for proper innovation portfolio management as well. All innovation projects should be evaluated and developed based on the directives of the relevant steering strategy/ies.

Other than deciding what to measure we also need to decide how to measure it. Poor measurement of good criteria will still provide poor guidance. Collecting different types of data may require different types of methods for collecting it.

1.2 Functionality and requirements
There are three areas that need to be covered to make the foundation for the prototype solid.

  1. User scenarios. They describe the workflows of the proposed solution, including both the front-end and the back-end activities of all scenarios. They incorporate user stories (or user journeys) at a detailed level.
  2. Functionality. Describes the functionality that happens “behind the scenes” in each scenario. It is not enough for a scenario to say “then the door opens automatically”, it also needs to explain how the door opens automatically. It may be technical at various levels.
  3. Requirements. Describes the special demands on the solution that will influence its design. It may concern such things as security, usability, stability, etc. Requirements may be driven by users or by formal laws and regulations.

1.3 Prototyping
Now we iteratively embody the solution according to the depicted scenarios, functionality and requirements. We successively increase the amount of detailing as we test and learn from the early versions and onwards. We follow the “fail fast” principle to create simple prototypes from which we can learn quickly without having to invest too much time and effort in costly development endeavors. To do this we generally start with cheap and low-quality mockups that are quick to create and then advance to relatively more advanced prototypes that are still very limited in actual functionality but that can more realistically mimic the performance of the envisioned solution. This work is often divided into two key phases:

  1. Low fidelity mockups. Quick and dirty prototypes that are simple and easy to create. They are built or drawn in very simple materials and provide rough, but instant, feedback from users without much effort. Typical mockups are such that they are drawn on paper or built with styrofoam or cardboard.
  2. High fidelity prototypes. Having tested our lo-fi mockups with users we move on to slightly more advanced and realistic prototypes. These are still prototypes with no actual functionality, but that reflect the bonafide functionality of the suggested solution in a more naturalistic and authentic manner.
Low fidelity mockups drawn on paper to simulate the functionality of a mobile app.

1.4 User testing
User testing is actually done iteratively for each version of the mockups and prototypes produced in the previous step. The results of the user tests are what brings feedback to the improvement of each prototype. User tests are not only conducted to receive feedback on if a prototype is usable or not, but also to collect ideas for how the general solution can be improved overall. There are two crucial factors to consider when executing user tests:

  1. User groups. It is highly important that the users chosen for each test are representative for the defined target group(s). Thus the target group must be well defined before testing begins. Developing so called “personas” is usually a good way of enhancing the user definition.
  2. Testing methods. There are many ways in which to perform user testing. They include walk throughs, card boarding, video recording, A/B testing, etc. Each with its own pros and cons depending on what kind of input we are looking for. Your choice of testing method may also depend on the level of innovativeness the solution represents.

Once we have run a number of iterations of functionality definition, prototyping and user testing, we have a more solid foundation to build a business case on.

2. Incubation

When we have run a series of collaborative development- and testing rounds with users we have a better understanding of the expected functionality and the probable market applicability of the solution. For an innovation to bypass the Valley of Death it must prove market interest and projected future profitability, else it will be impossible to ensure funding for the forthcoming development- and launch program. Apart from securing the finances for development and rollout, we must also start organizing ourselves for managing the innovation. We will build on the pre-incubation work conducted in the idea management process.

The stages of incubation as defined by the European Commission and European Business and Innovation (EBN)

2.1 Set up the organization
Whether it is an entrepreneurial (startup) or intrapreneurial (incumbent) effort we will still need an organization to produce, run, own and manage the innovation. We will need to define what people will be responsible for what activities, how administration and legal issues (such as IP) are managed, how they are organized, and what resources they will have at their disposal.

2.2 Business development
Now that we have the basic knowledge about how the concept works and how it is perceived by the target audience we can more readily produce a business plan. We may need some mentorship and coaching, we will need to do some networking, but mostly we need to specify and document the business case for the innovation over time.

2.3 Funding
When we have a fully-fledged business plan at our hands, including an expected growth trajectory, we should have all the arguments to get investment funding for the innovation even if many figures will need to be generally estimated due to the lack of reference points and benchmarks. But now we can make plans for how each phase of development can be funded and so we can start approaching appropriate actors. If this is an internal process within an organization the process may already be slim-lined and prepared with the relevant templates.

And when the concept is finally defined, created and visualized, improved, validated with user feedback, and the business plan, organization, and funding is coming to place, we are ready move the concept to the next level.

Read part 3 Read part 5