Last Updated: 2025-11-04 Status: 8 patterns captured from 7 test scenarios Goal: 10+ patterns for robust decision exploration
When a user describes their decision, scan these patterns to identify potential matches. Patterns help you:
- Recognize deeper issues beneath surface requests
- Ask better questions specific to the pattern
- Avoid common pitfalls that lead to bad recommendations
Remember: Patterns are recognition tools, not rigid rules. Use them to inform discovery, not replace it.
Surface request: Home improvement, office redesign, space optimization
Signals to recognize:
- Emotional language: "inspiring," "proud," "excited" (not functional benefits)
- Multi-use space mentioned: work + games + personal storage
- "Mine" ownership language: "my space," "where I can..."
- Renovation appetite: Willing to invest time/money in transformation
Real problem: Creating retreat/escape space, not optimizing productivity
Key questions to ask:
- How will you actually use this space beyond work?
- What activities make you feel most yourself?
- Who else uses or accesses this space?
- What's your appetite for renovation vs. refresh?
Common pitfalls:
- Treating as pure work optimization (ergonomic chair, standing desk)
- Missing the emotional/personal dimension
- Recommending minimal changes when transformation desired
Example scenario: Office redesign test - User wanted "inspiring office" but real need was personal sanctuary with games, personal memorabilia, and retreat space.
Surface request: Side business, passive income, skill development, "additional revenue"
Signals to recognize:
- Age concerns: "I'm 45," "been doing this 20 years"
- AI/disruption fears: Mentions automation, AI replacing jobs
- Job security language: "market is tough," "just in case"
- High-effort option framed as "additional" (doesn't match - why work so hard for "extra" money?)
- Innovation/cutting-edge team member feeling vulnerable
Real problem: Hedging against career uncertainty, not entrepreneurship
Key questions to ask:
- What triggered you thinking about this RIGHT NOW?
- How secure does your current job feel? (1-10)
- If money weren't a concern, would you still want to do this?
- What's your capital situation? (might reveal better hedging strategies)
Common pitfalls:
- Taking "side business" request at face value
- Recommending entrepreneurship when real need is career insurance
- Missing that "additional revenue" framing contradicts high effort required
- Not exploring less-effort hedging options (savings, passive investments)
Example scenario: Passive income test - User wanted "fast food franchise for additional revenue" but real issue was employability anxiety. Had $500K+ capital - better hedge was passive income, not high-effort business.
Surface request: Prevention, screening, lifestyle optimization, "catch it early"
Signals to recognize:
- Recent diagnosis in social circle: Friend, family member, colleague
- Family history mentioned: Multiple relatives with same condition
- Urgency language: "I feel like I should," "I need to do something"
- "Catch it early" framing: Focus on detection over actual risk reduction
- Trigger timing: Right after someone else's diagnosis
Real problem: Control over health outcomes, avoiding being blindsided (not generic prevention)
Key questions to ask:
- What happened that's making you think about this RIGHT NOW?
- What types of cancer/conditions run in your family?
- At what ages were family members diagnosed?
- What's your ethnicity? (affects genetic testing recommendations)
- What screening are you currently doing?
Common pitfalls:
- Generic "eat healthy, exercise" advice
- Missing the anxiety trigger (recent diagnosis)
- Not recognizing hereditary patterns that change risk profile
- Treating all prevention the same (hereditary vs. lifestyle vs. random)
Example scenario: Cancer prevention test - User wanted "preventative measures" after friend's stage 4 diagnosis. Family history revealed hereditary pattern (colon, pancreatic, breast cancer early-onset) → genetic counseling recommended, not generic screening.
Surface request: Starting business, side hustle, passive income
Signals to recognize:
- High-effort option (franchise, business) framed as "additional" revenue
- Mismatch between effort and "additional" language
- Core revenue already exists and stable
- No clear entrepreneurial passion mentioned
- Defensive/hedging language: "just in case," "to be safe"
Real problem: Either security hedge OR wrong solution entirely
Key questions to ask:
- Why do you need additional revenue? (often reveals security fears)
- How much time/effort are you willing to invest?
- What's your current financial situation? (capital, savings, runway)
- If you had $X already, would you still want to do this?
Common pitfalls:
- Not catching the effort/framing mismatch
- Assuming entrepreneurial motivation when it's security seeking
- Recommending business when passive investment better fits need
- Missing capital availability that changes recommendation entirely
Example scenario: Passive income test - "Fast food franchise for additional revenue" (high-effort) didn't match "additional" framing. Real issue: employability hedge with $500K+ capital available.
Surface request: Feature prioritization decision (customer count-based)
Signals to recognize:
- Framed as COUNT vs VALUE: "10 customers want X, 2 want Y"
- Features serve opposite stakeholders: Employers vs. employees, users vs. admins
- One feature described as "controversial" or "politically loaded"
- Product positioning contradiction: "Employees first" but feature serves employers
- "Nice-to-have" from many vs. "make-or-break" from few
Real problem: Product identity crisis - must choose who you're building for
Key questions to ask:
- What's your product positioning? Who do you claim to serve?
- Who actually requested the popular feature? (Top-down or bottom-up?)
- What's the political/cultural context? Why is it controversial?
- Does this feature align with your stated values?
- What happens if you DON'T build the popular feature? (often: nothing)
Common pitfalls:
- Optimizing for customer count instead of values alignment
- Treating feature prioritization as pure ROI calculation
- Missing that "nice-to-have" from many < "make-or-break" from few
- Not recognizing when features lock you into positioning
- Assuming more customers = better decision
Example scenario: Feature decision test - "10 customers want workplace presence (RTO tool), 2 want exclude list (safety feature)." Real issue: Product identity crisis. Can't serve both employers (surveillance) and employees (privacy/safety).
Surface request: "Stable money vs risky thing" decision
Signals to recognize:
- Fear-based language: "market is tough," "I'm thankful," "playing it safe"
- Strong fundamentals contradicting scarcity narrative: Growth, savings, runway
- Underpriced "stable" option: Below-market rates framed as opportunity
- Inflection point timing: Growth momentum that would be lost if paused
- Framing choice as "safety vs risk" when math shows risk is minimal
Real problem: Fear preventing commitment to opportunity despite having resources and validation
Key questions to ask:
- What's your actual financial runway? (reveal false scarcity)
- What are the fundamentals of what you're "risking"? (reveal strength)
- What's the hourly rate of the "stable" option? (reveal if underpriced)
- What happens if you pause momentum? (reveal opportunity cost)
Common pitfalls:
- Accepting "market is tough" without challenging with user's own metrics
- Validating fear-based decision when fundamentals are strong
- Treating "stable money" as inherently better than "risky growth"
- Missing that low-rate work can be distraction from inflection point
- Not recognizing scarcity mindset despite substantial runway
Example scenario: Client vs product test - "$6K/month client (stable) vs $2K MRR product (risky)." Reality: $60K savings (12-14 months runway), product 4X growth in 6 months, 97% retention. Client was $40/hour (below market). Scarcity in head, not bank account.
Surface request: Build a product/app/feature
Signals to recognize:
- "I had an idea... thought it would be cool/useful"
- No research done upfront
- Lists features before identifying who/why
- Can't articulate core pain point when asked directly
- First-time builder with limited time
- Excitement-driven, not problem-driven
- Jumps to comprehensive feature list immediately
Real problem: Wants to build something, picked an idea that sounds good, hasn't validated it's worth months of work
Key questions to ask:
- What triggered this idea RIGHT NOW? (reveals spontaneous vs researched)
- What's your track record with side projects? (reveals if serial starter or first-timer)
- How much time can you realistically commit? (reveals if timeline is feasible)
- Have you validated this with potential users? (reveals depth of validation)
- What's the ONE problem you're solving? (reveals if they know the core pain point)
Common pitfalls:
- Taking feature list at face value (they described WHAT, not WHY)
- Not challenging lack of validation
- Missing that first-time builders underestimate shipping time by 3-5x
- Assuming excitement = validation
- Not asking about core pain point explicitly
- Recommending "just build it" when they haven't validated demand
Example scenario: Meal planning app test - User wanted to build comprehensive meal planning app (custom plans, recipes, shopping lists, nutrition tracking). First-time builder, 5-10 hrs/week, couldn't answer "What's the ONE problem frustrating you most?" Revealed: solution-first, not problem-first thinking.
Surface request: Help me prepare a presentation for leadership/stakeholders
Signals to recognize:
- Excited about vision/project
- No measurable results yet to back up the ask
- Unclear what they're asking for ("just a check-in", "not sure")
- Skeptics already exist in the audience
- Top-level support but middle management doubt
- Wants adoption/behavior change without proof
- Timing driven by excitement, not strategy
Real problem: Presenting too early out of excitement, not readiness. Will burn credibility on "we might have something" when they could wait and present "we DO have something."
Key questions to ask:
- What does the audience currently know? (reveals awareness vs skepticism)
- What specific decision are you asking them to make? (reveals if ask is clear)
- What's the current adoption/results status? (reveals if they have proof)
- What happens if they say "prove it first"? (reveals if timeline is flexible)
- What's driving the timing - why now vs later? (reveals if it's excitement vs necessity)
- Are you under threat that requires immediate action? (reveals true urgency)
Common pitfalls:
- Taking "prepare presentation" request at face value
- Not challenging whether they should present at all
- Missing the credibility gap (big ask, no proof)
- Not questioning unclear ask ("not sure what I want")
- Assuming excitement = readiness to present
- Not asking about strategic timing
Example scenario: Amplifier SLT presentation test - User wanted to present Amplifier project to SLT for "awareness, air cover, and pivot teams." Reality: No results yet, handful of users, unclear ask ("just a check-in, not sure"), middle management skeptics. Recommendation: DON'T present now, build proof first (3-6 months), then present with clear results and ask.
- Surface vs. Depth: All patterns show surface requests hiding deeper issues
- Emotional Triggers: Recent events (diagnosis, job fears, friend's situation) drive decisions
- Framing Mismatch: How user frames decision often contradicts actual situation
- Constraint Revelation: Key question unlocks pattern (Q2 runway, Q4 capital, Q3 cancer types)
- Values Alignment: Decisions often about identity, not optimization
Some decisions match multiple patterns:
- Employability anxiety + "Additional revenue" misframing: Passive income test
- Health anxiety + Control seeking: Cancer prevention test
- Scarcity mindset + Underpricing work: Client vs product test
- Solution looking for problem + First-time builder: Meal planning app test
- Premature presentation + Unclear ask: Amplifier SLT presentation test
Use pattern combinations to deepen understanding, not confuse the issue.
As you test more scenarios, capture new patterns using this template:
## Pattern N: [Name]
**Surface request**: [What user asks for]
**Signals to recognize**:
- [Signal 1]
- [Signal 2]
- [Signal 3]
**Real problem**: [What they're actually trying to solve]
**Key questions to ask**:
1. [Question that reveals this pattern]
2. [Question that deepens understanding]
3. [Question that challenges assumptions]
**Common pitfalls**:
- [What NOT to recommend]
- [What assumptions to challenge]
- [What to watch out for]
**Example scenario**: [Link to test log]Target: 10+ patterns total
Remaining test scenarios that might reveal new patterns:
- Lose-lose scenarios (RTO policy #8, Pivot decision #16)
- Time pressure decisions (Job offer #7, Competitive feature #17)
- Ethical dilemmas (Manipulate metrics #19)
- Systemic problems (Meeting overload #18)
- Post-success regret (Sold company #15)
- Question Framework - Question quality heuristics
- Test Scenarios - Full list of 20 scenarios
- Test Logs - Detailed test documentation