Confirm that the MVP can complete the core job
Do not measure retention before the product can do something useful end to end. Define the core job as a completed task in context, not account creation, a feature click, or a marketing-page visit. Identify eligible people, the real trigger, and the version used.
An MVP can be narrow and manual behind the scenes if the user honestly receives the outcome. Someone must complete the job. A landing page tests an offer earlier, but its CTA traffic is not evidence of MVP delivery or retention.
Copyable MVP validation worksheet
Use after a core task is completed. Separate first and repeat use, behavior and stated intent, and disconfirming interviews.
MVP VALIDATION WORKSHEET Core job [completed working-MVP task] Target user and context [role] during [real trigger or workflow] Completion and repeat use First completion: [observable task] Repeat completion: [second or later use within window] Existing alternative Before the MVP: [tool, manual process, or no action] at [cost, effort, delay, or risk]. Evidence sources [lawful analytics, support records, invoices, interviews, or permitted notes] Window and denominator Start: [date] End: [date] Eligible people with access: [definition] Record separately First completion: [definition] Repeat completion: [definition] Alternative cost: [definition] Disconfirming interview: [definition] Limits: [what each signal cannot prove] Decision rule If [pattern], [next investment or test]. If [counterevidence], [narrow, revise, or pause]. If [missing evidence], record [inconclusive condition]. Decision snapshot Supports: [statement] Challenges: [statement] Unknown: [statement] Next action: [statement]
Collect behavior, alternative cost, and counterevidence
Separate first completion from repeat completion within a defined window. Study the prior spreadsheet, existing product, delay, service, or no action. Alternative cost gives context, but do not invent savings from anecdote. Look for return when the trigger recurs, workarounds, and blockers.
Pair records with disconfirming interviews. Ask about a recent completion, failed attempt, existing alternative, and a case where the product was not chosen. Interviews explain a trace; they do not erase it. Use lawful, permissioned data sources you control and record gaps.
Fictional illustrative example
Fictional example: repeat use after a usable approval tracker
A fictional MVP lets solo grant consultants collect client approvals and mark a package complete. Twelve eligible consultants receive access after a real deadline. Seven complete one package. Within four weeks, three complete another when a deadline recurs; two return but finish in a spreadsheet, and two have no second deadline. Interviews show one repeat user values client ownership, while two non-repeat users have a portal from their largest client.
This supports investigating recurring deadline workflows for solo consultants and challenges a broad tracker claim. It does not establish long-term retention, market size, or payment willingness. Compare the MVP with the supplied portal and observe more permitted deadline cycles.
Decide from patterns, not a single activity count
First completion may show that onboarding and the basic task work. Repeat completion after a similar trigger can strengthen a recurring-job case; sustained use of an alternative may challenge value or switching cost. Payment is a separate question and cannot be inferred from visits or leads.
Keep cohorts, versions, and access conditions separate. A small early group can expose a broken job definition or missing constraint, not estimate a market. Decide to improve the workflow, narrow the segment, examine an alternative, or pause, and retain counterevidence.
What weak MVP validation usually misses
Do not call signups, page clicks, or onboarding retention. Avoid pooling people on different versions, access dates, or triggers. Do not ask only completers why they liked it. Do not equate stated preference with a completed job or assume analytics are lawful or complete. Missing records are unknown, not a favorable story.
What is the minimum evidence for MVP validation?
There is no universal minimum. Begin with a defined core job, eligible users, a completion record, a repeat-use window, the existing alternative, and evidence that could challenge your interpretation.
Can a public CTA measure retention?
No. It measures interest in a public page action. Retention requires evidence that people returned to a usable product and completed a relevant task again under a defined condition.
Does EviDemand connect to my analytics or billing tools?
No automatic external product, retention, or payment collection is promised. Export or organize lawful records from tools you control, then use them as evidence for your own decision.
Use public-page evidence for the question it can answer
Keep a validation question in an individual project and use a page experiment when the next question concerns an offer or audience. Two templates, three styles, system-subdomain publishing, built-in forms, private test plans, and decision snapshots are available. Public-page visits, CTA clicks, and section views are measured after analytics consent; declining analytics does not block submissions. Those page signals do not measure completion, repeat use, or payment inside your MVP. Bring lawful external evidence to a separately agreed research scope rather than expecting automatic integrations or worksheet import. You provide visitors and execute tests; operations handles research separately. AI drafting is not currently configured, and a project does not promise an immediate verdict.
