The GTM engineer portfolio
A GTM engineer's portfolio documents systems: 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 needs to find out. 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.
Use a system as the unit of evidence. For each, give the situation you walked into, what you built, the alternatives you considered, the constraints, and what happened afterwards, including where it fell short. Choose a small set you can describe honestly and in depth.
To decide which systems make the cut, read a handful of live GTM engineering job postings and note the problems the hiring teams describe. The systems closest to those problems are the ones worth writing up first.
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
A long document is easy to generate, so length does not establish effort or judgment. Give the reader a concise first layer they can understand without the appendix.
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, so the top layer of your portfolio is a working sample whether or not you meant it that way.
Use progressive disclosure. 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
A portfolio piece can combine several of these formats. Choose the ones that help a reader inspect the system and your decisions.
-
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.
Confidentiality may prevent this for your main work, so treat it as optional. 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.
Practise this deliberately. Label the arrows, show failure paths, and keep each diagram focused on one idea.
-
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 the walkthrough short enough to review during an initial application screen. 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. It is there for a 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
Describe what you decided as well as what you built. The reader needs to see how you made calls under the constraints you 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.
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 when you cannot name the company. Give ratios and multiples when absolute figures are sensitive — 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 before publishing.
Frequently asked questions
How do you build a GTM engineer portfolio?
Document a small set of systems in depth. 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?
Make the first layer concise enough for an initial application review. Use it to show the decisions that mattered, then put supporting depth in a clearly labelled appendix.
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.