Which role variant would you assign to owning the internal prompt library, and why?

Placecard is Tarnhollow Labs' reservation and no-show tool for independent restaurants. Four separate flows, reminders, waitlist offers, win-back texts, and confirmations, all draw their guest-facing wording from the same shared prompt library. Wysteria Deniau owns it today, by accident, because her team built it first for their own no-show-risk feature. Her VP wants to know which role variant should actually hold it, the week after a guest at The Wrenford no-showed a table Placecard itself had scored as risky.

How to answer this, stage by stage

Nobody is grading whether you can name four job titles. They're grading whether you can rank them, and defend the top pick, when the wrong owner has already cost a real restaurant real money.

Let's learn

Placecard reads a restaurant's own booking history, a guest's past no-show record, and how far out a reservation was made. It scores that reservation's no-show risk, then drafts the text the guest actually receives: a confirmation, a reminder, a waitlist offer, or a win-back message after a miss.

One library. Four flows quietly depend on the exact same sentences, whether anyone planned that or not.

Before Placecard, The Wrenford's no-show rate ran about 18 percent, a number GM Josiah Marchetti had lived with for years. With Placecard's reminder texts, worded differently depending on how risky a reservation looked, that dropped to 9 percent within two months, including the elevated-risk tier, the reservations most likely to no-show in the first place.

Same risk score, same guest, two different sentences. Only one of them asks the guest to do anything.

Here's the turn. Placecard's model never got worse at spotting risk. What broke was the one sentence that told the guest to do something about it.

What it costs at its worst: across those six weeks, about 19 reservations that Placecard's own model had flagged elevated risk no-showed anyway, guests who had been told, in plain words, that they were all set. At The Wrenford's average of 3.4 guests a table and 71 dollars a head, that's roughly 4,600 dollars walking out the door over six weeks, for one restaurant. Placecard serves 340 restaurants. If even a third of them route their elevated-risk texts through the same shared template the same way, the same six weeks cost the platform an estimated 520,000 dollars, and the one dashboard leadership actually watched, blended no-show rate across every tier, moved from 10 percent to 11. Barely a ripple.

What I would leave alone: the small number of high-risk reservations that trigger an actual phone call from Wrenford staff instead of an automated text. A person writes and reads that message, so the shared library never touches it, and it never drifted. Nothing about this fix needs to go anywhere near it.

The lesson: a shared thing with no named owner isn't ownerless. It's quietly owned by whoever built it first, for exactly as long as it takes their private idea of "good" to become everyone else's default, without anyone deciding that on purpose.

Now here is the same thing as a story

The short version above is what you actually say in the room. Read this one for the year and a half it actually took to notice who was holding the keys.

Wysteria Deniau is good at her job. She built Placecard's no-show-risk score from a rough first pass into the feature that made Tarnhollow Labs' pitch to independent restaurants land: not just a prediction, but a plain-language text that told a guest exactly what to do about it. She wrote that language herself, tested it against her own set of no-show scenarios, and it worked.

Other teams noticed. The waitlist team needed to tell a guest their table might open up. The win-back team needed to text someone who'd already no-showed once. Neither team had anyone who wrote guest-facing copy as well as Wysteria's reminder prompts did, so they copied her templates, changed a few words, and shipped. Nobody asked her. She didn't mind. It felt like a compliment.

Nobody at Tarnhollow Labs decided, on any single day, that one team's prompt library had quietly become everyone's shared infrastructure. It just happened, the way it usually does.

Josiah Marchetti built a habit of his own. For years at The Wrenford, he'd personally called every reservation that felt shaky, a first-timer, a big party, someone booking weeks out. Once Placecard's reminder texts started doing that work for him, reliably, he stopped. He had a dining room to run. The no-show rate held at 9 percent for a year. He trusted the number the way you trust a thing that has never once let you down.

Then Tarnhollow Labs swapped Placecard's guest-facing model for a cheaper one, to cut the per-text inference cost that scaled with every restaurant on the platform. A sensible move, on its own terms. Wysteria's team retuned and retested the reminder prompts against her own eval set of no-show scenarios, and shipped. She had no reason to test the waitlist or win-back prompts. She didn't own them. She didn't know, day to day, that they even still pulled from her library.

The shared instruction underneath all four flows told the model to "state the guest's reservation status in one plain, confident sentence." It never spelled out the three tiers by name, all set, please confirm, needs action, it left the model to infer which sentence sounded "confident" for a given risk score. The old model had settled on three distinct sentences. The new one, run through the exact same instruction, leaned toward reassurance by default, and started collapsing the middle tier, please confirm, into the top one, all set.

Nobody saw it happen. The blended no-show number Josiah watched barely moved, 10 percent instead of 9. Elevated-risk reservations are only about a fifth of his bookings, so a real problem there gets diluted almost out of sight in a number that averages every tier together.

What actually surfaced it was a question, not a report. Yestin Okwuosa, three weeks into the waitlist team, was reading two of the shared templates side by side while onboarding, and asked his lead why the "holding your table" version and the "confirmed" version said basically the same thing for two different risk scores. Nobody on his team could answer him cleanly, because nobody owned the whole library, only their own corner of it.

The decision Perceval Quenneville, Tarnhollow's platform PM, would take back sits in a meeting that never happened. When the waitlist team first forked Wysteria's template, over a year before the migration, nobody flagged that a second team touching the same shared instruction meant it needed a real owner and a real test process. It felt too small to escalate. One more team using a good template seemed like a win, not a governance gap.

Run the same six weeks again, with Perceval already holding the library and a version-controlled eval set covering all four flows. The migration still ships, since it's a real cost win. But the test suite runs the exact same risk-tier prompts through the new model before anyone else does, and the elevated-risk tier's sentence comes back wrong on day one, not week six. The fix ships before a single guest text goes out worded incorrectly. Two days, not forty-two.

What I'd tell myself, looking back at that first fork: a shared thing being useful to more people was never the moment it needed an owner. It was the moment two people who didn't talk to each other started depending on the same words for different reasons.

ORDER, for handing someone the keys instead of leaving them with whoever grabbed them first

FLIPS would fit if this were only about Josiah's habit of trusting the reminder texts. But the actual question asks for a ranked answer among four fixed roles, which is ORDER's job.

The middle box was the actual gap at Tarnhollow Labs. Four teams, zero shared tests, for over a year.

One of these you catch on a Tuesday. The other one you find out about from a new hire's question, over a year later.

Platform PM is the only one of the four who sits far from any single feature's day job and close to every team's dependency at once. That's the actual shape of the job, not a preference.

Three things worth stating directly, since the real judgment sits here. The alternative worth naming and rejecting isn't only the other three roles, it's also "don't centralize it at all, let each flow fork its own copy of the templates." That option loses because forks don't stay in sync, they drift further apart with every edit, which is a slower version of exactly the failure that already happened once. The AI-specific failure worth naming is a shared instruction that leans on the model's own judgment of tone instead of an explicit, enumerated contract: "state the status in one confident sentence" let two different models resolve the same risk score into two different sentences, and nothing caught it because nothing was checking. The guardrail is the version-controlled eval set itself, one exact expected sentence per risk tier per flow, run against any candidate model before it ships to guests. And the trade-off is real and accepted on purpose: running that full four-flow suite adds roughly half an hour to every shared prompt edit, and it delayed the next cost-saving migration by two extra days while the team fixed what the tests caught. Slower shipping, on purpose, for a shared asset four teams already depend on.

And if you want to be sure it really works, try it somewhere else

Same five letters, a city permit office instead of a dining room, and the thing nobody separates this time is a routine reminder from a violation notice that actually matters.

Groundwork, built by Wickfield Civic Systems, reads a city's inspection schedule and a property's past compliance record, predicts which scheduled inspections are likely no-shows, and drafts the text a property owner receives. Perpetua Iwu, the applied PM for the inspection-reminder feature, built Groundwork's shared notice library the same way Wysteria built Placecard's, for her own flow first, copied informally by the violation-notice team afterward.

Different office, same missing owner. The library doesn't know or care which city it's serving.

When Wickfield Civic Systems updated Groundwork's phrasing rules for a new inspection code year, Perpetua's team retested the reminder flow only. The violation-notice flow, forked from the same base instruction, started reading exactly like a routine reminder for property owner Boniface Ekwueme, whose actual violation notice said "your inspection is coming up" instead of naming the code violation itself. He missed the real deadline, because the text never told him it was different from any other appointment reminder.

Same rank, mapped straight onto Groundwork: Perpetua had to be the one who first noticed the gap, since she owned the flow that leaked it, but Groundwork's platform PM is who should have owned the shared library from the start, for the same structural reason as Placecard: violation notices, reminders, and appeal-deadline texts all pull from one base instruction, and only a cross-team owner is accountable to all three at once.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: platform PM owns any shared prompt library, because it's cross-team infrastructure, and applied ownership optimizes for one team's numbers while the rest quietly drift.
Cost: no budget this quarter for a dedicated platform hire. Have the platform PM who already owns the model-serving roadmap absorb the library and its eval set as one line item, rather than leaving it further split.
The model got better, for real: say the new model is measurably more accurate across the board. Keep the shared eval set anyway. A better model can still resolve an underspecified instruction differently than the old one did, and better was never the same claim as calibrated.

Where people run it wrong.
They give ownership to whoever built the thing first, mistaking authorship for accountability.
They assign a title without building the version-controlled test process underneath it, so ownership exists on the org chart and nowhere else.
They watch one blended metric that dilutes exactly the slice where the real damage is happening.

How to use it live. Before ranking anyone, ask yourself out loud: "if this drifts, who is the one person every affected team can go to?" Whichever role variant answers that question honestly is usually the exact rank an interviewer is listening for.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0