Red teaming for product teams: challenge the plan before everyone agrees
The proposal is tidy. The slides make sense. Everyone can see how the new feature should work, and the meeting is heading towards agreement.
Then someone asks what happens when the customer can’t use it in the way the team expects.
That question can feel inconvenient when a plan already has momentum. It can also reveal the assumption that most needs checking. Red teaming offers a useful way to make that challenge part of the work.
The UK Defence connection
Red teaming uses structured critical thinking to examine a problem or proposal from different perspectives. The UK Ministry of Defence’s 2021 handbook encourages this questioning mindset in everyday decisions, as well as discussing formal red teams. Its intended audience includes civilian organisations.
For a product team, I would adapt that principle into a focused review: identify what the plan depends on, look for evidence that could challenge it and decide what needs to change. The exercise below is a practical tech adaptation.
A practical tech example
Consider an equipment-hire business planning self-service collection. Customers will receive a code on their phone, enter it at a locker and collect their equipment. The proposal assumes that fewer desk visits will free staff for other work.
That sounds plausible. It leaves questions about customers with a flat phone battery, equipment returned late and items that need a safety explanation before use. A working code-entry screen cannot answer those questions by itself.
The review needs product, development and operational knowledge. Include someone who handles collections, alongside people proposing the feature. Give everyone a short description beforehand, including the decision that needs to be made.
How to put it into practice
Name the assumption
Purpose: Make the hidden dependency discussable.
Write claims as statements that could be checked. “Customers will find this convenient” is broad. “Customers collecting after desk hours can access their code at the locker” is more useful.
Separate what the team knows from what it expects. A survey about interest in self-service does not show whether people can retrieve a code at the collection point. Keep the evidence attached to the specific claim it supports.
Look for a case that challenges it
Purpose: Find the edge of the plan before it reaches customers.
Ask each participant to bring one situation where the proposal could struggle. Offer a written route as well as speaking time, so a quick discussion does not become the only way to contribute.
In the example, a colleague raises poor mobile reception near the lockers. Another asks whether a late return would leave the next customer with a valid code but no equipment. Explore the consequences without expecting the person raising them to design every solution.
Choose a proportionate check
Purpose: Turn a concern into evidence or a bounded decision.
For code access, the team could inspect the collection location and test the proposed retrieval journey on permitted test devices. For late returns, operations could walk through how availability is confirmed and who contacts the waiting customer.
Avoid labelling every uncertainty a blocker. Agree which questions must be answered before a pilot, which can be monitored and which make the proposal unsuitable in its current form. Give each important check an owner and time in the plan.
Record what the challenge changed
Purpose: Show how the review affected the decision.
Suppose the team proposes a staffed-hours pilot while it investigates code access and late-return handling. Record the scope, outstanding evidence and who will review it. This is a proposed response, not a claim that the pilot has succeeded.
If a concern does not change the decision, explain why. Useful challenge needs somewhere to go after the meeting. Otherwise, people may reasonably conclude that the invitation to question the plan was only a formality.
A record you can use
What to try next
Start with one assumption in your next proposal review. Ask what evidence would change the team’s mind, then make space to examine the answer.
The value comes from a clearer decision and a plan that responds to what the team has learned. A lively debate alone is not enough.
Source: UK Ministry of Defence, Red Teaming Handbook, third edition (2021). The tech examples and working tools are Coded Female adaptations.
You May Also Like
Building useful AI products: a practical guide for product leaders
Removing blockers: a practical guide for Scrum Masters
