Google the phrase “fast and fun.” You’ll find that this describes things like video games, products for learning languages, and even simple steps for cleaning your bathroom. Whatever your industry, it is hard to imagine the long and tedious process of developing new products—under scrutiny of the leadership of your organization of course—being described as fast and fun though.
Still, if you change your thinking about product development, product development can not only be fast and fun, but provide unimagined value to your company. What smart product development is really about is delivering extremely high-quality products in short, fast timeframes. Let’s see how to do it.
It’s really a matter of coming to learn a new framework for product development:
- Slow down and think. Engage your organization.
- Change your perspective to create knowledge.
- Get rid of things that slow down learning.
- Learn, then execute (the sequence is important).
- Fix your current process (don’t use other people’s solutions).
First, Slow Down and Think. Engage your organization.
You have been on a treadmill, mindlessly working on trying to produce that good new product in the timeframe given by management, marketing, or your boss. How do you jump off the treadmill, or at least slow it down enough to begin practicing a more effective process for product development?
In his 2011 book Thinking Fast and Slow, Daniel Kahneman helps us understand the two thinking systems of the brain. System 1 “works easily and automatically and doesn’t take much effort: quick judgement based on familiar patterns.” This is the system you most likely are currently using to develop products. You are thinking about and working on the next possible solution, and not much thought is going into the development process. What you’re not doing is looking for a more effective way to develop that product in the first place. Your engineers are working hard at coming up with the best solution and are simply using the process given to them, following the steps defined in a staged development process. But a different kind of thinking is needed to create the new product and improve the development process while simultaneously using all the intellectual capability of your entire organization.
To do that kind of thinking takes System 2. Kahneman reminds us, this takes more thinking; it takes persistence, requires refined focus, and operates methodically. I know what you are thinking. “I don’t have time to slow down and think about the process!” Well, wait a minute. First, let’s think about what product development is and why such careful focus is needed.
Change your perspective to create new knowledge.
Product development is about creating new knowledge more than anything else, not new products, yet we manage the process by focusing on tasks. Many of us use some form of stage gate process that has well-defined deliverables to be completed at each gate review. We do our best to complete these in time for a report-out to a steering committee or leadership group. In parallel with preparing for that gate review, we run tests on our latest “Hail Mary Pass,” something that we hope will fix the design problem related a performance or quality problem.
Now, instead of this task-based approach, a wise process for product development instead is focused on attempting to create new knowledge, learning fast, and closing design gaps… and more than this, doing so in a methodical process that harnesses the collective thinking of cross-functional teams. This process should be guided by the questions that need to be answered, this month, this week, and today—all with agreement by the team. Consider the process of product development as being the fastest way of getting answers to the questions that will help you create the right, most robust product. It is about learning fast, very fast. Fast and fun, right? Anyway, fast is important now because you want to get answers to your next set of critical questions.
So how do we stay focused on the right questions and reduce the time? Let’s continue.
Get rid of activities that slow down learning.
When did you complete your first detailed design? What did you know (and not know) about the product when you had your first design completed? How many design versions/revisions do you have? How many changes were made? How much time was wasted?
There are three big delays in most product development processes:
- New directions from management or responding to emergencies causing delays in your current development process.
- Waiting for suppliers to provide components, designing and building new parts, and running tests.
- Rework, Rework, Rework (Re-running tests, making new parts, etc.)…
The idea here is to pay attention to these delays, capture them, and begin running experiments to reduce them. Fast and fun! Ok, not really. But it can go a long way toward reducing the pressure and time to market. Now we’re getting somewhere faster.
Let’s focus on item 3, and why we have so much rework. If much of your time is lost because you are redoing something, this likely means that you did not put first things first. You do not have a process that reduces the delays of rework. Most teams barely have any process at all.
Learn first, then execute.
Think about how much time you lose because you don’t close your gaps in knowledge before you begin your detailed design. What are these gaps? There is the information you need to create a great product. This may include important market information, critical customer needs, required supplier capabilities, certain manufacturing processes, and certain technical requirements based on physics fundamentals. For example, it is important to know when your product will exceed its usable life based on the root causes of fatigue (from temperature, humidity, stress, and force, etc.). I don’t care what industry you are in, detailed design should only come after a thorough and critical exploration of what you know and don’t know about what your design needs to be. Some people use “FMEA - Failure Mode and Effects Analysis,” but often it is done as a task, as part of passing a gate review and is often performed too late, after detailed design. Instead, this should be used as the guide for your learning journey. (For a better understanding of the correct use of FMEA please read the following link https://asq.org/quality-resources/fmea.)
Not so interested in the learning journey for its own sake? I think it’s pretty cool, but ok, just use the following template:
Knowledge Template
| What do we know? | How do we know it? |
| What do we need to know (form of a question) |
What is the fastest way to get to an answer? |
Use this with your team to keep track of your team’s ability to create new knowledge. At the end of the week, you should be able to lead your team in a reflection on their work. Which questions have you all been able to answer? Which actions have been completed? Then create a new template for next week with the next set of questions you need to answer and decide which actions you’ll take to get answers. (Ahem, someone needs to volunteer or be assigned to each action for getting the questions answered).
Fix your current process. (Don’t use other people’s solutions.)
It’s easy to look to other people’s solutions to fix your product development process. Six Sigma, Lean, QFD, DRBFM, Design Thinking, Stage Gate Reviews etc. are all popular “solutions”. There are some good ideas in each of these methods but, if you “deploy” or “implement” these across your organization, then you are imposing solutions, not solving problems. You are only adding these to and on top of your current processes, often adding complexity and confusion.
The alternative is to start where you are now and use value stream thinking and problem solving to make changes to your processes by engaging your team members in improving your current process. Pick a few teams currently in the early stages of development and run experiments on reducing the delays and rework. Structure the process to learn first and only then execute and create a process based on fast PDCA learning cycles. Fix problems by getting cross-functional teams together to perform real, old-fashioned problem solving. Very fun!
Where else is the fun?
Years ago I read the psychologist Mihaly Csikszentmihalyi’s book Flow: The Psychology of the Optimal Experience. We all know the experience of flow. Think about athletes who do remarkable things and how often we describe them being in a “Flow State.” When we’re in flow, we are totally focused, and we lose track of time. When you and your team work together to solve problems fast, this can create the equivalent of that flow state. Csikszentmihalyi says it’s all about setting goals, becoming immersed in your activity, paying attention, and learning to enjoy the immediate experience.
When you do it right, this team-based knowledge creation process for product development is all about this kind of flow. From my experience working with teams in product development, when people are truly given the opportunity to work together at solving problems, are challenged to go find the answers to the most important questions fast, and are recognized for their contributions, everyone on the team goes home after work each night more satisfied and energized for the next day.
Product development becomes focused, more intentional, faster, more profitable, and definitely more fun.