2026/03/06
The Critical Question
If you're building a sensor-dependent product, one question matters more than any other: "Can we actually sense what we need to sense to accomplish our goals for this product?"
This is not the same as asking, "Do sensors exist for this type of measurement?" Or, "Has someone else built something similar?"
The real question is, "Can WE sense what WE need given OUR constraints?" If the answer is no, you have a very different path ahead of you, than if the answer is yes.
Those constraints are specific to your product and use case:
- Performance requirements - What bandwidth, sensitivity, dynamic range, and minimum detectable signal do you actually need? What’s critical versus nice to have?
- Sensor placement - Where must sensors reside to capture valid measurements? Can they be protected, or must they be exposed to the environment?
- Size constraints - What physical space is available where the sensors need to live?
- Power budget - How much power can you allocate to the complete sensing chain? (Sensors + support circuitry)
- Environmental conditions - What temperature range, humidity, vibration, acoustics, and light exposure must the system tolerate?
- Cost targets - How much of your BOM budget can sensing consume?
So with these constraints in mind (and any other relevant ones), will you be able to sense what you need to meet your product's vision? This isn't about the engineering challenges yet. It's about understanding the fundamental physics and what you're really up against. Physics doesn't negotiate with any of these constraints — and neither does your product's viability.
Get these answers early. As early as possible. The difference between Week 2 and Month 14 could be the difference between integrating an off-the-shelf sensor and pivoting your entire product. |
Why Teams Skip This Step
Most teams skip the Critical Question entirely. They jump straight into implementation and prototyping, assuming it will work out. Then discover fundamental limitations months into development.
The Assumptions and The Reality:
“Sensors are commodities - just pick one from a catalog.”
Reality: while competitive sensors exist in most categories, they often operate differently, have unique interfaces, and come with their own quirks. Swapping sensors mid-development means revisiting all of your feasibility questions.
“If similar products exist, we can use the same sensors they do.”
Reality: they’re solving for their constraints, not yours. What works for them may not work at all for you.
“Product development is about building, not validating.”
Reality: fast prototypes for stakeholder feedback? Absolutely. But you also need a defined path to technical validation, building only what’s necessary to prove feasibility quickly.
“Feasibility validation feels like delay, not progress.”
Reality: validation is extra work up front, but discovering your approach won’t work in month 14 is far more expensive than discovering it in week 2.
Take Action
Write down your constraints right now—all six categories. If you can’t fill them all in, that’s your first signal you need to validate feasibility before prototyping.
Next week: I’ll walk you through the first two steps of the framework—how to define exactly what you need to sense, and how to validate the physics as efficiently as possible.
Reply and tell me: What's the one constraint that worries you most about your sensing approach? Power? Placement? Cost?
Hit reply—I read every response.
-Steve
Founder, Perceptive Hardware
P.S. Here are 4 ways you can get started right now:
- Get the Hardware Validation Roadmap: (Pre-order $67) A practical guide and Notion workbook for validating your sensing approach before committing to expensive prototypes.
- Run a Technical Diagnostic: (<1 week) We’ll identify your 3-5 Critical Feasibility Questions and give you a clear technical assessment of what needs validation. → [Schedule your diagnostic] or reply "Diagnostic"
- Get Your Feasibility Pathfinder: (2-3 weeks) We'll perform a deep technical assessment of your concept, with experiment designs, development roadmap, and go/no-go recommendation. Know exactly how to validate feasibility in less time. → [Learn about Pathfinder] or reply "Pathfinder"
- Launch an Execution Partnership: (6 weeks to 6 months) Work with our team to execute targeted validation experiments, advance your Technical Readiness Level and achieve technical and market validation. → [Explore Execution Partnership] or reply "Execution"