Should you put a failed project on your resume?
Yes, when the work in it is the work the next job needs. A project can miss its goal and still show that you built, tested, measured or led something real. What you can't do is describe it as a success. The bullet reports what happened, and the project's ending stays available for the interview.
Employers say this directly. Amazon's interview loop page, checked October 26, 2026, tells candidates that "not every story has to be a success. We know that failure is part of innovation." It also asks you to have examples ready of times you've "taken risks, succeeded, failed, and grown." A failed project on your resume gives the interviewer a reason to ask for that story.
Leave it off when it shows nothing the posting asks for, or when the only figures you have are ones you can't share. A resume is a selection of your work. Nobody expects every project you touched to appear, whether it worked or not.
What is the number that survived the failure?
It is a figure that stays true whatever happened next. The project was cancelled, missed its target or was rolled back, and the work still left a count behind: what you built, what you measured, what you tested, what you stopped. That figure belongs on the page. The target the project never reached does not.
Most failed projects leave more records than successful ones. There was a launch plan, a dashboard someone watched, a review meeting and often a written postmortem. Google's Site Reliability Engineering book defines a postmortem as "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions." That document is often where your surviving figure lives.
The table shows the usual kinds, with a made-up figure for each. Every figure in it is an example written for this page.
| What survived the failure | Example figure (made up) | Where the record usually lives |
|---|---|---|
| Work you finished | 3 services built, 1,200 beta users | Repository history, beta dashboard |
| A real change that fell short of the target | Setup time cut from 9 days to 6, against a target of 3 | Onboarding dashboard, project review |
| A test result, even a negative one | Conversion fell 4% across 2 markets in 6 weeks | Experiment readout |
| A loss kept small | Pilot stopped at week 4 of a planned 12 | Decision memo, budget sheet |
| Work that carried over | Billing module reused by 2 later products | Release notes, design documents |
| Your part in the review | Wrote 5 of the postmortem's follow-up actions | The postmortem itself |
The fourth row needs care. Claim money saved only when a budget sheet shows what was never spent. A guess at what a full rollout "would have cost" is a figure with no record, and it will be the first thing an interviewer asks about.
What do three real-shape bullets look like?
Each one names the work, gives the figure that survived and says how the project ended where the ending helps. The three below are examples written for this page, about made-up people and projects. They cover the three common shapes: a product that was cancelled, a goal that was missed and an experiment that failed.
- Cancelled: "Built offline mode for the merchant app with 3 engineers, reaching 1,200 beta users before the product line closed in March 2025."
- Missed target: "Led the onboarding rebuild that cut setup time from 9 days to 6, and traced the rest of the delay to bank verification."
- Failed experiment: "Ran a 6-week pricing test in 2 markets; conversion fell 4%, and the readout kept the old pricing in place for all 11 markets."
The surviving numbers are 1,200 beta users, 9 days to 6 and a 6-week test in 2 markets. Each one came from a record: a beta dashboard, an onboarding report and an experiment readout. None of the three bullets claims the result the project was meant to reach.
The second bullet is where people go wrong, so here is its before and after. Before: "Launched self-serve onboarding, cutting setup time by 70%." After: "Led the onboarding rebuild that cut setup time from 9 days to 6." The number that changed is the 70%. It was the target in the business case, and the dashboard showed a cut of 3 days, about 33%.
How do you write a failed project on your resume, step by step?
Start with the ending, written privately in one plain sentence, so you know what the bullet must never contradict. Then collect the project's figures, keep the ones that pass three questions and write the bullet from your own part. The last step checks the verbs, because that is where a failed project quietly turns into a success.
- Write how the project ended in one sentence, for yourself: cancelled, paused, rolled back or short of target, and when.
- List every figure the project produced, with the record that holds each one.
- Ask three questions of each figure: what is it, what did it measure and where did it come from.
- Keep the figures that stay true however the project ended, and drop targets, forecasts and projections.
- Separate your part from the team's, and write the bullet from your part.
- Check each verb against the ending. "Launched" needs a launch, and "grew" needs growth.
- Write the two sentences you'll say when asked how it ended, and keep them with your facts.
Step 3 is the method from the page on how to turn your resume into facts, where each question is worked through on a filled example. Step 4 matters most here. A forecast is a figure about a future that didn't happen, so it measured nothing.
Should the bullet say the project failed?
It doesn't have to, and it can't imply the opposite. A resume line can report the work and the surviving figure without stating the ending, the same way it leaves out a hundred other details. Say the ending in the bullet when it shows judgment, such as a test that stopped a costly rollout. Leave it for the interview otherwise.
The line you can't cross is wording that suggests a result nobody measured. "Launched" for a product that never shipped, "drove" for a metric that fell and "delivered" for a project that was cancelled all claim an ending that didn't happen. Each of those words is a question waiting in the interview.
Dates help here too. The USAJOBS guide on how to write a resume for a federal job asks for start and end dates with month and year, and for results shown with "numbers, percentages, dollars or descriptions." An end date that matches the project's real end keeps the bullet consistent with the story you'll tell.
What will an interviewer ask about a failed project?
Expect to be asked what your part was, how it turned out and what you'd change. Those are the standard follow-up probes in structured interviews, and a failed project invites all three. Have a short, factual answer for each, with the same figures as the resume. Rehearse the ending until you can say it without explaining it away.
The US Office of Personnel Management's structured interview training lists sample probes for behavioral questions. They include "What was your role?", "What was the outcome?" and "Is there anything you would have done differently?" The same training tells interviewers to "seek clarification when candidates say 'we did…'" and when they are vague.
Amazon publishes one version of the question itself on its interview loop page: "Describe a time when you took a risk, made a mistake, or failed. What happened, and what did you learn from it?" The page says outcomes should include "what you learned," and adds that numbers to back a result up are "even better." Your surviving figure is that number.
How do you explain the failure without blaming anyone?
Describe the causes as conditions, then name your own part in them. Say what the team knew at the time, what it found out later and what you would do differently. Leave other people's names and mistakes out. An interviewer judges how you talk about the failure as much as the failure itself.
Google's engineers have a written rule for this. The SRE book says a blameless postmortem "must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior." That standard works in an interview answer too. For example: "We sized the pilot on last year's order data, and weekend demand turned out to be a third of weekday demand."
Then add your own part. Amazon's Leadership Principles describe leaders as "vocally self-critical, even when doing so is awkward or embarrassing." One sentence does it: "I should have pushed for a two-week test before we committed to four cities." Keep it specific and true, and stop there.
How do you keep the failure story the same in every round?
Write the facts down once and tell them from that page every time. The surviving figure, the end date and your one-sentence ending go on your list of facts, next to everything else on your resume. A failed project is the story most likely to shift between rounds, because each telling tries to make it sound a little better.
The page on what a fact-locked resume is explains the rule: wording can change between versions, values can't. If the project is the only place a figure could come from, the page on what to do when your resume has no numbers lists where else to look. When a posting asks for exactly the skill the failed project used, the page on how to tailor a resume to a job description without lying shows how far that bullet can lead.
After each round, note how you told the ending and which figures came up, using the free 10-minute debrief template. The page on consistent answers across interviews covers what to do if the story moved. Prept's resume optimizer writes each tailored resume only from facts you confirm, so a result the project never reached is left off rather than invented.