1.1 Team mobilization

Make sure you have the right people in the right room, all pulling in the same direction. It's crucial to the success of your project.

Our definition of ready aligns us for success. It relies heavily on the outputs created during pre-mobilization:

Before starting

Mobilizing the team means getting the right people in the right room, with clear roles, clear responsibilities and clear communication from day one. The activity produces your team matrix, RACI, decision rights, schedule of team rituals and collaboration channels — everything the team needs to function as an active, cross-functional unit. Teams routinely show up to new projects without basic context about the customer, product or their own responsibilities; mobilization prevents that.

If anything’s missing from your definiton or ready, go back to pre-mobilization first.

Guide to team mobilization

Having the right people in the right room is crucial to the success of your project. You need a team that is able to handle all aspects of delivery. That means having end user and customer representation, so the customer experience and customer value is clear. It means having business analysts to work through how the enterprise operates. And of course, you need your technology roles to actually build the product. It’s crucial that each of these is part of an active, collaborating team. Having all of these capabilities on the team is essential to protecting the value we want to create and, therefore, the overall success of the project. This is the heart of a product mindset.

It’s equally important that we get everyone communicating well, sharing information, and set them up for intense collaboration. To do that, we need to know who’s doing what. We also need everyone to be clear on their own responsibilities, including when those responsibilities are communicated or conveyed to the larger group.

The product trio

Every product team is led by three roles working as one unit — the product trio:

Product manager. Owns value and viability: the vision → strategy → roadmap thread, prioritization and the evidence behind every build decision.
Product designer. Owns usability: user research, prototyping and usability testing — continuous discovery, run together with the product manager.
Tech lead. Owns feasibility: technical direction, engineering standards and the technical health of the product. Where the playbook says “architect,” the tech lead is the accountable owner; architects support as an enabling function.

The trio leads; it doesn’t replace the team. Around it sit engineers, quality, domain experts, business analysts and — always — the customer. If one of the three seats is empty, fill it before proceeding. An empty seat means a whole class of decisions has no owner. If product teams are new to you, there’s a companion article on building product teams that’s a valuable read.

Goals and impact

This activity has clear goals that align with specific, long-term impact to the project. These are, respectively:

Inputs

Executive sponsorship is a key success metric. It means having buy-in from someone with decision-making authority at your customer. Some people refer to this as a “champion,” who helps you align for success within the customer account.

Identifying other stakeholders is also very important. This ensures that everyone vested in the successful outcome of the project is involved from day one.

Executive sponsorship with the customer (buy-in from decision makers).
Team roster, along with proposed roles and responsibilities.
Key stakeholder roster, along with roles and responsibilities.

Process

Set up your customer’s delivery playbook wiki page. This will serve as the top-level of the customer project wiki, and should include essential information about the team and project. It should also include a good index of all resources. You can use this template to get started.
Identify your team and all of the project participants. Start with the product trio — product manager, product designer and tech lead — then round out the team: domain experts, engineers, quality and the customer.
1. Document the team in the customer’s delivery playbook wiki.
2. Be certain the right stakeholders are involved. Who are we delivering value to? Those are the people that need to have an active role in the project. This template provides an expanded stakeholder mapping worksheet.
3. Right-size the team. You may find a product mindset is suitable. It’s critical that all stakeholders are represented, and the team has the appropriate mix of cross-functional skills.
Set expectations clearly with the team. The roles of each participant, their responsibilities, are clearly communicated.
Establish clear schedules. Ensure appropriate time is committed to the project. Set up the team’s initial rituals — daily syncs, increment reviews, retrospectives — and block calendars.
Start the continuous discovery loop before there’s anything to discover about. Create the hypothesis log alongside the backlog, agree the weekly customer touchpoint with your stakeholders while you have their attention, and name the product manager and product designer as its owners. A team that leaves mobilization without a standing customer slot will be negotiating for one every week thereafter.
Enable collaboration. Set up the right tools and cadence to ensure the team functions collaboratively. This is covered in the section on ways of working.
Schedule your customer project kickoff meeting with your whole team and your customer stakeholders. This is an “all hands” meeting. The agenda is to review all of the information gathered above, and come to agreement on team members, roles, responsibilities, meeting cadence, communication methods, and your RACI matrix. Some refinement may be expected at a later date, as it’s a lot to cover.

As part of this activity, you’ll want to be very clear about who is doing what, and who’s responsible for what. This is where the team matrix and RACI matrix come in.

A team matrix is simply a roster, identifying who is filling each role on the team. One of the most important outcomes of building your team matrix is defining what your team will look like. Who is your product manager? Who designs the product experience? Who leads technical direction? Who will represent the end user and customer? What about quality and performance? All of these roles should be considered — and probably many more.

Hand-in-hand with the team matrix is your RACI matrix. The RACI communicates “who is doing what,” by clearly denoting who is responsible, accountable, consulted or informed during any activity (hence the “RACI” acronym). Make sure your team understands their responsibilities, and buys in when it comes to being involved. This Forbes article provides some good additional background on RACI.

Decision rights

The RACI covers activities; decision rights cover authority. One decision, one owner, consulted parties named — so nothing important waits on an ambiguous “we:”

Decision	Owner	Consulted
What outcome is valuable	Customer	Product manager, product designer
Build priority (what’s next)	Product manager	Customer, trio, team
Technical approach	Tech lead	Engineers, enabling architects
UX and discovery method	Product designer	Product manager, users
Increment readiness	The trio	Team
Commitment for the cycle	The team	Trio
Readiness exceptions	The trio, logged and visible	—

In a customer engagement, the client additionally holds scope and spend — they are the buyer. Everything else in the table stands unchanged.

It is absolutely critical that the right stakeholders are actively involved. For example, if the value consumer (the customer or beneficiary of the product) is not present, how can we ensure value is delivered? If the right people aren’t available, likelihood of a failure is prominent. Push hard to make sure the team is fit-for-purpose. Anything else dramatically reduces the likelihood of success.

Outputs

Team matrix. Project team structure and essential roles identified, led by the product trio.
RACI matrix. Participants in the project have clear expectations regarding their responsibilities and activities.
Decision rights. Authority is explicit: one decision, one owner.
Schedule of team rituals. The team’s interaction and goals established.
Established communication channels. Collaboration ensured through tools, cadence, and time commitment.
Hypothesis log and standing customer touchpoint. The continuous discovery loop’s home, created here from this template — empty at first, and filled as soon as the team starts forming opinions about what to build. Negotiate customer access once, now, and book the weekly slot; renegotiating it session by session is how discovery quietly stops happening.

Creating a product mindset and product oriented team is a key success indicator. Review these concepts with the client when determining team makeup. Accelerated teams need to be self-sufficient and empowered to deliver. If this isn’t possible within the client organization it will slow down acceleration and delivery efforts. For the full composition argument — and the evidence behind it — see Building a product oriented team and Product teams really do outperform.

Templates

Next activity

1.2 Current state analysis