Building Poly Studio

When Plantronics acquired Polycom, we rebranded as Poly and suddenly needed an entirely new software platform. The existing tools, Hub and PMP, were aging out and couldn’t scale to the combined product line, so we had to build a suite from scratch. Something that could manage, deploy, and monitor devices across big enterprise customers.

I started with a team of two. Over the life of the project I grew it to fifteen, hiring across UX, research, and prototyping.

The first big call was going cross-platform with Electron instead of building native apps. It let us move fast and ship on macOS, Windows, and Linux at the same time, but it also meant building one design system that held up across all three while still feeling like the new Poly brand. That was harder than it sounds. Every platform has its own conventions, and we spent a lot of time finding the line between staying consistent and feeling native enough on each.

We launched the whole thing at once as an MVP, then let real customer feedback tell us what to build next and what to quietly retire from the old tooling. It kept us honest about what actually mattered instead of guessing.

When HP acquired Poly, I carried the team through the transition and kept growing it inside HP’s Industrial Design org. The original Poly Lens client needed to become something much bigger. Rather than argue for it the usual way, I wrote the full product spec and built a working prototype in Claude Code, then put the actual working app in front of the exec team. It got funded. That became Poly Studio.

Studio now manages headsets, room systems, cameras, docks, and displays across more than 8 million onboarded devices, with mice and keyboards coming soon. Outside of Print, it’s the second-largest application at HP.

I used the same approach to make the case for bringing AI into the platform, and it landed the same way. That concept is in public alpha now. It extends Studio from managing devices into AI-powered meeting intelligence, using Poly hardware as the capture layer and HP’s AI PCs to do the processing locally.

I work in the production codebase alongside my engineers. I have GitHub access and build locally, branching and opening PRs like everyone else on the team. So when I spot a product opportunity, I can just build it instead of handing off a Figma file and hoping.

My take on AI is pretty simple. Nobody cares how impressive the model is. They care whether the thing is trustworthy and quietly useful in the middle of a real workday. So I keep the processing local where I can, and I treat the model as a layer I can swap out, not as the product. The output should land in the tools and agents people already use. Trapping people in one more app is how these features die.

It’s worked enough times now that I don’t plan on going back to decks.