Who Owns Voice AI as a Product When the System Keeps Mishearing Customers?

The Call Where the System Heard 214 as 240 and Confirmed Nothing

A guest calls at eleven at night and asks for towels in 214. The system hears 240, says of course, and dispatches. Two rooms are unhappy, the night manager is on the phone, and the incident review finds the speech model's confidence score, the dispatch integration, and the prompt that told the assistant to be warm and efficient. It finds nobody who decided that a room number should be read back before anything moves. That missing decision is the job.

A voice AI product manager owns the behavior of the conversation rather than its personality. The unit of product is the turn: when the system confirms, when it asks again, when it guesses, how long it may go silent, what happens when a caller talks over it, and when the call leaves the machine entirely. Three tells separate someone who owns that from a strong PM who has worked next to a voice feature.

The first is that they specify in repair rather than in flow. Ask a candidate to spec something small, like taking a reservation change. A flow answer walks the happy path and adds an error state. A voice answer starts with the fields that must be confirmed before an action, names the ones where a wrong value is cheap and confirmation costs more than it saves, and then describes what the system says on the second and third failed attempt, which are different sentences for a reason.

The second is that they treat latency as a product constraint with a number on it. Listen for someone who knows what a caller does after roughly a second of silence, who has argued about whether to fill the gap or shorten the model call, and who can say which parts of their system were slow rather than that the system felt slow.

The third is that they define a correct call independently of a correct transcript. Word error rate is a component metric and a bad north star. Strong candidates measure task completion, containment, repair rate, and the share of calls where a person had to redo the work afterward. Ask what percentage of calls they would accept a misheard word on. Someone who has run a voice product has a real answer and a reason.

The cleanest negative question is this: what should the system never do on its own voice? A real owner has a list, usually short, usually argued through with operations and legal. A performed answer says guardrails and moves on.

Which Backgrounds Produce Someone Who Can Spec a Conversation That Fails Out Loud?

The reliable feeders shipped products where a person was waiting on the line and a mistake was audible immediately: IVR and contact center product owners, telephony platform PMs, and the accessibility and speech people who worked on dictation or captioning. All three have lived with a system that is right most of the time and embarrassing in public the rest, and all three already think about what the machine says on the way to being wrong.

Contact center product owners convert fastest. They have written containment targets and escalation matrices for human agents, they know which caller situations are genuinely hard, and they have watched a transfer go badly enough to care about what the human receives. Speech and accessibility backgrounds bring the other half, which is a working intuition for accents, noise, code switching, and the fact that a model that tests well on clean audio will meet a lobby, a highway, and a speakerphone.

The unexpected feeders are worth more than the obvious ones. Hotel and restaurant operations managers who have actually answered the phone at capacity know the twenty calls that make up most of the volume and which ones cannot be automated at any quality. Air traffic, dispatch, and emergency call takers bring formal readback discipline, which is the confirmation policy this role has to invent, already worked out over decades. Language teachers and interpreters hear repair strategies the rest of the industry has no vocabulary for.

What almost nobody arrives with is fluency in reading a call trace against its audio. The difference between a mishearing, a correct transcript the model reasoned past, and a tool that returned nothing is invisible in the summary and obvious when the two are lined up. That is a few weeks of teaching and worth budgeting for. Screen for the person who asks to hear the recording rather than the person who quotes the score.

Two profiles interview well and often disappoint. Chatbot PMs sometimes carry text habits into a channel with no scrollback, no undo, and no way to reread the last message. And PMs whose craft is persona and script polish can stall the moment the interesting work is a permission and a threshold. The habit of judging a system by what it actually did shows up more strongly in the autonomy evaluation operations manager pipeline than in most product pools.

Ask How They Personally Got Good at Judging a System That Mishears

Ask how they got good at this and listen for practice rather than coursework. The answers worth hearing are specific: an assistant produced something plausible, they believed it, it was wrong in a way that reached a customer, and they changed how they work afterward. They can name the claim, name how it fell apart, and name the check they now run every time before trusting a summary.

Good answers share a shape. Someone stopped reading model-generated call summaries and started listening to a fixed sample every week, because the summaries agreed with each other and disagreed with the audio. Someone else recorded themselves reading the same twenty utterances in a car, a lobby, and a quiet room, and found the failure was environmental rather than linguistic. A third keeps a running file of calls that went sideways, which is the closest thing this discipline has to a lab notebook and usually becomes the first evaluation set engineering receives.

The habit underneath all of it is checking a confident claim against something outside the conversation. A model reports a ninety-four percent containment rate, and this person pulls thirty of the contained calls and finds nine callers who simply gave up. That habit is invisible on a resume and hard to perform in front of real work.

So make the interview a working session. Hand over forty real call recordings with their transcripts, including six you already know went wrong, and give ninety minutes. Ask for a one-page proposal at the end: which turns should change, what the system should now confirm before acting, what it should refuse to handle by voice at all, and which calls would prove the change worked. That page will tell you more than four conversations about speech architecture.

One caution about vocabulary. Barge-in, endpointing, turn detection, word error rate, containment: all of it is a week of reading away. The candidate who has shipped three voice launches and the one who has read about them sound nearly identical for the first thirty minutes. Only the work separates them, and this is a role where a great deal of the work is listening.

Where Do You Find Voice AI Product Managers While the Category Is Still Forming?

Search by responsibility, because no two employers use the same title. It shows up as voice AI product manager, conversational AI product manager, and staff platform manager over conversational products, and it is concentrated in hospitality, travel and clinic scheduling, where a phone line is the main channel. Run the search against a job board and read the descriptions rather than the titles; a posting that names a confirmation policy or a containment target is the one you want.

Look inside first anyway. Whoever runs your phone operations has been writing routing rules and escalation criteria for years and knows which calls are hard. The implementation and solutions people at your voice vendor are the second pool, since they have been answering the what does it do when it mishears question in front of customers with no specification to point at.

What closes this hire is rarely money. It is authority over the tradeoff. The candidates worth having will ask three things: whether they can hold a launch, who they must convince to make the system slower in exchange for confirming more, and whether the evaluation set is theirs or engineering's. Answer all three concretely. If the honest answer is that an executive decides on the day, say so, because week two will reveal it anyway.

The second closing lever is evidence. Play a call that went badly during the interview process. Strong candidates read that as a company willing to look at its own failures, which is the working condition they are shopping for. Teams that only play the demo call lose these people to teams that do not. The same appetite for finding where a system breaks before a customer does drives the AI red team engineer hire, and the two roles argue productively when they sit near each other.

What Should This Role Cost, and Does It Need to Be Near the Front Desk?

No wage series covers this title, and no survey found for this piece prices it, so this stays qualitative on purpose. Any single figure quoted for the role today is a guess wearing a benchmark's clothes. Price it against your senior or principal product manager band, then adjust for whether the person can hold a release and whether the voice product takes payments or changes bookings. Both change the job more than the title does.

The pressure on that band is real even where a point estimate is not. PwC's 2026 AI Jobs Barometer, analyzing roughly one billion job advertisements, reports an average wage premium of 62 percent for roles demanding AI skills as of 2026 ¹. Read that as a reason your existing product band will be tested rather than as a number to write into an offer.

There is a leveling trap worth naming. The title is new enough that scope varies wildly between employers, so a candidate's current title tells you close to nothing. Ask what they were allowed to change without approval, and whether they owned the number the business watched. That answer sets the band.

On location, the specification and analysis work travels fine, and most teams hiring this run distributed. What resists distance is the first three months. A voice product for hotels, restaurants, or clinics is inseparable from what happens at the desk when the phone rings, and a product manager who has never stood there during a rush will spec for the calls that are easy to imagine. Budget real time on site early, then let the role go remote once the operational picture is in their head.

On-premise constraints show up where the recordings are the sensitive material: health information, payment card data, or anything under a residency rule. The binding constraint is usually where calls may be stored and replayed rather than where the person sits, so scope it before writing the offer.

One legal note, offered as a flag rather than as advice. Recording and using calls is governed by consent rules that differ sharply by jurisdiction, and several places now add disclosure duties when the voice on the line is synthetic. California's bot disclosure law, Business and Professions Code sections 17940 to 17943, has required disclosure in certain commercial and electoral contexts since 2019 ², and other jurisdictions have moved since. The confirmation and disclosure script this role writes is frequently the only artifact that says what callers were told. Check with counsel in your own jurisdiction rather than reasoning from a summary.

See how it works >