HRLens HRLens Check your CV free
← See all articles

How to put a scrapped product on your resume

Quick answer: Write a scrapped product as a decision, not a dead end. Lead each bullet with the problem you were solving and the engineering calls you made, quantify what existed before launch — design partners, latency, infrastructure cost, build time — then name the pivot in one neutral clause. Never write "unfortunately never launched". Recruiters hire judgment, and a killed product is full of it.

Is your CV good enough?

Upload your CV and get an instant AI score out of 100, an ATS-compatibility rating and a breakdown across five categories — free.

Analyze my CV

What does the Melius pivot say about a scrapped product on your resume?

A scrapped product isn't a hole in your experience — it's a decision you were part of, and decisions are what hiring managers screen for. On October 6, 2026, the New York startup Melius announced $25 million in funding: a $5 million seed led by General Catalyst and a $20 million Series A led by CRV. Its founders — Joowon Kim, Young Kim and Arnav Ramu — met as engineers at Ramp. Before any of that money arrived they spent more than six months building something else entirely: software to help marketers manage and optimize ad spend. They decided the idea didn't have legs, deleted the whole codebase, and rebuilt around generating the ad creative itself. The new platform passed $1 million in annualized revenue within two months of leaving stealth.

That's the story investors rewarded. Now picture the same six months on a resume. "Worked on an ad spend optimization platform (product discontinued)" tells a recruiter nothing except that the work evaporated. This is the most common scoring problem we see in engineering and product CVs: when the biggest block of recent experience never shipped, impact and ownership collapses, because every bullet describes activity instead of consequence. Six months of architecture, hiring, customer calls and one hard call to kill it — compressed into a parenthetical. The work was real. Systems were built, a market was tested, a conclusion was reached. None of it reaches the page if you list the things you touched and then quietly apologize for the ending.

Here's the contrarian part, and we'll stand behind it: a scrapped product written well beats a shipped feature written lazily. "Shipped v2 of the billing page" is a sentence anyone can write. "Built and killed an ad spend optimizer after validation showed buyers wouldn't switch tools" is a sentence only someone with real product judgment can write. Hiring managers at startups have all lived through a pivot, and plenty are hiring precisely because their own roadmap changed. What makes them nervous isn't failure — it's a candidate who can't explain what they learned, or who seems not to have noticed. A dead product is a free pass to talk about judgment, which a shipped feature rarely proves. The goal was never to hide it.

dropme

How do you write resume bullets for a product that failed?

Lead with the problem, then the decision, then the evidence — in that order. A bullet for a product that failed should name the problem you were solving, the constraint that made it hard, what you built or chose, and what that choice proved. The outcome comes last and it doesn't have to be a launch: "proved the segment wouldn't switch tools" is a legitimate outcome. Compare the shapes. Weak: "Developed a React dashboard for ad spend reporting." Strong: "Built an ad spend reporting dashboard for [N] design-partner accounts in [N] weeks; usage data showed teams wouldn't abandon existing reporting, which drove the decision to redirect the product." Same six months, completely different signal — and notice the second version never uses the word "failed".

Fill those four slots with your own numbers and the bullet nearly writes itself. Start with a verb that implies a decision rather than attendance — designed, chose, cut, migrated, benchmarked, killed — and resist the urge to hide behind "we". Recruiters can't award credit to a pronoun. If you owned the data model, say you owned the data model. If you argued for a boring monolith over services and shaved weeks off the build, that's a bullet. Keep each one to a line and a half, because anything longer gets skimmed. Order them by the size of the decision rather than by chronology: the architectural call belongs above the ticket you closed in week three. If a bullet could have been written by anyone who sat in the same standups, it isn't finished.

Placement matters as much as phrasing. Keep the scrapped product inside the role it belonged to, under the same employer heading, with a one-line descriptor of what it was — "ad spend optimization platform, pre-launch" — followed by three to five bullets. Never build a separate "unlaunched projects" or "learnings" section; it quarantines the work and invites the exact question you were trying to answer. If the product was the whole job, then it's your main block of experience and should look like it: real scope, real numbers, real decisions. Recruiters read top-down and assume the first block is your best work. Engineers can see how this plays out against first-screen criteria in our breakdown of the software engineer CV that passes the first screen.

What can you quantify when the product never shipped?

Almost everything except revenue. Pre-launch products generate hard numbers constantly and most people throw them away: beta or design-partner accounts using the build, time from first commit to working demo, the p95 latency you hit under load, monthly infrastructure cost before and after tuning, events processed in testing, customer interviews run, team size and sprint cadence. None of that requires a public launch. A bullet saying you cut median query time by an order of magnitude on a multi-million-row event table is specific, verifiable and completely indifferent to whether anything shipped. Revenue is the only metric a pivot genuinely takes away from you. That's the whole trick to showing impact without a shipped product — measure the system and the process, not the market.

Go and dig the numbers out before you start writing, because guessing is what gets candidates caught in interviews. Your git history gives you dates, commit volume and the real shape of the build. Cloud billing consoles still hold last year's spend. Old pull request descriptions and incident channels often contain the exact benchmark you need. Project trackers tell you how many sprints you ran and how big the team was. If you demoed to customers, your calendar is a record of how many conversations you had. A build time stated in weeks is a credibility signal all by itself. Export or screenshot what you find while you still have access — once you leave, those dashboards close and you'll be reconstructing your best bullets from memory.

Then stay honest about the labels, because a sharp interviewer will push. Say "design partners" rather than "customers" if nobody paid. Say "load tested to" rather than "served" if it never carried production traffic. Say "pre-launch" or "internal pilot" once, plainly, and every number after it gets more credible, not less. Overstating a pilot as production is the fastest way to lose an offer you'd already won. Precision is the entire currency here. If you're rebuilding your CV from scratch around a product that never launched, the HRLens CV builder works conversationally — paste your old CV or just describe what you built, refine the bullets by chat, then export in one of six templates.

What you can still measureWhere the number usually lives
Design-partner or beta accounts on the buildCRM, onboarding sheet, auth table
Time from first commit to working demoGit history, first and last commit dates
Latency or throughput reached under loadAPM dashboards, load-test results, old PR descriptions
Monthly infrastructure cost, before and after tuningCloud billing console, finance tickets
Data or events processed in testingPipeline logs, warehouse row counts
Customer interviews and usability sessions runResearch notes, calendar history
Team size led and sprints shippedProject tracker, old org chart
Pre-launch work still produces hard numbers — here's where to go looking before you rewrite a single bullet.

Is your CV good enough?

Upload your CV and get an instant AI score out of 100, an ATS-compatibility rating and a breakdown across five categories — free.

Analyze my CV

How do you name the pivot without blaming anyone?

Use one neutral clause that states the decision and stops. "The company redirected its roadmap toward creative generation" does the entire job. No villains, no "unfortunately", no "due to a change in leadership", and absolutely no named people. The grammar matters: write the pivot as a strategic decision the business made, not as something that happened to you. Blame reads as a warning sign even when it's deserved, because the person reading your CV is a manager who has also killed a project and knows exactly how it sounds from the other side. One clause, factual, forward-facing — then move straight back to what you built and what it proved. The bullets that follow are what you want remembered, not the explanation.

Keep that clause identical everywhere. The same sentence should appear in your CV, your LinkedIn role description and your cover letter, because inconsistency across those three is one of the first things a recruiter notices when they cross-check. Write it down once and reuse the wording verbatim. Then rehearse the thirty-second spoken version in three beats: what you were building, what the evidence showed, what the team did about it. Candidates lose this question not by admitting the product died but by rambling, or by sounding surprised that anyone asked. Practice until it's boring. A founder who says "we burned the codebase" sounds decisive; a candidate who sighs and says "it's complicated" sounds like they weren't in the room.

Two edge cases come up constantly. First, confidentiality: if the product was never announced, describe the problem space and technical scope without naming the feature or the client — "a pre-launch B2B spend management product" is specific enough to be credible and vague enough to be safe. Be precise about which kind of ending it was, too, since a pivot, a shutdown and a deprioritized roadmap item all read differently. Second, a company that no longer exists. Write the dates and the work exactly as you would anywhere else, add the closure as a short parenthetical if it's public knowledge, and line up a former manager or co-founder as a reference. Verification problems, not failure, are what actually sink these applications.

Which three phrasings make a scrapped project read as wasted time?

Three: "worked on", "unfortunately never launched", and "gained valuable experience in". Each tells the reader the same thing in a different costume — that you were present while something happened. "Worked on an ad spend platform" describes attendance. "The project was cancelled before launch" hands a skimming recruiter the only sentence they'll remember. "Gained experience in distributed systems" is what people write when they have nothing concrete to point at. The same family includes "involved in", "helped with", "exposure to", "assisted the team with" and "participated in". If one of these opens a bullet about your biggest project, the six months behind it are invisible. All three are habits rather than honesty, and all three are fixable in an afternoon.

They fail twice over. A recruiter skimming for eight seconds reads verbs first, and passive-adjacent verbs give them nothing to grade, so your strongest work scores the same as a bystander's. Automated screening doesn't rescue you either: parsers and keyword matching pull concrete nouns, tools and skills out of your bullets, and "gained experience in" lines are usually thin on exactly those. The third phrasing is the most self-destructive, because nobody asked you to editorialize. Stating that a project was cancelled isn't candour — the dates already imply it and the interview will cover it. Writing "unfortunately" volunteers your own worst framing before anyone has formed an opinion. Your CV's job here is to earn eight more seconds, not to pre-empt an objection.

The fix is mechanical. Open each bullet with a decision verb, put a number in the middle, and let the final clause carry the result — even when the result is a conclusion rather than a launch. Rewrite the three or four bullets covering the scrapped product first, since they carry the most weight. Then check whether a machine and a stranger actually see the impact you think you wrote. A free CV analysis from HRLens scores your CV out of 100 with separate marks for impact and ownership, clarity and structure, and ATS compatibility, plus a visual layout check — the fastest way to learn whether your scrapped product now reads as six months of judgment or six months of nothing.

Frequently asked questions

Should I just leave the scrapped product off my resume?

No — not if it covers a meaningful stretch of time. Removing it leaves an unexplained gap in your dates, and gaps attract far more scrutiny than dead products do. Keep the role, keep the dates, and rewrite the bullets around the problem you solved, the decisions you owned and the numbers you can still verify. The only thing genuinely worth cutting is the apologetic sentence at the end.

How do I list a cancelled project on a CV if I was only on it three months?

Compress it to one or two bullets inside the role rather than giving it its own block. Pick the most senior thing you did — a design call, a migration, a benchmark, a research finding — and write that with a number attached. Short stints read badly only when they're padded out. A tight, specific two-line entry signals that you know which of your contributions actually mattered.

Does an ATS penalize a product that never launched?

Automated screening doesn't know or care whether your product shipped. It parses text, so what hurts you is the writing: vague verbs, missing skill nouns, and detail buried inside a sentence about cancellation. Spell out your stack, tools and scope plainly in the bullets and a pre-launch project gets indexed exactly like a shipped one. Formatting problems cost you far more screens than outcomes ever will.

What do I say when an interviewer asks why the product failed?

Answer in three beats and under thirty seconds: what you were building, what the evidence showed, and what the team decided. Name the signal that changed your mind — usage data, churn in a pilot, customers refusing to switch tools. Then say what you'd do differently, which is usually testing willingness to pay earlier. Confidence and specifics land well here; blame and vagueness don't.

Is your CV good enough?

Upload your CV and get an instant AI score out of 100, an ATS-compatibility rating and a breakdown across five categories — free.

Analyze my CV

How helpful was this article?

Articles by HRLens →