stanislavnianko Feasibility Spike
Part of the discovery-phase skill pack ·
validationgroup · readsdiscovery-context.md(runprofile-builderfirst if missing).
Kill the biggest technical risks cheaply. Throwaway by contract.
Step 1 — Read context
Read discovery-context.md (section 3. Engagement → Runner role) and risk-assumption-map.md (anchors the spike to a specific assumption).
If discovery-context.md is missing, ask the BA inline: "who's running the spike — solo BA / BA + engineer / engineering lead?" — tag the output [ASSUMED ENGINEERING]. If risk-assumption-map.md is missing, ask: "name 1–3 feasibility assumptions to test in one sentence each" or proceed as open exploration tagged [EXPLORATION-NOT-SPIKE]. Never block; recommend profile-builder / risk-assumption-mapping for high-stakes work.
Engineering capacity reality-check (warn + confirm, do not halt): if runner is solo BA with no engineering support, warn that the spike will produce a spike-shaped artifact with weak engineering signal. Offer: loop in an engineer, defer the spike to delivery, skip and accept the risk in the proposal, or proceed solo with a ⚠ NO-ENGINEER-OVERRIDE banner at the top of tech-spike-report.md and findings tagged [SPECULATIVE].
Step 2 — State spike goal
One sentence. Tie to a specific assumption from risk-map.
Example: "Prove we can extract structured events from free-text emails with ≥80% precision using a single Claude API call."
Step 3 — Time box
| Tier | When |
|---|---|
| Short — 4 hours | Ruling out a "is this even possible?" question |
| Standard — 1-2 days | Validating a specific approach against representative inputs |
| Escalated — up to 1 week | Genuinely unknown territory; requires explicit BA + engineering lead sign-off |
| >1 week | This is no longer a spike. Re-frame as prototype-plan. |
Stop at the time box. Overrunning spikes are how discovery bleeds into delivery.
Step 4 — Narrowest test
- Use production-representative inputs, not cherry-picked
- Throwaway branch / repo named
spike/<topic>— never merge to main - Prefer manual scripting over frameworks (frameworks hide what you're testing)
- Logging is essential; UI is irrelevant
Step 5 — Build minimum, run, measure
Capture:
- What worked, with evidence (screenshots, logs, numbers)
- What didn't, with same
- Surprises — especially newly-discovered constraints
- Rough performance, latency, cost per operation
Step 6 — Feasibility call
Three outcomes only:
- Green — proceed to PoC / MVP as scoped
- Yellow — feasible with caveats; caveats become PoC scope constraints
- Red — blocker. Escalate before building anything. Options:
- Re-scope (loop
feature-scoping) - Different solution (loop
opportunity-mapping) - KILL or PIVOT in
go-nogo-memo
- Re-scope (loop
In outsourcing, a Red call before contract = save the engagement (don't sell what can't be built). After contract = harder; either renegotiate scope or eat the loss.
Step 7 — Archive + tear down
Commit spike code under ./discovery/spike/<topic>/. Do NOT merge to product code. Document tear-down status — was the spike code disposed of, kept as reference, or repurposed?
Output
./discovery/tech-spike-report.mdper./template.md./discovery/spike/<topic>/— disposable code
Append to _log.md: [feasibility-spike | YYYY-MM-DD] goal: <one-line>; box: <hours>; result: <green/yellow/red>; constraints: <list>.
Anti-patterns
- Spike without an assumption. That's exploration. Useful sometimes, but don't mislabel.
- Merging spike code. Spike code skips error handling, tests, polish. Shipping = silent tech debt.
- Overrun. "Just one more hour" violates the rule. Stop, report yellow, decide.
- Hiding red. A failed spike is a saved project. Surface it; celebrate it.
- Spike with no time box. That's R&D. Different cost structure.
- Skipping prerequisite check (engineering capacity in context). BA running this solo will produce a spike-shaped artifact with zero engineering signal.