Leadership methods / Cross-team discovery
Cross-team discovery: Align stakeholders around a shared direction
A practical facilitation method for connecting business, design and development perspectives to a shared product decision.
Explore my enterprise delivery practiceGive the conversation a shared purpose
Cross-team discovery works best when people can see what they are contributing to. Business owners, development and design bring different forms of expertise. The facilitator’s responsibility is to give those perspectives a common problem to work on and a route towards a decision the team can carry into delivery.
I developed NO-PRESSURE after working in marketing and facilitating creative discussions. I published the approach in UX Collective on 21 November 2019. This version reframes the method around stakeholder alignment and product discovery, with an illustrative example of how to apply it.
Start with the goal and the evidence of success
Before exploring ideas, write down the outcome the session is meant to support and how the group will recognise success. Those two questions give participants a reference point when the discussion opens into different possibilities. A moderator records the contributions and guides the group through the stages.
The outcome should be specific enough to guide a choice. For an illustrative field-service discovery session, the goal might be to help crews complete a repair with fewer avoidable return journeys. The team can then discuss how it would recognise a useful change. I use this hypothetical example to show how the method can be applied.
Collect the problems each function can see
The first stage is to ask participants which problems stand between the current situation and the intended result. Capture those problems in a shared list. Business owners can explain the commercial or operational need, while design and development contribute what they know about the experience and implementation.
In the illustrative field-service example, operations may need a more complete inspection record, crews may need to know which materials to collect and product teams may need to connect those needs into one journey. Recording the concerns together gives the group a fuller view of the work.
The facilitator can help distinguish a problem from a proposed solution. A request for another form may point to missing information at a handoff. Making the underlying need explicit leaves the team room to consider several ways to address it.
Explore solutions with room to contribute
The second stage invites suggestions for each recorded problem. In my original format, I used a fifteen-minute exploration period and asked participants to suspend criticism while generating ideas. That separation gives people a clear opportunity to contribute before the group assesses what is practical.
For the field-service example, possibilities could include clearer inspection guidance, a more useful defect record or better preparation before dispatch. At this stage, the moderator helps participants connect ideas to the problems they address. The shared goal remains visible while the group explores.
A later evaluation can test assumptions, dependencies and suitability. First create useful options, then decide which deserve further work.
Bring resources and constraints into the decision
The third stage asks what each option needs and which resources are available. This is where the group connects ideas to expertise, implementation effort and budget. A promising direction becomes more concrete when people can explain what would be required to deliver it.
In a product organisation, that discussion might cover the team’s knowledge, available components, systems that need to connect and the work required to validate the experience. These are suggested application questions. The original method gives the group a resource stage; the relevant questions depend on the product and decision.
The discussion can also expose opportunities to develop expertise internally. Where the work recurs, building that capability may give the business more control over delivery. The enterprise delivery article explains how I connect that kind of operating decision to senior-stakeholder alignment.
Carry the agreed direction into execution
The fourth stage moves the work into execution. In the original method, the design team leads this phase using an approach appropriate to the problem. The useful connection is between the business goal, the problems the group identified and the direction it chose to develop.
For applying the method today, I recommend leaving the session with a clear record of the chosen direction, the assumptions that need checking and the next responsibility. That record gives the team something it can revisit when discovery produces new evidence or the business context changes.
The method supports alignment through a shared sequence. Its value is in helping people understand one another and connect their contributions to a product decision. The facilitator still needs judgment about when the group has enough understanding to move forward.
Keep the original account available
This article is adapted from my 2019 UX Collective article on cross-team brainstorming. The original contains the first explanation of NO-PRESSURE and a different illustrative scenario. The field-service example and the suggested decision record here are additions for this version.
Together with my enterprise delivery practice, the method shows how I approach the space between executive intent and team execution: hear the expertise in the room, establish the shared purpose and give the group a practical way to work towards it.