How do you show product judgement rather than technical execution in a portfolio?

Owen Mackey spent six years as an HVAC field technician before moving toward product work. His portfolio project is a diagnostic assistant for Ferncrest Mechanical Services, a mid-sized HVAC service company: it suggests likely causes for a unit's fault codes before a technician even opens the panel. Bridget Calloway hires AI PMs, and she's seen plenty of technically polished portfolios that never once show her how the candidate actually thinks.

How to answer this, stage by stage

This isn't a portfolio-formatting question. It's asking whether you understand that a hiring panel is evaluating your thinking, and that clean code alone doesn't show them any of it.

Let's learn

Picture two portfolio pieces, built by two equally skilled people, that leave a reviewer with completely different impressions.

Before Owen rewrote his, the project page opened with architecture details: which model, which features, a validation accuracy of 91%. No sentence anywhere explained why he'd made a single one of his design choices.

After the rewrite, the page opens with the fault-code ranking decision, names the frequency-based approach he rejected, and only then gets to the model and the accuracy number, now framed as proof the chosen approach actually works.

At its worst: a technically excellent candidate gets hired on the strength of clean code and a strong accuracy number, and three months in, it turns out every design choice was picked by trial and error, with no real reasoning behind any of it.

What I would leave alone: the model architecture and accuracy number still belong on the page. They're just not the opening argument anymore. Once a reviewer has seen the reasoning, the technical detail becomes proof it actually holds up.

The lesson: execution answers "can this person build it." Judgment answers "should this person be the one deciding what gets built." Only one of those is actually the job.

Now here is the same thing as a story

The short version above is what you'd say defending your own portfolio's structure. Read this one for how Owen actually found the fix.

Owen could stand in front of a rooftop unit throwing three fault codes at once and know, within a minute, which one was the real problem and which two were just noise from the same failure.

His first portfolio draft read like a technical report: model choice, feature engineering, validation split, a clean 91% accuracy number sitting at the top like a trophy.

One kind of gap gets caught in the first five minutes. The other one hides behind good-looking work until it doesn't.

He got through three interviews on the strength of that draft, and each time the same thing happened: a technical question he could answer fine, followed by silence when asked why he'd made a specific design choice at all.

The reviewer's real decision happens at the second stop, not the first. Owen's old draft had almost nothing waiting there.

Bridget, reviewing his draft as a favor, put it plainly: "I believe you can build this. I have no idea if you decided to build it this way for a reason."

Owen's draft sat in the corner with the most polish and the least judgment shown. That corner is more common than it should be.

He spent a weekend rewriting the page from the decision outward: the fault-code ranking choice first, the rejected frequency-based approach named plainly, and one wrong call owned honestly, a threshold he'd set too aggressively at first and had to loosen after testing.

Four parts, and none of them require the code underneath to be any cleaner than it already was.

The decision comes first now. The build comes after, as evidence the decision actually worked.

Judgment and execution both belong on the page. They're just answering two completely different questions.

The old draft asked Bridget to infer judgment from clean code, which she couldn't do reliably. The new one hands her the reasoning directly, and lets the code sit underneath it as proof, not as the argument itself.

I built the technical section first because it was the part I felt most confident about, and I assumed the reasoning would come through on its own if the work was good enough. Hearing Bridget say she had no idea if I'd decided anything on purpose is what showed me good work was never going to speak for the decisions behind it.

PICK, on judgment versus executionNot a style preference. A question about which gap actually costs more.

The recap, one line per letter: position is judgment before execution, always, unless the role says otherwise; impact is that either extreme misleads a reviewer in a different way; cost asymmetry is the hidden, expensive judgment gap beating the cheap, visible execution gap; and kill criteria is a genuinely engineering-heavy role flipping the emphasis back.

And if you want to be sure it really works, try it somewhere elseSame four letters, a textile quality-inspection project instead of HVAC diagnostics. A different candidate, and this time the rough edge was in the judgment write-up itself.

Tobias Kemp built a fabric-defect flagging tool for a small textile mill's quality-control line. Applied to PICK: position is still judgment first. Impact: a reviewer seeing only Tobias's clean defect-detection code can't tell if he understood which defects actually mattered to a buyer versus which were merely visible. Cost asymmetry: same shape, a rough interface gets forgiven quickly, but Tobias's first write-up had the opposite problem, confident judgment language with no specific rejected alternative named, which read as vague rather than reasoned. Kill criteria: for this specific role, a hands-on textile-manufacturing engineering team, the panel actually wanted more technical depth than Tobias initially included, since defect classification accuracy genuinely mattered to their day-to-day process.

The same four parts apply, but here the missing piece wasn't execution polish. It was a specific enough rejected alternative.

Swap the trigger and it still runs.
Speed: an interviewer wants your answer in ten seconds. Say "lead with the decision you made, not the code that carried it out," and stop.
Cost: you don't have time to polish the build at all. Ship it rough and spend the saved time writing the judgment call clearly instead.
The role shifts, for real: if a role turns out to be more engineering-heavy than expected, the position doesn't disappear, it just moves down the priority list, behind a real technical deep-dive.

Where people run it wrong.
They treat a high accuracy number as if it speaks for the judgment behind it, when it doesn't.
They write about judgment in the abstract, "I carefully considered trade-offs," without ever naming the specific alternative they rejected.
They assume more polish always helps, when polish spent on low-stakes parts of a build is polish not spent proving judgment.

How to use it live. When asked how to show judgment over execution, answer with the concrete move itself: name one alternative you rejected, and why, before describing anything you built. That single sentence does more work than any amount of code.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0