Brainstorming is dead. May it rest in peace. Thankfully, there is a better way. Whoa, you might say. Brainstorming is tried and true. We are an innovative company and brainstorming is what we do. My question to you is, how well has it been working? Let me backup a bit.
A few months back I was stuck on a design problem. I needed a solution and I needed it quickly. What was an engineer to do? Brainstorming session. I called in a few of the other Mechanical Engineers, described my problem and the necessary constraints, while still leaving some wiggle room to generate new concepts. Over the next 30 minutes, we came up with over 20 clever ideas, most of which sounded like gold. They were creative, clean, and potentially simple. I dutifully went back to my desk and started sorting through them. Hmm, this one won’t work because it blocks a required interface. Trash. This one won’t work because…well, you get the idea. On and on. Within an hour all of the ideas had been scrapped for one reason or another. The brainstorm session itself was a success, we generated a ton of ideas quickly, but why couldn’t I get any workable ideas?
Over the next couple of weeks I did some more thinking and some research. After reviewing blogs, talking with other engineers and designers, reading books, and listening to audio-books, it seemed like this was a common problem. Even in my past experience, I couldn’t think of too many instances when brainstorming sessions generated winning ideas. They’re just too short. Too haphazard. More often than not, it was days of working the problem from multiple angles that proved the most successful. It was time to abandon brainstorming in favor of something more practical.
For that matter, it occurred to me that how you approach problems should vary over time, depending on the project phase. Earlier stages of a project can (and should) be more flexible, more adaptable. Early ideation needs to be fast, out of the box thinking. It forces new solutions and allows a project team to change quickly as product requirements are fleshed out. However, as time goes on, problems become more specific and changes to a design more expensive. Solutions cannot redesign a product without causing delays and cost increases. As such, they need to be more targeted. Furthermore, problems need to be identified as early as possible. Your customers should not interact with your product for the first time as you launch it. Test early, test often. With this thinking in mind, I came up with a plan. A mental model of sorts for how to think throughout a project:
Stage 1: IDEATION
In this stage, speed and adaptability are king. Use techniques like 1 week Sprints (www.thesprintbook.com), storyboarding (https://en.wikipedia.org/wiki/Storyboard), and other lean and Agile techniques to generate proof of principle prototypes. More importantly, put these prototypes in front of your customers. This means not just end users, but maintenance technicians, sales people, and administrators. Basically, anyone who is going to touch your product. This doesn’t need to be a week long endeavor. A 1-day user test with 4-6 people should suffice and keep the logistical burden low. Steve Krug does a great job explaining how this could work (http://www.sensible.com/rsme.html) Plan, build, test.
Stage 2: DEVELOPMENT
At last, you have a list of features and a proof of concept prototype that you and your customers are happy with, now what? It’s time for a deep dive. This is when you want to get into the nitty gritty details of your design. Move away from Sprint-like activities and get into the design details. At this point, reserve Sprints for when you need to solve a big problem. Do the engineering analyses. Do some bench testing. Whatever it takes to get a reliable product, but you have to be careful to watch for scope creep here. Now is not the time to add to your product. Think Minimum Viable Product. Let me explain what I mean.
Your MVP is not the least functional thing to go out the door. Whatever is on your product has to work, and work very well. Despite what people say, you cannot fix your product later without losing customers. Just think Windows OS. However, as long as your features work almost flawlessly, you CAN go out the door with limited features and add them in at a later time. This is not fixing, it is increasing functionality to get a wider customer base.
That’s great, you say, but how do you know when enough is enough? The answer is simple: user testing. About every 1-2 months seems to be about right. More frequently and there isn’t enough time to get a working product. Less frequently and the design progresses too far without being checked. Again, you don’t need a week long study, just a day activity with 4-6 users. Eventually, you will arrive at a product that satisfies both engineering and the business folks. So, it’s on to the next stage.
Stage 3: USER SUPPORT
At this point, you have a manufacturable product. It has been thoroughly vetted by engineering, tested by users, and approved by the product team. Now it’s time to launch. Big launches are expensive, especially if they are poorly planned. Furthermore, there always seem to be production delays, missed timing, and other issues. Instead, I advocate a limited, but well publicized launch. Let your customers know, but use the smaller launch to perfect your marketing, get the word out, and give word of mouth time to take effect. Low quantities (low supply), plus a salivating customer base (high demand) equals a very profitable product.
CONCLUSION
All this being said, I am still a fan of brainstorming. It is a valuable tool to get you thinking outside the box, though it may not directly generate a usable concept. Instead, focusing your thinking as it is related to your product development stage has proven highly effective for me. Hopefully, you find this the case as well. As you try this, please comment below and let me know how it went. What went well? What didn’t? What would you do differently next time? Hopefully, you will enjoy trying this as much as I did.
Originally posted August 20, 2016