Build products people can trust when the work matters.

We had a meaningful customer problem and an opportunity to approach it differently. Communications centers had large volumes of recorded interactions, but finding important information and evaluating quality required significant manual effort. AI offered a way to make that work more accessible and scalable.

What we did not have was an established product or a proven playbook for delivering it. The Innovation Lab gave us a place to start. A small group of interns became central to the development effort.

My responsibility was to connect that talent to a clear customer problem, establish a direction we could execute, and build the organizational support needed to move beyond experimentation.

The opportunity was broad: search, quality evaluation, coaching, incident reconstruction, and operational intelligence. A small team could not pursue every possibility at once.

I focused the initial direction on intelligent search and replay, and AI-assisted quality evaluation. Both addressed problems customers already understood. They gave us something concrete to build, demonstrate, and test.

I held the broader vision while translating it into practical next steps: what mattered now, what could wait, and what we needed to learn before making a larger commitment.

The interns were not working on isolated exercises or a demonstration that would be set aside when their assignments ended. They wrote the foundational code for the product.

I spent considerable time coaching them on how to ask for help and how to interact with product management. Technical ability was one part of the work. Learning how to clarify requirements, communicate an obstacle, and work through an unclear problem with others was equally important.

I wanted them to take ownership without feeling they had to solve everything alone. Asking for help needed to be part of responsible execution, not something they avoided until they were stuck.

My role was to bring customer context, explain the reasoning behind priorities, and coach them through the conversations that connected their development work to product decisions. As the initiative progressed, they became integrated into the full team for production.

My leadership responsibilities grew with the product. I began by running a small, focused group, working closely with the interns who wrote the foundational code.

As the initiative moved toward production, I transitioned to leading a much larger development effort toward commercialization. The challenge expanded from helping a small group build the foundation to aligning the broader development organization around a commercially ready product.

That required shared priorities, tradeoffs across competing needs, coordination of dependencies, and a consistent connection between development, customer expectations, and business outcomes.

I remained close to the product, but my responsibility was no longer limited to what the original group could build. It was to create direction across the larger effort and keep the organization moving toward commercialization.

A working demonstration gave us something concrete to put in front of customers and stakeholders. I used those conversations to test whether the workflow made sense, whether customers trusted the outputs, and whether the experience addressed a problem they would invest in solving.

That evidence informed requirements, priorities, evaluation design, messaging, and pricing. Customer interest had to become a clearer problem statement, a change in scope, or a better understanding of what the product needed to do.

Alongside that work, I coordinated across engineering, security, implementation, sales, and leadership. Moving beyond the lab required attention to customer readiness, operating costs, support, and commercialization.

I initially expected the AI model to be the principal source of complexity. Customer trials showed how much depended on the system around it: metadata, incident mapping, audio quality, and evaluation practices.

We needed to distinguish model errors from data, configuration, and workflow problems. “Make the AI better” was not a useful direction. We needed to identify what was failing, understand why, and give people a specific problem they could investigate.

Creating something new with limited resources requires focus and a willingness to develop capability while delivering. This experience brought my three principles together.

Product: Give people a meaningful customer problem and a clear direction.

Process: Create enough structure for people to ask questions, make decisions, and turn learning into progress.

People: Trust emerging talent with meaningful ownership, coach them through the difficult parts, and help them grow into a larger contribution.

That is the work I find most rewarding: seeing an opportunity, creating enough clarity for people to act, and helping a team build something that becomes bigger than its starting point.