Product development is driven by discovery. Plan your projects accordingly.

In hardware development, the fastest path to a reliable, manufacturable product is not a fully locked plan on day one. It is a plan that buys down risk quickly and lets evidence steer the next step. When RFPs try to predetermine every deliverable and decision, they harden assumptions that have not been tested. That slows learning and constrains innovation. Our CEO’s recent Forbes Business Council about RFP’s and RFQ's in product development makes the case clearly: effective RFPs make room for the unknown and compare vendors on how they reduce uncertainty, not only on price or hours. 

Why front-loading certainty backfires

A cradle-to-grave scope implies key assumptions are already correct. In practice, early assumptions about thermals, RF coexistence, power budget, materials, tolerance stacks, or supply options often change once prototypes are built and tested. Locking scope too early forces teams to meet the plan rather than the evidence. That is the opposite of good development practice.

As a reinforcing analogy, consider homebuilding. Builders apply prescriptive codes to produce predictable outcomes, so past projects are strong predictors of scope and cost. Innovative product work does not have a universal codebook and often lacks a close “looks like” reference. Treating it like homebuilding creates false certainty and avoidable rework.

What changes when the work is truly innovative

Innovation means today’s work does not perfectly resemble yesterday’s. That changes how you should structure an RFP.

• Unknowns are the work. The riskiest questions sit in physics, user behavior, manufacturability, and supply. Finding answers is not rework. It is the job.
• Learning speed matters. Time to run a useful experiment and make a decision is a stronger predictor of progress than the number of pages in the SOW.
• Evidence must move the plan. If new data never changes scope, the team is not learning, or the governance model is ignoring the learning.

Plan for discovery, not just delivery

High-performing product teams still plan, but they plan for learning. The Lean Startup model calls this build-measure-learn: run the smallest useful experiment, measure what matters, and use that learning to decide the next move. Hardware teams adapt the loop with benchtop tests, breadboards, rapid prototypes, supplier conversations, and early environmental screening. 

Short discovery loops

Front-load a few fast cycles aimed at the riskiest assumptions. Examples include:

• Thermal path experiments with simple heat spreader swaps and instrumented prototypes
• RF coexistence checks in a basic chamber to validate antenna placement and shielding concepts
• Power budget profiling under realistic loads to size batteries and regulators early
• Tolerance stack reviews with a process-capable supplier before styling locks the geometry
• Preliminary landed-cost checks to avoid late tariff or logistics surprises

Each loop should end in a decision that either narrows options or redirects the path.

Evidence-based gates

Phase gates should be tied to measurable exit criteria, not calendar dates. Examples:

• Feasibility: bench data shows thermal rise within target, and two heat-spreader options have been tried
• Integration: measured RF coexistence at target bands supports the selected antenna placement
• Manufacturability: at least two suppliers quote the chosen process; draft angles and wall thickness validated

Gates create clarity without pretending that the entire route is knowable at kickoff.

Shape the RFP to purchase uncertainty reduction

If you use an RFP for innovative hardware, shape it to reward rapid, transparent learning.

Ask for a discovery plan. Require a short plan for the first 4 to 6 weeks that identifies top risks, the tests to run, and the evidence that will trigger decisions. Ask vendors to include examples of exit criteria they have used on prior programs.

Ask for learning velocity, not slogans. Request recent prototype cycle times and a specific example where fast tests changed the approach. This is a better signal than generic “agile” language.

Pull manufacturability forward. Make preliminary DFM and process input part of discovery. Have vendors show how supplier feedback influences early geometry and BOM choices.

Expect supply and cost awareness. Ask for a first-pass landed-cost view across plausible sourcing regions and the design choices that could shift HS codes or logistics cost categories.

Require transparent governance. Keep a lightweight cadence for risk, decision, and assumption logs. Insist that meaningful new information is visible to the client within a week, not at the end of a phase.

What to watch for in vendor responses

Certain tells in a proposal signal how a team will behave under uncertainty.

• Evidence-light planning. Lots of deliverables, few decision criteria.
• Change-order optimism. A low price anchored to an untested path, with vague language about handling new information.
• Manufacturability at the end. DFM and supplier input deferred to a late gate, which increases the odds of painful changes in DVT or PVT.
• Single-threaded skill sets. One discipline dominates the early plan. Innovative programs do better when ME, EE, FW, ID, and test each get a small but decisive role in discovery.

A short note on the homebuilding analogy

Homebuilding aims for compliance and repeatability. Product development aims for discovery. Builders can apply code to a new set of dimensions and predict cost with confidence. Innovative product teams do not have a universal codebook, and often there is no true “looks like” example. This is why a rigid, fully specified plan on day one creates risk rather than reducing it. The more novel the work, the more the RFP should buy rapid learning instead of false certainty.

How this looks in practice

On successful programs, the first 2 to 4 weeks produce decisions that permanently reduce risk: a thermal approach with measured headroom, an antenna placement validated in test, a narrowed materials set proven to meet mechanical targets, or a supplier path that passes a tolerance and yield sniff test. This initial step is often referred to as Phase 0 development work. Those decisions then shape the next body of work and the next gate. Teams move faster not because they skip steps, but because they avoid investing in directions that data has already ruled out.

This is the same spirit as build-measure-learn. In other words, iterate with intent, measure what matters, and let the results decide. The method is simple to describe and hard to fake, which is exactly why an RFP should ask for it explicitly. 

Bottom line

Innovative hardware emerges from disciplined iteration. Scope your RFPs to test assumptions quickly, gate on evidence, and evolve the plan as you learn. That is how you protect budget, accelerate manufacturability, and keep room for genuine innovation. For leaders socializing this approach internally, our CEO’s Forbes Business Council piece on RFQ’s in product development is a concise resource to share.