The GTM engineer portfolio
A GTM engineer's portfolio documents systems rather than artifacts: for each one, the problem, what you built, the constraints you were working under, and what changed as a result — with the top layer kept short and the depth held in an appendix behind it. That structure exists because the work itself usually can't be handed over: it runs inside someone else's account, on someone else's data.
How do you build a GTM engineer portfolio?
Start from what a hiring manager is trying to find out, which is narrower than it feels. They want to know whether you have actually owned a system end to end, whether your judgment about what to build is any good, and whether you can explain a technical decision to someone who wasn't there. Everything in a portfolio either serves one of those or is padding.
So the unit is a system, not a deliverable. Two or three of them is plenty. For each, the reader needs the situation you walked into, what you built and why that rather than the obvious alternative, what constrained you, and what happened afterwards — including where it fell short. A portfolio of three systems described honestly beats a list of nine with the failures sanded off, because the second one reads as marketing and gets discounted accordingly.
Once your portfolio is built, you spend an hour walking an interviewer through it, answering their questions about the decisions behind it. The portfolio review round is written for the interviewer's side of that hour, and it tells them which questions to ask. Reading it while you are still deciding what to include shows you which parts of your portfolio will get pushed on.
The thing that makes this genre hard is that you usually can't show the system. It lives in an employer's account, it runs on customer data, and a screenshot of a workflow canvas tells a reader almost nothing. Every recommendation below is a way around that.
Length is the judgment test
Claude or Codex will write you forty pages about a system in an afternoon, so length no longer demonstrates effort and a reader knows it. What used to signal thoroughness now signals nothing at all, and a document that reads as generated gets skimmed at best.
What still costs something is deciding what to leave out. Compressing a nine-month project into a page someone can read in three minutes requires you to know which decision actually mattered, which detail is load-bearing, and which two months of work can be one sentence. That is the same judgment the job needs — knowing what matters and what doesn't is most of what a GTM engineer does all day — so the top layer of your portfolio is a working sample whether or not you meant it that way.
Hence progressive disclosure rather than brevity for its own sake. Nothing is lost: the depth goes in an appendix, and the reader who wants the full reasoning can get it. But the piece you actually want read stays short, and the decision about what belongs in it is the part being assessed. A hiring manager reading forty undifferentiated pages learns that you didn't make that decision.
Four ways to show a system, strongest first
These stack rather than compete — a strong portfolio piece uses several. They are ordered by how much a reader can verify for themselves, which is also roughly the order of how hard they are to produce.
-
01
Something they can click
A working thing a reader can open and poke at is worth more than any description of one, because it removes the question of whether it exists. A small internal tool rebuilt with fake data, a public demo of an agent, a repository someone can read.
Most people can't do this for their main work, and that is fine — it is a bonus rather than a requirement. When it's possible at all, it is usually possible for one piece, and one is enough to establish that the rest of the portfolio describes real things.
-
02
The diagram
A system's shape is spatial, and prose forces a reader to rebuild it in their head one clause at a time. One clear diagram of what flows where — sources, the steps, the decision points, where it lands — does the work of three paragraphs and does it better.
This is a real skill and it is worth practising deliberately, because most engineers draw badly and the gap is visible. Label the arrows. Show the failure paths, not just the happy one. Keep one diagram to one idea rather than drawing the entire architecture at once.
-
03
The two-minute walkthrough
A short recording of you moving through the system, narrating what it does and why, carries tone and command that text can't. It also proves you can explain your own work out loud, which is the thing the interview is going to test anyway.
Keep it to two or three minutes. Five is the outer limit and almost nobody watches to the end of it — a hiring manager with a stack of candidates gives you the first thirty seconds and decides from there. Script the opening, cut the tour of the login screen, and put the detail in the appendix where it can be skipped.
-
04
The written appendix
Behind the short piece, the full reasoning: what you considered, what the data looked like, the constraints, the things that broke, the version you'd build now. Nobody reads all of it, and that isn't the point — it's there for the one reader who wants to go deep, and its existence lets the top layer stay short.
This is the one place where more is fine. Just keep it clearly labelled as the appendix so nobody mistakes it for the thing you wanted them to read.
The trade-offs are the interesting part
Most portfolios describe what was built. The ones that get someone hired describe what was decided, and those are different documents. Anyone can build a working system given enough time; the question is whether you made good calls under the constraints you actually had.
So for each system, say what you knew at the time. What data existed and what you had to work around. What you gave up to ship when you shipped, and what that cost later. Which approach you rejected and why — the no-code version you didn't take, the model you decided wasn't worth the latency, the feature you argued out of scope. What you would build differently now, stated plainly rather than as a humblebrag.
This is also the part an assistant can't write for you, which is increasingly the point. A model can produce a competent description of an enrichment pipeline. It cannot produce the reason you chose a cheaper provider for the first pass, because that reason lived in a conversation about budget that only you were in.
Confidentiality without vagueness
The usual failure mode when work is sensitive is to blur everything, and the result reads as though nothing happened. "Improved efficiency across the go-to-market stack" is safe and worthless. The way out is to be precise about the structure and imprecise only about the identifying details.
Mechanics: name the industry rather than the company. Give ratios and multiples instead of absolute figures — a rate that went from four percent to eleven says something without revealing volume. Describe the data model without the real field names. Say what the system does, not who it was pointed at. Where you genuinely can't say something, say that you can't, which reads far better than a sentence engineered to sound like content.
Done well, this is itself a signal. Someone who can describe a system precisely while protecting their employer's specifics is demonstrating exactly the discretion their next employer will want applied to their own data. Check your employment agreement before publishing anything, and when in doubt ask rather than assume.
Frequently asked questions
How do you build a GTM engineer portfolio?
Document two or three systems rather than a list of deliverables. For each: the problem, what you built, the constraints, the trade-offs you made, and what changed as a result. Keep the top layer short enough to read in a few minutes, support it with a diagram and a two-minute walkthrough, and hold the full reasoning in an appendix behind it.
What if all my work is confidential?
Be precise about structure and vague only about identifying details. Name the industry rather than the company, use ratios instead of absolute numbers, describe the data model without real field names, and say explicitly where you can't go further. Describing a system accurately while protecting your employer's specifics demonstrates the discretion your next employer wants.
How long should a GTM engineer portfolio be?
The part you want read should take a few minutes. Length stopped signalling effort once assistants could generate forty pages on demand, so what a reader now reads as effort is compression — knowing which decision mattered and which two months can be one sentence. Put the depth in an appendix rather than cutting it.
Do I need a personal website for this?
No. A shared document, a slide deck, or a short write-up sent with your application all work, and hiring managers open whatever is easiest to open. Build a site if you enjoy it or if the site itself demonstrates something relevant; don't treat it as a prerequisite for showing your work.