A portfolio when your work is not visual
Writers, analysts, engineers and operators have proof too. How to show work that produces documents and decisions, not screens.

Part of The portfolio that gets you hired, and the one that gets skipped
Someone tells you to build a portfolio, and the advice that follows assumes you have something to put in a grid: a screen, a poster, a photograph, a shot of a product in someone's hand. You don't. Your work is a spreadsheet that reconciled two ledgers that disagreed by a number nobody could previously explain, or a policy memo that changed how a claims team makes a judgement call, or a migration that moved four hundred thousand records off a system nobody wanted to touch and broke nothing on the way. None of that photographs. There is no hero image for "we noticed the join was wrong."
The templates don't help, because every portfolio template on the market was built by looking at what designers and photographers needed and generalising outward from there — a gallery, a lightbox, hover states on thumbnails. Pour a compliance rewrite into that shape and you get a title, a paragraph, and a lot of empty space where the picture is supposed to go. The honest response to that gap is not to force an image in — a stock photo of a laptop, a screenshot of a spreadsheet dressed up with a drop shadow — it is to notice that the format was wrong for the job and stop using it.
The unit is the decision, not the artefact
This is true for visual work too, and the case for it holds regardless of field: reviewers are not hiring your old output, they are hiring the judgement that produced it, and the only evidence for judgement is a record of judgement being exercised. For a designer that record happens to have a picture attached. For you it doesn't, and it turns out the picture was never the load-bearing part.
What a reviewer needs from each piece of work is four things, in words: what the situation was, what you specifically decided, what a competent peer might have decided instead, and what it cost. "Rebuilt the pricing model" is an artefact sentence and it tells a stranger almost nothing. "The old model priced renewals off list price, which overcharged our best customers and undercharged churn-risk ones; I switched the base to trailing usage, which meant a two-week gap where sales couldn't quote confidently while finance validated the new numbers" is a decision sentence, and it does something the first version cannot: it shows you knew the trade-off existed before you made it, and it names the cost rather than hiding it. A reviewer reading that sentence has enough to ask a real follow-up question in an interview. A reviewer reading "rebuilt the pricing model" has nothing to ask except "can you tell me more," which is a request for the version you should have written the first time.
This is also why a non-visual portfolio can end up stronger than a visual one, not weaker. A screenshot lets a reviewer assume it looks fine and move on. A decision, spelled out, cannot be skimmed the same way — it has to be read to be judged, and it invites the kind of scrutiny that favours people who actually did the thinking.
What to show when the artefact itself is off-limits
Most of what produced those decisions is confidential in a way a screenshot never is. The spreadsheet has a client's actual revenue in it. The policy memo names a real claims process a competitor could reverse-engineer. The migration plan has production database names in it. You cannot post any of that, and pretending otherwise is how people end up in trouble with a former employer over something that felt harmless at the time.
The fix is the same one that applies to any confidential work, and it holds up well for documents specifically because a document is easier to sanitise than a product screen. Redact the artefact rather than omitting it: a chart rebuilt with invented but proportionally faithful numbers, labelled as reconstructed; a policy excerpt with the client's name and identifying detail stripped, structure intact; a migration diagram redrawn with generic system names instead of the real ones. None of that reveals anything a competitor could use, and all of it does more work than a text description alone, because a reader can see the shape of what you actually built even though the specifics have been swapped out.
Two rules make this safe rather than misleading. First, say plainly that the numbers are reconstructed — "figures below are illustrative, rebuilt to the same proportions as the original" costs you one sentence and removes any question about whether you are presenting fabricated data as real. Second, keep the scale honest: if the actual reduction was 34%, write "roughly a third," not a number you never measured. A reviewer who later asks a specific question in an interview should hear an answer that matches what the page implied, not a walk-back. This is the same discipline covered in more depth for cases where the whole engagement is under NDA, where the difference between protecting a client and protecting yourself gets more specific.
Three short write-ups beat one long one
The instinct, once you've accepted that writing carries the weight, is to write everything you know about the one project you're proudest of. Resist it. Length reads as enthusiasm to the person writing it and as work to the person reading it, and a reviewer giving your page ninety seconds will not finish four screens of prose about a single migration no matter how well argued it is.
Three write-ups, each three or four short paragraphs, chosen for range rather than depth, does more for you than one exhaustive account. Range means picking decisions that show different kinds of judgement — one that was mostly analytical (the reconciliation), one that was mostly about persuading people who disagreed with you (the policy change), one that was mostly about managing risk under a deadline (the migration) — so a reviewer finishes three short pieces having seen three different situations you can operate in, rather than one situation described three ways. That is a genuinely different signal, and it is the same argument this publication makes about how many projects belong on a portfolio generally: a set is judged as a set, and a fourth mediocre entry lowers the average of the three good ones sitting next to it.
Each write-up should be readable in under a minute and end with a stated cost, not just a stated win. "This raised approval accuracy and slowed the team down for the first quarter while people adjusted" is a sentence a reviewer trusts. A write-up that reads as an unbroken string of successes reads as marketing, and gets discounted the way marketing always is.
The container: one page, and why that's usually correct here
Once the writing exists, the temptation is to reach for a site builder with sections, navigation and a blog, because that's what "a website" has come to mean by default. For this kind of portfolio it's the wrong instinct. Three decision write-ups, a line about what you do, and a way to get in touch fit on a single scroll, and a single page has a property multi-page sites don't: it is finished the day you publish it. There is no Insights tab sitting empty, no About page nobody wrote, nothing half-built for a visitor to stumble into.
reach is built around exactly this shape and is worth
naming because it starts from the one document a spreadsheet-and-memo career already
has — the CV — rather than an empty canvas. You upload a résumé and a photo, answer a
short form, pick a look, and the page is generated in about twenty seconds; you can be
live at a free yourname.joinreach.app subdomain in under two
minutes. What you get from the CV is the shell — the timeline, the role, the framing —
and the three decision write-ups go in as the "own projects" section, in your own words,
because that judgement is the part no generator can write for you.
The limitation is worth stating as plainly as the speed: it makes exactly one page. There are no sub-pages, no navigation between pages, and there is no CMS — content comes from the CV and the profile, with no collections and no editorial workflow layered on top. That is fine while the portfolio is three write-ups. It stops being fine the moment you're publishing a fourth, fifth and sixth over the following year and want them to accumulate into something a returning visitor can browse, because there is nowhere for them to accumulate to. Someone who expects to be adding a new write-up every quarter is choosing a container that will need replacing on its own schedule, not because reach did anything wrong, but because a growing library and a single fixed page are two different products. Know which one you're actually building before you pick.
Have someone else read it before it goes live
The last step matters more here than in almost any other kind of portfolio, because the whole case rests on claims a reader cannot verify by looking at a picture. A designer's portfolio can be wrong about the story and still show real, checkable work. Yours cannot — if the write-up says the reconciliation found a discrepancy and fixed it, that claim is either true or it isn't, and there is nothing on the page a stranger can independently check.
So before it goes live, get a colleague who was actually there to read the three write-ups — not for grammar, for accuracy. Did you actually make that call, or did you implement a call someone above you made? Is the cost you named the real cost, or a softer one that reads better? People round their own contribution upward without noticing, especially months after the fact, and a former teammate is the cheapest and most reliable check against that. It is also the check that protects you the hardest if you ever end up in an interview with someone who worked on the same team and remembers it differently. The version that survives that conversation is the only version worth publishing, and for product managers building the same kind of evidence-first page, the same review step is the one people skip most often and regret skipping first.
Questions people ask
- What do I put in a portfolio if I don't have anything visual to show?
- Write up the decisions your work involved — situation, options, the call you made, what it cost — rather than trying to invent something to display. A spreadsheet, a policy or a migration plan is proof of judgement even without a picture attached to it.
- Is it okay to change the numbers in a portfolio write-up?
- Yes, as long as the shape of the result survives. Scale a real 34% reduction to "roughly a third" and the reasoning still holds; invent a number that was never measured and it does not, and a technical reader will usually be able to tell.
- How many write-ups should a non-visual portfolio have?
- Three, chosen for range rather than volume. Three decisions that show different kinds of judgement beat one exhaustive account of a single project, because a reviewer is trying to predict how you think, not how much you did.
- Do I need a website at all if my work is just documents?
- You need a page, not a document library. One page that states what you do and walks through three decisions is easier for someone to trust than a folder of PDFs, because it has been written for a stranger rather than assembled for an audit.