How would you document the tradeoffs you rejected, and why does that matter?

Harborlight Civic Fund is a fictional civic-tech nonprofit that helps small community groups find and apply for grants. Solveig Tjaden built Civora there as her portfolio project: it reads a group's project description and matches it against open grant programs, then drafts the eligibility case. Tobias Wexler, a former AI PM, mentors her through the write-up.

How to answer this, stage by stage

Nobody is grading whether you can list what you didn't build. They're grading whether your list is something they could actually check.

Let's learn

A rejected-tradeoff record is a short note that says what you didn't build, and exactly what would have to be true for you to reconsider it.

Tobias Wexler mentors AI PM candidates through their portfolio write-ups. For a long while, he took a narrative paragraph like "I considered X, but Y felt safer" at face value, since it read like real reasoning.

Lately, across dozens of mentee reviews, Tobias has noticed something. A narrative-style rejection now costs him about eight minutes of probing before he trusts it, if he ever does. A structured record, with a real number in it, costs him about ninety seconds, because the record is basically pre-answered.

More narrative detail never made Tobias trust a rejection more. A longer story explaining a decision he can't check is just a longer thing to stay suspicious of.

At its worst: a candidate who genuinely made the right call loses an entire interview's momentum, not because the decision was wrong, but because the way it was written gave the interviewer nothing to check.

What I would leave alone: the tone and personal voice in the rest of the write-up still matter and should stay free-form. Only the rejected-tradeoff claims themselves need the structured format.

The lesson: a record beats a story, not because it's more honest, but because it's checkable. Checkable is the only kind of honest an interviewer can verify in twenty minutes.

Now here is the same thing as a story

The short version above is what you'd say defending your documentation habit out loud. Read this one for how Solveig actually built hers.

Every Sunday night, Solveig Tjaden used to update a running note of everything Civora got wrong that week, a habit left over from three years as a grants coordinator, where she'd learned which rejections actually stung a small nonprofit and which ones didn't matter at all.

In her first weeks building Civora, she wrote full paragraphs the moment she made a real call. One entry, from an early Tuesday, ran six sentences on why she'd picked precision over recall for the eligibility matcher.

A story only has to sound right the first time someone hears it. A record has to survive being checked a second time.

The habit thinned in three beats. Three weeks in, tired on a Sunday night, she started summarizing each tradeoff in one line instead of a paragraph. By the time she wrote her actual portfolio page, months later, she wrote from memory: "we chose precision over recall because false positives hurt trust more." It sounded reasonable. It also wasn't quite the reasoning she'd used in the moment, and she'd genuinely forgotten the number behind it.

Then Tobias, reading her draft, asked one plain question: "What number made you pick precision over recall? What would have to happen for you to flip that?" She didn't have an answer beyond "it felt safer."

One unanswerable question rarely stays contained to itself. It spreads doubt across every other claim on the page.

Solveig spent the next four hours digging through old Slack messages and a private spreadsheet she'd kept of Civora's weekly eval runs, a workaround she'd built for herself since the tool itself kept no history of its own. She found the real number: a false positive, a wrongly suggested grant, cost a small nonprofit about 40 minutes re-verifying eligibility it never actually had, while a false negative, a real match Civora missed, cost about 10 minutes of extra manual search.

The real decision happened in week 5. The write-up describing it got written months after launch, from memory alone.

The real cost was never the four hours spent rebuilding the record. It was that without her old spreadsheet, that number would have been gone for good, replaced by a guess that sounded just as confident.

Back on that tired Sunday night, cutting her notes down to one line each had felt harmless. It saved her maybe fifteen minutes a week, and the project felt basically done. It stopped feeling harmless the day someone asked her to defend a number she no longer had.

The exact same sentence reads two different ways, depending only on when it got written down.

The next rejected tradeoff Solveig logged, choosing a smaller local grants dataset over a larger national one to train the matcher, took her twelve minutes to write as a full record, kill signal included. When Tobias read it, his one real follow-up question was already answered in the same paragraph, and he moved to her next project in under two minutes.

The old note asked Tobias to trust her memory. The new one gave him the exact number her memory used to hold.

I cut the full version to save fifteen minutes a week. It cost me four hours later, and it nearly cost me the one number that proved I'd made a real call at all.

PICK, in one screenNot a style preference. PICK is what forces a documentation choice to name its own hidden cost.

Naming the exact signal is the step most candidates skip, since it forces a number they don't yet have.

Five short lines. All five fit on one sticky note, and that's the point.

The recap, one line per letter: position is a structured record over a story, impact is minutes spent by reader versus writer, cost asymmetry is a hidden cost versus a visible one, and kill criteria is skipping the formal record for the earliest, still-forming ideas.

And if you want to be sure it really works, try it somewhere elseSame four letters, a container port instead of a grants office. The kill signal this time is a missed-anomaly rate, not a minute count.

Kessling Port Authority is a fictional container port. Rutger Voss built an AI tool there that prioritizes which containers get a full inspection. Nadia Furstenberg reviews his portfolio write-up.

Mapped onto PICK: Rutger's position was picking a faster, cheaper anomaly-detection model over a slower, more thorough one. The impact: inspectors feel the visible cost, an occasional slow queue if the faster model misses something subtle, while the port feels the hidden cost, a shipment held for days over a false alarm from an overcautious slow model. The cost asymmetry: false alarms from the slow model cost the port real money and time on every occurrence, while a true miss from the fast model is rare, but far more serious when it happens. Nadia pushed him past a vague "the fast model felt like the right balance" until he named a real kill criterion: if the missed-anomaly rate in production ever crossed one flagged case per thousand containers, he'd switch back to the slower model, no exceptions.

A named rate, not a feeling, is what let Nadia stop probing after one read.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "I log the option, the reason, and the number that would flip it, right when I make the call," and stop.
Cost: there's no time to write a full record for every idea you drop in a single afternoon of exploring. Save the format for the choices that actually shipped, or that a reader would reasonably ask about.
The model gets better, for real: if Civora's matching accuracy improves later, the old kill signal doesn't disappear, it just means the number that would flip it should get re-checked, not deleted.

Where people run it wrong.
They write a narrative explanation because it feels more personal, and it reads like spin the moment someone probes it.
They write the record weeks after the decision, from memory, and quietly change the reasoning without noticing.
They state a kill signal once and never check it again, which makes it decoration, not a real decision rule.

How to use it live. When someone asks how to document a rejected tradeoff, ask yourself one question first: what number would make me reverse this. Say that number out loud before you say anything else about your reasoning.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0