Solo Founder Idea Kill Sheet

Purpose

Use this sheet to decide whether an idea deserves the next unit of founder effort. For a solo founder, continuing is not a neutral choice: it spends the same attention needed for discovery, sales, support, and every stronger idea left unattended.

The sheet does not begin from the assumption that the idea should die. It makes four outcomes available—continue, narrow, postpone, or kill—so that technical pride and time already spent do not get a private veto over the evidence.

When To Use

Use it after the first idea filter and before an MVP claims serious build time. Return to it when a product or feature consumes effort without producing customer pull, a clearer buying path, repeated use, or sharper learning.

Do not wait for complete knowledge. Uncertainty belongs on the sheet. The useful distinction is between an unknown with a cheap way to learn and an unknown that the proposed product quietly assumes away.

Name the Bet You Are Judging

Evaluate the idea in the form you could act on now, not the company it might become after funding, hiring, partnerships, or years of product development. At the top of the page, write:

• Customer and painful event: Who experiences the problem, and what recent event reveals it?
• Proposed first result: What useful result will the customer receive before the full product exists?
• First boundary: Which customer, workflow, data source, integration, promise, or failure consequence is deliberately outside the test?
• Decision horizon: What work or commitment will this decision authorize?

“Software for maintenance teams” cannot be judged. “A founder-run service that finds qualified repair options for one equipment class in one region” can.

Write the Evidence Record

Bring discovery notes, outreach results, observed alternatives, budget signals, build estimates, support concerns, and evidence from prototypes or manual tests. For each test below, write three lines:

• Finding: supported, uncertain, or blocked.
• Evidence: the behavior, event, artifact, or result behind the finding.
• Consequence: the next test, narrowing move, or reason to stop.

Keep observation separate from interpretation. “Three operations leads pay an assistant to assemble this report every Friday” is evidence. “The market wants automation” is a hypothesis.

Pain and present priority

Reconstruct a recent instance of the problem. Record its frequency and what it cost, delayed, endangered, or made harder. Then describe the current alternative and the time, money, risk, or reputation already committed to it.

Reach, buyer, and budget

Name a credible route to the first qualified conversations. Identify who feels the pain, who can authorize change, and where the money or savings case would come from. A market category is not a route, and sincere user interest is not buyer authority.

First value and behavior change

State the smallest result the customer can receive before the full product exists. Name the customer behavior that would demonstrate value: sharing real work, changing a workflow, returning, paying, referring, or accepting a pilot. Signups and compliments count only when they remove a genuine uncertainty.

Build and data burden

Work backward from that first result. What code, data, permissions, integrations, migration, setup, and recovery must exist before the promise is honest? Mark what can be bought, borrowed, manually operated, faked for learning, or deferred without misleading the customer.

Trust and failure burden

Describe what happens when the result is late, wrong, unavailable, exposed, or misunderstood. Record the reliability, privacy, security, compliance, audit, or human-review boundary required from the first customer—not from an imagined future scale.

Sales, support, and operating burden

Trace the work from first contact through onboarding, delivery, questions, exceptions, billing, and renewal. Decide whether those acts expose a repeated product pattern or create a different service for every customer. Include the dull recurring work, not only the build.

Founder fit and energy

Ask whether your access, judgment, credibility, technical ability, and tolerance for the sales and service motion shorten the route to evidence. Name a repairable gap plainly. Do not grant a future hire, partner, advisor, or audience a capability that does not exist.

Evidence pace

Review what changed during the last evidence window. Did conversations become more specific? Did a buyer act? Did the first-value boundary shrink? Did the same need recur? Activity that leaves the important assumptions untouched is not progress.

Find the Governing Constraint

Do not total the findings. One blocker can dominate several supported conditions: strong pain cannot compensate for unreachable buyers, and easy software cannot compensate for a first promise that is unsafe or operationally impossible.

Circle the condition most likely to make the next commitment irrational. Then ask whether a low-cost test can change it without presuming the product works. If it can, write the test, its deadline, and the result that would change your decision. If it cannot, narrow, postpone, or kill the idea.

Repeated narrowing moves are useful evidence. They often reveal that the original idea was a category and that the viable opportunity, if any, is one customer, workflow, geography, data boundary, or first-value moment inside it.

Make One Decision

• Continue when pain, reach, and a responsible path to first value are supported, no blocker is being hidden inside the proposed experiment, and the next test is worth the burden it adds.
• Narrow when the pain is credible but the current promise imports too much scope, dependency, trust, custom operation, or support. Name the boundary that changes the bet.
• Postpone when a named condition outside the present test must change first, such as access, expertise, credibility, capital, regulation, data, infrastructure, or timing. Record the condition; do not use “later” as a decision.
• Kill when the pain, reach, buyer, or priority remains weak, or when the smallest responsible result still requires capacity one person cannot supply. Record the evidence so the same idea does not return under a new description.

Finish the sheet with this decision record:

• Decision: continue, narrow, postpone, or kill.
• Evidence that earned it: the strongest observed support, not the most encouraging opinion.
• Governing constraint: the condition that limits the idea now.
• Boundary or condition: what must stay excluded, or what must change before reconsideration.
• Next action: one experiment with a deadline, or an archive note with no disguised build work.

Worked Decision

Suppose the initial idea is a marketplace connecting small manufacturers with maintenance contractors. The pain is supported: downtime is expensive, and managers already spend hours calling known vendors. Reach is uncertain but testable through one regional trade group. The broad first result is blocked because useful matching requires qualified supply, local availability, diagnosis, site-safety knowledge, and urgent failure handling before the first promise can be reliable.

The decision should not average those findings into a weak “continue.” A defensible record is:

Narrow. Test a founder-run sourcing service for one equipment class in one region. Downtime and existing spend support the problem, but liquidity, contractor verification, and urgent support block the marketplace promise. Interview five maintenance managers and manually source three real requests within four weeks; kill or postpone if requirements do not repeat or safe fulfillment depends on founder availability at all hours.

The narrower test does not preserve the marketplace by rhetoric. It puts the repeated workflow, trust boundary, and operating burden where evidence can reach them.

Common Mistakes

Founders often treat weak positive feedback as permission to continue. Compliments, signups, and friendly curiosity do not outweigh missing urgency, missing reach, or missing behavior change.

Do not kill an idea only because the eventual build looks hard. Strong pain, reach, budget, and founder advantage may justify a manual or lower-cost test. Judge the burden required for the next honest result.

Do not postpone without a trigger. A calendar reminder does not change missing access, trust, expertise, or capital. Reconsider the idea only when the named condition changes.

Finally, do not turn every custom request into “learning.” Useful custom work exposes a pattern that becomes easier to predict and bound. Work that remains novel for every customer may be a service worth selling, but it is not evidence for the product as described.

Field Reference

The sheet is complete when it changes what you will do: continue with one bounded experiment, narrow the promise, postpone until a named condition changes, or kill the idea and release the attention it was consuming.