Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. One of the primary benefits of working in a product trio is we reduce the hand-offs between functional roles.
In the old way of working, a business stakeholder communicated a need to a product manager, the product manager wrote requirements, handed them off to a designer, who then created designs, and then the requirements and the designs were handed off to engineers to implement.
With each hand-off, we lost context and nuance. It was like a game of telephone. With each person, the message got a little more distorted.
This means that by the time it gets to the engineers, the message is unrecognizable. It’s no wonder we end up with software that doesn’t work for our customers.
When a product manager, a designer, and a software engineer work together to decide what to build and they engage directly with customers themselves, we avoid this game of telephone.
Good discovery establishes a direct communication line between the team who is building the product and the customer.
Good discovery establishes a direct communication line between the team who is building the product and the customer. – Tweet This
There’s only one problem. Products aren’t built by trios. We typically have additional engineers, sometimes a second designer, maybe a product owner, a scrum master, and any number of additional roles depending on the organizational context.
How do we avoid hands-offs between the product trio who is leading discovery and the rest of the team?
Before we answer that question, let’s tackle a common myth.
Discovery and Delivery Are Done by the Same Team
Too many people interpret dual-track Agile as having two teams—a discovery team and a delivery team. This is not the intent.
This team design results in a discovery team handing off requirements to a delivery team and suffers from the same consequences I described above.
It’s critical that the team that is building the product is the same team that is engaging with customers directly.
It’s critical that the team that is building the product is the same team that is engaging with customers directly. – Tweet This
However, not everyone on the team can take part in every interview or every assumption test. This is why we talk about the product trio leading discovery. The trio is the smallest decision-making unit. That doesn’t mean other team members aren’t included in discovery.
We want all of our team members to have some exposure to customers. Everybody should sit in on an interview from time to time. Everybody should contribute ideas. Everybody should help surface assumptions and contribute to assumption test design.
The key distinction here is that everyone on the team should participate in some discovery efforts. The trio should lead all discovery efforts. (Those modifiers “some” and “all” are making me nostalgic for my semantics classes in college. Such little words that pack so much power.)
Everyone on the product team should participate in some discovery efforts. The product trio should lead all discovery efforts. – Tweet This
And everyone on the team should be following along week over week as the team learns what might work and what might not.
The product trio needs to make it easy for the rest of the team to stay engaged.
Two Key Principles Will Help Your Team Stay Engaged with Discovery
More often than not, we forget to show our work as we work. We take the easy road.
When we interview a customer, we post a video of the recording and hope the rest of the team watches it. They usually intend to. But there’s always the next user story to tackle.
When we get results back from an assumption test, we tend to iterate on our ideas based on what we learn. But we forget to update the team on why we made these changes.
I get why this happens. Most product trios have full calendars. We don’t have time to slow down and show our work. We are too busy doing the work.
The challenge, however, is that this means that the rest of the team is hearing for the first time during a sprint planning meeting what we are building and why. This meeting becomes a hand-off. To avoid this fate, we need to internalize our first principle:
Key Principle #1: Make your work visible in an easily digestible way while doing the work.
This is different from what most of us tend to do. Most of us separate the doing from the showing.
We think through a problem and then we put together a slide deck to walk our team through our thinking. We interview some customers and then we create a research deck summarizing our findings. We run a series of assumption tests and then we write user stories to share our conclusions.
The problem with this approach is that when we get busy, we skip the second step. We end up not showing our work. And we are always busy.
So instead, we are going to look at how we can show our work while doing the work.
It’s not enough, however, to just show our work, which brings us to our second key principle.
Key Principle #2: Remind people continuously that they can follow along.
Even when we show our work, people will forget to follow along. They have their own jobs to do.
We need to remind them continuously where and how they can follow along. And we need to make it as easy as possible for them to do so.
Even when we show our work, people will forget to follow along. We need to remind them continuously where and how they can follow along. And we need to make it as easy as possible for them to do so. – Tweet This
Let’s dive into how you can put these two key principles into practice.
Show Your Work As You Do It
The key to the first principle is to combine the doing with the showing so that they are no longer two distinct activities.
One of the first things new product trios need to learn is how to truly collaborate as a cross-functional team. This sounds obvious, but it’s not trivial.
Most of us don’t have a lot of experience working on leaderless teams. We still want to fall back to escalating decisions when we can’t agree. We still worry about who ultimately owns what.
One of the best ways to learn to truly collaborate is to visualize your thinking. Doing so helps everyone on the team see what’s in other people’s heads and helps them align around a shared understanding.
This is why in my book Continuous Discovery Habits, I encourage teams to visualize their thinking with each habit. The best teams:
- Create experience maps to visualize what they individually and collectively know about their customer.
- Generate interview snapshots for each and every customer interview.
- Map out the best path to their desired outcome using opportunity solution trees.
- Align around specific solutions by story mapping the possibilities.
- And use assumption maps to get clarity on their priorities.
These visual exercises facilitate the work of discovery. They help us think through our options, strategize about our best path forward, and ensure that the trio is on the same page as they work.
And they have another benefit. These exercises result in visual artifacts that are easy for other people on your team to understand.
While all of your engineers can’t attend every interview, they can review an interview snapshot for each interview you conduct.
While the broader team might not be involved in the design of every assumption test, they can follow along as the story maps for your top ideas shift and evolve based on what you are learning.
There are many advantages to visualizing your thinking while working, but one of the biggest ones is that it allows you to quickly and easily share your thinking with the rest of the team.
To ensure that you show your work while you are doing it, make sure these visual artifacts live somewhere where everyone on the team can follow along.
What tools you use will differ from team to team. Each team needs to find the right tools that work for them. But if you create and store these visuals in tools that everyone on the team can use, you’ll make it easier for the rest of the team to follow along.
For inspiration about what tools might work for your team, check out our Tools of the Trade series where teams share their discovery tech stack with us.
Remind Your Team Where They Can Follow Along
It’s not enough to make these visuals available to people. Everyone is busy and nobody is going to seek them out on their own. You need to constantly remind people.
Start by identifying an asynchronous location to provide continuous updates. This might be a Slack or MS Teams channel. It might be a blog or a Confluence page or a daily email.
The specific tool doesn’t matter. The key is: Don’t reinvent the wheel. Use whatever tool already has everyone’s attention. Don’t introduce a new tool for this. Make sure it’s a tool that everyone uses. If your engineers use Jira and Confluence, but your designers don’t, that’s not the right tool.
Once you’ve identified the right tool, the product trio should provide continuous updates. Here are a few things you might share:
- Progress toward your outcome
- Interview snapshots
- Revisions to your opportunity solution tree and experience maps with a summary of key changes
- What target opportunity you chose and why
- Story maps, assumption maps, and the assumption tests you are currently running
- And most importantly, how you are using all of these inputs to make discovery decisions
Make sure this channel is not just a broadcast channel. Make it easy for people to give feedback. When someone does share thoughts, engage and act on their feedback.
Remember, the trio leads discovery, but everyone on the team should contribute to the discovery efforts.
The product trio leads discovery, but everyone on the team should contribute to the discovery efforts. – Tweet This
But don’t rely on asynchronous communication alone. Use your existing rituals to remind people that they can and should be following along and actively engaging.
During your daily standups, share the most important discovery findings from the previous day and highlight what’s next. Don’t overdo it, though. These meetings are intended to be quick share outs. Don’t derail the intent of this meeting.
A daily standup share might be as simple as one of the following:
- “We had a great interview yesterday and learned a lot about our target opportunity. You can find the interview snapshot in Slack.”
- “We got test results back that called a critical assumption into question. We are rethinking the solution as a result. We sent everyone a link to the Miro board where we’ll be working.”
During your sprint planning meetings, don’t just share user stories. Make sure that each user story links to the supporting discovery work. If the team has been following along, these meetings should go much quicker. Your goal is that this should not be the first time your team is hearing what you are building and why.
During sprint retrospectives, be sure to include your discovery work in the review. I encourage teams to ask these two questions in every retrospective:
- What did we learn in the past sprint that surprised us?
- How could we have learned that sooner?
For the first question, consider everything. You might generate answers such as:
- A user story took longer than expected to implement.
- You were able to measure the impact of a previous release and it fell short of expectations.
- You learned that your target opportunity wasn’t worth solving.
- A stakeholder swooped in and changed the deadline or a key requirement.
When you answer the second question, you’ll find ways you can iterate and improve on your discovery process.
- Did you miss a key feasibility assumption? What was it? Is there a pattern that might indicate a blind spot?
- Did you not test with enough people? The right people? Did you miss a key desirability or usability assumption?
- Did you wait too long to start testing solutions? Did you over rely on interview data? Did you let key stakeholders influence your target opportunity selection?
- Is there a gap in how you are showing your work to key stakeholders? Are there stakeholder assumptions that you should be testing?
When we infuse our daily rituals with our discovery activities and we show our work as we do our work, it makes it easy for the rest of the team to follow along and engage as they have time.
When we infuse our daily rituals with our discovery activities and we show our work as we do our work, it makes it easy for the rest of the team to follow along and engage as they have time. – Tweet This
There’s no need to fall back to the old hand-offs of a waterfall world. Continuous discovery makes it easy for everyone to stay engaged. What can you do today to show your work while doing your work?
