After Day 30
Iterate or Kill
Use evidence, not attachment, to decide whether to improve, reposition, or start the next build.
Decision
A shipped product is a learning asset.
The right question is not whether the first version is impressive. The question is what it proved.
Signals include conversations, usage, payment intent, repeated objections, and the founder's ability to keep serving the market.
The decision should happen from a memo, not from mood. A tired founder often wants to kill too early; an attached founder often wants to iterate with no evidence.
Evidence
Separate facts from interpretation.
Facts are counts and artifacts: what shipped, who saw it, who replied, who tried it, who paid or asked to pay, which bugs appeared, and which objections repeated.
Interpretation is the story you tell about those facts. Keep it separate so the decision does not become a defense of the work already done.
No response is evidence too. It may mean the channel is wrong, the promise is unclear, the buyer is unreachable, or the problem is not urgent enough.
Options
Iterate, reposition, or kill.
Iterate when the buyer and problem are clear, at least a few users engaged, and the next fix is obvious.
Reposition when the artifact works but the buyer, promise, or channel is wrong. This keeps useful code and learning while changing the market angle.
Kill when the problem is weak, access to users is poor, support would be miserable, or the founder cannot see a credible next two-week test.
Assets
Carry forward what survived.
Even a killed product should leave assets: prompts, components, copy, support replies, customer language, smoke tests, and distribution notes.
The next build should start faster because the member now has a harness workflow, a deploy habit, a validation script, and a stronger sense of buyer reality.
This is the repeatable skill the membership sells: not one magic app, but the ability to run the build-measure-decide loop again.
Community
Turn the memo into the next office-hours agenda.
The decision memo is useful community material. It gives office hours a concrete artifact to review: evidence, confusion, next bet, and risks.
Members should ask for critique before starting the next cycle. The group can catch vague promises, missing evidence, and overbuilt plans earlier the second time.
The next 30 days begins only after the decision is explicit.
Write the decision memo
- Summarize what shipped.
- List evidence for and against continuing.
- Separate facts from interpretation.
- Choose iterate, reposition, or kill.
- Write the next two-week test if continuing.
- Carry forward the reusable prompts, code, content, and customer insight.
- Share the memo for review before starting the next build cycle.
Prompt starters
- Turn these launch notes into a decision memo with facts, interpretation, iterate evidence, reposition evidence, kill evidence, and recommendation.
- Challenge my attachment to this product. What evidence is strong, weak, missing, or misleading?
- If I iterate, propose the smallest two-week test and the acceptance criteria that would prove progress.
- If I reposition, suggest three clearer buyers or jobs using the same shipped asset.
- List the reusable prompts, code, content, support replies, customer language, and distribution notes that should survive this cycle.