Build · Create · Analysis & Finance

Build a Pre-Launch PMF Threshold Register

The founder gets a structured PMF threshold register that fixes the metrics, their pass thresholds, and the false-positive traps in advance, so the later PMF call is measured against pre-committed bars instead of post-hoc rationalization.

You receive: A JSON object: { metrics: [{ metricId, name, metricType: enum(survey|retention|activation|revenue|referral), threshold: number, unit: enum(percent|count|days|ratio), measurementWindow }], falsePositives: [{ pattern, whyItMisleads }], sets BeforeLaunch: bool, seanEllisIncluded: bool }

Part of Choose Business Model

What's verified: STUD verifies the register is structurally complete and that the named guardrails exist: minimum metric count, a Sean-Ellis-style survey threshold at >=40%, Day-7/Day-30 retention metrics, and defined false-positive patterns. STUD does NOT measure the product's actual retention or run the survey; it does NOT decide whether the chosen thresholds are the correct PMF bar. It checks that pre-committed, structurally valid thresholds were authored, not that PMF was achieved.

{
 "buyerParamKeys": [
  "requireRetentionWindows",
  "requireSeanEllis"
 ],
 "checkNames": [
  "format_parses",
  "shape_present",
  "metrics_min",
  "unique_metric_ids",
  "fp_min",
  "threshold_sane",
  "set_before_launch",
  "sean_ellis",
  "retention_windows"
 ],
 "constants": {},
 "deliverableLabel": "pmf_readiness_threshold_register",
 "documentKeys": [
  "falsePositives",
  "measurementWindow",
  "metricId",
  "metricType",
  "metrics",
  "name",
  "pattern",
  "setBeforeLaunch",
  "threshold",
  "unit",
  "whyItMisleads"
 ],
 "enumLiterals": [
  [
   "percent",
   "count",
   "days",
   "ratio"
  ],
  [
   "survey",
   "retention",
   "activation",
   "revenue",
   "referral"
  ],
  [
   "yes",
   "true",
   "1"
  ]
 ],
 "submission": "a JSON document (submitted as a string), validated as data; every check below must pass",
 "tier": "doc-validator"
}