The Products You Didn’t Build Belong on Your CV
How to evidence the work that never ships, including the decisions that saved time, money, and effort by not building.
Ask a designer for proof of their work and they send a portfolio. Ask an engineer and they send a GitHub profile. Ask a product manager and you usually get a list of launches, a few percentages, and a link to an app store page.
That list shows what a team produced. It leaves out the half of the job that happens before anything gets built: deciding what deserves to exist, and stopping what doesn't.
In nine years of product work across telecom, banking, and fintech, some of my best calls left no trace on a launch list. I cut scope that would have delayed a regulated go-live. I argued against features that looked good in a roadmap review and had no customer pull behind them. I recommended against building a product for the segment leadership had chosen. Each of those was a product decision with real consequences, and none of them has a URL.
Yet each one saved the company something real: engineering months that went to better bets, budget that wasn't spent on a product nobody would use, and effort the team never had to undo.
If you're a PM trying to show your value, including the work that ended in "no," here is a way to do it using a tool you already know.
Most of your work has no URL
The launch is the visible tip. Underneath it sits the discovery that proved a segment too small to serve, the feature you removed three weeks before release, and the product you recommended shutting down after the data came in.
Stopping is some of the most valuable work a PM does. When Steve Jobs returned to Apple in 1997, one of his first moves was cutting the product line down to four: a consumer and a pro machine, each in desktop and portable form. Nobody describes that as a failure to ship. Yet most PM CVs have no way to express a call like it, because the format rewards things that launched and moved a metric.
The fix is to treat decisions as your unit of evidence, whether the decision was to build, to change course, or to stop.
Why this matters more in the age of AI
AI tools can now turn an idea into a clickable prototype in an afternoon. That speed is useful, and it also means building is no longer the scarce part of product work. Knowing what deserves to be built is.
A prototyping tool works from the prompt it's given. A product manager works from the full context: the customers they've sat across from, the workflows they've watched people struggle through, the regulator's constraints, the company's strategy, and the trade-offs the team can realistically carry. That context comes from meeting customers and observing what actually happens, and it's where product judgment lives.
In the worked example below, no prototype would have revealed that the target segment already had a better-fit solution. That came from talking to them. As building gets cheaper, the evidence that sets a PM apart shifts even further toward decisions: what you chose, what you cut, and why.
Use a map every PM already reads
Teresa Torres's Opportunity Solution Tree is the closest thing product management has to a shared language for discovery. A desired outcome sits at the top. Customer opportunities branch beneath it, candidate solutions hang under each opportunity, and assumption tests hang under each solution. When a team serves more than one audience, Torres places customer segments at the top of the tree as well. Most product leaders can read one in seconds, and she publishes a free FigJam template for building your own.
That familiarity is why it works as proof. You don't need to teach a hiring manager a new format. You need to show them your tree, filled in with what actually happened.
A worked example
On a regulated financial product I worked on, leadership wanted to target institutional investors. The PRD connected the company vision to the product goal and objectives, and the problem statement was solid.
Before anything was built, I ran one-to-one interviews with the target segment. Two findings changed the plan. The segment already used a solution that fit their usage and needs better than what we planned to offer. And liquidity limits set by the regulator removed the advantage our product would have given them.
I went back to leadership with a recommendation not to build for that segment, along with an alternative: the same regulatory limits suited retail users, where similar products already proved demand. Leadership approved the pivot.
Before defining features, I tested competitor products hands-on and scored each one by area, then went through app reviews and social media to find the weaknesses users complained about most. The feature set was built around those gaps, and the product went on to be licensed, targeting the segment more likely to use it.
The dropped opportunity branch stays visible, marked as explored and dropped, with the evidence that stopped it.
Mark the branches you cut, and why
The tree in its usual form captures discovery in progress. To turn it into evidence, annotate it after the fact:
Mark the opportunity or segment you chose, with one line on why it beat the others.
Keep the branches you dropped visible, with the evidence that dropped them.
Note the constraints that ruled options out, whether regulatory, capacity, or strategic.
In the example above, the most important branch on the tree is the one that was never built. It shows discovery done before engineering spend, an executive hypothesis tested against evidence, and a recommendation that gave leadership a viable path instead of a dead end.
Close the loop with a result
The tree has the same blind spot as the PRD. The PRD holds the hypothesis, the discovery, and the definition, then stops. Results end up in a dashboard, a quarterly slide, or someone's memory.
Put the result back on the tree. If it shipped, show what happened. If you stopped it, show what stopping it bought: the engineering time returned, the risk avoided, the better opportunity that took its place. Keep these claims conservative and specific, because a cost-avoided figure invites more scrutiny than a growth figure.
Better still, keep the tree live during the work. A tree updated as discovery happens never has to be reconstructed later, and it reads as evidence.
Write one page on the call that mattered
The tree shows breadth. For depth, pair it with a one-page decision record on the single call that defined the case: the context, the options you weighed, the trade-off you put in front of the team, who disagreed and why, what you decided, and what happened next.
This is where the team shows up. The core PM job is making calls a whole team will act on, and the decision record is the artifact that shows the disagreement and how you moved through it.
Putting it to work: your CV and your portfolio
On the CV, write bullets as decisions with evidence and consequence. Here is the example above, written the usual way:
Launched a licensed retail financial product.
And written as decisions:
Ran one-to-one discovery interviews with an executive-sponsored institutional segment before build; found they already used a better-fit solution and that regulator-set liquidity limits removed our advantage, and recommended against building for them.
Proposed a pivot to retail users, where the same regulatory limits fit and comparable products proved demand; leadership approved the change of direction.
Defined the feature set from a hands-on competitor teardown scored by area and an analysis of app reviews and social media; the product was licensed, targeting the segment more likely to use it.
The first bullet would be a strong line even if the product had never been built. Write each bullet in the words you'd use explaining the call to your engineering lead, and cut anything a hiring manager would need a glossary for.
In the portfolio, build two or three cases, and make at least one of them a case where the answer was no. Each case is a single page: the annotated tree as the visual, the decision record beneath it, and a link to anything that shipped. Host it as a web page or PDF and link it from your CV header and your LinkedIn Featured section.
In the interview, the tree becomes your answer to "tell me about a hard product decision." You walk the interviewer from the outcome down to the branch you chose, and across to the ones you cut.
A fair objection is that anyone can draw a tree. Anyone can also write "grew active users 40%" on a CV, and hiring managers have long tested that claim with follow-up questions. A tree gets the same treatment. Ask why a branch was cut, and a real decision holds up through three follow-ups, while a reconstructed one runs out of detail by the second.
Most of these documents belong to your employer, so recreate them instead of exporting them. Rewrite in your own words, replace company and client names with descriptors, and show metrics as percentages or direction of change.
Takeaway
A PM's value lives in judgment, and a large share of good judgment ends in "no." As AI makes building faster, that judgment becomes the part of the job that matters most, and the part most worth showing. The Opportunity Solution Tree gives you a map every product leader already reads. Annotating it with what you chose, what you cut, and what happened turns it into a record of judgment, and the decision record adds the team behind the call.
This week, open Torres's free FigJam template and pick one decision from the last quarter, ideally one where you stopped something. Rebuild the tree as it looked when you decided, mark what you cut and why, and write the one-page record. On the next product discovery, do another tree live. Your decisions will grow in confidence and within a year you'll have a portfolio that shows the work a launch list leaves out, and a CV that reads like a strategic product leader wrote it.
