Describe the difference between an applied AI PM and a platform AI PM in terms of who their customer is.

Drossel Freight runs two things on top of the same idea. Lanecast predicts what a truckload should cost to move from one place to another. Boundfare is the screen where a broker types in a lane and sees a bindable price in about three seconds. Torvin Bramlett owns Lanecast. Isaure Callary owns Boundfare. For a year, neither of them had much reason to think hard about who the other one was actually building for.

How to answer this, stage by stage

Nobody is grading whether you know two job titles. They're grading whether you can name who each one actually answers to, with real numbers behind it, in a room where someone might ask you to prove it.

Let's learn

Lanecast is a guess. Boundfare is a price a person can actually click "book" on.

Same number, two different people asking two different questions of it.

Drossel Freight built a tool that predicts what a truckload should cost to move from one place to another, and a screen where a broker can see that price and book the load right there.

Before Boundfare, a broker rang around: four or five calls or emails to different carriers, then waited for someone to call back. About 35 minutes for one lane, and that's if nobody was at lunch. With Boundfare, that same lane comes back priced in about three seconds.

Five steps. The middle one, turning a raw prediction into a price a stranger can trust, is the step this whole answer turns on.

Here's the turn. The model's own accuracy was never the real problem, on either side. Isaure's mistake wasn't that Lanecast was wrong. It was that Boundfare's screen got built for someone who already understood the model, not for the person actually staring at it. Torvin's mistake wasn't that Lanecast was inaccurate either. It was that Lanecast got built for exactly one caller, and a second one showed up anyway.

Same price underneath. One version a broker can act on in a glance, one version that stops him mid-click to wonder what he's looking at.

At its worst, Isaure's mistake sends a broker straight to a competitor's app mid-quote. At its worst, Torvin's mistake puts two different prices in front of the same customer, in the same week, from the same company.

Every one of these four choices was reasonable on its own. Together, they built a model that could only ever answer to one caller.

What I would leave alone: a rough range on Boundfare's screen for a broker who's still browsing lanes, not booking one yet, doesn't need any of this. Without a confidence band or a model tag, a loose number is fine there, because nobody's about to click "book" on it.

The lesson: one model can answer two different questions honestly, and still fail both people asking them, if nobody ever writes down which question belongs to which person.

Now here is the same thing as a story

The short version above is what you actually say in the room. Read this one when you want to feel exactly what a narrow model and a cluttered screen cost, and how long it took anyone to notice either one.

Every Monday morning, before the standup, Torvin Bramlett checks one number: how many lanes Lanecast is least sure about that week. He's owned the rate-prediction engine at Drossel Freight for two years, since before Boundfare had a single broker using it.

Boundfare came out of his model. Isaure Callary built the screen: a broker types in a lane, origin and destination, trailer type, ready date, and in about three seconds sees one price and one button, Book this load. For most of a year, that was the whole relationship between the two of them. Torvin kept the number accurate. Isaure kept the screen simple. Neither had much reason to think about the other's job.

Then, eight months in, growth wanted more trust on the screen. Someone had noticed brokers sometimes hesitated on a quote before booking, and the fix that got greenlit was to show more of what Lanecast already knew: predicted rate per mile, an 80 percent confidence band around it, even a small model-version tag in the corner, so a broker could see the number was fresh.

It shipped on a Tuesday. Isaure watched book-through rate all week the way she always did. By Thursday it had gone from 54 percent to 41. By the following Thursday, 29.

Zsolt Nazarov, an independent broker who had used Boundfare almost daily since it launched, was one of the ones who stopped. He didn't stop because the price was wrong. He stopped because he didn't know what an 80 percent band meant, and a screen that used to answer his question in one glance now made him feel like he needed to ask someone first. So he went back to calling around, the way he used to, and Drossel lost the load.

Isaure pulled the screen back to one number and one button within the week. Book-through recovered to 51 percent inside ten days, and the whole thing cost about $96,000 in lost margin, mostly absorbed in that first week before anyone even asked about the pattern. Loud, fast, and by the time it came up in a review meeting, it was already fixed.

Torvin's mistake took longer to find, because nobody was watching for it at all.

When Lanecast first shipped, it was built to answer exactly one kind of question, fast: what should this one lane cost, right now, for the broker looking at Boundfare. Single lane in, one point estimate out, retrained every week to match Boundfare's own release cycle. Nobody built a batch mode, because nobody had asked for one.

Nobody at Drossel decided, on any single day, to let a second version of Lanecast exist. It just got built, the way a workaround does.

Five months after Boundfare launched, Nuray Endale's network-planning team wanted something different: not one lane, fast, but 3,800 lanes, once a week, to plan where Drossel needed more trucks the following month. Lanecast could not do that. It would have taken the model over six hours to answer 3,800 questions built for answering one at a time, and Nuray's team had a Thursday deadline.

So they didn't wait. One of Nuray's engineers, who had worked with Torvin's team before, built a lighter version of the same idea: similar features, a monthly retrain instead of weekly, tuned to run fast across thousands of lanes overnight instead of one lane in real time. It worked. Nobody thought of it as a second model. They thought of it as a spreadsheet with some machine learning in it, built to hit a deadline.

For three months, both numbers existed, quietly disagreeing a little more each month. Average gap of 9 percent by month three. On the lanes that moved a lot, produce season, holiday freight, the gap hit 21 percent.

It surfaced on a Wednesday, in a renewal call Isaure wasn't even on. A customer's logistics manager pulled up a live Boundfare quote for a lane, $2,150, at the same time an account manager was sharing a capacity report built off the network team's model, which priced that same lane at $2,390 for the same week. The customer asked, reasonably, which number Drossel actually believed.

The decision Torvin would take back sits fourteen months earlier, the week Lanecast first shipped. Someone asked, in passing, whether the model should be built to serve more than Boundfare eventually. The honest answer at the time was no, not yet: Boundfare was the only thing calling it, and building batch support nobody had asked for felt like the wrong thing to spend a sprint on. Nobody wrote down that the question should get asked again once a second team actually needed it.

Run the five months again with one change: Lanecast ships with a batch endpoint from day one, even a slow, overnight one, and Torvin's team owns a standing answer for "who else might call this." Nuray's team never builds their own copy, because they don't need to. There's one number, computed twice, updated on two different schedules, but from the same model, the same training run, the same eval set. The renewal call still happens. Both numbers on the screen agree, because they were always the same number.

What I would tell myself, back in that first sprint planning meeting: "nobody's asking for it yet" was true, and it was never a reason to stop asking whether somebody would.

Four checks for telling two customers apart

Not a way to prove either PM was careless. PICK is what forces you to commit to who each role actually serves, then say which kind of "wrong customer" mistake costs you more.

One mistake announces itself on a dashboard within the week. The other one hides inside two numbers that both look fine on their own.

Three things worth naming directly, since this is where the real judgment sits. Torvin's team considered merging the two roles back into one AI PM who would own both Lanecast and Boundfare, and rejected it: a synchronous, three-second, single-lane call for a broker and a batch, overnight, thousands-of-lanes forecast for a planning team pull a roadmap in two directions at once, and one person cannot protect both without one of them quietly losing every sprint. The AI-specific failure worth naming by name is silent drift: two independently retrained copies of what is supposed to be the same prediction, disagreeing a little more each month, with nothing that alerts anyone because neither model is technically wrong, they are just no longer the same guess. The guardrail is a weekly reconciliation job, not a smarter model: both versions get scored against the same settled-rate eval set every week, and any lane where they disagree by more than 5 percent gets held from any customer-facing number until someone checks it. And the trade-off is real, and accepted on purpose: the batch endpoint Torvin eventually built prices 3,800 lanes overnight for a fraction of the cost of 3,800 live calls, but every number in it can be up to eighteen hours old, which is fine for a Thursday planning meeting and would be the wrong choice entirely for a broker about to click book.

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

Same four letters, an insurance claims desk instead of a dispatch floor, and this time the shared number isn't a freight rate. It's a fraud-risk score.

Wyndham Mutual built Brackendale, a model that scores every incoming auto claim for fraud risk, and Beaufort, the screen an adjuster uses to actually work a claim. Colwyn Bertoldi owns Brackendale. Yevheniy Ottoway owns Beaufort. Two other teams pull from Brackendale too: subrogation, which chases claims tied to known fraud rings, and underwriting, which uses the same risk signal in aggregate to reprice next year's policies in a region.

One score, walking out four different doors, to four different customers of the same model.

The same confusion showed up here, in a different shape. Beaufort briefly showed adjusters Brackendale's raw risk score, a number from 0 to 100, instead of a plain reason. Adjusters started treating any claim under 20 as automatically safe and anything over 80 as automatically suspicious, skipping their own judgment on the ones in between, because a number felt more official than it was. Yevheniy's team pulled the raw score and replaced it with three lines a person actually reads: what looked odd, what looked normal, and what to check first.

Mapped straight onto PICK: the position holds the same shape. Yevheniy's customer is the adjuster deciding whether to pay a claim today. Colwyn's customer is every team, claims, subrogation, underwriting, pulling a different cut of the same risk signal. The impact splits the same way too: a raw score on an adjuster's screen gets misread inside days; a model tuned only for one team's shape of the question gets duplicated in the shadows and drifts, the same way Lanecast did. The cost asymmetry lands the same way: the adjuster-screen fix was loud and cheap, the narrow-model fix was quiet and took a full underwriting cycle to notice. And the kill criteria transfer directly: track how many real teams call Brackendale in production, and fold the roles back together the day that number sits at one for two straight quarters.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: the applied PM answers to the person reading the screen, the platform PM answers to every team calling the model, and the two roles fight if nobody names which mistake to watch for.
Cost: no budget to build the batch endpoint or the region-level cut this quarter. Ship the narrow version anyway, but write down, on day one, which second team is most likely to need it, so the rebuild-versus-reuse decision isn't a surprise later.
The model got better, for real: say Lanecast's accuracy climbs another five points next quarter. It doesn't touch this problem at all. A more accurate single-lane model is still the wrong shape for a team that needs 3,800 lanes at once.

Where people run it wrong.
They answer with "the platform PM is more technical," instead of naming who each one actually serves.
They let the first team that asks for a model define its shape forever, instead of asking who else might need it.
They fix a trust problem by hiding the model's own number entirely, instead of translating it into something the actual customer can use.

How to use it live. Before answering, ask yourself one question: does this person ever see the model directly, or only the product built on top of it? Whoever only sees the product built on top of it is the applied PM's customer. Everyone else, calling the same model for their own reasons, is the platform PM's customer.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0