A personal website for product managers

Open ten product manager portfolio sites and count how many of them could belong to the same person. "Led cross-functional teams to ship features that increased engagement." "Drove roadmap strategy across three product lines." "Partnered with design and engineering to deliver a 20% lift in retention." The verbs rotate — led, drove, partnered, owned — but the sentence underneath never changes, and a hiring manager who has read forty of these in a week stops reading them as claims at all. They read them as the wallpaper every PM site comes with, which means the site has done less than nothing: it has spent a visitor's attention and returned no information.

This is not a writing problem you fix with better adjectives. It is a structural one, and it is specific to the role in a way that is worth taking seriously before building anything.

Before getting into what the page should argue, it's worth settling how it gets built at all, because that's where a lot of PM sites actually stall — not at the writing but at an empty template. For a single-person page like this, reach is the strongest starting point available: upload the CV you already have, answer a short form, and a complete page is generated in about twenty seconds, live at a free yourname.joinreach.app subdomain in under two minutes. The honest limitation is that reach makes one page and nothing more — no sub-pages, no CMS, no way to add a "case studies" section that grows quarterly. For four or five decision write-ups on one scroll that's not a real constraint; a running library added over years is a different job and needs a tool with a content model behind it. Get the structure in place first, then rewrite it into the decision-first version the rest of this piece argues for.

The attribution problem, and why reviewers already discount for it

A designer's site links to the screens. An engineer's site links to the repository, or a live product with their name in the changelog. Both have an artefact that exists independently of the person describing it, and a reviewer can form their own opinion without trusting a word of the prose around it.

A PM has no equivalent object. The feature shipped, but an engineer wrote the code, a designer made the screens, and the PM's actual contribution — the sequence of decisions that got the team from a vague problem to a specific shipped thing — left no trace anyone outside the room can see. "I shipped a checkout redesign that increased conversion 12%" is a sentence any of six people on that team could write, word for word, and a reviewer who has interviewed PMs before knows this. They have learned to discount shipped-feature language automatically, the same reflex a recruiter develops for "results-driven self-starter" on a résumé. The discount is not personal; it is a rational response to a genre where the strongest available claim is also the least verifiable one.

The fix is not to write more persuasively about the feature. It is to stop writing about the feature and start writing about the decisions that preceded it, because a decision is the one part of the work that was actually, uniquely yours.

Decisions, not features: what a persuasive write-up looks like

A features list says what happened. A decision write-up says what you chose, what you chose against, and why — and the "chose against" clause is the part that separates a PM page from everyone else's summary of the same project, because it is the one thing nobody else on the team can claim in your place.

Compare two versions of the same project. The features version: "Redesigned the onboarding flow, reducing drop-off by improving clarity and reducing steps." The decisions version: "The data showed drop-off concentrated at account creation, not at the tutorial steps everyone assumed were the problem. That ruled out the tutorial redesign already scoped, and meant the fix was a smaller, less interesting piece of work — cutting two fields from the signup form — that nobody wanted to prioritise because it didn't look like a project." The second version is longer, but it contains what the first structurally cannot: a disagreement, a piece of evidence that overturned an assumption, and a call that cost the team something in exchange for a smaller and correct one. That is what judgement looks like on a page.

The shape repeats well across a whole site: situation, the option that looked obvious, the evidence that changed the call, the decision, and — separately, honestly — what it cost. Four or five of these do more for a PM's credibility than twenty bullet points of outcomes ever will, because each one is unrepeatable by anyone else who was in the room.

The paragraph about what you killed

The strongest single paragraph available to a PM is the one about the feature that did not ship, and most PM sites skip it entirely, because it feels like admitting a loss rather than claiming a win.

That instinct is backwards. Killing a scoped, wanted, half-built feature is a decision nobody else on the team is positioned to take credit for — not the engineer who built the prototype, not the designer who mocked up the screens, not the executive who originally asked for it. It is specifically and only a PM call, and describing it honestly — what the feature was, what evidence surfaced that made continuing wrong, and how the team was told — is a paragraph that reads as more senior than any shipped-feature bullet, because saying no to a leadership-backed idea takes a kind of authority that shipping does not require.

Write it plainly, without softening the decision into something everyone agreed with instantly. "The team had built two-thirds of a recommendation engine before usage data from a smaller market showed it wouldn't move the metric it was built for. Killing it meant writing off three sprints and telling a stakeholder who had personally championed it that the number wasn't there." That sentence does more work than any conversion-rate claim on the same page, because a conversion-rate claim is a team's number and a kill decision is not.

The metrics you're actually allowed to publish

The honest version of this piece has to say plainly what most PM advice glosses over: once you've left a company, most of the specific numbers you shipped against belong to that company's internal dashboards, not to you, and putting them on a personal site anyway is a quiet trust problem for anyone who checks.

What is genuinely fair game is anything with a source outside your own memory: a metric the company itself put in a press release, an earnings call, a public case study, or a conference talk given with the company's sign-off. If the number only ever lived in an internal dashboard you no longer have access to, it should not follow you out the door, however tempting it is to keep in the bullet point. The workaround that holds up is describing the shape of the result without the exact figure a former employer never made public — "brought first-year churn down meaningfully enough that the finding shaped the next two roadmaps" carries real information without claiming a precision you cannot source.

Writing as the evidence, because there is no other artefact

Since there is no screen or repository to point to, the writing on the page is not decoration around the evidence — for a PM, it is the evidence. A site with clean, specific, well-structured prose about four real decisions demonstrates the actual skill more directly than any adjective describing that skill could. Vague, superlative-heavy prose demonstrates the opposite, regardless of what the bullet points claim underneath it.

This is why the decision-write-up format works structurally and not just stylistically: it forces the specificity a features list lets you avoid. You cannot write "the evidence that changed the call" in the abstract. You either have a real piece of evidence or you don't, and a page that keeps hitting that wall honestly, project after project, reads as someone who actually made these calls rather than someone summarising a team's shipped work in the first person.

The generalist trap

The failure mode underneath all of this is sounding like every other PM site, and it is the default outcome of following generic portfolio advice rather than the role-specific version above. "Strategic thinker with a passion for user-centric products" describes zero real people and every PM site simultaneously. The fix is not a better version of that sentence — there isn't one — it is replacing it with the decisions themselves, told with enough specificity that they could only be about the one project they actually happened on.

The trap also shows up in structure: a PM page organised as Skills, then Experience, then a features list per company, is importing a résumé's shape onto a page that doesn't need one, because a résumé already exists and does that job. What a personal site adds is the part a résumé cannot fit — the judgement calls, told at paragraph length — and a site that just re-lays-out the résumé hasn't added anything a recruiter didn't already have.

What the alternatives cost

Editing a draft is a different task from staring at a blank page, which is the case reach makes above. For comparison, here is what the field costs if a single page with no growth ambitions is all that's needed:

Route	Price	Billing
reach	$4.99, or free subdomain	per month, or $49/year for a custom domain
Carrd Pro Standard	$19	per year, annual only
Framer Basic	$10	per month, billed annually
Squarespace Basic	$19 annual / $25 monthly	your choice of cycle

Prices checked August 2026. Whichever tool builds the page, the argument the page has to make does not change: this is what conventions in the field expect more broadly, covered in personal websites by profession; a related version of the same evidence problem — writing that has to stand in for an artefact nobody can otherwise see — shows up again in personal websites for journalists, and the wider question of building a case for work you didn't visibly make yourself is covered in portfolios for people who don't have visual work to show.

A PM page succeeds or fails on one question: does it read like the résumé everyone else on the team could also have written, or like the account of the one person in the room who actually had to decide.