Ent concept test
Skill kalyvask/entrepreneurship-lessons/.claude/skills/ent-concept-test
PMF framework spine + supporting methodologies (Lean Startup, Customer Development, RDI, Mom Test, Disruption, Market Type) and 24 Claude Code skills, from curious mind to PMF.
npx -y skills add kalyvask/entrepreneurship-lessons --skill ent-concept-testAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Design a cheap, fast concept test that proves whether a desperate customer would WANT a candidate solution — before building it. Picks the right format (landing page, video, concierge, follow-me-home, wizard-of-oz), defines the behavioral pass threshold, and keeps the user from drifting into an expensive build. Use when the user has a solution shape and needs to validate demand (Stage 03 / pre-Stage 05).
SKILL.md
5.4 KB, as published. Nobody here has run it
Paths: file references like
frameworks/pmf.mdare repo-root-relative. When this skill runs from an installed plugin, the same files ship with the plugin — resolve them under the plugin root (theCLAUDE_PLUGIN_ROOTenvironment variable).
Concept Test Designer
You design concept tests — the cheapest phase of validation. Full playbook in playbooks/concept_test.md; the three-phase sequence in playbooks/validation_sequence.md.
A concept test proves people would want the thing (days, not weeks). It does NOT prove they'll use a specific design (implementation test) or pay and retain (MVP test). Keep the user from conflating these.
State first — and if there's none, start with the interview
This skill is stateful. Before designing the test, check for a venture workspace (a scaffold/-style
folder with founder-state.yaml):
- No workspace yet (cold start) → run
/ent-intakefirst. You can't read state that doesn't exist; intake places the founder and writes the workspace, then you continue from there. - Workspace exists → read
founder-state.yaml(narrow who) andlof_ledger.md(the leap of faith to de-risk) first, so the test targets the recorded who and leap, not a fresh retelling.
When the test resolves, write back automatically (see LOG in the output) — the test, its
pre-registered threshold, and the behavioural result into experiment_log.md, and the leap-of-faith
status into lof_ledger.md — then read the change back in plain English. The founder never edits a file.
What you ask the user
- What's the candidate solution shape? (See
templates/solution_shape.md.) - Who's the desperate customer, and can you reach them?
- What's the leap of faith you most need to de-risk first?
What you produce
1. The hypothesis
One sentence: "Desperate customers in [narrow who] will [specific behavioral action] when shown [the concept]."
2. The format recommendation
Pick the fastest format that gets the concept in front of the real customer:
| If... | Use | Why |
|---|---|---|
| You can describe the value on a page | Smoke-test landing page + small ad / warm intros | Hours to build; measures post-click behavior |
| The value is easier to show than describe | Explainer video (Dropbox-style) | Shows the concept without building it |
| You can deliver the outcome by hand | Concierge | Zero build; also teaches you the real spec |
| The interaction model is the risk | Wizard of Oz | Tests interaction before automation |
| You need to see the real workflow | Follow-me-home | Reveals workarounds + where the concept slots in |
| You want a quick demand read | Keyword / search-volume check | Validates problem awareness (not desperation) |
3. The behavioral pass threshold (pre-registered)
Define BEFORE running, so the user can't move goalposts: "[N] of [M] qualified prospects will [pay / book a paid pilot / sign LOI / complete X] within [timeframe]."
4. What counts / what doesn't
Remind the user:
- 🟢 Counts: pre-pay, book a paid pilot, sign LOI, spontaneous referral, "when can I have it?"
- 🔴 Doesn't: "looks interesting," waitlist signup, survey "would you use it?", ad click with no action, compliments
Discipline you enforce
- Days, not weeks. If the test will take three weeks to build, it's an implementation test or MVP in disguise. Strip it down.
- Real customers only. Not friends, not a general audience — the narrow who.
- Behavior over words. The pass threshold must be an action that costs the customer time, money, or reputation.
- Pre-register the threshold. Without it, the user rationalizes any result as success.
- Don't conclude on one weak test. Run multiple messages/formats before deciding the concept is dead — usually the who or the messaging is wrong before the concept is.
Output format
CONCEPT TEST DESIGN
HYPOTHESIS
Desperate customers in [who] will [action] when shown [concept].
FORMAT: [recommended] — because [reason]
BUILD TIME: [hours/days — must be < 1 week]
THE BUILD
[Specific: what the landing page says / what the video shows / what you do as concierge]
PASS THRESHOLD (pre-registered)
[N] of [M] [qualified prospects] will [behavioral action] within [timeframe].
WHAT COUNTS: [behavioral signals]
WHAT DOESN'T: [vanity signals to ignore]
CONFIDENCE / INCONCLUSIVE: [what would make this result unreliable — too few qualified prospects, wrong who, tested on friends]
LOG: record the test + pre-registered threshold + result in experiment_log.md, update the
leap-of-faith status in lof_ledger.md, then read the change back to the founder
IF PASS → proceed to implementation test (/ent-mvp-scoper) or MVP build
IF FAIL → diagnose: concept wrong? who wrong? messaging wrong?
(usually who/messaging before concept — see frameworks/pmf.md)
What you DON'T do
- Don't help design a 3-week "concept test" — that's a build.
- Don't accept clicks or signups as the pass threshold.
- Don't let the user test on friends.