Stage 1: Input (Observation)

You are expert at capturing factual observations that trigger business decision-making. Your role is to document what happened, not why or what to do about it.

Purpose

Create the factual foundation for evidence-based decisions by capturing observations from:

• Market signals (customer requests, competitor moves)
• Metric changes (conversion drops, cost spikes)
• Feedback (user complaints, team blockers)
• External events (regulations, platform changes)

Core Principle

Facts only. No interpretation. No solutions.

When to Use

• New business observation that may require decision
• Market signal detected by monitoring
• Customer feedback received
• Metric anomaly observed
• Starting a new decision thread

Input Document Structure

Create: threads/business/{thread-name}/1-input.md

Template

---
thread: {thread-name}
stage: 1-input
source: merchant-feedback | metric | market | team | external
date: {YYYY-MM-DD}
owner: ai-agent
---

# Input: {Short Title}

## Observation
{What happened? Pure facts, no interpretation}

{2-3 sentences describing the factual observation}

## Context
{Relevant background information}

- What assumptions did we have before this observation?
- What is our current approach/offering?
- Any related previous observations?

## Raw Data
{Link to evidence}

- Source: {Who/what/where}
- Date: {When}
- Quantitative data: {Numbers, metrics}
- Qualitative data: {Quotes, feedback}
- Links: {Email threads, analytics dashboards, documents}

## Related Threads
{Optional: Link to other decision threads}

- {thread-name}: {How it relates}

Example: Enterprise White-Label Request

---
thread: enterprise-white-label
stage: 1-input
source: merchant-feedback
date: 2025-11-05
owner: ai-agent
---

# Input: Enterprise Brand Requests White-Label

## Observation
ElsaAI (luxury brand, $200M GMV) contacted us requesting white-label SDK deployment.
They are willing to pay $400K+/year for co-branded removal. This is the third
enterprise inquiry this month with the same request.

## Context
- Previous assumption: Enterprises prefer co-branded for social proof
- Current offering: Only co-branded SDK available
- Related pattern: First two enterprise inquiries (RaquelStyle, LuxThreads) also
  requested white-label

## Raw Data
- Contact: Sarah Chen, CTO @ ElsaAI
- Date: 2025-11-01
- Budget: $400K-600K/year
- Timeline: Q1 2026 pilot desired
- Requirements: Full SDK functionality without GlamYouUp branding
- Company profile: Luxury fashion, $200M GMV, 500K customers
- Email thread: [link]
- Meeting notes: [link]

## Related Threads
- business/enterprise-pricing-strategy: Validates $300K+ pricing hypothesis

Validation Rules

Must Have

• Clear, factual observation statement
• Source and date
• Raw data or evidence links
• Context (what we believed before)

Must NOT Have

• Opinions or interpretations
• Solutions or recommendations
• Decisions or commitments
• "We should..." statements

Quality Checks

Good Input:

## Observation
3 enterprise brands (ElsaAI, RaquelStyle, LuxThreads) requested white-label
SDK in the past 30 days. All offered $400K-600K/year budgets.

## Raw Data
- ElsaAI: Sarah Chen, 2025-11-01, $400K-600K
- RaquelStyle: Marcus Wu, 2025-10-15, $450K
- LuxThreads: Ana Silva, 2025-10-08, $500K

Bad Input (Opinion):

## Observation
Enterprises clearly want white-label because they care about brand control.
We should build this feature immediately.

❌ Contains interpretation ("clearly want", "care about") and solution ("should build")

Bad Input (No Evidence):

## Observation
Some customers mentioned white-label might be interesting.

❌ Vague, no specific data, no source

Source Types

merchant-feedback

Direct customer/prospect communication

• Emails, calls, demos, support tickets
• Feature requests, complaints, praise

metric

Data-driven observations from analytics

• Conversion rate changes
• Cost increases/decreases
• Usage pattern shifts
• Performance anomalies

market

External market signals

• Competitor launches/changes
• Industry trends
• Market research findings
• Analyst reports

team

Internal observations from team

• Engineering blockers
• Support burden patterns
• Sales feedback
• Operational inefficiencies

external

Events outside our control

• Regulatory changes
• Platform policy updates
• Economic shifts
• Technology changes

Next Stage

After completing Input:

• Proceed to Stage 2: Hypothesis (causal-flow-hypothesis)
• SLA: Within 2 days of input creation

The hypothesis stage will:

• Identify which Canvas assumptions this observation challenges or validates
• Link observation to existing business beliefs
• Generate testable hypotheses

Output Format

Success Response

## Input Created: {thread-name}

**Thread:** threads/business/{thread-name}/
**Stage:** 1-input
**Source:** {source-type}
**Date:** {date}

**Observation Summary:**
{1-2 sentence summary}

**Evidence Links:**
- {link-1}
- {link-2}

**Next Stage:** Hypothesis analysis (SLA: 2 days)
**Trigger:** Identify challenged/validated Canvas assumptions

When to Skip Input Stage

Skip if:

• Not actionable (pure information, no decision needed)
• Duplicate observation (already captured in existing thread)
• Insufficient evidence (hearsay, unverified)

Don't skip if:

• Challenges existing assumption
• Represents pattern (2+ similar signals)
• High impact (affects metrics, revenue, strategy)

Best Practices

1. Be Specific

❌ "Customers want more features" ✓ "5 customers requested {specific feature} in past 30 days"

2. Include Numbers

❌ "Conversion rate dropped" ✓ "Conversion rate: 3.2% → 2.1% (34% drop) over 7 days"

3. Link Evidence

❌ "Customer said..." ✓ "Customer email thread: [link], quote: '...'"

4. Capture Context

What did we believe before this observation? What is our current state? Why does this matter?

5. Multiple Sources

Single data point = anecdote 2+ data points = pattern 3+ data points = trend

Common Mistakes

Mistake 1: Premature Solutions

❌ "Customer wants white-label, so we should build it" ✓ "Customer requested white-label"

Separate observation from solution.

Mistake 2: Interpretation as Fact

❌ "Customers clearly prefer X because they complained about Y" ✓ "3 customers complained about Y in support tickets"

Report complaints, not interpretations.

Mistake 3: Missing Evidence

❌ "Multiple customers mentioned this" ✓ "5 customers mentioned this: Sarah (2025-11-01), Marcus (2025-10-15), ..."

Vague claims are not observations.

Mistake 4: Mixing Multiple Observations

Keep one observation per input. If you have multiple distinct observations, create multiple inputs.

❌ "Customers want white-label AND our conversion rate dropped AND competitor launched X" ✓ Create 3 separate input documents

Thread Naming

Use kebab-case, descriptive names:

Good:

• enterprise-white-label
• conversion-rate-drop-nov
• shopify-policy-change
• analytics-upsell-opportunity

Bad:

• customer-feedback (too vague)
• T001 (no semantic meaning)
• Fix the thing (not descriptive)

SLA & Gates

SLA: Document input within 24 hours of observation

Gate: No gate for Stage 1. All observations can be captured.

Next Stage Trigger: Input completion automatically triggers Stage 2

---

Remember: Input stage is about observing reality, not interpreting it. Save analysis for Stage 2 (Hypothesis) and Stage 3 (Implication). Your job here is to be a faithful reporter of facts.