Building Poly Studio

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

I started with a team of two. Over the course of the project I grew that to 15, hiring across UX, research, and prototyping.

Fig 01

The first big call was going cross-platform with Electron instead of building native apps. It let us move fast and ship across macOS, Windows, and Linux simultaneously, but it meant building a universal design system that worked within the new Poly brand across all three platforms. That was harder than it sounds. Every platform has its own conventions and expectations, and we had to find the line between consistency and feeling native enough.

We launched everything at once as an MVP, then iterated using real customer feedback to prioritize what to build next and what to cut from the old tooling. That approach kept us honest about what actually mattered to users instead of guessing.

Fig 02

When HP acquired Poly, I carried the team through the transition and continued to grow it within HP’s Industrial Design org. The original Poly Lens client needed to evolve into something bigger, and I used a new approach to make the case. I wrote the full product spec and built a working prototype in Claude Code. Not a deck. A working app. I put it in front of our exec team, and it got funded. That became Poly Studio.

Studio now manages headsets, room systems, cameras, docks, displays, and soon mice and keyboards across over 7 million onboarded devices. It’s the second largest application within HP outside of Print.

Fig 03

I used the same approach to pitch bringing AI into the platform. That concept, now in public alpha, extends Studio from device management into AI-powered meeting intelligence, using Poly hardware as the capture layer and HP AI PCs for local processing. Wrote the spec. Built the prototype. Presented a working demo. Funded.

I work in the production codebase alongside my engineering team. I have GitHub access, I build locally, I branch and create PRs. When I see a product opportunity, I don’t hand off a Figma file. I build it.

Fig 04

My point of view on AI is simple: products should be judged less by how flashy the model is and more by whether they’re trustworthy, composable, and unobtrusive in real workflows. That’s why I default toward local processing where possible, treat the model as a swappable layer rather than the product itself, keep capture ambient instead of performative, and expose outputs into the tools and agents people already use rather than forcing engagement in a dedicated app.

A deck creates a conversation. A working prototype creates a decision.