Slow down and think about requirements
As engineers, there is always a temptation to dive right into design and building after a project kicks off. It’s a mistake we’ve seen on countless projects when well intended engineers want to make progress fast. At this stage, your best bet is to heed the advice of mega project expert Bent Flyvbjerg to “think slow and act fast” instead of thinking fast and acting faster. That’s why we always recommend starting with a simple product requirements document (PRD) to help align everyone on the project and get all stakeholders oriented to what exactly you are developing.
When sketching out your initial PRD don’t worry about being perfect, just get started with what you know (or think you know) and keep updating it as you learn. Understand that your PRD will always be a working document.
A good PRD development process will help you and the broader team understand the following:
- Definition of Purpose: The PRD is the central repository for what the hardware product is supposed to accomplish. It sets out in clear terms the objectives of the product and the problems it's supposed to solve.
- Functional Requirements: A good PRD defines exactly what the product should do and how it should perform, but not how it accomplishes this technically. If you can’t define the desired function at a high level, its dangerous to start designing.
- Design Constraints: Every hardware product has certain constraints, such as cost, size, power consumption, or safety standards. A well-prepared PRD will identify these constraints upfront, ensuring that the product's design and development stages take them into account.
- Stakeholder Communication: A PRD acts as a common language among stakeholders, which can include engineers, designers, marketing staff, executives, manufacturers, and even end-users. By establishing a clear vision and requirements for the product, the PRD can help to avoid miscommunications or misunderstandings.
- Risk Mitigation: By documenting and prioritizing features and requirements, a PRD allows for potential risks to be identified early in the process, enabling proactive risk mitigation.
- Quality Assurance: Finally, a PRD provides the basis for testing and validation, forming the criteria against which the final product can be evaluated to ensure it meets the intended specifications and quality standards.
Tackle the biggest risks first
Development of your PRD will naturally start to bring key functional requirements and their associated technical risks to the forefront. You should evaluate and prioritize these risks and then build your project plans accordingly. Practically speaking, this means breaking your development activities down into a stack ranked list of “big bets.” From there you can decide what level of design, analysis and/or prototyping is necessary to de-risk each big bet. If you stay focused on de-risking in the correct order, it ensures that your design team has the most flexibility (and fewest constraints) when tackling each technical challenge.
Note: The plan you develop should de-risk these big bets in a prioritized order that considers both the degree of risk and impact.
Don’t rush through concept development
The trend we’ve seen in hardware product development is that the concept development stage tends have the least focus on engineering rigor, and yet it is perhaps the most impactful period of decision making in the lifecycle of any product. Decisions made during concept development tend to lock in a large percentage of development and support costs regardless of all engineering decisions made downstream. Because there is such a premium on these decisions, we recommend exploring concept spaces fully. Here are some tips to help your team do the same:
-
Brainstorm effectively to get a broad and deep exploration of the solution space.
-
Post-process your brainstorm ideas thoroughly to explore creative combinations of concept designs.
-
Resist the temptation to jump into CAD. Keep it on the whiteboard or on paper for as long as possible.
-
Explore tradeoffs with simple mathematical models.
Stay modular for as long as you can
We strongly recommend developing modular prototypes first, instead of integrating them together into a fully functional device. Each module should be designed to prove one or more of your “big bets”, thereby de-risking your development incrementally. Staying modular goes hand in hand with having a clear PRD and a cogent plan for de-risking development in the right order. Here are some rough guidelines to keep your team moving efficiently when prototyping.
-
Break down risks into testable modules and then prototype at module level until risks are retired. This enables concurrent development that unblocks teams and decouples development schedules.
-
Remember that integration adds cost and slows down development by introducing dependencies and cross functional technical coupling. If this kind of deep integration happens before risk reduction, it can handcuff design teams, increase constraints, and slow progress significantly. Delay integration as long as feasibly possible.
-
Keep teams small and independent for as long as possible. Modularity allows a certain amount of decoupled concurrent engineering, which should be carried out by small and nimble design teams with significant authority to solve problems within their areas of ownership. This is also a nod to rule number three of Kelly Johnson’s “14 Rules and Practices for Project Work” which states “The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).
Design review continuously with a focus on issue discovery and iteration speed
Design review plays a critical role in helping teams identify issues early, but most teams only have reviews at large “phase gate” intervals. In our experience, the best performing engineering teams design review early and often. The vast majority of these design reviews are informal, and don’t necessarily correspond with a particular phase of the project. Modularity goes hand in hand with continuous design review by making repeated bite-sized reviews possible at a much higher cadence than typical formal review processes (RR>PDR>CDR>PRR).
The goal of each review is to discover as many issues as early as possible with each design iteration. That is the foundation of development speed. Earlier discovery typically means designers have more time to find solutions, and are operating in less constrained design environments.
Here are some general guidelines for effective continuous design review:
- Design review as soon as a possible for a given subassembly or module.
- Design reviews on partially completed designs can be extremely useful if the goals of the review are stated clearly and reviews are well moderated. See this article on how to plan and prepare your reviews.
- Build an issue tracking system that can help you learn from your design reviews. This can help educate new team members when they join the team, as well as serve as a useful design history with a record of your engineering rationale for key decisions. On complex projects in particular, knowing why you made certain decisions can unload your design team later when assumptions and constraints evolve (as they often do). We built Five Flute to help with this 🙂.
DFM early and often
Design for manufacturability is often left until the very end of the design process. Efficient teams understand that there is an appropriate time to start folding DFM into the design. Design engineers and technical leads need to make a judgement call to determine when production or production-like processes should be used during prototyping. The short answer here is, as early as possible! DFMA principles, such as focusing on designing for a particular process, geometric simplicity, ease of assembly, minimizing part count, and reduction of fastener variety should all be considerations at the concept design stage if possible.
Pro tip: we recommend addressing DFM during design reviews by using simple checklists.
Iterate intelligently: Know what each prototype is testing
How many prototypes will it take before you can get to market? Because each prototype requires a full design-build-test cycle, the number of prototypes (and associated iterations) plays a large role in dictating the overall project duration. Because of this, it’s critical to understand the role of each prototype in your development lifecycle. This is where great engineering teams can leverage their product requirements document to chart an efficient development path. Here are some considerations to help you get the most out of each development iteration.
- Each new design iteration should reduce risk and prove a new subset of requirements. The best teams tackle these requirements in order of the highest risk & impact to least risk & impact.
- Time can be saved by opting to partially de-risk certain product features through both scale model testing and analysis. Sometimes accepting a slight increase in technical risk can lead to a massive decrease in schedule.
- Don’t build redundant prototypes. If a planned prototype doesn’t increase your learnings or reduce risk significantly enough to justify the build cost, consider moving up in prototype fidelity. This is the flip side to developing modularly. Once you are ready to move past modular subsystems, paradoxically you want to develop integrated prototypes as fast as possible because the remaining risks are associated with the integration itself and the complexity of subsystem interations.
Design in insurance: expect problems and plan for unknowns
Even the best mechanical, electrical, and firmware engineers make mistakes when designing and buidling complex hardware. Efficient teams recognize this as an eventuality, so they consider expected failure modes during the design process. At Five Flute we call this “belt and suspenders design.” The basic idea is that likely failure modes should be considered, or even expected during initial testing. Designers can add redundant, fall-back, and “insurance policy” features to their designs that allow prototypes to continue to function and fulfil their original goals (de-risking key requirments) even in the event of partial system failures.
Closing thoughts
In wrapping up, the journey to engineering and building a hardware product is one that requires thoughtfulness, strategic planning, and adaptability. Start by solidifying your product requirements document, mapping out what the product is meant to achieve and the constraints it needs to work within. Confront risks head-on and prioritize them in your development activities. Emphasize the importance of the concept development stage and explore the solution space exhaustively. Adopt a modular approach in the early stages to ensure effective risk management and efficient design iterations. Conduct design reviews continuously and iteratively for issue discovery and problem-solving. Integrate Design for Manufacturability early into your process and iterate intelligently with each prototype. Lastly, anticipate problems and design solutions that have contingencies in place. Remember, efficiency in design and development isn't about speed alone; it's about making smart decisions that set your product up for success, from the drawing board to the production line.
