/spark

Feature Ideation Anti-Patterns

Purpose: prevent Spark from generating features that are politically driven, weakly validated, or strategically misaligned.

Contents

• Core anti-patterns
• Kill criteria
• Shiny-object filter
• Explore vs exploit balance
• Proposal checklist

Core Anti-Patterns

Feature Factory

Reference data point:

• roughly 80% of enterprise software features are barely used or not used at all

Diagnostic signals:

• shipped feature count is treated as success
• adoption is not measured after launch
• backlog growth never slows down
• teams ask "what next?" more often than "why?"
• stakeholder requests enter delivery without discovery

Escape moves:

• focus OKRs on outcomes, not output
• use data-backed prioritization such as RICE
• define adoption and retention checks before shipping
• add kill criteria to every material proposal

HiPPO And Build Trap

Rules:

• data beats hierarchy
• personas beat generic stakeholder preference
• hypotheses beat intuition
• outcomes beat busyness

Build Trap reframing:

Do not ask: "What should we build next?"
Ask: "Which outcome matters most, and what is the smallest move that can improve it?"

Kill Criteria

## Kill Criteria

Add this block when the proposal needs a post-launch stop condition.

Minimum structure:

• adoption below ___% after 30 days
• primary metric regresses by ___%
• experiment shows no statistically significant improvement

Rule:

• if a feature cannot define a realistic kill condition, treat it as riskier than it looks

Shiny Object Filter

Use this sequence:

1. Does it fit the product vision?
2. Is it grounded in a target persona need?
3. Is the RICE Score above the bar?
4. Can an existing feature be extended instead?

If any answer is no:

• reject, backlog, or convert the idea into an enhancement rather than a new feature

Explore vs Exploit

Recommended portfolio balance:

• Exploit 70%
• Explore 30%

Proposal Checklist

Before proposing

• a concrete persona exists
• the desired outcome is named
• RICE Score is calculated
• kill criteria are defined when relevant
• existing feature extension was considered first

While proposing

• the proposal is data-backed, not HiPPO-backed
• the idea matches product vision
• the hypothesis is measurable
• sunk-cost bias is not driving continuation

After proposing

• adoption measurement is planned
• kill-criteria review is scheduled

Discovery Anti-Patterns (sources + detail)

Extended rationale and sources for the Spark "Never" and "Ask First" boundaries:

• Confirmation-biased discovery — validating only pre-committed ideas is the most common discovery anti-pattern; it produces proposals that confirm assumptions rather than test them. Discovery must explore at least two alternative problem framings before converging. Retrofitting tell: if every discovered opportunity maps neatly to a feature already on the roadmap, the team is confirming, not discovering. Real discovery surfaces uncomfortable truths — features already shipped that do not serve important jobs. [Source: svpg.com — product discovery anti-patterns; age-of-product.com — discovery anti-patterns; kaizenko.com — JTBD retrofitting]
• Feature factory — proposing features focused solely on output velocity without measurable outcomes. Every proposal must define the behavioral change or business metric it targets, not just the feature shape. [Source: logrocket.com — PM anti-patterns; prodpad.com — Agile anti-patterns]
• Incrementalism bias — shipping a conservative-only slate. Every session must surface ≥1 ambitious bet (new capability, contrarian framing, or 10x outcome) even when it scores lower on raw RICE. Comparing an H3 moonshot against an H1 quick-win on a single RICE number and silently dropping the moonshot is the bias — rank bold bets within their horizon class, present the best of each, and let the human choose the risk appetite. "Safe and obvious" is a finding to flag, not a default to settle on. [Source: svpg.com — product discovery anti-patterns]
• Bloated backlog — a backlog of 50+ unscored items signals a need to prune and prioritize before proposing new features. [Source: prodpad.com — Agile anti-patterns]