There is a spectrum of product development methodologies with two in particular that we would like to compare and contrast: Design By Analogy (DBA); and Knowledge Driven Product Development (KDPD). DBA is a “feel good” approach that satisfies one of the very basic tenets of good engineering, namely “don’t reinvent the wheel”. This also satisfies the sense of urgency that goes with one of the three basic constraints on all development projects: schedule; budget; performance.
The comfort level with DBA seems to increase with the experience level of the development team. More experienced teams are often totally at ease with experiential learning and more inclined to rely on that experience. Similarly, the less in touch they are with their hard-earned engineering skills the more intimidating is a data-driven, analytical, process. In a DBA mode, the development team tends to rely almost entirely on experiential, tribal knowledge and hope that this knowledge is applicable to the current functional requirements.
Typically, this approach begins without careful consideration of the requirements, little or no consideration of what the requirements really mean in terms of design decisions, little or no analysis, and a rush to prototyping.
Sometimes this works – often it does not. And when it fails, the exact reason(s) for the failure are likely not readily apparent. This can set-up a situation where the team falls into a design→build → test →iterate cycle that drains financial resources, human resources and – often most importantly – time. Furthermore, it is all but impossible to predict when such a process will converge.
The alternative to a DBA method is one that takes a more data-driven approach to the development process. This is known as a “First Principles” based approach to product development and engineering. This approach, also called Knowledge-Driven Product
Development (KDPD), blends analytical and empirical data to arrive at a more complete, objective, understanding of the design.
This is the approach that we employ at FPrin. Specifically, we perform analysis, modeling, and test to determine strengths and weaknesses of the design and use that to map an informed approach to design development. This tells us where we need to focus our efforts – specifically on “make or break” design elements – and where we can afford to defer closer scrutiny. It allows us to put the right resources on the right problem at the right time.
While this approach can be used at any time in the design cycle, it is best employed starting at the very beginning of the process, after the concept of the design has been articulated and a Market Need has been described – typically in the form of a Market Requirements Document (MRD). An MRD expresses an ambition – i.e., performance and functional goals – and defines constraints such as size, weight, cost, useful life, end-of-life requirements, target market, and market opportunity, etc. The initial KDPD effort, at this point, may require two or three weeks of effort and is comprised of a series of steps that will be covered below.
These up-front efforts are analogous to the method that one might follow when beginning a journey where you know your starting point (current design or technology status) and where you need to end-up (say…a successful DVT, Validation, Product Launch and Commercialization).
You could begin the journey by grabbing a map, taking a compass reading and stepping forward in the general direction of your desired endpoint. You may have an idea where you are and where you want to end-up but very little knowledge about what lies in between. Is it a smooth unimpeded path to your goal? Or is the path fraught with obstacles, of which you are unaware, that will force you take a tortuous, inefficient path to your destination? Even worse, are you going in the wrong direction entirely, or in the direction of insurmountable (i.e., “violating laws of physics”) barriers?
At FPrin we advocate a better approach to your design journey. Rather than heading off immediately towards your destination we recommend taking time at the beginning to assess the “lay of the land.” We make effort, up-front, to get to the figurative high ground – a vantage point – so that we can “see” the endpoint AND the route. We want to anticipate the “uncrossable rivers,” and the “box canyons” of the development process so that we can avoid, or at least anticipate, where it will be difficult and where it will be easy. Most importantly, we want to put ourselves in a position to minimize the former and exploit the latter. We see the upfront effort associated with a KDPD approach as being the way to get to this “high ground” that will allow you to optimize your future development efforts.
Next week, we’ll explore what those steps look like.
About the authors
Fprin is a group of inquisitive engineers, designers and innovators who take a First Principles approach to product development. We dive deeply into the “why” to solve hard problems, help develop breakthrough products, and bring those products to market. Blending analytical and empirical data provides assurance to our clients. Learn more at fprin.com.