samarv/.claude/skills/lighthouse-user-incubation

---
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.