Building a Public-Service Voice Assistant with Jamie Chung | Episode #3

Jamie Chung's path into product management combines hands-on technology, small businesses, computer science, and commercial experience. Born and raised in Jamaica, he moved to the United States when he was young and learned technology by breaking and fixing things. He later worked on web hosting, software development, and WordPress sites, studied computer science and mathematics at Virginia Tech, and reached Microsoft through an internship. His work eventually included advertising commercialization and healthcare machine learning before he returned to the United Kingdom and joined the BBC.

At the time of this conversation, Chung was nearing his first 100 days in both the UK and the BBC. He describes a creative environment where radio producers, editors, designers, engineers, architects, and data scientists work together around the BBC's role as a trusted public broadcaster.

What you'll learn

• How technical experience can support a move into product management

• Why product work varies more across organizations than many disciplines

• What the BBC hoped to learn by building its own voice assistant

• How technical fluency can help or hinder collaboration with engineers

Use technical depth to understand value

Chung's early businesses already involved product activities, even before he had the formal title. His computer science background then helped him communicate credibly with engineers. The larger career shift happened when he began looking beyond implementation to the business context and value a product could create.

He is drawn to product management because it offers flexibility and ambiguity. Product roles can look very different from one organization to another, and the PM may be asked to take a large, uncertain problem and determine how to create value. Chung connects that work to starting with the customer and repeatedly asking why.

Technical knowledge, however, is not automatically beneficial. Earlier in his career, Chung's ability to understand lower levels of the stack helped him collaborate with engineering teams. Later, it sometimes created a perception that he knew too much or did not trust engineers. He had to learn to let go. His renewed use of technical fluency is less about directing implementation and more about helping engineers understand the story and value proposition behind the technology.

Build voice products for the audience you actually serve

Chung discusses the BBC's assistant, Beeb, as an effort to ensure the broadcaster had a place in the emerging voice ecosystem. Voice interfaces already existed in phones, smart speakers, and cars. The strategic question for the BBC was what it would mean for an audience to have a conversation with a trusted public broadcaster. Could an assistant teach someone something interesting or offer inspiration in a distinctly BBC way?

The project was also a learning exercise rather than a claim that every answer was known. The team wanted to understand what conversation with the BBC should mean for listeners and how the organization's long history of creative content could shape that experience.

Language made the audience challenge concrete. The United Kingdom includes many regional dialects, and Chung says Beeb was trained to recognize more than 30 when users said its wake phrase. That detail shows why a generic definition of voice recognition quality is insufficient. Product performance has to reflect the speech patterns of the people the service intends to reach.

Partner where reinvention adds little value

The BBC worked with Microsoft on the voice technology. Chung frames the partnership as a way to stand on the shoulders of giants instead of reinventing too much of the wheel. That allowed teams to use an established toolbox while concentrating on the differentiated goal: a UK public-service assistant shaped by the BBC's mission and audiences.

For PMs, the broader lesson is to separate foundational capability from product distinction. A team does not need to build every technical layer itself to create a meaningful experience. The important decision is where ownership creates unique value and where a partnership gives the team more capacity to solve audience-specific problems.

The same judgment applies inside the team. A technically experienced PM can understand architecture and constraints without making implementation the main source of personal impact. Chung's experience suggests that technical depth becomes more valuable when it improves translation, trust, and shared purpose.

Listen to the full conversation: Episode #3 audio.

Chung's early BBC perspective is a practical study in balancing mission, audience diversity, partnership, and technical judgment. The PM's contribution is not to own every answer, but to help a varied group of specialists understand which problem is worth solving and why.