How to Get Product Teams to Agree on the Problems to Solve

A 5-step approach to collectively define the problems to solve and focus on your end users

One of the most critical parts of any product development project is to agree as a team on the problems to solve, yet getting everyone on the same page can seem like an impossible task. That’s because product development is a people business. And like people, the teams that develop products are often very diverse, and have different and sometimes competing perspectives on which problems need to be solved. Some team members will have a technical perspective, others will have a business perspective, while others will have the most recent customer escalation in mind. All these perspectives are valid. A product does not only need to be desirable, it also needs to be viable and feasible.

So, what is the glue that brings and keeps us together? It’s simple: our end users. End users’ needs and goals are why we exist as a team in the first place. We come together to build products that solve their problems and add value to their life. The needs and desired outcomes of our end users should in fact define our goals as a team and give us a clear direction.

Below I’d like to share a simple and practical way to collectively define the problems to solve, and to unite the entire team around these. By enabling the team to experience these shared, collaborative moments, you’ll be able to create the perfect conditions for your most innovative work.

1. Start with what you have

In many cases, there is already a vast amount of knowledge available within the organization that lives in folders, spreadsheets, slide decks, cloud storage, and research repositories. Make use of it! Dig everything out and see what you can find out about your users, the domain, the market, and your competitors.

Collecting existing documents is a great starting point. It will also point to existing knowledge gaps.

2. Put your heads together to fill in the gaps

Once you’ve looked through all available information, it’s time to tap into the team’s brainpower. It’s not uncommon that much of the knowledge will actually reside within people’s heads and not in documents — it’s the accumulated knowledge they have collected over the years.

Bring everyone into the same (virtual) room. Run a workshop where the whole team comes together: PMs, designers, developers, researchers. Make sure to also invite subject matter experts who are not part of the team but might have touchpoints with the domain you are targeting. You can also invite external experts if you have access to them.

Finally, assign a dedicated facilitator to guide the group and make sure the team collaboratively progresses and increases their understanding about the domain, the business, the end users, and their context during the session.

To structure your approach, focus on the following questions:

• Who are the users?
• What do we know about what they are trying to accomplish and their motivations?
• What do we know about their needs and challenges?
• What might be the context around these challenges? When do they occur? What causes them?
• Why should we as a team care about this?

The last question is a key one. It helps connect our understanding of the user to the business objectives that we want to address. As I mentioned, a product has to be desirable, but also viable and feasible. Business objectives should always be part of the equation.

Collect all the knowledge the group has around these and similar points. You won’t have answers to all the questions, and that’s okay. Write down your assumptions. You can validate or adjust them later on when you talk to end users.

At the end of this step, you will have experienced moments of productive collaboration and the group will start feeling more involved. When you are finished with this exercise, the collective knowledge of the team should be well documented and owned by all members. You will know what you know, and perhaps more importantly, what you don’t know.

3. Get comfortable in the problem space

Now is the time to come together as a group and start to create alignment. Revisit the information you have collected for each question and begin to prioritize it.

Run a voting session to see where the group stands. Discuss the most voted answers, reflect on them, and come to a consensus. It’s not about finding the one and only correct answer, it is about agreeing as a team.

Use the answers to the questions from the previous step to create a problem statement. Rephrase it as often as needed until the team agrees on it. Again, it does not have to be perfect — you are going to validate it with end users anyway. But it must be specific enough to help you bring more focus to your upcoming explorations. Here are some tips about how to write a problem statement.

At the end of this step, you will start to have alignment. You’ll begin to form an initial picture of your end users and their context. It’s a picture you painted together as a team.

4. Listen to your end users

Once you’ve created a problem statement, it’s time to proverbially gather around the fire to listen to the stories of your end users.

Once upon a time, when my grandparents were children, there was no TV and no — can you imagine? — internet. In the evening, families gathered around the fire and the older family members shared insights into their worlds. Listening to their stories created shared experiences, collectively memorable moments, and a sense of belonging. Listening to your end users’ stories together, as a team, can be as powerful as listening to our grandmother’s wisdom and can spark our imagination.

Before starting with the interviews, define the main themes you want to cover. The problem statement you created in the previous step will help you to define the scope of your interviews. At the same time, be open to surprising themes that will emerge during your conversations.

When selecting which users you want to talk to, make sure that you cover a wide variety of perspectives. Include end users, but also business users and expert users. And of course, make sure that you are following inclusive research practices and are intentionally involving people with a range of abilities, cultures, and backgrounds.

During the interviews, make sure you have a structured way to take notes. If you’re unsure of which user research method to use, or how to effectively conduct an interview, have a look at our User Research Method Cards for guidance.

5. Reflect on what your learned and come up with a powerful problem statement

After you’ve conducted your end user conversations, you will need to consolidate your notes and make them memorable and referenceable.

Ideally, the whole team should take ownership of this content. How? Come together as a group and share your notes and observations. Organize the data and sort it into categories, cluster it, and identify themes. A method you can use to cluster your data is affinity mapping.

Revisit the data you have put together in the assumption phase. Go back to the questions you answered there. Compare and add your newly acquired knowledge:

• What evidence were you able to find around your assumptions? Were there assumptions that you were able to validate? Were some invalidated by your conversations with end users?
• What were some surprising moments? What were new things you learned as a team?

And now, go back to your assumption-based problem statement. You most probably will feel as a team that you want to refine it or even rewrite it based on your new acquired knowledge. Perfect! That’s what the whole exercise was about: To define and agree as a team on the problems you want to solve.

Some last thoughts on this approach

This approach should help you and your team to generate agreement, memorable moments, and shared experiences. Think of it as the beginning of your journey as a team. You are not just a group of diverse people anymore, but a team that is aligned around a real problem. And you will work together to solve it and bring a product to market.

As a side product, you will have enough data to continue with a structured research approach, define user outcomes, and work on any kind of mapping exercises, assumption testing, and ideation sessions. In fact, this approach will make your life as a UX professional easier because you won’t need to constantly go back to the question of “what problem are we trying to solve” anymore.

Although this exercise does not replace a structured research approach, it recognizes that sometimes we just need to work with what we have and quickly align as a team.

There are many frameworks out there that one can use, though I personally don’t recommend any one in particular because I believe that what’s important in this approach is the mindset. Try to create the mindset first, and the framework will follow.

Special thanks to Malli Konduri for your contribution to this article.