What is the right length and format for an AI PM portfolio piece?

Ridgeline Telecom is a fictional regional carrier. Kofi Asante, a former field network engineer, built Signalcheck there as his portfolio project: it reads an incoming outage ticket and ranks the three most likely root causes for the on-call engineer. Sunniva Berg, his mentor, has read a dozen drafts of his write-up, in four very different lengths.

How to answer this, stage by stage

Nobody is grading whether you can hit an exact word count. They're grading whether you can show your work sizing something that feels totally unmeasurable.

Let's learn

A portfolio page's length is really a bet about how long a stranger will keep reading before they decide whether to trust you.

Sunniva Berg has read a dozen drafts of Kofi's Signalcheck write-up. His first version ran two full pages, dense with architecture diagrams. She read the first third, skimmed the rest, and forgot most of it by the next morning.

His second version, written after Sunniva pushed back, ran four sentences and a screenshot. She finished it in under a minute, and had no idea what tradeoff, if any, he'd actually weighed.

Here's the turn: neither draft's real problem was word count. The two-page version buried one real decision under architecture nobody needed. The four-sentence version had no room left for the one thing that actually proves judgment: what Kofi tried and rejected.

At its worst: a candidate spends an entire evening either cutting a good page down to nothing or padding a thin page with detail nobody asked for, and ends up with a length that has nothing to do with what the page actually needs to prove.

What I would leave alone: the appendix can run as long as it wants. Screenshots, logs, a full architecture diagram, none of that needs a length limit, since a reader only opens it by choice.

The lesson: the right length isn't a number you pick in advance. It's whatever's left once you've included the one decision, the tradeoffs behind it, and the result, and cut everything else.

Now here is the same thing as a story

The short version above is what you'd say defending your page's length out loud. Read this one for how Kofi actually found his.

Kofi Asante spent six years climbing cell towers and reading outage logs before he ever wrote a line of a model prompt, and he can still tell a fiber cut from a router failure faster than most dashboards can.

His first draft of the Signalcheck write-up ran two pages: full architecture, every model he'd considered, every metric he'd tracked. It felt thorough. Sunniva read a third of it and stopped.

Two pages of the same length, and only one of them reads like somebody actually decided something.

Over three revisions, the page thinned in the wrong direction. Draft two cut the architecture but kept a long history of every version he'd tried. Draft three cut that too, chasing "concise," until draft four was four sentences and a single screenshot, with nothing left describing why he'd built Signalcheck the way he had.

A reviewer scans for length and bold text before reading a single sentence. If the decision isn't near the top, it may as well not exist.

Sunniva's question was small: "Which model did you rule out, and why?" Kofi realized his four-sentence draft had no answer in it at all, because he'd cut that section trying to hit a shorter page.

The same word count reads as padded or complete, depending entirely on whether a real decision is in it.

Rebuilding the page around five clear parts took Kofi about two hours, most of it spent deciding what to cut rather than what to add. The tradeoffs section, on choosing a smaller, faster ranking model over a larger, slower one, ended up the longest single part of the page.

Kofi's final page landed right in the middle of this range, with an appendix that most readers never opened, and that was fine.

The old draft asked Sunniva to wade through everything to find the one thing that mattered. The new one put that one thing where she'd actually see it, and let the rest wait in an appendix she could open or skip.

Kofi's four drafts moved through three of these corners before landing in the one that actually works: short, and dense with an actual call.

Chasing "concise" by deleting the tradeoffs section had felt like progress each time the page got shorter. It stopped feeling like progress the moment Sunniva asked a question the shortest draft had no way to answer.

I cut the tradeoffs section chasing a shorter page. It took one plain question to see I'd cut the one part that was ever going to prove anything.

BOUND, the page sized properlyNot a word-count rule. BOUND is what forces "how long should this be" to show its own arithmetic.

Five parts, and only the appendix is allowed to grow past its own budget.

The recap, one line per letter: break it down is the five-part equation, own numbers is each part's sourced timing, use a range is the two-to-eight-minute spread around a four-to-six-minute core, nail the sanity check is comparing it to a resume with a cover note, and direction is the tradeoffs section as the biggest lever.

And if you want to be sure it really works, try it somewhere elseSame five letters, a school district's scheduling tool instead of a fault ticket. A different building, and this time the sanity check is a school board meeting.

Oakmere School District is a fictional public school system. Greta Solvang built a class-scheduling assistant there, an AI tool that proposes conflict-free schedules for students with unusual course combinations. Baxter Hume reviews her write-up's length.

Mapped onto BOUND: break it down is total reading time equals the problem, the scheduling logic she chose, the tradeoffs against a simpler rules-based system, the result, and an appendix of edge cases. Own numbers: 25 seconds on the problem, since school scheduling needs almost no setup for a reader to picture, 70 seconds on the tradeoffs, since that section carries her hardest call, choosing a flexible model over a rigid rule engine the district already had. Use a range: about five minutes typical, two minutes best case, ten minutes worst case if a reader opens the edge-case appendix. Nail the sanity check: five minutes is shorter than one class period, which felt like the right scale for a tool meant to save exactly that much time per schedule. Direction: the tradeoffs section swings it most here too, since "why not just use the rules the district already has" is the one question every school administrator asks first.

The same tree applies here: a scheduling write-up with no stated tradeoff reads exactly as padded as Kofi's four-sentence draft did.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "about five minutes, five parts, tradeoffs get the most room," and stop.
Cost: there's no time to build a polished appendix this week. Skip it entirely; a page with no appendix still works, since the core five parts carry the whole argument on their own.
The model gets better, for real: if Signalcheck's ranking accuracy improves later, the page doesn't need to get longer to say so. One sentence in the result section and an updated number is enough.

Where people run it wrong.
They treat length as a taste question instead of something with a real, sourceable estimate behind it.
They cut the tradeoffs section first when trying to shorten a page, since it feels the most cuttable, when it's actually the part doing the most work.
They pad the problem-framing section instead, since it's the easiest part to write more of, and it's also the part that matters least.

How to use it live. When someone asks what the right length is, ask yourself one question first: which single part, if it ran long, would actually be worth the extra time. Size that part generously, and cut everything else to fit around it.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0