Shipping the IoT Platform a 14-Year-Old Hardware Company Had Never Commercialized

LynkD made IoT hardware—security cameras, smart locks, and a specialty time-based access lock for owners of high-value rental assets like cars and second homes. The hardware was good. The companion software was not. In fourteen years as a hardware business, the company had never commercialized its software: what existed was a buggy, clunky legacy system that customers tolerated but didn't love, and the unified platform meant to replace it had been started and left unfinished when my predecessor departed.

The CEO brought me in as Director of Product to finish it. The pressure was real: customers were asking for the upgrade, the hardware roadmap was being held back by software gaps, and the company's runway was finite.

When I came in, I didn't start by writing tickets. I started by figuring out why the platform had never shipped. Two patterns showed up immediately.

First, nobody had ever fully scoped what the software was supposed to be. Earlier work had built the piece in front of it—the camera app, the lock controls, the access management module—and bolted them together. My predecessor had made real progress on early designs before leaving, but there was no unified product architecture, no shared user model, no consistent flow across hardware types. Customers experienced it as three apps pretending to be one.

Second, the development process was structurally broken. Hardware and software developers were on the same team but operating on different cadences and ticket structures. Tickets were getting handed off between hardware and software with no defined gates, no acceptance criteria, and no clear ownership. Critical work was getting dropped at the seams between teams and only surfacing when QA caught a regression weeks later.

The earlier work hadn't stalled because it was hard. It stalled because the work wasn't actually defined.

I sat with the CEO until I understood the vision well enough to defend it without him in the room. Then I went to the customers—both the legacy users we'd inherited and prospects evaluating us—to understand how they actually used the hardware, where the gaps in their workflow were, and what they wished a software layer would do for them.

With both inputs, I mapped the full software flow for every hardware type onto a single architecture. Then I designed the system end-to-end in Figma—not as wireframes, but as a complete, cohesive product that engineering could build against. For the first time in the project's history, there was a single source of truth for what was being built.

I wrote the SOPs for our development process from scratch. Every ticket started with the PM (whom I coached) writing a clear user story, application requirements, and acceptance criteria. Tickets moved through defined stage gates: PM scoping → engineering assignment (hardware or software) → cross-team handoff if needed → QA acceptance → done. Handoffs between hardware and software developers became formal events with named owners on both sides, not informal pings that got lost.

The throughput change was immediate and measurable. We went from completing 20 story tickets per sprint to completing 40—a 100% increase in team velocity—without adding headcount. The bigger gain, harder to measure, was the drop in tickets that vanished between teams. Critical work stopped slipping through the cracks.

I led a cross-functional team of fourteen—one PM, two QA engineers, ten developers across hardware and software, and one sales lead—through to launch. We onboarded approximately twenty legacy customers from the old system onto the new platform and brought on roughly five net-new customers, establishing LynkD's first software revenue line on top of the existing hardware business.

I want to be honest about how this story ends, because I think the honest version is more useful. We launched. We hit first paying customers. Shortly after launch, the company ran out of runway. The product worked; the business didn't last. That's a real outcome and I'd rather tell it straight than dress it up.

0→1 builder who ships in chaos. The work that mattered most wasn't writing tickets—it was diagnosing why the platform had never shipped, and then fixing the underlying issues (architecture and process) before fixing the symptoms (features). The product reached customers because the system around the product finally worked.