Feature Kill / Keep Decision — by an AI council
Decide whether to invest in, fix, or kill an underperforming feature. Four rival AIs debate it and hand back: A clear kill / keep / fix verdict with the reasoning and next step.
A clear kill / keep / fix verdict with the reasoning and next step.
Signed off by an independent Final QA audit — with a “verify before you rely on this” list, never a black box.
Why this team
Kill/keep calls fail in two opposite ways: sentimentality keeps a corpse on life support, or a spreadsheet kills something a loyal segment quietly depends on. The Minimalist argues for deletion as a feature, the Customer Success Lead and End-User Advocate speak for the people who would notice, and the Data Skeptic checks whether “nobody uses it” is actually true in the data. The Product Strategist weighs the roadmap cost of keeping it, and the Devil’s Advocate takes whichever side the room is avoiding.
Each seat runs on a different frontier model — GPT, Claude, Gemini, Grok — so it’s a genuine cross-model review, not one AI in costumes. How a run works →
What the debate sounds like
An illustrative excerpt — A project-management tool is deciding the fate of its built-in time tracker: 6% of workspaces touch it monthly, but support tickets suggest an agency segment relies on it for client billing.
Six percent monthly usage for a feature that occupies a top-level tab and a settings page is a tax on the other ninety-four. Every onboarding screen, every pricing conversation, every mobile release pays for it. The default for a number like that should be removal, and the burden of proof on keeping.
The 6% is doing a lot of work in that argument and it is the wrong cut. Filter to agencies and usage concentrates — if the workspaces that use it are disproportionately the paying ones, this is not a fringe feature, it is a niche feature. Those are different verdicts. Segment the number before anyone votes.
From the ticket log: the agencies are not asking us to keep it, they are asking us to fix its export. That is the tell — they use it for invoicing clients, which means ripping it out without a migration path converts quiet customers into churned ones. Whatever the verdict, the exit ramp is part of it.
Questions
What data should I bring to a kill/keep decision?
Usage segmented by customer type if you can get it, support-ticket themes, maintenance cost in engineer-time, and what was originally promised to whom. The debate turns on exactly those cuts — a raw usage percentage on its own reliably produces the wrong verdict.
What if the council splits between kill and keep?
The moderator still commits — KILL, KEEP-AND-INVEST, or FIX-THEN-REASSESS, with the reasoning in three lines and the dissent preserved next to it. A 3–2 verdict with the minority case written down is more useful than false unanimity, because you know exactly what evidence would flip it.
How do I kill a feature without burning the users who loved it?
That is part of the deliverable when the verdict is kill: the clean path — sunset timeline, migration or export route, and who to tell personally before the changelog goes out. Features rarely damage trust when they die; they damage trust when they vanish.
Your material is used only to run your review — never to train public models. Encrypted in transit and at rest. Security & privacy →
Want full control — pick your own minds, set the depth? Open the full council →