Write the Kill Rule Before You Write the Pivot Doc

A product can stay alive for a surprisingly long time without becoming a business.

The code still works. A few people still visit. Someone says the idea is interesting. You make another small improvement and tell yourself the next release will change things.

Then another month disappears.

The problem is often not the original idea. It is the absence of a clear point at which you are willing to change course.

That is what a kill rule is for.

Make the decision before the pressure arrives

A useful kill rule has three parts:

1. the number you will watch
2. the date you will review it
3. the action you will take if it misses

For example:

“By Friday at 5 PM, if fewer than eight trial users complete the paid setup, I will stop the current onboarding experiment and spend next week talking to ten users.”

That is much more useful than “we need better activation.”

The point is not to make the product feel dramatic. It is to make the next decision concrete.

Choose a number that actually proves something

Solo founders can drown in metrics.

Visits, signups, followers, sessions, waitlist size and social impressions all have their place. But when you are deciding whether an offer deserves another month, choose a number close to the value you actually sell.

If the product is a booking tool, look at completed bookings.

If it is a reporting product, look at reports being generated by paying customers.

If it is an API, look for recurring paid usage rather than the first experimental API key.

A signup is not the same as activation.

Activation is not the same as reuse.

And reuse is not the same as a customer who keeps paying.

Know which step you are trying to prove.

Put the date on the calendar

“Let's give it a little more time” is how a two-week experiment becomes six months.

Pick a real review date.

Weekly reviews are useful when the product is changing quickly because you still remember what you tried. Longer cycles can make sense for businesses with longer sales periods, but the principle is the same: decide the review date before the result arrives.

When the date comes, do not move it simply because the result is uncomfortable.

You have three basic options.

Keep the current approach because the number passed.

Change one important variable because the evidence points to a specific problem.

Stop the current offer because the evidence does not justify more time.

Stopping an experiment is not the same thing as declaring yourself a failure.

It is simply closing a loop.

Change one thing at a time

A disappointing number can create the urge to rebuild everything.

That is usually unnecessary.

If people reach the product but fail during onboarding, fix onboarding before changing the target customer.

If people use the product but do not return, investigate the recurring job before redesigning the entire interface.

If customers use the product and refuse the price, test the pricing or buyer before replacing the technology.

A pivot should explain what you learned.

“If this misses, I will interview the last ten trial users and change the first-run experience” is a plan.

“If this misses, I will build something else” is an escape route.

Talk before you code

When a metric misses, founders often respond by opening the editor.

Try opening the phone instead.

Talk to recent users. Ask what they tried to accomplish, what they did instead and whether they would care if the product disappeared next week.

Do not turn every conversation into a sales pitch.

You are trying to understand the gap between what you think the product does and what the customer actually values.

Ten honest conversations can save a month of building.

Do not kill the learning loop

A kill rule should apply to a product offer, feature or experiment.

It should not become an excuse to stop doing the work that produces evidence.

Keep the customer conversations. Keep the support loop. Keep the weekly review. Keep talking to people.

The thing you kill is the part that is not earning its place.

Keep a one-page decision note

At the start of the week, write:

• What the product does in one sentence
• Who the buyer is
• The one number that matters this week
• The pass threshold
• The review date
• What changes if the number misses
• What you will double down on if it passes

That page is more useful than a roadmap filled with possibilities.

The real benefit of a kill rule is simple: it stops hope from becoming an operating system.

You can still change direction. You can still discover a better idea. You can still give a product more time when the evidence deserves it.

But the decision happens because you agreed on a test—not because another month quietly went by.

Practical playbook

For Write the Kill Rule Before You Write the Pivot Doc, turn the main idea into a small operating decision. Identify the customer or user, the problem being solved, the signal that proves progress, and the next action that can be tested.

Decision map

problem → evidence → smallest action → result → next decision

Checklist

• Define the problem in one sentence.
• Use evidence instead of assumptions where possible.
• Start with a small test.
• Measure the result.
• Document what changed and why.

Editorial note

This practical section turns the article central idea into something a founder can test, measure, and revisit. It is deliberately separate from the main argument so readers can distinguish the article analysis from the implementation checklist.