Spotify's Three AI PMs Share a Vocabulary. Put a Row Set, a Floor, and a Date on Every Seam.

Three principal product managers at Spotify published one piece yesterday about three jobs that all get called "the AI PM." This is a Field Note: what the piece shows about how AI product work is actually split inside a large company, and the one number it does not have.

The short version

• Henrik (Henok) Lindström, Divita Vohra, and Humberto Corona, principal PMs in Spotify's Personalization org, wrote on November 9 that "the AI PM" is three jobs on one stack: research, where the product is technical leverage; the recommendation foundation model, whose customers are other Spotify teams; and the listener-facing experience.
• Their own line is that quality, evals, and shipping mean different things in each.
• Each section describes its evals, Vohra's best result this year came from agreeing the measure before the architecture, and Corona says a general-purpose eval is a starting point, not the finish line. Three seams between the layers, and no number at any of them.
• I have shipped across seams without one: a classifier scored 89% held-out and 61% in production six weeks later, and a feature passed 200 real cases and failed on one slice that was a fifth of traffic. The note: put three things on every seam.
• A row set of real cases with agreed answers, owned by the layer closer to the user. A floor, the pass rate at handoff. A date, the re-run on production rows with the no-answer count as the alarm. Corona's "that is not what I meant" is the row set's intake, and its rate is the repair rate, read weekly by surface.

What the three of them wrote

The opening is a complaint I share: almost every article about product management and AI "refers to 'the AI PM' as one job." The three authors sit in the same org, on the same stack, and their days do not look alike.

Lindström leads product for Tech Research. He calls the product technical leverage, "applying scientific expertise where it can change what Spotify builds or how confidently we build it." AI lets product teams do work that used to need research, so research moves to shared methods and the questions that span several teams, such as how to evaluate open-ended model behavior. His sharpest line is that "a promising model architecture is not a roadmap," and his job is to turn an exciting result into decisions the organization can make: "start with a concrete problem, find a useful test, and agree on what evidence would justify the next step." Research impact can take months to land in another team's metrics, so influence starts before the research is done.

Vohra leads product for the recommendation foundation model, a language model built to reference real items on Spotify. Her customers are internal teams with their own roadmaps and metrics, and the same model has to serve different definitions of a good recommendation. "You cannot spec model behavior. You shape it, and then you prove it matters." The two levers are "what you teach the model and how you check what it learned. Data and evals." Her first task with each partner team is to show the shared model meets that experience's requirements for quality, latency, and cost. And her best result this year came from a surface team that wanted an outcome her model could deliver, where "we agreed on how we would measure success before we agreed on the architecture."

Corona leads product for Sessions, the surface where a vague mood becomes a set of songs. His customers are listeners, directly. The input is open-ended, so the constraints move: latency that is unacceptable in keyword search is fine in a conversation, and what the system does when it is not confident "belongs to the product, not the model." His section's heading is "Evaluation is a product, not just a process." A general-purpose eval across the foundation model's many uses "is a starting point, not the finish line," and the experience team "has to close the gap between 'the model is generally good' and 'this specific interaction was good for this specific user.'" When a listener says "that is not what I meant," that is feedback on the experience, the model, and the training data at once, and the job is to detect it at scale and pass it back through the chain.

The closing is that the fundamentals hold and the stack adds "a layer of specialization on top of the fundamentals," in more flavors than people realize.

It is a good piece, and I would hand it to anyone who still thinks AI PM is one job description.

The word that changes meaning

The field note is in their own sentence: "We all talk about 'quality', 'evals', and 'shipping', but their meaning shifts with the problem space each of us owns."

Read the three sections for the word eval. In research it is a test that justifies the next investment. In the model layer it is the check on what the model learned, against each partner team's requirements. In the experience layer it is a continuous product built from real usage, judges, and custom evaluators. Three honest definitions. None of them wrong.

Now look for the seams. Research hands the model team an architecture and a result. The model team hands a surface team a capability that meets "that experience's requirements for quality, latency, and cost." The surface team hands listeners an interaction and hands "that is not what I meant" back up the chain.

Three seams, and at each one the word eval changes meaning. What the piece does not have, at any of them, is a number. Vohra agreed the measure before the architecture with her best partner team this year, and the post does not say what the measure was, what rate it had to hit, or when it gets re-run. Lindström agrees what evidence would justify the next step, and the post does not say what the evidence threshold was. Corona says the general eval is a starting point, which is the same seam seen from below.

That is not a criticism of the writing. It is what a vocabulary does. A shared word carries the agreement across the table and drops the number on the way.

What a seam without a number did to me

I have shipped across two of these seams, and both times the upstream score was true.

A classifier of mine scored 89% on held-out data. Six weeks into production it was at 61%, which I wrote up in Rules 97.5%, Trained 100%, Model 87.5%. The Bake-Off Table Needs a Slice and a Date. The held-out set shared the training set's skew, so the model layer's "generally good" was a true statement about the held-out set and a false one about traffic. Nobody was reviewing by week six, because the number at the seam had been 89% and nobody had written down when to look again.

89% to 61%

A feature of mine scored well across 200 real cases and failed on one slice that was a fifth of traffic. The 200 were real. The slice was not in them in proportion. The experience layer, in Corona's terms, found out from users.

In both cases the vocabulary had carried the agreement. "It evals well." What it had not carried was which rows, what floor, and what date.

Three lines on every seam

So the note is three lines, written down at each handoff, and the AI Product Management thesis says why they are PM work: AI collapsed the cost of the parts PMs were trained for and left the parts nobody trained for, and writing the number at the seam is one of those parts.

A row set. Real cases with agreed-correct answers, versioned, owned by the layer closer to the user, because that layer can see the cases. For a model team serving a surface team, that is the surface team's rows, run against the model. It is the same object I described in The FDE Writes the Eval: Almost Right Has a Number, one level up the stack: the rows are the statement of work.

A floor. The pass rate at handoff, on those rows. From then on, falling under the floor is a recall, not a conversation. Vohra's "requirements for quality, latency, and cost" are three floors, and the piece suggests her team already agrees them per partner; the note is to write the number where the next cycle reads it.

A date. The re-run on production rows, not held-out rows, with the count of no-answers as the alarm. The Threshold Card: Tune the Judge Before You Trust the Score, and Date the Re-Tune has the six lines I keep per judge, and the last of them is a name and a date for the next hundred. The date is what would have caught my 61% at week three instead of week six.

Corona's "that is not what I meant" is where the row set comes from. A re-ask the experience team catches is a case with a known wrong answer, and after the listener corrects it, a known right one. That is a row, and it travels up to the model team's next cycle. The rate of re-asks is the repair rate, which I argued in 84,000 Chats Show When Users Re-Ask the AI. Design Should Own the Repair Rate. belongs by surface, read weekly. Corona's section describes building exactly that instrument. The note is to make its output a row set with a floor, so the model team is scored against it next cycle rather than told about it.

Vohra's team did all three once this year and called it their best result. The vocabulary will not carry the numbers across the seam. Only the rows do.

This week

If you own a model or a platform that other product teams build on: pick your most important partner team and write the three lines for that seam, the rows, the floor, and the next re-run date, on one page both teams can open. If you own a surface: count the re-asks on it this week and send the ten clearest ones upstream as rows with the right answer attached. Either way, the number is now somewhere the word cannot lose it.

Related answer: How should AI PMs on different layers of the stack hand off work?

Sources: Henrik (Henok) Lindström, Divita Vohra, and Humberto Corona, "AI Product Management at Spotify: A View From Three Angles," Spotify Engineering, November 9, 2026, read in full; every statement about Spotify is as the three authors wrote it. The 89% and 61%, the 200 cases and the one-fifth slice, the threshold card, and the repair rate are my own, from the posts linked above.