The difference between a scoping call that produces a real answer and one that produces a vague placeholder estimate almost never comes down to the engineering team. It comes down to what you walk in with.
A good scoping conversation for a connected hardware product should size the hardware, firmware, and software surface area well enough to produce a real, specific plan — not a range so wide it's useless. Getting there in one session depends on a handful of things being ready on your side before the call starts.
"We want a smart water sensor" is a product idea. "We want to detect a leak inside two minutes and alert a phone within thirty seconds, without a subscription-dependent cloud connection" is a problem statement an engineering team can actually size. Come in with the second kind. If you don't have it fully worked out, that's fine — but be ready to talk through the underlying problem, not just the product concept, because the constraints hiding inside "detect a leak" are what actually drive the hardware and firmware decisions.
Any existing schematics, breadboard prototypes, firmware sketches, or even a competitor product you're benchmarking against changes the conversation from "estimate from zero" to "assess and extend." Bring it, however unfinished. A team that can look at what already exists gives a far more accurate answer than one working purely from a description.
Target markets and the certifications that come with them (a device sold in the EU has different obligations than one sold only in the US, and automotive or medical applications add their own pre-submission questions), expected deployment environment (a consumer countertop vs. an outdoor industrial enclosure), and any hard ship-date pressure from a funding round, a trade show, or a customer commitment all materially change the engineering plan. These get left out of the pitch deck version of a product but they're often the single biggest driver of scope — surface them early. If the product touches a functional-safety domain, that's worth flagging up front too: see our notes on getting ready for an ASIL safety case or an IEC 62304 / ISO 14971 submission.
Every product has a wishlist. The scoping conversation is far more useful when you've already separated what has to be true for a first shippable version from what's a fast-follow. A team that's asked to scope the wishlist as if it's all v1 will either give you an inflated plan or quietly assume a cut list you never agreed to.
Our own discovery step is built around exactly this: sizing the hardware, firmware, and software surface in one working session, not a lengthy RFP cycle. The more of the above you bring in, the more that one session produces a plan you can actually act on instead of a placeholder range. If you're getting ready for a scoping conversation, start one with us — or read more about how engagements run from there in The AI/Human Split. For related groundwork, see our notes on estimating a realistic hardware timeline, vetting a hardware engineering partner, and — if you haven't settled build-vs-buy yet — in-house vs. outsourced hardware teams.
