validation

name	validation
description	Validate software product or feature ideas using user interviews, market evidence, feasibility checks, technical spikes, and prototypes. Use when confirming whether an idea is worth building and technically possible.

Purpose

This skill helps gather evidence before committing significant engineering effort to a product or feature idea.

Use this skill when:

• Planning user interviews
• Testing market demand
• Checking technical feasibility
• Designing spikes or prototypes
• Evaluating product risk
• Deciding whether to proceed, pivot, or stop

Inputs

Expected inputs:

• Candidate idea
• Problem statement
• Target user
• Value hypothesis
• Riskiest assumptions
• Known constraints
• Feasibility concerns

These inputs usually come from ideation. If the idea is vague, use ideation first to turn it into a testable concept.

Validation Principles

Always optimize for:

1. Testing the riskiest assumption first
2. Using the cheapest reliable evidence
3. Separating user desire from implementation preference
4. Defining decision thresholds before collecting evidence
5. Learning quickly

Avoid optimizing solely for:

• Confirming an existing plan
• Building polished prototypes too early
• Asking leading questions
• Treating opinions as evidence
• Measuring vanity interest

Process

Step 1: Identify Assumptions

List assumptions about:

• User problem
• Willingness to adopt
• Business value
• Technical feasibility
• Operational cost
• Legal or compliance constraints

Flag assumptions that would invalidate the idea if false.

---

Step 2: Choose Validation Methods

Match each assumption to an evidence method.

Assumption Type	Useful Methods
User pain	Interviews, support logs, workflow observation
Demand	Landing page tests, waitlists, sales discovery
Usability	Prototype tests, concept walkthroughs
Feasibility	Technical spikes, architecture review
Viability	Cost model, market analysis, pricing tests

Prefer the smallest test that can produce a decision.

---

Step 3: Define Decision Criteria

Before testing, define:

• What evidence confirms the idea
• What evidence weakens the idea
• What evidence invalidates the idea
• Minimum sample or confidence needed
• Timebox for the validation work

---

Step 4: Interpret Evidence

Summarize:

• Evidence collected
• What changed about the assumptions
• Remaining risks
• Recommended decision

Suggested decisions:

• Proceed
• Refine
• Run another test
• Pivot
• Stop

Anti-Patterns

Avoid:

• Validating after implementation has already begun
• Treating stakeholder enthusiasm as user evidence
• Testing too many assumptions at once
• Ignoring negative signals
• Using prototypes that imply more certainty than exists
• Failing to define a stop condition

Reviewer Checklist

Before finalizing validation:

• Was the riskiest assumption tested?
• Is the evidence specific and decision-relevant?
• Are results separated from interpretation?
• Are remaining risks visible?
• Is there a clear next step into goal-setting, scoping, or back to ideation?

Escalation Guidance

Escalate when:

• Evidence contradicts business pressure
• Technical feasibility is uncertain
• Users and buyers disagree
• Validation requires sensitive customer access
• Compliance or security risks appear material

Example

Input:

• Idea: Guided onboarding checklist
• Assumption: New admins fail setup because required steps are unclear

Expected validation:

1. Interview five recently onboarded admins
2. Review support tickets tagged onboarding
3. Prototype a checklist and test task completion

Recommended next skill:

• Use goal-setting if the idea is worth pursuing.