Idea Evaluation
Overview
Systematically assess solution ideas to prioritize which ones to pursue through prototyping.
When to Use
- •During Ideate phase after generating multiple ideas
- •When deciding which ideas to prototype
- •When stakeholders or leadership ask for prioritization
- •Before committing resources to development
How to Apply
1. Grade on Two Dimensions
IMPACT — How much value would this create?
- •High: Solves major pain point, affects many users, strategic value
- •Medium: Improves experience, helps some users, supports goals
- •Low: Nice improvement, limited scope, minor benefit
FEASIBILITY — How realistic is this to build/implement?
- •High: Clear path, existing tech, reasonable timeline/resources
- •Medium: Some unknowns, might need new tech, moderate complexity
- •Low: Major technical challenges, unclear if possible, high cost
2. Plot on Impact/Feasibility Matrix
FEASIBILITY
Low Med High
┌─────────────────────┐
H │ │ B │ A │
I │ │ │ │
M ├───────┼─────┼──────┤
P │ │ C │ B │
A │ │ │ │
C ├───────┼─────┼──────┤
T │ D │ D │ C │
└─────────────────────┘
A tier: High impact, High feasibility → Prioritize B tier: High impact, Med feasibility OR Med impact, High feasibility → Consider C tier: Med impact, Med feasibility OR Low impact, High feasibility → Maybe later D tier: Low feasibility or Low impact → Park or discard
3. Consider Additional Factors
Beyond impact/feasibility:
- •Stakeholder priority: What do users care about most?
- •Strategic fit: Aligns with business goals?
- •Dependencies: Blocks or enables other ideas?
- •Learning value: Will prototyping teach us something important?
- •Risk: What happens if we're wrong?
4. Make Recommendations
For each tier:
A tier: "Prototype immediately. This addresses [key insight] with clear path forward."
B tier: "Strong candidate. Needs [feasibility spike / user validation / resource check] before committing."
C tier: "Interesting but not priority. Revisit if A/B tier ideas fail or after launch."
D tier: "Park for now. [Technical barriers / unclear value / other ideas are stronger]."
5. Document in currentstate.json
{
"id": "idea1",
"title": "Offline data capture",
"description": "Allow field techs to log data without connection, sync when back online",
"impact": "high",
"feasibility": "high",
"status": "ideated",
"idea_doc_link": "ideas/offline_capture.md"
}
Evaluation Example
Idea: "AI-powered predictive maintenance alerts"
- •Impact: High — Prevents costly downtime, major pain point
- •Feasibility: Low — Need ML expertise, training data, unclear accuracy
- •Grade: B tier
- •Recommendation: Validate predictive value with simple rule-based alerts first, then explore AI if rules prove useful
Idea: "Quick-capture field form"
- •Impact: High — Addresses #1 user frustration with current 10-step process
- •Feasibility: High — Straightforward UI work, existing tech
- •Grade: A tier
- •Recommendation: Prototype immediately, test with 5 field techs
Tips
- •Involve the whole DesignTeam
- •Get stakeholder input on impact
- •Validate feasibility with technical experts
- •Don't over-engineer low-hanging fruit
- •High impact + Low feasibility may need research spike first
- •Re-evaluate as you learn more
- •Document reasoning, not just grades