Most discovery weeks start with an existing product to react to. This one started with a client who wanted a fleet monitoring product, hadn't picked a hardware vendor, and asked us to help scope the software before that decision was made. Sequencing the two turned out to be the actual work of the week.
Why we refused to scope the software first
Every hardware vendor we looked at reports slightly different things, at different intervals, with different reliability characteristics for the same nominal signal. A software architecture built against one vendor's assumptions would either need rework or would quietly constrain which vendor the client could choose, and neither is a decision we wanted to make on their behalf by accident.
What we did instead
We wrote the software's data contract first, independent of any vendor: the events the product needs to reason about — location, ignition state, door state, fault codes — described in terms of what they mean, not how a specific device reports them. Then we evaluated three candidate vendors against that contract rather than the other way round.
What the evaluation actually found
- No vendor matched the contract exactly. Every one required a translation layer between what the hardware reports and what the software contract expects, which we'd assumed going in and confirmed rather than discovered.
- Reliability varied more than feature lists suggested. One vendor's spec sheet looked strongest and its real-world reporting was the least consistent in a short field trial, a gap that would not have shown up from documentation alone.
- The translation layer became a defined, isolated component rather than logic scattered through the product, specifically so a future vendor change wouldn't mean rewriting the software above it.
The decision the client actually needed help with
Not "which vendor is best", which is a commercial and reliability question we could inform but not answer for them, but "how do we choose in a way that doesn't lock us in for five years if we're wrong". The translation layer was the software answer to that question.
Scoping software around a device before it's chosen is a bet. Scoping software around a contract the device has to satisfy is not.
What shipped from the week
A written data contract, a short evaluation of three vendors against it with a field-trial component, and a software architecture with the translation layer as an explicit, replaceable boundary. The client chose a vendor two weeks later with a much clearer sense of what they were actually trading off.