Speed of Innovation – How to Master Rapid Prototyping

By: Langdon Morris

In the disciplined and structured process of innovation we search for unmet needs and unfulfilled desires, and when we think we find them we have to construct a sort of a mental map that defines why our proposed solution will be better than whatever currently exists. We may use the business model map to show how we’re using this innovation to move up and to the right, or we may use the customer value ladder to show how this innovation provides differentiated value. And once we’re convinced that our idea is a really good one, the next step is often prototyping.

Those who can sketch, build, create maquettes, and quickly create elegant prototypes are also essential in helping us transform ideas into possibilities and then into testable artifacts. Prototypers are people who like to make things, and prototyping well is an essential contributor to the speed of your innovation efforts.

This is where we translate product and service ideas into tangibles that we can see, touch, taste and smell (especially if it’s food), and certainly use. This step is critical to transforming concepts into a workable form that can be evaluated not only for fit with the needs and desires of customers, but also for manufacturability and packaging, or service delivery, as well as for design refinement and cost modeling.

A prototype is in fact an experiment, the purpose of which is to determine what works and doesn’t work.

The principles of experimentation in the sciences is defined by the scientific method. It’s an activity done to “try something,” and in a rigorous setting every attempt is made in relation to a specific hypothesis about what the outcome will be. The scientist explicitly predicts the result before conducting the experiment, and then compares the results with expectations to discern the validity of the hypothesis. The progress of science therefore comes as a result of failures and successes, where outcomes are compared with expectations, and an explanation for the causal connection is provided in the form of an underlying theory, and then validated through subsequent testing.

The predictions you make in relation to the driving forces of change thus constitute the hypothesis; the actual outcomes are the experiment, and the accuracy or inaccuracy is the evidence of reality. The quality of the learning outcome is defined by the prediction > test > result cycle because it forces each person to make their assumptions explicit, and therefore discussable.

Edison’s famous experience with the light bulb illustrates the necessity of systematic failure, and also the social myths that grow around it. In looking for the best material for the light bulb filament Edison’s team tested a lot of materials; most of them, of course, didn’t work, or didn’t work well.

When he was interviewed later, he was how he felt about “failing so many times.” The journalist was of course expressing the common attitude that an unsuccessful experiment must equate with a failure, and therefore with disappointment, a value-laden viewpoint about the stigma failure and the joy (and necessity) of success.

But Edison interpreted the process much differently. They were not failures in his mind, because with each one the research team had learned something specific. Identifying such a difference of perspective, and exploring the underlying values and experiences that would lead anyone to one or the other attitude about experimentation, success, and failure, is exactly the sort of thing that would interest an ethnographer; it is definitely tacit.

Collaborative Design

Another way to help a team is to structure its work as a disciplined process of inquiry. To innovate together, people have to work together to apply their intellectual abilities to situations of novelty.

Collaborative design occurs when people work together so that their different points of view, bases of experience, and knowledge of the problem and its context can be blended together to yield actionable solutions. Collaboration can involve two people, ten, one hundred, or an entire organization, and it can occur in many settings, and carefully designed and facilitated collaborative processes can lead to comprehensive solutions, in much less time, compressing months down to days or weeks.

Leverage the critical insights of even people who are idea killers by using their healthy skepticism and constructive criticism…

The goal is to enable 100% of the people to be idea generators and promoters, and to leverage the critical insights of even people who are idea killers by using their healthy skepticism and constructive criticism as creative inputs rather than allowing them to suck all the energy out of the creative process through their negativity.

Sometimes it’s also necessary for a team to put a problem aside for a while, giving potential solutions time to incubate. Former Nissan USA design chief Jerry Hirshberg notes, “Disengaging from an involving task, one with which we are not yet finished, does not amount to abandoning it. Quite the contrary. While conscious focus shifts elsewhere, the subconscious continues grinding away, considering anything that comes its away as grist for the mill. And that grist, defined as anything that that can be turned to an advantage, might be found anywhere. Our preoccupied minds will mine any new activity, sifting continually through it for previously unseen connection, for bits and parts to fill the nagging void of an unfinished, unresolved question.”

It’s also important to overcome the tendency of people to avoid controversy in group settings, which Irving Janis labeled “groupthink.” Controversy is important in creativity, but group dynamics normally suppress it in favor of congenial interactions because there is strong group pressure not to “rock the boat.” When you’re dealing with complexity, however, rocking the boat is often absolutely necessary, so skillful facilitation can stir things up sufficiently to actually prevent a group from settling for easy solutions that … don’t work.

In fact, one study of the group process in a complex problem- solving situation showed that while the group came to a solution very quickly, they almost immediately discovered that it wasn’t really a solution at all, so had to keep working. In total, they oscillated between dialoging about the problem and considering alternative solutions for some time, and along the way they eventually had considered eight possible options before finally deciding that the ninth would actually work.

Innovation Networks

Most effective organizations function as a combination of centralized hierarchies and distributed networks of semi- independent but connected nodes.

Hierarchies are effective for top down, large scale, piloting and implementation programs, but networks are good for innovation because they proliferate multitudes of experiments, testing them in ad-hoc fashion, and distributing the best in self-organizing cascades.

A culture of innovation works more like a network, composed of many people from throughout an organization and quite a few from outside of traditional boundaries, including customers, students, suppliers, community members, and even competitors. In successful and vibrant innovation cultures, the number of members from outside is likely to be greater than from inside.

Like Amazon, some aspects of an innovation network should come from the center and pervade outwardly.

Like eBay, networks allow individuals to interact directly with one another and exchange ideas.

Like Wikipedia, networks allow everyone, insiders and outsiders alike, to contribute as peers in an asynchronous way to the creation of something larger, and results in a product is something that all of the users can examine and gain value from.

And the network enables subsets of users to form sub-networks to focus for various durations of time on specific projects, so it takes on some of the characteristics of a project management intranet.

Creating innovation networks that don’t exist but should, and facilitating existing networks to become more effective, are two key roles for organizational leaders.

Networks coalesce around the exchange of something of value, and while trust and self-reliance are the foundations of the innovation culture, the results are produced as a result of exchange.

To be effective, network users apply tools to evaluate ideas and idea makers. On eBay, any buyer or seller can see how other buyers and sellers rank – whether they’re trustworthy or not. The community thus evaluates its own members, and the quality of the services and products that they each provide to one another. Amazon enables shoppers to rate products and to rate the value of each other’s reviews.

With tools like these it’s easier to find popular ideas based on their interest rating. But popular ideas then become more popular, so to allow backwater ideas a chance in the spotlight, innovation networks also need to employ a capability for randomness. As users browse through idea lists and user profiles, they should find not only with the most popular ones, but also with a random selection of new or not-so-popular ones as well, to bring forth obscure ideas that may have merit.

This is because the most useful information in a network is densely interconnected, so if someone comes up with an idea for an innovation, others must be able to see how this idea connects to other ideas and other people.

The final destination for ideas is at not the feet of senior management, but other members of the network, which includes senior managers not as spectators or judges, but as users & participants.

In large networks, individual users are thus not only posting ideas for other people to try out, but also sharing ideas that they intend to experiment with themselves, or ideas they’ve experimented with already. The network isn’t some big suggestion box, but a living, learning record. And the final destination for ideas is at not the feet of senior management, but other members of the network, which includes senior managers not as spectators or judges, but as users and participants.

The Minimum Viable Product

In Silicon Valley, and elsewhere of course, new approaches to starting and growing companies are always being tried, and recently a set of principles has been defined by Eric Ries and documented in his fine book The Lean Startup. One of those principles is the notion of the “minimum viable product.”

That is, what’s the fastest, quickest thing you can put out in the market that would indeed be viable as a product, and which will enable you to learn how potential customers and actual customers feel.

Minimum means that you don’t have to load it up with features that aren’t essential, even with features that you know may be needed later on.

Viable means that you don’t just trust the judgment of the product design team; you actually put the product out there in the market and see how people really respond to it.

A-B Testing

Ries also describes the process of split testing, or A-B testing, which simply means creating two versions of a product and testing both in the market to see which is more attractive. A structured series of A- B tests can yield tremendous insights, eliminate a lot of guesswork, and neutralize a lot of ungrounded opinions.

Agile: The Scrum and the Sprint

In our book Agile Innovation, Moses Ma, Po Chi Wu and I defined an approach to business management and innovation based on the core principle that speed very often wins, that the innovation process must therefore speed up, and that a very fine model for how to do this has emerged in the software development field through a management technique called “agile.”

Agile is a software development process that was developed by a small team of programmers who justifiably became quite frustrated with the chronic failures of small, medium, and huge software development projects. Indeed, as programs and projects have become more and more complex and ambitious, the failure rate has grown to epidemic proportions. It is a popular sport among technology writers to lampoon the massive and highly visible failures, such as the state of Oregon, which spent $134 million on a health care insurance exchange before giving up on it, the US Internal Revenue Agency that spent $8 billion on a project that was abandoned, and a $600 million baggage handling system that was built for a new Denver airport that never worked.

While the creators of agile technique may not themselves have been directly involved in those specific disasters, they certainly had experienced the deeply frustrating techniques used to manage big projects that so often led these projects astray. This is a profoundly important insight that must be emphasized – traditional project so often fail because of how they are managed.

Hence, it’s not a failure of the people, it may not even be a failure of the underlying idea, or the goal, nor is it even a misperception of the customer need. It’s the very way that the work was organized that causes the projects to fail.

Their obvious conclusion was that work must be organized in a different manner. Simple, actionable, and profound. But how? Aha, the multi-million dollar question!

The inventors of agile came up with a powerful set of tools, a compelling how, and one that works. They realized that it was the traditional techniques themselves that resulted in the failures: the very methods for managing software development were just plain wrong, and were creating the opposite of the intended results. Instead of great work, traditional management produced boondoggles. Instead of on-time deliveries, they got massive delays. Instead of reliable budgets they got huge cost overruns. Instead of success they got failure.

And it was not just an isolated few projects that went bad; it was a trend across the entire industry that extended across every geography where code was being written, and which endured for decades, only getting worse and worse as projects became more critical and more massive. Huge, essential infrastructure project collapsed – health care, infrastructure management, public administration, etc. etc.

And so they set about to create a better way. The solution they invented they called agile, because they knew it had to be fast and efficient, and now it’s being used more and more widely for the very obvious reason that it works stunningly well.

However (and there has to be a however in a story like this), implementing agile requires some tradeoffs that are operationally and conceptually challenging for those who manage software development projects. Specifically, in order to make agile work, managers have to give up the usual techniques they use to control these types of projects, and instead to trust a process that is largely self-organizing and self-managed.

Of course this is exactly what programmers want – to be left alone to write great code. But it’s definitely not how managers are accustomed to working. After all, what job do they have if every project largely runs itself?

Nevertheless, the bold and the brave have proven how well agile works, through indices like development times cut by half or more, and quality double or better, and failure rates negligible, not on every project, of course, but on a significant and impressive majority.

…that need for management oversight is precisely the factor which leads to the failures.

The underlying discovery, of course, is that need for management oversight is precisely the factor which leads to the failures. The instinct to control, that is, becomes the fatal attraction.

The essential work of agile is done by a team of people called a scrum who work in a process called a sprint. These are the two core elements necessary to organize people to achieve goals that require highly coordinated team work in complex problems where there is value in speed (and there is always value in speed).

So of course this is relevant for you, the small business leader who is setting out on the innovation journey, because you can easily and very successfully create innovation scrum teams and organize their work into innovation sprints to bring impressive speed to your own innovation process.

In case it’s not obvious, I should mention that agile borrows the notion of the scrum from rugby, where it refers to an ordered formation of players who lock arms, put their heads down, and push forward against players from the other team who are doing the same thing. Scrums occur frequently during a rugby game, as they are one of the main elements of a typical contest. Teams are considered superior because of their strength in the scrum and thus their capacity to push forward against enormous obstacles, i.e., the other team that is pushing back nearly as hard.

Similarly, the word “scrimmage”, derived from the word scrum, describes a basic concept of American football, where the meaning is the same. In American football, the starting point of every play is the “line of scrimmage.”

Scrum is a useful metaphor for software development teams who “puts their heads down” and blast their way through writing a given module or section of code, all the while striving toward a final product which may be larger and much more complex, but which has been broken into addressable increments.

As you look to design your innovation process, you’ll naturally give a lot of though to who ought to be on the scrum team. Please pay attention, then, to a key element of the agile process, for they’ve done something profoundly smart here – they include the customer in the scrum. Brilliant thinking, that, because what the customer brings, of course, is the intimate knowledge of their own needs, the deeper context in which an innovation must become relevant.

Any product specification, or software specification for that matter, no matter how detailed, can never capture the full scope and extent of that context, largely because so much of the necessary information is hidden, unarticulated, unrecognized. The customer, however, lives inside that context and knows it not as an external, intellectual concept, but rather as a fundamental aspect of their own existence. Consequently, a customer knows instantly and intuitively when a given function or feature or element is essential, and when it is extraneous.

So including the customer as a member of the scrum team is a clever way to assure that this essential knowledge is constantly and immediately present throughout the process.

Another of the key features that distinguishes agile from traditional long-cycle, large scale software development projects is that scrum teams organize their work into short segments that generally last two to four weeks each. These segments are short enough to be termed a “sprint,” a short foot race that is a contest of speed, as compared with a longer race such as a 10,000 kilometers (10k) run or a marathon (26.2 miles), which is a test of endurance. The sprint is thus one short portion of a much longer process, a single play in the midst of a longer contest. A sprint is long enough to make meaningful progress, but short enough to sustain clear accountability, maintain focus, and identify and achieve specific deliverables that are already meaningful.

While mega-software projects are very much like marathons, or even 100-mile long ultra-marathons, agile sprints consist of small, digestible portions. And since agile projects are broken into sprint increments, a typical large project may require dozens of sprints to reach completion. Hence, instead of running the marathon in one continuous race, it’s like a marathon composed of 26, one-mile long races, or 104 quarter-mile sprints.

What are the advantages of that?

First, because a given chunk of work is expected to be completed in a series of sprints, the work process can more readily be controlled. At the end of each week progress is assessed, and plans are adjusted based on whether the scrum team did, or did not, get to their goal for that period.

This ensures constant feedback, which allows the opportunity to fine-tune the process from sprint to sprint. Is someone on the team doing exceptionally great work? What are secrets that the rest of us can learn from that person?

Conversely, is one team member lagging consistently behind? In that case, what do we need to do to improve their proficiency?

When the results of each sprint are there for the entire scrum team to see, fully evident, fully documented, and fully transparent, procrastination is not tolerated.

Second, teams can track their progress sprint by sprint, and readily assess incremental progress toward the final goal. This is important because, in classic (and failed) software projects, programming teams often fall into the trap of telling themselves that “they’ll make up the lost time later in the year (or next year).” In reality, these projects tend to fall farther and farther behind. Ironically, the underlying complexity and massive project management overhead obscure these realities, reducing accountability.

The concepts of the minimum viable product and A-B testing are relevant here, as they provide guidance for what each sprint may be designed to achieve.

The concepts of the minimum viable product and A-B testing are relevant here, as they provide guidance for what each sprint may be designed to achieve. It’s makes a lot of sense to design a work process to get to the MVP as fast as possible, knowing that other layers of detail and functionality will be required if the MVP is indeed viable, that is, if customers like it.

And if they don’t like it, it’s easier to shift directions, or abandon it entirely, and thereby save precious resources.

Third, since each unit of completed work is done in collaboration with clients or customers, the scrum team receives valuable feedback directly from actual end users while working collaboratively with them. This process optimizes learning about the value proposition and thus enhances the pursuit of viability, while unpleasant surprises are reduced or eliminated altogether. No client of an agile project was ever “shocked and dismayed” by the final results, because they were right there with the team, step by step.

Doesn’t this sound like the way innovation projects should be pursued? Exactly!

So while the variety of activities in a typical innovation project will likely be far greater than in an agile programming effort, the principles and the practices are entirely consistent. Innovation projects can be organized into multi-week sprints, during which specific deliverables are planned and expected to be accomplished, and the work is managed accordingly.

Uncertainty

Given the high degree of uncertainty inherent in innovation projects, at any point in the process three possible outcomes could result:

• The completed ideas-become-innovations will be brought to market, if the feedback shows that they constitute compelling value propositions in the market.
• Some ideas will be discovered to be lacking in some fundamental aspect, such as insufficient market need or demand, or insufficient functionality. These will be set aside, archived, and we’ll move on to other ideas, having learned all we can from this experience.
• Some ideas will remain promising, but the timing for their introduction seems to be poor. These we will set aside for consideration another day.

There are only three possible outcomes: success, abandonment, or postponement.

The problem, of course, is that at the outset, we don’t know what the fate of a given idea will be. Those we consider at the outset to be “best” will get resources, time and effort precisely to figure out what we do in fact have.

Further, a key principle embedded in agile and in innovation is that the problem being addressed may not at any time in the process be fully understood or defined. Innovation projects constantly deal with this exact form of uncertainty, and the more ambitious and far- reaching the goal, the more likely it is that the problem itself may remain undefined, and sometimes undefinable, even as progress is being made.

Consequently, innovation teams must create a learning system much like the agile sprint, an iterative process through which problems can be defined in progressive levels of detail through multiple iterations of work.

Technically, however, each problem is not being “defined,” but rather it evolves into creation. And thus in our experience, the first major act of any significant creative process is precisely the creation of the problem.

The process of solving problems through the act of design begins with vision. “A compelling vision, well expressed, is one of the most powerful of forces in human society. It sets up the contrast between what is and what could be, and in this contrast emerges a driving force, a compelling motive. This contrast is the source of creative tension, the energy that drives visionaries, whether they are artists or scientists or entrepreneurs or educators; missionaries or presidents or revolutionaries or parents. … If you do not somehow take action to fulfill the vision, it will remain in the vague and distant future, inconsequential. But once the quest for fulfillment is begun, this vague future is given distinct shape and form in the present and offers possibilities that once were only dreamed of. In this regard the fulfillment of a vision transcends time. The vision and its contrast with the current condition has, in effect, created a problem.” 21

Because customers are essential participants in both the Agile Software and the Agile Innovation processes, the results of sprint efforts are tested rigorously and repeatedly in real world environments where customers experience what we offer and evaluate and give feedback. Hence, uncertainty is gradually replaced by awareness and knowledge of what works, as well as what does not work. Both types of knowledge are highly valuable.

The intent of the innovation process is to transform ideas into working prototypes and their associated business models, and to do as fast as possible.

Taking Action

Once you’ve identified some promising projects, put a team together and set an ambitious goal. Then give them a lot of support and coaching so that they can begin working productively. Encourage speed, which means that you may have to remove obstacles that impede them.

Remain open to feedback and suggestions, and make sure that everyone knows that learning is essential and that fast failures are preferable to slow ones.

By Langdon Morris

Photo: Making Models In Office from Shutterstock.com