I live in the Pacific Northwest, the home of Starbucks and many small craft coffee roasters. I like my coffee strong and dark. When I travel, I bring my own coffee and mini coffee maker so that I can enjoy my first cup of the morning just the way that I like it. Yet this week, the coffee I craft with such care tasted thin and watery, and I didn’t know why. I had a Knowledge Gap that was standing between me and my morning wake-up cup.

What is a Knowledge Gap?

A Knowledge Gap is the distance between the knowledge you already have and the knowledge you need to create in order to solve one specific challenge that has arisen in your program.

The word “knowledge” is important here because it serves to remind us that knowledge is the value that we create in product development: we may close a Knowledge Gap for a specific product, and we may also close a Knowledge Gap permanently so that future products can take advantage of the knowledge without having a gap to close.

This is not new: this is exactly what happens in all early development, no matter what a development team or innovation team calls their work. But most product development teams focus on the tangible product, and often a working physical prototype is the primary goal of early development. Yet the team has had to close a lot of Knowledge Gaps to get the prototype to work.

When we manage early product development programs by the Knowledge Gaps we need to close vs. the deliverables we need to produce, we attack the root causes of late design loopbacks because we minimize the risk that an undiscovered Knowledge Gap will cause unanticipated problems in late development. We are much less likely to encounter a problem in late development that delays the program.

This approach encourages us to build reusable knowledge, since that will reduce the number of Knowledge Gaps to close in future programs. Finally, it gives us much greater visibility into the health of the new product and the risks that we’ve chosen to take, making it much less likely that we’ll be surprised by higher costs, missed performance marks or lower quality when the new product approaches its final launch date.

Multiple Approaches to Find Knowledge Gaps

How do you identify the Knowledge Gaps you need to close? It’s best to take a multi-dimensional approach. It’s like cleaning debris from a pool — you need to take several different passes running orthogonal to each other to surface as many of them as possible. Here are some approaches that identify Knowledge Gaps:

• List all the “known unknowns” that you have about the new product: what specifications do you know that you cannot meet with your current understanding of the product?
• Analyze the existing product that is as close to the new product as possible: what makes the new product “new” and different? Where are the gaps between the performance you have now, and the performance you need? What about cost, quality, new features and the user experience? What about waste in your customer’s value stream?
• Look at the assumptions that you have already built into your product’s value proposition. What do you need to do to validate those assumptions?
• Look at late design loopbacks from previous programs. What areas of the product seem to change the most in late development? What Knowledge Gaps went undiscovered until they required a lot of redesign work?
• List the things that you already know about the new product. How do you know them? Is the evidence strong enough or are there still some hidden Knowledge Gaps?

The Inventory of Knowledge Gaps

You may emerge from a series of these discussions with a large stack of Knowledge Gaps. How do you sort, prioritize and track them? What happens when you close a Knowledge Gap — or realize that it cannot be closed? Here are some ways that teams can track their queue of Knowledge Gaps to close:

• Visual planning boards: one Knowledge Gap per sticky note, organized into a visual planning board that shows who owns it, where it is in the process, and what happens with it.
• Simple spreadsheets: lists of open and closed Knowledge Gaps.
• A wall of A3 reports or “story cards” (or a file share, SharePoint site, etc for electronic files) showing each Knowledge Gap and its resolution.

What you don’t want to do: put the activities to close the Knowledge Gaps into a Gantt chart-based project plan. It works much better to keep people focused on the learning cycle to close the Knowledge Gap vs. the activities that should close it.

Closing Knowledge Gaps

We close Knowledge Gaps with the Scientific Method: we develop a hypothesis, design an experiment, run it and analyze the results.

The experiment can be anything from engineering calculations or marketing models to physical tests and human interaction studies. In general, we want to find the smallest, fastest, least expensive way to close Knowledge Gaps. We want to find something we can do with the tools we have so that we don’t get stuck.

How to Avoid Getting Stuck in “Analysis Paralysis”

The biggest challenge with Knowledge Gaps is that you will always find more of them. Some Knowledge Gap investigations lead to many more questions than answers. There will always be more Knowledge Gaps than a team can afford to close. How do you know when it’s time to stop learning, and start building a product?

• Knowledge Gaps should always be prioritized, and the ones that are critical to the success of the product should be flagged as such, so that you know when you’ve got enough confidence in your approach to proceed. Reprioritize when new Knowledge Gaps get uncovered.
• Establish agreements about the scope of the knowledge that you will seek out. While it’s great to develop a lot of broadly-applicable knowledge, the reality is that you may only be able to work deeply in one or two critical areas. Choose your battlefield, and then conquer it so that the next team can go someplace else.
• Establish a “time box” — a fixed period of time — for learning as much as you can, and then work your way down a prioritized list of Knowledge Gaps until time runs out.
• Establish a regular cadence of Rapid Learning Cycles to close Knowledge Gaps: teams have two weeks (up to eight weeks but no longer) to do as much as they can to close a Knowledge Gap, then they need to report what they’ve learned. The firm deadlines provide focus and generate pull to get Knowledge Gaps closed.
• Understand the “last responsible moment” for closing a Knowledge Gap — this may be later than the end of the “feasibility phase” for some gaps. In fact, you can choose to keep some things open to preserve flexibility.
• Establish an acceptable level of risk for the product development program: how many and what kind of Knowledge Gaps can stay open later in development?

Fortunately, a few minutes of leveraging reusable knowledge on the Internet helped me to pinpoint the problem with my coffee: the water was flowing through the coffee too fast to pick up the flavor.

A few minutes more of thinking led me to the root cause: I had brought coffee that was ground for a French Press, but I was using a pour-over filter. The water ran through the coarsely-ground French Press coffee, picking up only the flavor on the surface. Drip coffee is more finely ground to expose more surface area to the flowing water. Espresso is the most finely ground of all, to produce concentrated flavor with a small amount of water.

I knew the coffee grind made a difference, but I didn’t know why. Now I do, and I won’t have to suffer through watery coffee again.