Removal test: the remove prompt pack

I build Settl, an expense-splitting app, with AI. Fast building makes it easy to mistake activity for evidence. This pack helps you test whether a favourite feature creates real value before continuing to maintain and promote it, before another week disappears into work that looked sensible at the time.

Why this trap costs more than it looks

The tempting assumption is that the feature with the most effort or cleverness must be important. It feels reasonable because visible work is emotionally satisfying. A new screen, a longer feature list, or a positive answer gives you something concrete to point at. The weaker evidence stays hidden because it is less exciting and often more uncomfortable.

The cost is not limited to the first build. Every decision creates maintenance, explanations, support, and more decisions around it. The earlier choice becomes harder to question because you have already spent time on it. A small evidence check before building is cheaper than defending the work after it exists.

What useful evidence looks like

Look for behaviour that existed before your solution was suggested:

People search for the missing action. This shows the problem is already changing behaviour.
A real task takes longer without it. Repetition separates a real pattern from a strange afternoon.
Support requests mention the missing outcome. A visible cost tells you why solving it might matter now.

Do not demand perfect proof. Early products rarely have it. You need enough evidence to make the next decision smaller and more honest. One specific recent story is usually worth more than ten broad opinions because you can inspect what actually happened.

Start with an evidence inventory

Gather the material you already have: user messages, notes, product screens, support conversations, usage summaries, and the assumptions behind the idea. Then paste this:

I am deciding how to test whether a favourite feature creates real value before continuing to maintain and promote it.
Review the material I paste below.
Separate it into four groups:
1. Observed behaviour that already happened.
2. Direct statements with a specific example.
3. Opinions or compliments with no behaviour behind them.
4. Assumptions I am making without evidence.
Do not suggest solutions yet.
Quote the exact evidence for every item.
End with the three biggest evidence gaps.

This first pass is intentionally boring. Its job is to prevent the AI from filling empty spaces with plausible advice. If the material contains no evidence, that is a useful result. You now know the next step is learning, not polishing.

Run the smallest honest test

The test for this decision is to hide the feature for a small group and look for changed behaviour instead of asking whether they like it. Keep the test small enough to run this week. You are not trying to prove the whole business. You are trying to expose one assumption while changing as little as possible.

Design a small test for this decision: hide the feature for a small group and look for changed behaviour instead of asking whether they like it.
The assumption is: the feature with the most effort or cleverness must be important.
The test must take no more than seven days.
It must observe real behaviour, not ask for a prediction.
Give me: the participant, task, evidence to capture, pass condition,
failure condition, and the decision each result would trigger.
Do not propose a larger feature or a marketing campaign.

Decide the pass and failure conditions before seeing the result. Otherwise a hopeful founder can explain almost any outcome as good news. A useful test is allowed to disappoint you. That is how it saves time.

Ask questions that produce a timeline

Use questions that return to a real moment. Avoid asking whether someone likes the idea or might use it later. This prompt turns a vague conversation into something you can inspect:

Create five interview questions about this problem.
Every question must ask about a specific past event.
Cover: what happened, what they did first, the workaround,
what the problem cost, and what happened afterward.
Do not ask "would you use", "do you like", or "what features do you want".
Add one follow-up question under each question.

During the conversation, follow the timeline instead of rushing to your next prepared question. Ask to see the note, message, spreadsheet, or screen when that is appropriate. Specific artefacts reduce the pressure on memory and make contradictions easier to notice without turning the conversation into an interrogation.

Read the result without rescuing it

After the test, write down what happened before explaining why. Builders are good at rescuing a preferred idea with context: the participant was unusual, the timing was bad, or the test was too small. Some of that may be true, but record the behaviour first. Interpretation comes second.

Review these test notes as a skeptical product partner.
Create two columns: what happened, and my interpretation of it.
Flag any interpretation that is not supported by an observation.
Then give the strongest case for continuing and the strongest case for stopping.
Name one missing fact that would most change the decision.

Make the decision smaller

Restore it when people lose a meaningful outcome. Remove or simplify it when only the builder misses it. You do not need a permanent answer. Choose the smallest next move that matches the evidence. That might be building one narrow path, rewriting a sentence, watching another session, charging a real price, or removing something that creates noise.

Use this decision note so the next week does not reopen the same argument:

Decision: What are we doing now?
Evidence: Which observed behaviours support it?
Risk: What could still make this wrong?
Next check: What will we inspect, and when?
Not doing: Which attractive option is deliberately waiting?

A written "not doing" line matters. Good ideas return wearing new clothes. Recording the decision keeps the team from confusing repetition with new evidence.

Run this on your codebase

Paste your relevant product notes, user feedback, screens, and current plan after this prompt:

Help me test whether a favourite feature creates real value before continuing to maintain and promote it.
My current assumption is: the feature with the most effort or cleverness must be important.
1. List the observed evidence and quote its source.
2. Separate behaviour, statements, opinions, and assumptions.
3. Name the weakest assumption carrying the most risk.
4. Design a seven-day test that will hide the feature for a small group and look for changed behaviour instead of asking whether they like it.
5. Set a pass condition and failure condition before the test runs.
6. Give me five past-behaviour interview questions.
7. End with a one-page decision note: decision, evidence, risk,
next check, and what we are deliberately not doing.
Do not invent customer facts. Mark missing evidence clearly.

Run the decision as a safe workflow

The runnable starter turns the existing removal test into a reviewable dry-run. It accepts the feature, baseline evidence, affected users, off-switch method, observation window, and decision owner. It returns the experiment plan, restore threshold, evidence fields, and pending approval state. It never hides or deletes a production feature.

npm test
npm run validate
npm run sample
cp .env.example .env
docker compose up --build

Download the runnable pack

Start with the fictional dry-run. It validates the input and returns a reviewable draft without changing code, production data, customer accounts, or an external service.

Before enabling a real experiment

Test the off switch and restore path in a non-production environment first. Name the decision owner, save the baseline, define the restore threshold, and keep the first production cohort small.