Red Team

Origin & evolution

The practice grew out of cold-war military and intelligence work in the United States, where "red" denoted the adversary and a designated red team would play the opposing side in wargames and strategic analysis. The term and the discipline spread from defence into intelligence assessment, then into cybersecurity, where a red team probes a system's defences while a blue team defends, and more recently into corporate strategy and product decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →-making. Across all of these the core move is the same: assign a group to think like the threat☠️ThreatSecurityA specific security threatView reference →, and protect their independence so they can report what they find.

In product and software work, red teaming has converged with security testing on one side and decision-quality practice on the other. A modern red team might attack a launch plan, a system architecture, a market assumption, or, increasingly, the safety of an AI system, but the structural commitment is constant: adversarial stance, outside-in view, honest reporting.

How it works in practice

An effective red team is set up deliberately, not improvised in the meeting where the decision is made:

• Define the target precisely. The team needs🫀NeedUserA user need, pain, desire, or constraintView reference → a concrete artefact to attack: a written plan, a design document, a specific claim. "Review the strategy" is too diffuse to red team well.
• Grant independence. The red team must be free to reach uncomfortable conclusions. If its members report to the people whose work they are attacking, the findings get softened.
• Choose attack vectors. The team works through the angles a real adversary or reality would exploit: the load that breaks the system, the competitor🥊CompetitorMarket IntelligenceA competing product or companyView reference → response that undercuts the plan, the assumption that, if false, collapses the case.
• Report findings, not verdicts. The output is a set of specific weaknesses and the conditions under which they bite, handed back to the owners to act on, rather than a thumbs up or down.

A worked example. Before a fintech launches a new instant-transfer feature⭐FeatureProduct SpecificationA product capability or featureView reference →, a red team is asked to break it. They probe several vectors. On fraud, they map how a stolen card plus instant settlement removes the chargeback window the current system relies on. On load, they note that the launch coincides with payday, when transfer volume triples. On trust, they find the error messaging✉️MessagingGo-To-MarketMessaging framework and key messagesView reference → exposes whether an account exists, a minor enumeration leak. The launch goes ahead, but with a velocity limit on new accounts, a payday-scale load test, and reworded errors, none of which the build team had prioritised because each lived in someone else's blind spot.

When to use it (and when not)

Red teaming pays off on high-stakes, hard-to-reverse decisions where the cost of a missed weakness is large: security-sensitive systems, major launches, big strategic bets, safety-critical AI. It is most valuable when a team has been close to its own work for a long time and has stopped being able to see it from the outside.

It is overkill for routine, low-stakes, or easily reversible decisions, where the overhead is not justified. It also fails in two predictable ways: when the red team lacks real independence and pulls its punches, and when its findings are received defensively and explained away rather than addressed. A red team only works if the organisation actually wants to hear that it is wrong.

In the Unified Product Graph

Red teaming is a reflection framework in the team-process category. Its work maps to three entity types:

• The plan or design under review is an initiative🚀InitiativeStrategyA large coordinated effort to achieve a strategic goalView reference →: the target of the attack.
• Each angle of attack is a risk🎲RiskComplianceA risk to the product or businessView reference →: a way the target could fail.
• Each weakness or blind spot surfaced is an insight🔦InsightUser ResearchA synthesised finding from researchView reference →.

Capturing a red-team review in the graph connects the findings to the initiative🚀InitiativeStrategyA large coordinated effort to achieve a strategic goalView reference → they assess and to any mitigations that follow. The same target can be red teamed again later and the new findings compared against the old, so the exercise builds a record of how a plan was stress-tested rather than a slide that is shown once and lost.