Three people enter a room: one product manager, one developer and one QA. Each represents three main perspectives on the product — that of the business, the development team and testing.
Knowing where to start when building a new feature can be daunting. LendInvest’s Product Manager, Charles Fournier breaks down the ‘Three Amigos’ approach.
The Three Amigos session is essentially a kick-off meeting.
The aim of the Three Amigos is to create a common understanding of a feature, a piece of work, a deliverable, and to settle on a way to tackle it. The three perspectives give context to what we discuss, what we want to build, why and for whom. We ask each other, ‘What are the objectives and what does success look like? And how might we go about building this? What are the prerequisites and the different steps involved?
During the process, we’re not trying to debate how to build the feature in question. We are trying to find one approach to go with. Debating stifles activity and often leads to uncertainty about the approach.
It all starts with the product manager (uno amigo)
Of course, there are prerequisites to a Three Amigos session, and indeed to any feature being built.
Firstly, there needs to be a problem for the business to thoroughly understand, and appetite for solving it. That’s the role of the product manager. Working with the business, various solutions are brought to the table, discussed, and eventually a preferred solution emerges.
What’s next is the product manager’s approach getting things done.
The feature requirements must be defined in as much detail as feasible. This is done through speaking to each of the project’s stakeholders, getting everyone’s take on the feature and determining both how we think it might solve the problem and what success looks like.
As they progress, show them the designs, compare the current and soon-to-be updated user journey, workflow, and, most importantly, ask questions, take notes and poke holes.
“I relentlessly try to break the flow. Challenge everything. Ask why this and not that. Ask why again. And again. Then repeat asking why with someone else, another stakeholder in the project. Keep asking.”
Every why leads to additional information regardless of how many times you’ve asked the question. This creates a stronger understanding of the requirements, limitations, objectives, and obstacles that can then be shared with the other two ‘amigos’.
Provided that amigo uno has kept his peers informed of the work to come in meetings such as stand ups or roadmap reviews, then the group should be aware of new products and features on the horizon and how they fit into the company’s objectives.
Enter the developer and QA (los otros amigos)
Meetings work best if in-person, and time boxed. The product manager presents the feature or deliverable for ten minutes. The rest is a storm of questions and brainstorming. It’s key for the product manager to first keep the conversation centred on the objective: a common understanding of the feature.
Only then can we move on to how we might go about building it and shift the focus on the fastest route from A to B.
It is also the product manager’s role to probe in an attempt to unlock the conversation and push engineers and QA to think outside the box or find compromises.
“I probe to encourage brainstorming and alternatives, but ultimately I don’t need to understand every single step of the process.”
What outcomes to expect
The expected outcomes of a three amigos session are:
- A shared understanding of the feature or piece of work in question
- One or multiple ideas around how best to build it
- A rough list of the stories/tickets/tasks necessary to deliver it
- An estimation of the complexity of each story/ticket/task as well as their dependants
“At times, due to the sheer complexity of a project, you just can’t get it all in one go. I wouldn’t force it. I think it’s best to cut the session after 40 minutes tops, sleep on it and resume the following day.”
The amigos made a list, then what?
Having understood the work that needs to be done, the project manager starts writing up rough tickets. “I write the stories usually starting with just the story titles on a document,” explains Charles. “Then I flesh out each story in detail. During this phase I address any relevant questions raised by the developers during the Three Amigos meeting.”
After refining the stories, there may be a requirement for a further session with one or two developers. We then go through each story asking ourselves if it needs more work for a developer to start working on it.
With the stories in place, their complexity and dependencies understood, prioritisation can start.
Change is not an issue, change and adaptation is expected. The main idea behind the Three Amigos approach is to provide a common understanding of what we’re trying to build and identify different ways to get there.
“It’s fine if the strategies you come up with evolve. How you actually build it does not have to be set in stone.”