runners on a track
share

Competitive Collaboration:
Brainstorms are too Slow. Here’s a Better Approach.

Traditional approaches to innovation desperately need a refresh. Keeping up with fast-paced product development requirements in the era of hackathons and 3D printing calls for something different. We call our solution Competitive Collaboration.

Heather Benoit

October, 24 th 2019 | 8 minute read

This article has been edited from the original version dated February 2017.

Since I was a bright-eyed college freshman, the brainstorm (routinely followed by the “brain dump”) has been taught as the defacto strategy to ideate and innovate. It’s an easy and low-cost way to pull lots of ideas from lots of smart people in a very short amount of time. But, for all of its merits and successes, the brainstorm does leave some room for improvement. Recent studies have shown that brainstorms lead to social loafing, convergent thinking, and (unfortunately) the soapboxing of senior staff.

There are certain techniques available to minimize these negative aspects, but that’s for another blog post. The fact is, as we move into a younger and faster product development environment (just look at the emergence of hackathons and 3D printing), the brainstorm begins to appear much too slow.

Ultimately, the collection and evaluation of brainstormed ideas takes a couple days, with the outcome often subjective. Complex problems require a strategy dependent on fast iteration – it is essential to determining the core technology or mechanism for a new product.

A couple of years ago, M3 developed a new ideation tactic utilizing the new tools and skill sets of modern product development. Since then, we’ve found that certain projects greatly benefit from this alternative approach, which we fondly refer to as competitive collaboration.

Adapted from the strategy used in MIT’s 2.009 Product Design Process Capstone, competitive collaboration allows our staff to quickly take ideas further than any brainstorm. Part hackathon and part R&D, this process throws our staff into design teams who collaboratively create multiple mockups/prototypes that are evaluated in a competition format.

This process forces the project teams to utilize functional decomposition in order to down select concepts using quantitative methods. The outcome is an evaluation of multiple physical mockups demonstrating viable ideas – much more effective than a few brainstorm sketches. Design teams are forced to concentrate on the quality of ideas, as opposed to the quantity (as in a traditional brainstorm).

 

Here’s the setup:

Determine an objective.

Your output is only as good as your input. Most competent design consultancies will suggest some sort of research phase to determine product requirements. The goal of this research isn’t to fully define all of the specific product requirements, but instead to put a framework in place for making design trade-offs.

In this competitive collaboration setup, this step allows you to determine where you want efforts applied, and most importantly, how you will define success. The big questions are: what are your teams designing and how do they know they’re on the right track?

Build a challenge.

The purpose here is to define the boundaries of the challenge. Teams will need to be given constraints, such as a budget or limitations on the types of parts or outside systems that can be used in the solution. For instance, is it acceptable to assume your solution can utilize vacuum? Are electronics off-limits or ok?

It is also important to create a playing field for testing and evaluating each idea based on the predetermined success criteria. Medical device? Build an analogous anatomical structure. Consumer device? Build a simulated user experience. An equal playing field allows for fair evaluation of each idea.

Build a scoring equation.

At M3 Design, we feel like this is the 21st century version of the brainstorm’s Pugh Chart. It serves 2 purposes.

First, we can stress the importance of certain design requirements by weighing them heavily in our equation. This also gives the inventors a way to prioritize their design efforts. Functional decomposition plays a key role in this stage of the design process. What are the most important/critical design challenges? Make those worth the most points.

Second, it’s a competition! In order to crown a winner, there must be an objective way to determine the effectiveness of the mockup. If everyone knows the scoring methods upfront, there can be a clear numeric ranking at the end of the exercise.

Examples of what might go into an equation: How many points should be awarded for how fast they can accomplish the task? Can they do the competition with limited visibility (fog or blindfold) for bonus points? Does optimizing size, distance, or weight matter?

Make multiple teams.

Best results are obtained by having cross-functional teams or combining people who don’t work together frequently.

We often choose to make as many teams as possible, so we like to make at least 3 teams of 2 people each. We also like to include a small prize (such as a subscription to a design magazine) or trophy to add a little incentive and recognition for the winners.

Let them loose.

After explaining the challenge and giving them a budget, let them solve the solution in any way they choose. We usually like to give them about 16 – 24 work hours to make their mockup.

This requires trusting your staff, which can be incredibly difficult for certain types of managers. It’s important to recognize that the goal here is to explore ideas and let teams navigate the trade-offs on their own, sequestered from outside influences. Even well-intended advice can corrupt outcomes prematurely, especially if it’s a product of expert bias.

Compete.

This step is somewhat self-explanatory. But we’ve found it is much more effective to evaluate an idea based on a mockup, as opposed to a brainstorm sketch.

Bring your teams together and hold your competition according to the rules and scoring criteria you outlined. Let teams get competitive, but decide ahead of time whether you’ll allow real-time modifications to the prototypes.

Repeat.

But wait, there’s more! My favorite part is, there is always an unexpected twist.

In the most recent version of this tactic, we held a second round where all the teams could either iterate or “steal” another team’s concept. Other variants include having a second run with another team operating your mockup/prototype or forcing the prototype to work in an alternative environment.

So why does this work?

First, it narrows ideas down to simple, executable concepts.

Second, there is immediate feedback on the efficacy of your idea.

Last, people like to win.

The outcome is a few ideas that have been down selected via proof-of-concept mockups that are much more advanced than a few sketches from a typical brainstorm.

About the Author

Heather Benoit – Engineering

“Without courage, wisdom bears no fruit.”
-Baltasar Gracian