What should you avoid putting in an AI PM portfolio?

Cascade Wireless is a fictional telecom carrier. Saoirse Mullally built a tool there that summarizes long customer-complaint transcripts for escalation agents, so an agent can catch up on a case in seconds instead of scrolling through a full call log. Ekene Bassey, her mentor, reviewed the portfolio draft Saoirse built after leaving the company.

How to answer this, stage by stage

Nobody is grading whether your project looks impressive. They're grading whether you know exactly who could get hurt by how you chose to show it.

Let's learn

A complaint-transcript summarizer is a tool that reads a long, messy customer conversation and gives an agent the short version: what happened, what the customer wants, what's already been tried.

Ekene Bassey has reviewed dozens of AI PM portfolios. In a recent stretch of reviews, she checked each one specifically for real, identifiable customer or employer data, something most candidates never think to scan for on their own.

Across those reviews, a striking share of portfolios had at least one real identifiable detail sitting somewhere in a screenshot, usually one the candidate had genuinely stopped noticing.

Here's the turn: the problem was never that these candidates were careless people. It's that a screenshot you've looked at fifty times during development stops looking like real data to you, even though it's still real data to everyone else.

At its worst: a portfolio piece gets shared widely, a former customer or colleague recognizes their own complaint or their own name, and what should have been a proud, persuasive artifact becomes a real complaint about the candidate instead.

What I would leave alone: describing the tool's general purpose, its architecture, and its aggregate, non-identifying metrics is completely fine to include in detail. None of that requires a real person's data to be persuasive.

The lesson: the fix for a privacy problem in a portfolio is never "blur it a little." It's rebuilding the example so there was never a real person in it to begin with.

Now here is the same thing as a story

The short version above is what you'd say defending your portfolio's data choices out loud. Read this one for how Saoirse almost got it wrong.

Saoirse Mullally spent five years handling escalated complaints herself before she ever built a tool for the job, and she can tell within a sentence whether a customer just wants to be heard or genuinely wants a refund.

Leaving Cascade Wireless to job-hunt, she wanted her portfolio to feel real, not like a sanitized demo. She pulled three of her favorite screenshots from actual escalation cases, the ones that best showed the tool catching a detail a tired agent had missed.

One of these two people is choosing what gets published. The other doesn't know a choice is being made at all.

Adaeze, reviewing the draft on a video call, asked Saoirse to zoom into the corner of the second screenshot. A phone number, mostly cropped out, was still legible enough to read the last six digits clearly.

Nowhere in this chain does the customer ever get a chance to say no. That gap is the whole problem.

Saoirse hadn't noticed the number at all. She'd looked at that exact screenshot dozens of times while building the tool, and it had stopped registering as a real customer's actual phone number months ago.

Blurring one field isn't the same thing as making a screenshot safe. Only a full rebuild actually is.

Rebuilding all three examples with invented names, invented account numbers, and realistic but fabricated complaint text took Saoirse about four hours. The complaints still felt real, since she wrote them from genuine patterns she'd handled for years, just with no actual person behind any of them.

Every one of these four had to be true before Saoirse could trust the screenshot was actually safe to publish.

The real cost was never the four hours of rebuilding. It was that the original screenshots would have gone out to dozens of hiring managers, with a real person's phone number sitting quietly in the corner the whole time, if Adaeze hadn't happened to zoom in on a video call.

A cropped real screenshot and a well-built synthetic one can look equally convincing. Only one of them still points back to a real person.

Using real screenshots had felt like the honest choice, proof the tool actually worked on real, messy data instead of a tidy demo. It stopped feeling honest the moment Saoirse realized "honest about the tool" and "fair to the customer in it" were two entirely different things.

I used real screenshots because they felt more convincing than anything I could invent. It took one zoomed-in phone number to see that "convincing" and "fair to the person in the photo" were never the same test.

GUARD, applied to your own portfolioNot a compliance checklist. GUARD is what forces you to name the person who never gets a say in your own story.

None of these five require a policy document to avoid. They just require noticing them before you publish.

The recap, one line per letter: groups is naming both Saoirse and the customer, unequal is the one-sided benefit, ability to contest is the customer's complete lack of a lever, reduce is the full rebuild with invented data, and detect is zooming in and getting a second reviewer.

And if you want to be sure it really works, try it somewhere elseSame five letters, a public library's patron-question tool instead of a phone company. A different building, and the subject this time is a curious kid, not an angry customer.

Millbrook Public Library Network is a fictional library system. Piotr Zawadzki built an AI tool there that answers patrons' reference questions and logs the exchanges to improve over time. Aisling Doyle reviews his portfolio draft.

Mapped onto GUARD: the groups are Piotr, choosing what logs to show, and the actual patrons, including minors, who asked genuine, sometimes personal questions through the tool. The imbalance: Piotr gets a compelling real-world example; a patron, possibly a teenager researching a sensitive health topic, gets their question permanently attached to a public job-search document. The ability to contest is the same gap: no patron ever agreed to have their reference question used this way, and none of them will ever know it happened unless someone tells them directly. The reduce step here is identical in spirit: invent realistic reference questions instead of using logged real ones, however harmless a single question might seem on its own. The detect step adds one more layer specific to a library: checking not just names, but any combination of details, a specific rare book title plus a branch and a date, that could narrow a question down to one identifiable person even with no name attached at all.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "rebuild every example with invented data, and get a second reviewer before you publish anything," and stop.
Cost: there's no time to write a full new synthetic example before tomorrow's interview. Use a rougher, clearly-labeled placeholder over any real customer data, every time, no exceptions.
The model gets better, for real: even if a candidate's AI feature becomes far more accurate later, that's never a reason to relax which examples are safe to publish. Accuracy and consent are two completely separate questions.

Where people run it wrong.
They assume blurring one field, like a name, makes a screenshot safe, when other visible details can still identify someone.
They only check their own examples once, at a glance, instead of zooming in or asking someone else to look.
They treat this as a legal or compliance question instead of a real fairness question about a specific person who never got a vote.

How to use it live. When someone asks what to avoid in a portfolio, ask yourself one question first: is there a real person in this example who never agreed to be here. If the honest answer is yes, that example doesn't go in, no matter how good it looks.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0