```yaml
---
name: lighthouse-user-incubation
description: A framework for scaling 0-to-1 products within large organizations using a gated sequence (Wonder-Explore-Make-Impact) and a "Lighthouse Users" growth strategy. Use this to protect early-stage products from premature scaling, define non-traditional success metrics, and manage stakeholder expectations during incubation.
---
```

The Lighthouse User Incubation framework allows product teams within large organizations to operate like "starups" by creating artificial scarcity and protecting "ugly baby" ideas from being smothered by mature-company processes.

## The Four Stage Gates (Point A Framework)

Use these four stages to define the maturity of your internal bet and communicate requirements to leadership:

1.  **Wonder:** Prove there is a viable problem area. Articulate "Why Atlassian?" and "Why now?"
2.  **Explore:** Solution validation. Test Figma prototypes or low-fidelity mocks with users. Goal: Confirm the solution addresses the validated problem.
3.  **Make:** Build the MVP. Transition through Alpha and Beta phases.
4.  **Impact:** General Availability (GA). Shift to standard business metrics (revenue, retention, growth).

## The Lighthouse Scaling Sequence

Instead of focusing on Monthly Active Users (MAU), scale your user base in fixed tiers to protect the user experience and maintain high velocity.

### Phase 1: The First 10 (Qualitative Truth)
*   **Goal:** Prove the solution solves the core problem for a "Lighthouse" segment that represents your future mass market.
*   **Tactics:** 
    *   Recruit 10 users you know by name.
    *   Build a direct feedback loop (e.g., a shared Slack channel).
    *   Engage the whole team (Engineers/Designers) in Zoom calls with these 10 users to build empathy.
*   **Success Metric:** Video snippets of users solving their problems using your prototype.

### Phase 2: The 100 (Edge Case Identification)
*   **Goal:** Identify variations in user scenarios and technical constraints.
*   **Tactics:** 
    *   Expand to different company sizes or industries.
    *   Stay in "Alpha." Manual onboarding is still acceptable.
    *   Focus on the "Safety Funnel"—purposely limit the number of users to prevent a bad experience from damaging the brand.
*   **Success Metric:** Qualitative confirmation that the core solution scales across different contexts.

### Phase 3: The 1,000 (Self-Service & Reliability)
*   **Goal:** Prove the product can survive without the "hand-holding" of the product team.
*   **Tactics:** 
    *   Move to "Beta."
    *   Optimize for self-service onboarding.
    *   Build out documentation and support triggers.
*   **Success Metric:** Users successfully onboard and find value without direct interaction with a PM.

## Stakeholder Management Tactics

*   **Frame Failure Early:** Repeatedly remind stakeholders that "failure is the most likely outcome" (e.g., 70% chance this won't exist in six months). This creates the "scarcity" needed to ignore standard corporate processes (like 3-year roadmaps or complex architecture reviews).
*   **The "High-Speed Train" Effect:** Send weekly, bite-sized updates (e.g., via Slack or internal tools). Include a 30-second demo or a 1-minute user interview snippet. Constant, visible momentum prevents stakeholders from "fucking with the train."
*   **Incubate, Iterate, Integrate:** Do not force the product to fit into the main platform's UX or architecture initially. Hack the components needed to prove value, then "Integrate" once the product hits the Impact stage.

## Examples

**Example 1: Jira Product Discovery (JPD)**
*   **Context:** Building a tool for PMs within a developer-centric company.
*   **Application:** The team stayed in a "Make" phase for nearly 3 years. They used the **10 -> 100 -> 1000** sequence. In the early phase, they used Figma to validate workflows before writing code.
*   **Outcome:** Avoided the "MAU trap" by refusing to launch to 300,000 customers until the "Lighthouse" group was delighted.

**Example 2: Protecting a "Non-Standard" Architecture**
*   **Context:** An internal startup needs a tech stack that isn't supported by the main IT org.
*   **Application:** The PM uses the "Wonder" stage to explain that because the project is a "bet" that might fail in 6 months, it shouldn't "drag the rest of the company into it" by requiring platform support.
*   **Output:** The team gets autonomy to use contractors or separate infrastructure until the "Make" stage.

## Common Pitfalls

*   **Hiding Behind Research:** Relying solely on research reports or NPS scores. **Correction:** Maintain a "Lighthouse" Slack where engineers talk directly to users.
*   **Over-Investing Too Soon:** Dragging in platform teams or 50+ engineers before the "Explore" phase is complete. This slows velocity and increases the cost of failure.
*   **Treating Acquisitions Like Products:** Assuming a bought company can maintain its speed. **Correction:** Treat acquisitions like "hiring" rather than "buying." Expect a massive slowdown during the "Integration" phase.
*   **Falling for Competitive Myopia:** Reacting to every competitor feature. **Correction:** Watch competitors every 3 months; watch user interviews every week. Stay anchored in your "Lighthouse" users' specific pain.