What is Knowledge-driven Product Development?

André Esterhuizen
7 min readMay 29, 2018

“We’ll meet at 10 to discuss some concepts for the new product, and remind the guys to bring their ideas along,” shouts Steve to one of his designers down the hallway. Like most of the development projects lately, this one seems to be very urgent. The team has not had much time to prepare for it and most discussions happen on an ad hoc basis. Today it’s time for the all-important concept meeting, which means the development of the new product will officially kick off.

Steve always manages new projects this way. Developing new products really excites him and he seldom says no to an opportunity. He is a brilliant engineer, but the business has been struggling since he bought it 4 years ago and has lost a few longstanding customers. He is frustrated that most development projects end up under pressure towards the end, leading to compromises and late deliveries. Although Steve knows that the team is working hard, he thinks they work too slowly, even though he never says it in so many words.

The meeting starts on time and Steve kicks it off by asking everyone to share their ideas. Out of all the concepts, one emerges as a clear favourite, in spite of concerns that most of the engineers around the table had relating to the manufacturability of the metal parts. The meeting drags out as they try to find a way to work around the problem, but by lunchtime Steve is restless. “Guys, we have nine weeks to develop the product and another seven to get it into production. If we don’t start tomorrow, I’m afraid we’ll run out of time again. We’ll have to make a decision today. Tooling for the steel option will be quicker to produce, so let’s go for the steel rather than a plastic option. I’m sure we’ll be able to make it work.” The room goes quiet. Everyone can tell from the frown on his face that Steve has made up his mind. There will be no further discussion. The meeting adjourns.

Many teams, like Steve’s, often fall victim to the pressure of development timelines. They think that by making quick decisions to get them started early, they will buy themselves more time. Unfortunately, the opposite is so often true and teams find themselves backtracking at some point, having made decisions based on wrong knowledge or assumptions.

It is a way of doing design or product development that prevent teams from making decisions that are based on wishful thinking…

Knowledge-driven product development is not a process. It is a way of doing design or product development that prevents teams from making decisions that are based on wishful thinking, i.e. a lack of knowledge. It improves the certainty with which teams do their development work, highlighting to them those activities that slow them down and affect their quality. It is best described as a development culture where knowledge is treated as the team’s most valuable resource and where they proactively source and manage knowledge so that it will be available when they need it. Furthermore, the entire team and even the organization, work together to grow their knowledge inventory so that knowledge can be accessed more easily for use during development.

… it influences every step of the process as developers use it to solve problems and make decisions.

Seeing how knowledge influences the product development process is hard because it isn’t really visible. Yet, it influences every step of the process as developers use it to solve problems and make decisions. Every step depends on knowledge, making it, by far, the major constituent in any product. Even the raw materials themselves are products of knowledge.

…see knowledge as a resource.

To appreciate its impact, we need to see knowledge as a resource. What material resources are to the production process, knowledge is to the development process. A lack of resources will almost certainly cause delays or stoppages. With knowledge being a resource that is required in every development stage, developers have the opportunity to use it as a measure or criteria to gauge whether the process is ready to proceed from one stage to the next. Ideally, Steve’s team would have considered whether they had enough confidence in their ability to produce the steel parts, before proceeding with their decision. By deferring the start of the project to do a few tests or some research, they may avoid a surprise later on that could majorly affect the outcome.

Since knowledge is used continually throughout the development process, it can be used to improve project scheduling. By preempting what knowledge they will need for making decisions throughout the duration of the project, teams can schedule the time needed to proactively source the knowledge on time to keep the process on track. Steve is very frustrated with the uncertainty of their development process and knows how quickly the schedule can fall behind. The only way to fix this, in his view, is to give his team more time by starting earlier.

What slows most processes down is not the time it takes to do tasks…

Steve is failing to see one very important truth about product development. What slows most processes down is not the time it takes to do tasks, but stoppages, indecision, confusion, and the time it takes to redo tasks. It would have been more prudent for his team to slow down and give themselves time to review what gaps they have in their knowledge. By considering when they will need the knowledge, they can schedule a window to source it. This may go a long way to make their overall process more predictable and even shorter.

Download Infographic below

Even though knowledge is by far the biggest constituent of any product, it is abstract and has no real substance. Knowledge fuels decision-making and every decision contributes to the development of the product. We call this conversion of knowledge, translation. The development process is a series of recurring cycles where chunks of knowledge are systematically acquired and then translated to reach milestones. Doing research, interviewing customers, doing experiments, analyzing results, harvesting ideas, testing prototypes, etc. are all acquisition functions, while defining requirements and specifications, selecting concepts, building prototypes, doing designs, making drawings, etc. are all translation functions.

Acquisition is about learning and translation is about using the knowledge to make decisions.

The speed and the quality of the development process are highly dependent on the acquisition-translation (AT) cycles. Steve tries to compensate for what he sees as slowness in his team by interfering with the sequence and the timing of their AT cycles. Acquisition should always lead translation, i.e. teams should learn before they make decisions. Steve’s executive decision to go for the steel option, notwithstanding the reluctance of his team, meant that he interfered with the sequence, jumping directly to translation, and completely ignoring acquisition. His team will most likely, at some point, have to backtrack to acquire the right knowledge and in doing so delay the process.

Acquisition should always lead translation…

Similarly, the timing of the AT cycles will also slow the process down. There is no point in starting the design for example, when there is no confidence in the concept or when all the stakeholders aren’t in agreement. Teams often, to keep people busy, proceed to secondary phases without completing the earlier ones.

Acquisition and translation are greatly affected by the capability of the team. Their skills, their processes, team dynamics, leadership, equipment, and technology, will all contribute to the development of the product. Knowledge-driven teams will use every opportunity to maximize the knowledge they introduce into their products. Every activity, every new team member, and every piece of technology they purchase is carefully considered for the contribution it will make to the overall knowledge inventory of the team.

An important objective of knowledge-driven teams is to make their knowledge acquisition processes simpler, more reliable, and faster. Teams waste time acquiring knowledge that was acquired earlier but was lost. Knowledge can be reused, saving teams time and providing them with the confidence of using proven knowledge. Historical knowledge often goes to waste and efforts are duplicated when project folders are dumped somewhere on a network or in filing cabinets, never to be found again. A well-organized and centralized knowledge base will most certainly enhance the speed of knowledge acquisition, especially when care is taken to generalize knowledge and publish it in formats that will make it easily accessible and searchable.

Additionally, knowledge can benefit the entire organization and enhance the effectiveness of all departments. Knowledge is arguably the most valuable resource of any organization and having it officially recognized, at the same level as other departments like production, finances, HR, logistics, etc., goes a long way to ensure that it becomes an organization-wide function. Knowledge managers, for example, can boost the acquisition capability of teams by supporting and encouraging knowledge capturing and by keeping the knowledge base of the organization current and usable. Similarly, knowledge brokers can support teams by helping them search for knowledge, either internally or externally.

Steve’s product development woes are representative of what happens in many teams. Leaders are frustrated and feel that their people should be developing products faster, or they think their processes are wrong or they need better technology. While all these have important roles to play, they should really be looking at how their team intentionally exploits knowledge to drive their development programme.

--

--

André Esterhuizen
André Esterhuizen

Written by André Esterhuizen

I write about the lessons I have learned in Leadership, Change, Organisation Growth, Product Development and Manufacture.

No responses yet