Scamper

SCAMPER

Goal

Generate a small set of varied, practical idea directions by transforming an existing baseline rather than starting from a blank page.

The job of this skill is not to spray random ideas. The job is to apply structured provocations to a real baseline and return the most promising improvement directions.

This skill expands options. It does not claim the resulting variants are validated winners unless evidence is explicitly provided.

Default Posture

• baseline before variation
• breadth before premature selection
• practical moves over novelty theater
• transform something real, not a vague wish
• keep options distinguishable

When To Use

Run this skill when:

• a baseline product, workflow, feature, offer, or concept already exists
• the user wants more options, variants, or improvements
• ideation is needed but the problem is not a deep contradiction
• the team is circling small tweaks and needs structured divergence
• jtbd has already clarified the job and now options are needed

This is a strong next step before:

• prioritization
• concept selection
• lightweight prototyping
• triz if later variants reveal a real contradiction

Scope Boundaries

In scope:

• generate varied directions from a defined baseline
• use SCAMPER prompts selectively, not mechanically
• surface concrete changes, not only abstract themes
• keep options short, distinct, and testable

Out of scope by default:

• solving a root-cause problem with no baseline
• pretending all seven prompts are always useful
• evaluating full business viability
• replacing deeper methods like jtbd or triz

Escalation Conditions

Pause and keep uncertainty explicit when:

• the baseline cannot be named clearly
• the target outcome is still ambiguous
• all generated options remain cosmetic
• the real problem appears to be contradiction or framing, not variation

If output quality remains shallow after one pass, recommend returning to jtbd, escalating to triz, or narrowing the baseline.

SCAMPER Workflow

1. Name the baseline clearly.
2. Restate the target job or outcome the baseline should improve.
3. Choose the most relevant SCAMPER lenses:
   • substitute
   • combine
   • adapt
   • modify
   • put-to-another-use
   • eliminate
   • reverse
4. Generate 1-2 concrete ideas per useful lens.
5. Remove duplicates and weak cosmetic variants.
6. Return the strongest 3-7 options with the clearest rationale.
7. Recommend the next comparison or test.

Lens Heuristics

Prefer:

• substitute when a component, step, input, or audience assumption may be wrong
• combine when value may increase through bundling or sequencing
• adapt when another context already solved a similar problem
• modify when intensity, scale, speed, or emphasis can change
• put-to-another-use when hidden value exists in the current asset
• eliminate when friction or excess is the real issue
• reverse when the default order or logic may be backwards

Core Questions

Use the minimum set needed:

• What exactly is the baseline?
• What are we trying to improve about it?
• Which parts are fixed, and which can change?
• Which SCAMPER lenses would create genuinely different options?
• Which generated ideas are meaningfully distinct?
• What is the smallest test for the strongest variant?

Output Contract

Always return:

1. baseline
2. target_outcome
3. selected_lenses
4. idea_directions
5. dropped_variants
6. evidence_status (provided, inferred, mixed)
7. open_unknowns
8. recommended_followup (scamper, jtbd, triz, selector, validation)
9. next_test

Good SCAMPER Signals

Strong signals:

• there is a clear existing concept to transform
• multiple variations are useful before choosing
• the need is option expansion, not deep reframing
• ideas can be made concrete quickly

Weak signals:

• the baseline is still unclear
• the real issue is root-cause framing
• the team needs contradiction solving, not option generation
• generated ideas collapse into cosmetic rewrites

Guardrails

• Do not use SCAMPER when there is no real baseline.
• Do not force all seven lenses.
• Do not count cosmetic wording changes as new ideas.
• Distinguish evidence from inference.
• If options stay too shallow, recommend returning to jtbd, escalating to triz, or narrowing the baseline.
• Prefer fewer strong variations over a long weak list.
• If no meaningful variation appears, say so instead of padding the list.

Anti-Patterns

Watch for these failure modes:

• random brainstorming disguised as SCAMPER
• seven mandatory sections with filler ideas
• vague options with no concrete change
• treating quantity as quality
• generating variants that all preserve the same weak assumption
• skipping the next test

Example

User request:

We already have a basic meal planner app. Give me better directions for busy parents.

Expected shape of response:

1. baseline: basic meal planner app with static weekly planning
2. target_outcome: reduce weeknight meal-planning stress for busy parents
3. selected_lenses: combine, eliminate, reverse, adapt
4. idea_directions: combine planning with grocery batching; eliminate full-week planning in favor of 3-day planning; reverse from recipe-first to pantry-first suggestions; adapt school-calendar style shared family coordination
5. dropped_variants: generic "make UI nicer" and "add AI" ideas with no distinct mechanism
6. evidence_status: mixed
7. open_unknowns: who plans meals, how often plans break, whether grocery shopping or decision fatigue is the larger pain
8. recommended_followup: validation
9. next_test: compare 3-day planning and pantry-first planning concepts with target users