Explain how prototyping changes the PM's credibility with an engineering team.

How to answer this, stage by stage

Seven moves. The trap in this question is answering it with demo advice, a clean UI, a confident pitch, when it's really asking which single move an engineering team is quietly grading a PM on.

Let's learn

Glidepath is a tool built for Corrimal Air's operations desk. It watches weather, crew duty clocks, and the flights stacked behind a delay, and tells the desk which holds are about to turn into a cancellation, early enough to start rebooking passengers before it happens.

Before Glidepath, on a rough-weather morning, Warrick Fitzgerald and his team worked this out by hand. Warrick has run Corrimal's irregular-operations desk for eleven years. Checking one flight leg, the weather feed, the crew duty clock, the flights stacked behind it, took him about 20 minutes. Twelve legs like that before lunch is four hours gone, on a morning the desk barely has four hours to give.

Reya Colston, the PM building Glidepath, put together a rough version over one weekend, and tested it on the one day she had good data for: a snowstorm that shut Corrimal's hub down for six hours. It called every hold right. She walked into the planning meeting two weeks later and told Ezra Winslow's engineering team it was basically done.

The extra misses were not the problem. Say that plainly, because it's the part most people skip past. What actually decided whether Ezra's team trusted Reya's next request wasn't how often Glidepath got a call wrong. It was whether she'd told them, first, which calls she'd never tested at all.

Naming what wasn't tested comes before showing what was. Polish comes after both, or it never gets read as credibility, just decoration.

On the 29 weather-driven days Reya eventually tested, Glidepath matched Warrick's call 27 times. On the 13 crew-legality days, delays caused by a crew running out of legal hours, not weather, it matched him only 5 times.

Here's what that costs at its worst. Ezra's team found the crew-legality gap themselves, in the room, during planning. From then on, they stopped taking Reya's word for anything. Her next three proposals each got re-tested from scratch by an engineer who no longer trusted her numbers, whether or not those proposals had anything to do with the gap that started it.

What I would leave alone. Whether Glidepath's risk flag shows up as a red dot or an orange badge is not worth a minute of this conversation. Warrick reads either one the same way, in about two seconds. Spend the credibility-building time on what's been tested, not on how the flag looks.

The lesson. A prototype that gets the easy case right only proves it can do the easy part. Credibility gets built on the case nobody's checked yet, because that's the one that costs you later, and by then it isn't a bug report anymore. It's a reason not to trust the next thing you say.

Now here is the same thing as a story

The short version is above. Keep reading if you want to feel why the storm that made the best demo was the wrong thing to build a sprint estimate around.

The ops floor at Corrimal Air's hub gets loud fast once the ceiling drops below minimums.

Warrick Fitzgerald has run the desk for eleven years. Ask him which flight is about to fall apart and he'll tell you before he's finished reading the weather feed, from the shape of the hold alone.

Reya Colston joined Corrimal's product team seven months before Glidepath. What she was good at, from her first project, was turning a vague idea into something engineering could actually estimate without three rounds of clarifying questions.

She built the first version of Glidepath over a weekend, testing it against the one day she had clean data for: a snowstorm in January that shut the hub down for six hours and stacked forty flights into one tangled evening. Glidepath called every one of Warrick's holds right. She ran it against that same storm about a dozen times, checking herself, and it never missed.

For two weeks, that storm was the whole pitch. Every meeting opened with the same numbers. Nobody asked for a second kind of day, because the first one kept working.

Then, in the meeting where Ezra's team was supposed to size the sprint, one of his senior engineers asked something that wasn't really a jab. "This is all weather. What happens on a day the plane's fine but the crew's out of hours?" He hadn't meant to slow anything down. He'd just noticed nobody had shown him one.

Reya didn't have an answer. Nobody had run Glidepath against a crew-legality day, not once.

One of these you can walk back with a sentence. The other, once it's believed, has already cost you the next three weeks.

So instead of sending over the sprint estimate the way the plan called for, Reya pulled forty two real disruption days out of the ops log, already decided by Warrick's team, and ran the rough model against every one, the messy days included. It took her a weekend, plus Warrick's help pulling the files.

Twenty nine were weather days, the kind Warrick calls easy: ceiling drops, icing holds, the sort you can see coming an hour out. Glidepath matched his call on twenty seven of those. Thirteen were crew-legality days, the ones where a duty clock quietly runs out mid-afternoon and nobody notices until the crew's off the clock. Glidepath matched his call on five of those thirteen.

A month earlier, in the meeting where the team picked which day to build the demo around, someone had floated pulling a messier day instead, one with a crew swap buried in it. The storm already worked, and the messy days felt like something to test later, once the model was further along. Nobody wrote down that the storm would still be the only thing anyone had tested by the time Reya called it basically done.

I would go back and pick the messy day too. Not instead of the storm, alongside it. The storm proves Glidepath can do the job at all. The crew-legality day proves you know exactly where it stops.

With that change, here's the replay. Same forty two days, same weekend, but Reya's write-up leads with the gap, not the win: ninety three percent on weather, thirty eight percent on crew legality, untested past that. She sends it to Ezra before anyone estimates a sprint. His team spot-checks four of the crew-legality misses themselves, confirms the number is honest, and signs off in four days.

Three weeks later, her next proposal, a flag for gate-change cascades, gets the same treatment: name the gap first, then the numbers. Sign-off takes three days. The one after that, five. Compare that to the twenty one days her first post-storm proposal took, back when Ezra's team was quietly re-checking everything she sent them by hand.

What I'd tell myself, back in the meeting where the senior engineer asked his question: build the write-up around the day you're least sure about, not the day that made the best demo.

ORDER: the sentence that either earns trust or spends it

LEAD would fit if the question asked which metric proves the model is any good. This question sits earlier than that, which move a PM makes first, before any number gets to matter. That's ORDER's job.

Same order, a veterinary recovery tool instead of a delay desk

Marrowfield Veterinary Group built VitalWatch: a tool that reads vitals and wound-check photos after surgery and flags which pets need a vet's attention before their routine follow-up call, sparing techs from checking every discharge by hand.

Flashcards (click a card to flip it)

Check yourself Score: 0 / 0