BeltIQ

The problem

"Make the belt safer" is a mandate, not a specification. Failures are expensive and dangerous, but the operators living with them described symptoms rather than requirements: a spill nobody caught, a misalignment found on the next walk-around. There was no product to sell yet, no reference deployment to point at, and no obvious first slice, since the work could plausibly have started at any of a dozen failure modes and each one implied different cameras, different mounting, different compute, and a different conversation with the buyer. On top of that the work spanned ML, software, hardware, and field deployment teams with no shared plan between them, and the hardware those teams depended on had lead times measured in weeks, which is long enough that a scoping mistake made in month one does not show up as a schedule problem until month three.

What I built

Started with discovery rather than architecture. Sat with operators and the people who sign off on purchases to separate what actually hurt from what was merely irritating, and used that to pick a first failure mode narrow enough to build against and serious enough to justify someone paying for it. Broke the work into thin vertical slices, each one a working path from camera through to something an operator sees, rather than horizontal layers, so every increment produced something a client could watch running on their own site instead of deferring all the value to one launch. Laid those slices onto a technical roadmap with an explicit execution plan, then ran hardware selection and procurement against that sequence so lead times were absorbed by the plan rather than discovered by it. Built the pitch deck and product narrative in parallel with the build, which forced the positioning and market-entry decisions to happen while they could still change what got built.

Technical approach

• Requirements gathered in the language of the operator's own workflow, meaning what they walk past, what they check, and what they escalate, then translated into detection targets and tolerances engineering could design against. An alert nobody trusts is worse than no alert, so the acceptable false-alarm rate was treated as a product requirement rather than a model metric
• Scope broken into thin vertical slices instead of horizontal layers, so the first shippable increment ran the full path on real site hardware. That surfaced mounting, lighting, network, and power problems while they were still cheap to fix, which is the opposite of what happens when integration is left until the end
• Roadmap sequenced so the longest-lead-time item in each phase started first, with procurement, site access, and model development running as parallel tracks with named join points, rather than as a serial chain where any slip propagates to everything after it
• Vendor selection run as an evaluation rather than a purchase order, assessed against the real deployment constraint of an industrial box on a remote site with no operator, where a component failure costs a truck roll. A second source was identified for anything on the critical path
• Feature planning driven by what changed an operator's decision rather than by what was technically interesting. Capabilities that produced information nobody would act on were deferred explicitly, with the reasoning written down so the same argument did not get relitigated every planning cycle
• Client and executive communication run on a cadence that surfaced trade-offs and scope changes while they were still decisions. A date that shifts, raised early with options attached, lands as a plan; the same date raised late lands as an escalation
• Pitch deck built around the operational outcome rather than the model architecture, framing the capability in the terms a buyer evaluates: incidents caught, monitoring hours displaced, and what the system costs to run unattended

Visuals