behavioral · hard
"Tell me about a project you killed that you loved"
Tell me about a project you killed that you loved.
The word “loved” is load-bearing. Interviewers chose it deliberately. They are not asking about a project that was already dying and you pulled the plug. They are asking whether you can kill something you personally championed, that had real momentum, and that your team was proud of. The signal they are reading is not humility. It is judgment under attachment bias.
What this question is not
Most candidates treat this as a variant of “tell me about a failure.” It is not. A project that failed has no emotional cost to kill. The question only tests what it is supposed to test when the candidate genuinely loved the project and killed it anyway. If the story you pick was already showing weak engagement, missed milestones, and stakeholder skepticism before you ended it, the interviewer will see through the setup. There was nothing to overcome.
The adjacent failure question (tell me about a time you failed) scores the delta between who you were and who you became. This question scores your model of opportunity cost: can you articulate not just what the project cost to kill, but what the team was able to protect because you freed up the resources?
What companies specifically look for
At Amazon, this maps directly to “Are Right, A Lot” and “Ownership.” Killing something you love is evidence you use data and judgment rather than attachment. The interviewer wants to see you name a specific signal that changed your assessment and who you had to convince to stop.
At Meta, hiring managers have explicitly flagged “demonstrating courage to kill good ideas to protect the North Star metric” as a top behavioral signal. The project needs to have had genuine momentum and internal support, not just your personal enthusiasm.
At Anthropic and AI labs more broadly, the lens is resource discipline. With AI reducing build cost dramatically, teams can ship almost anything fast. The judgment to not build, or to kill what is built, is now a primary PM competency. A project killed because compute cost made unit economics nonviable is a stronger signal than one killed because “it did not fit the roadmap.”
Brandon Chu’s canonical “Ruthless Prioritization” frame applies: real ruthless prioritization means cutting the good to protect the great, not just cutting the bad.
The 2026 context
In 2026, feasibility is nearly free. AI compresses build time so dramatically that almost anything can be shipped fast. That means the PM’s core call is no longer “can we build this” but “should we, and if we shipped it, would it be viable AND lovable enough to sustain.” Killing a project you loved is proof you operate at this level.
The strongest kill stories now map to one of two bars:
- Viability failure: the market was not there at the unit economics required. Users liked it. No one was paying enough to cover the cost of running it. The math did not work.
- Lovability failure: the feature was usable, but users did not actually want it in their workflow. It solved the wrong version of their problem, or it created friction at exactly the moment users wanted to act.
“It did not scale” or “it did not fit the roadmap” are weak framings because they do not show a model of viable or lovable. They show you can read a roadmap. See feasibility is free and proving viability for the full framing.
Answer structure
Go beyond STAR. Use this sequence:
- Context and momentum. Set up why this project had real traction: team excitement, early user signal, your personal investment.
- What you loved about it. Be specific. One sentence. This is what the interviewer needs to believe was real.
- The signal that changed your view. A specific data point, a market reality, or a unit economics calculation. Name it. Do not soften it.
- The decision and who you convinced. Name the stakeholder. Killing something no one cared about is not a signal. Killing something a VP or a team of eight people believed in is.
- What killing it protected. Name the opportunity cost on the other side. This is the section most answers skip, and it is the most differentiating.
- How you closed it with the team. One sentence on how you handled the people dimension, not the logistics.
Structure a strong answer
strong
"We built a collaborative annotation layer on top of our core product. I had pushed for it, the team was proud of it, and early power users loved it. But when I modeled the unit economics, inference cost per active user was three times what we were capturing in ARPU for that cohort. The feature would cost more to keep alive as it grew. I also had qualitative signal from five user interviews that the annotation flow was adding steps at exactly the moment users wanted to act, not reflect. Usable, but not lovable. I had to convince the VP of Product, who had demoed this feature in an all-hands two months earlier. I brought the economics model and the interview clips and was direct: if this reaches 10% of users at current cost structure, we are underwater. We killed it at the next planning review and reinvested the team into a faster core action we had been deferring. That feature shipped shortly after and drove a 14% lift in the metric we cared about. The annotation layer taught me to attach a unit economics check to any inference-heavy feature before we write the brief, not after we ship."
weak
"I really loved this feature idea for a social sharing flow. We built it, but engagement was lower than expected and the team was stretched. It was hard to kill it because I had pushed for it, but I made the call and we moved on. I learned that you have to be willing to make tough decisions." No specific signal that changed the view. No named stakeholder to convince. No articulation of what the team protected. "Engagement was lower than expected" means the project was already failing, so there was nothing real to kill. The interviewer reads this as sandbagging.
What kills most answers
The most common failure mode is picking a project that was already visibly struggling. If engagement was weak, stakeholders were skeptical, and the project had already lost momentum before you ended it, there was no real love to overcome. The question’s core test goes unmet.
The second failure mode is vague opportunity cost. Saying “we freed up the team” is not an answer. Name what the team built or pursued instead, and name the outcome. The kill only matters if what came after it mattered.
The third is skipping the social cost. Name the person or group you had to convince, what they believed, and what you said to them. That is where judgment actually lives.
Reference points from public PM culture: Google Wave had genuine internal and external enthusiasm and died because it could not find a viable use case large enough to sustain it. The Amazon Fire Phone was loved internally and killed not because it was a bad phone but because market position and unit economics were unworkable. Use these as reference points to frame what “loved and killed” actually means, then tell your own story in those terms.
For behavioral prep mechanics, the Amazon Leadership Principles guide covers story bank construction and time allocation in detail.