MD+DI Online is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Engineering during the “Fuzzy Front End” of Development

Design Concepts Inc. Design Concepts Inc.
The “fuzzy front end” of product development can pose some unique challenges for engineers.

What’s the “fuzzy front end”? It’s the phase between first consideration of an opportunity and when it’s deemed ready to enter a structured development process. A common characteristic of the “fuzzy front end” is the desire to create and evaluate multiple concept alternatives on the road to selecting a single preferred approach.

It’s pursuing multiple concepts that often pose a special chicken-or-the-egg challenge for engineering because you:

  1. Don’t have a complete design to assess feasibility.
  2. Can’t fully assess feasibility without a complete design.

This dilemma means engineers must thoughtfully assess competing concepts to identify areas of high risk. They also need to perform sufficient engineering to prove/disprove that a concept can be made to work during a subsequent engineering phase.

By nature, we engineers are a cautious lot. But during the fuzzy front end, engineers must balance the need for caution and skepticism with the need to take and accept risk. A well-run fuzzy front end can ensure alignment on communication and acceptance of risk.

One valuable tool engineers can rely on during the fuzzy front end is the Concept Failure Mode Effects Analysis or Concept FMEA. Most engineers will be familiar with FMEAs but are used to seeing them used much later in the development process. During the fuzzy front end, the objective of a Concept FMEA is to use the collective wisdom of the design team to identify and prioritize aspects of the design, which might prove to be roadblocks during a subsequent development.

All design programs will end up working through challenges during engineering development, but the objective is to avoid selecting concepts that have fatal flaws. Without complete engineering, identifying possible conceptual flaws requires intuition, experience, and discussion, and the Concept FMEA can be a valuable tool for bringing high-risk areas to the fore. Aside from the typical severity, probability, and occurrence ratings found in an FMEA, for the concept FMEA, engineers will want to focus on aspects of the concept where:

  • There are no predicates or other examples of similar technologies in the market.
  • The concept requires developing new materials or manufacturing processes.
  • There are significant size, power, kinematic, thermodynamic, or strength challenges.
  • Failures could occur in an area that would be difficult to “tweak” or modify.
  • Failures might occur that would be difficult or impossible to test for until final products were available.

Once the high-risk areas of the concept have been identified and prioritized, the team can allocate precious engineering resources to mitigating the highest risk areas. Unlike a formal development phase, the trick is to perform sufficient engineering to convince the design team that there is a decent probability that the concept can be made to work. It doesn’t have to be fully engineered—in fact, there’s often no value in fully engineering concepts that might not be pursued for other marketing or business reasons. But ideally, the engineers will be able to clearly convey the advantages and risks, with sufficient engineering rigor to be able to assess the probability of success.

Adopting optimism as an approach to analysis

During the fuzzy front end, the development team is assessing the viability, desirability, and feasibility of various concepts. All three need to mesh for the launch of any successful product—from a tennis racket to a proton therapy suite. While business strategists and marketers often work on the viability and desirability portions of this triad, engineers are focused on feasibility. In other words, can this concept be made to work as intended?

To be an effective team member during this conceptual phase, engineers need to add a layer of optimism to our natural pessimistic skills. We need to go beyond hunting for ways that the concept could go wrong and forecasting the make-or-break decision points. The other questions we need to ask are:

  • How can I make it work?
  • How can I test it quickly?
  • What’s my backup plan?

It’s the engineer’s responsibility during the conceptual development phase to accurately communicate the level of risk and compromises to the team’s decision maker without bias. The challenge is to truly empathize with and stand in the shoes of that decision maker, so you understand the risk threshold and what compromises are important. To be successful in your role, you must get the design direction you need to be able to move on to the next phase of development.

If your attitude is in the right place, then all of this will come naturally. It involves:

  • Having empathy for the end-user.
  • Paying attention to safety concerns.
  • Being a good steward of project resources and budget.
  • Checking your gut to see if the project is in the best long-term interests of the business.
  • Showing respect to other designers during design reviews.

In other words, engineers—balance your pessimism with optimism that helps keep feasible concepts moving forward. The rest of the development team? As engineers, we are about making ideas into reality, so most of us aren’t comfortable in Fuzzyland. Mutual respect and patience goes a long way.

At BIOMEDevice Boston on Thursday, April 19, Franchino presented, "At the Fuzzy Front End, How Much Engineering is Enough?", which focused on the unique role that product developers play at the beginning of the development process.  

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.