Definition
A tiger team is a small group of skilled individuals pulled from different parts of an organization to address a specific, time-bound problem. The term originated in the U.S. military and NASA, where tiger teams were assembled to investigate failures and develop rapid fixes. In product development, tiger teams form when a problem is too urgent or too cross-cutting for any single team to handle through normal processes.
Tiger teams differ from standing product teams in three ways. First, they are temporary. They have a defined start date, end date, and deliverable. Second, they are composed of experts selected for the specific problem, not people who happen to be available. Third, they operate with reduced bureaucracy. Tiger teams typically report directly to an executive sponsor and bypass normal sprint ceremonies, approval chains, and planning cycles. This makes them fast but also expensive in terms of organizational disruption.
The relationship between tiger teams and regular empowered teams is delicate. Healthy organizations use tiger teams rarely, for genuinely exceptional situations. They are a complement to sprint-based delivery, not a replacement. When tiger teams become the default way to get important work done, it usually indicates a problem with team structure, resourcing, or stakeholder management processes.
Why It Matters for Product Managers
PMs need to know when to propose a tiger team and when to resist pressure to create one. The right time for a tiger team is when you face a problem that genuinely cannot wait for the next planning cycle and requires skills from multiple teams. A security breach that needs a permanent architectural fix, a competitor launch that threatens a key market position, or a technical migration that blocks three teams' roadmaps are all legitimate tiger team scenarios.
The PM's role on a tiger team is usually to scope the problem clearly, define success criteria, and ensure the team stays focused on the stated objective. Tiger teams have a tendency to expand their scope as they discover related problems. A good PM keeps the team laser-focused on the original deliverable and logs adjacent discoveries for the regular teams to address later. For PMs who are not on the tiger team, the key concern is managing the impact on your own team when key engineers are temporarily pulled away.
How to Apply It
Before forming a tiger team, write a one-page charter. Define the problem in specific terms, the success criteria, the timeline (two to four weeks is ideal), the team composition (by name, not by role), and the executive sponsor. Get agreement from each team manager whose people will be borrowed. Commit to returning those people to their home teams on the agreed date.
During the tiger team's operation, hold daily standups to maintain focus and surface blockers quickly. The executive sponsor should remove organizational obstacles, not micromanage the technical approach. When the tiger team delivers, do three things: hand off the solution to the team that will maintain it long-term, document what was built and why, and conduct a retrospective on both the solution and the organizational conditions that made a tiger team necessary. Use spike work within regular teams to investigate problems before escalating to a tiger team. For guidance on managing cross-functional collaboration, see the stakeholder management handbook.