Here's the situation I was trying to fix.
I had real, tested AI workflows—a reporting system, a meeting-notes process, a resume-rebuild method. Every one of them was built inside my job, on my employer's data, for my employer's benefit. Which meant that when I wanted to show what I could do, I had nothing I could show. The work was confidential. The workflows were mine. The evidence wasn't.
This is the problem with building a portfolio out of your day job: the most impressive proof is the least shareable. And the standard advice—"build a portfolio of personal projects"—usually means inventing projects that aren't connected to real work, which is exactly the kind of untested material this site argues against.
The answer isn't to fake projects. It's to extract the method from the confidential work and rebuild it on data you own. This piece is how I did that, and it's the final Career Move Lab entry.
Why the Standard Portfolio Advice Fails
Three reasons, and they're specific to professionals who already have real work.
Your Best Work Is Under NDA
The workflows that prove you can do the job are the ones you built for an employer. You can describe them in general terms. You can't show the data, the deliverable, or often the specifics of the process. A portfolio of vague descriptions proves nothing.
Personal Projects Feel Like Hobbies
"Here's a dashboard I built for fun" reads differently than "here's a system I built to solve a real problem." The first is a hobby. The second is evidence. When your real work is confidential, it's tempting to manufacture projects—and manufactured projects read as manufactured.
Employers Don't Want a Showcase, They Want a Signal
Nobody hiring you is looking for a gallery. They're looking for one thing: evidence that you can do the work they need, on problems like theirs. A portfolio that communicates that in one artifact beats a portfolio of ten polished-but-irrelevant pieces.
The Method: Extract, Rebuild, Document
Three moves. The point is to preserve the credibility of real work while making it shareable.
Move 1: Extract the Method, Not the Artifact
You can't share the report you built. You can share the shape of the process: the steps, the decision points, the human-judgment steps, the constraints.
For each piece of confidential work, write down:
The problem: what was broken, in one sentence.
The approach: the sequence of steps you took.
The judgment points: where a human had to decide something.
The constraints: time, data, tools, politics.
The outcome: what changed—in relative terms if the absolute numbers are confidential.
This is the raw material. It contains no confidential data and no employer-specific details. It's the method, which is yours.
Move 2: Rebuild It on Data You Own
Now take that method and run it on a public or synthetic dataset, or on your own data. Same steps, same structure, different inputs.
For example:
The reporting workflow you built for your employer → rebuild it as a public walkthrough using a public dataset, showing the same steps.
The meeting-notes system → document it as a process guide, with a fictional transcript as the example.
The resume-rebuild method → run it on your own resume, showing the before and after.
The rebuild is what makes it shareable. It's also what proves the method is transferable—that it doesn't depend on your employer's specific context. That's a stronger signal than the original work would have been, even if you could show it.
One caution: the rebuild has to actually work. If you take a method and run it on data it wasn't designed for, it may fail. That failure is useful—it's a finding about the method's limits—but it belongs in the portfolio as a limitation, not hidden. A rebuilt method that works on new data is proof. One that's fudged is worse than nothing.
Move 3: Document It as a Case Study, Not a Showcase
Structure each portfolio piece the same way:
The problem. One paragraph. What was broken and why it mattered.
The approach. The steps, with the judgment points called out.
The rebuild. What you did with public or owned data, with the artifact linked or shown.
The outcome. What changed, in defensible terms.
The limits. What the method doesn't handle, and when it wouldn't apply.
The "limits" section is the differentiator. Most portfolios show polished successes. A portfolio that names its own boundaries reads as tested and honest—and it's the thing interviewers actually probe.
The Before and After
Same capability, two portfolio entries.
Before (confidential, unusable):
Built a weekly reporting system for my company that cut production time significantly and improved accuracy. Details confidential.
This says nothing. It could be true or not. A reader has no way to evaluate it.
After (extracted, rebuilt, documented):
Problem: A weekly operations report took four hours to produce and frequently had errors from manual data pulls.
Approach: Consolidated three manual pulls into a single query, added a validation step, and restructured the output as a decision brief rather than a data dump. The judgment points were deciding which metrics mattered to the reader and writing the two-sentence interpretation.
Rebuild: I ran the same method on a public retail dataset (linked), producing a weekly brief with the same structure. The walkthrough shows the query consolidation and the validation step.
Outcome: In the original setting, production time dropped from four hours to ninety minutes and error reports stopped. The rebuild demonstrates the method works on unfamiliar data, though it required more manual validation for the first two weeks while the data quality was uneven.
Limits: The method assumes reasonably consistent source data. It doesn't handle schema changes gracefully and would need adjustment if the input format shifted regularly.
The first one is a claim. The second one is evidence—and it's entirely shareable, because nothing in it belongs to the employer.
What Still Needs You
The parts of this that can't be automated or templated:
Deciding what's shareable. The line between method and confidential detail is a judgment, and it's a legal and ethical one. When in doubt, err toward abstraction. A model can help you draft, but it can't know what your NDA covers.
Doing the rebuild. The rebuild is the work that makes the portfolio credible. If you skip it and just describe the method, you're back to claims.
Being honest about the outcome. Confidential outcomes often can't be quantified. "Error reports stopped" is defensible. "Improved accuracy by 40%" may not be, if you can't show the calculation. Honesty here is what makes the rest credible.
Writing the limits. Naming what your method doesn't do is uncomfortable and essential. It's the part that signals you've actually tested it.
Choosing which pieces to include. One strong case study beats five weak ones. The judgment is which of your workflows best signals the capability you're selling.
The model can help you extract and write. You decide what's shareable, do the rebuild, and stand behind the limits.
The One-Portfolio Version
If you have confidential work and want something to show:
Pick one workflow that best demonstrates the capability you want to sell.
Extract the method: problem, approach, judgment points, constraints, outcome. No employer data.
Rebuild it on public or owned data. Actually run it. Note what breaks.
Write it up as a case study with problem, approach, rebuild, outcome, and limits.
Show it to one person in the field. Ask what they'd want to know more about.
One case study, done honestly, will outperform a portfolio of polished claims. And the process is repeatable—each confidential workflow becomes one shareable piece, and the collection grows without you ever showing anything you shouldn't.
The work you can't show isn't a dead end. It's the source material. The method is yours to rebuild and show, and the rebuild is what proves it travels.
Better work first. More options next.
Make the workflow earn its place.
No feedback yet — submit the first.