| name | thermal-team-incubation |
| description | A framework for building high-impact, zero-to-one products within large organizations by operating as an autonomous "Thermal" unit. Use this when launching a new initiative that requires high speed, bypassing corporate bureaucracy, or when a project needs to survive multiple leadership changes by proving its own value. |
The "Thermal" model is an organizational strategy designed to insulate small, high-stakes teams from the "drag" of large-company bureaucracy. By operating like an internal startup with a "founder-leader" and a direct line to a single senior decision-maker, teams can ship products at 10x the speed of standard corporate cycles.
Core Pillars of a Thermal Team
- Founder-Leader Ownership: The project lead must act as a founder, not a manager. They own the vision, the team, and the output entirely.
- Single-Sponsor Decision Making: The team reports to exactly one senior executive (e.g., CEO, CPO, or CTO). This eliminates "middle management" layers and the need for consensus across multiple departments.
- The "Functional Atom" Staffing: Keep the team as small as possible—ideally one expert per function (1 ML, 1 Backend, 1 Frontend, 1 Designer, 1 Researcher, 1 PM).
- 100% Radical Focus: Every member must be 100% dedicated. Shared resources or part-time contributors create "momentum friction" that kills Thermal projects.
- Process Autonomy: The team is exempt from standard corporate rituals (OKRs, rigid planning cycles, Jira grooming) in favor of dynamic, milestone-based execution.
Implementation Workflow
Phase 1: Structural Setup
- Secure the "Sponsor": Identify one executive with the power to say "Yes" to everything. Establish a direct communication line (DM or weekly sync) with zero intermediaries.
- Recruit by Self-Selection: Do not assign people to the team. Pitch the vision and let people "opt-in." This ensures every member is mission-aligned and prepared for a high-intensity environment.
- Define the High-Bar Principle: Establish 2-3 non-negotiable principles early (e.g., "The algorithm must be open-source" or "The product is the voice of the people, not the company").
Phase 2: Execution Mechanics
- Dump Heavyweight Tools: Replace Jira/Asana with a single "Live Document" (e.g., Google Doc or Notion) that tracks everything. If a task is no longer relevant, it falls off the doc naturally instead of requiring "backlog grooming."
- Iterate Daily: Meet once a day. Focus on: "What is the biggest problem right now?" and "What is in the way of launching?"
- Set Milestone-Based Goals: Abandon quarterly OKRs. Set the goal for the next milestone (e.g., "Prove 1,000 users can write a helpful note"). When that is hit, set the next one. This allows the roadmap to change multiple times in a two-week span based on real data.
Phase 3: Proving Survival
- Iterative Proof Points: Prove the product at every stage to maintain funding.
- Stage 1: Use prototypes (Figma/UserTesting) to prove demand.
- Stage 2: Use small pilots (e.g., Amazon MTurk) to prove feasibility.
- Stage 3: Launch a limited public pilot to prove quality.
- Delete the "Cruft": Regularly audit the codebase and features. Deleting code is as important as writing it to keep the maintenance burden low for a small team.
Examples
Example 1: Launching a radical new AI feature in a legacy company
- Context: A PM wants to add a decentralized moderation tool to a social platform.
- Thermal Setup: The PM gets the CTO as a single sponsor. They recruit one ML engineer and one designer who are excited about the tech. They ignore the quarterly planning cycle.
- Execution: They use a Google Doc to track "Experiments for this week." They realize the first algorithm is biased. Because they aren't tied to an OKR to "Launch Version 1," they pivot immediately to a "Bridging Agreement" model and ship a new pilot in 14 days.
Example 2: Rapidly scaling a feature during a crisis
- Context: A sudden global event causes a deluge of misinformation.
- Thermal Setup: The team (already small and focused) skips all external meetings.
- Execution: The lead talks directly to the CEO. They realize they need "Image Matching" immediately. Because the team is "Thermal," they re-route all 5 engineers to this one task and ship the feature in 3 weeks—a task that would usually take 6 months.
Common Pitfalls
- The "Shared Resource" Trap: Allowing an engineer to spend "20% of their time" on another project. This introduces a 1-2 week delay every time you need a decision from them, killing momentum.
- Backlog Grooming Overload: Spending more time managing Jira tickets than talking about the product. If the team is small enough, you should be able to keep the core priorities in your head.
- Assigning vs. Recruiting: If people are "assigned" to a high-intensity Thermal team without opting in, they will burn out or resist the "Hardcore" pace.
- Over-Designing for Scale: Trying to build a system for 100M users before proving 1,000 users find it helpful. Use "Thermal" speed to prove the value first.
