The Problem Obsession

Why Product Teams Should Obsess About The Problem

Understanding your users isn't just a box to check; it's the foundation of success. Every member of your product team, not just the product manager, should strive to understand your customers deeply. The best way to achieve this? Engage directly with them. Conversations with your users reveal their real pain points, desires, and needs, providing invaluable insights for your product development.

However, many product teams fall into the trap of believing that understanding their customers is sufficient. While this is crucial, the best products emerge from teams that also have a profound understanding of the problem space (not the solution space) shared by their customer base. Recognizing that different customers often share common problems allows teams to address issues that have a broad impact.

Focus on "Sharp Problems"

Oji Udezue’s concept of "Sharp Problems" is a crucial idea for product teams. So…what is a sharp problem?

By focusing on sharp problems, teams ensure their solutions (products)are not just useful or cool but indispensable. Instead of starting with a solution in mind, you obsess over the problem to understand how it affects your customers, and then you solve it in a way that makes sense to them.

This is where we’ll focus for this post.

Step-by-Step Guide to Developing a Deep Understanding of the Problem Space

You Know Nothing Jon Snow

You actually know a LOT, and that’s a problem, specifically when you’re seeking to understand someone else’s problems and pains. While it’s hard, you need to start by pushing all of your assumptions into a little black box and start the process with the intent to learn as much as possible about how your customers (potential customers) experience the problem.

Build your mental model

Because I’ve worked in the agency space and have done advising and consulting, I put in a lot of “reps” for the process of learning a new product, problem space, audience segment, etc. It’s a process that tends to feel overwhelming for people across all roles/functions and (in my opinion) is amplified by the industry leaning hard into specialization and segmentation of teams across a product or product suite.

Note: I’m proud to be a generalist ;)

I have shaped and refined my own process over the years to help ground myself and ease my anxiety by getting from 0 to productive as quickly as possible. I know it works because I consistently receive feedback like this from my teams:

“I’ve never seen anyone ramp up on something so quickly. — especially something so technical.” and “I can tell you have put a lot of thought into this because you are already asking questions that I wish my team was asking.”

Most of the time, I take a sort of “method” acting approach and “adopt” the primary JTBD for our customers. When I was working on a newsletter platform, I started a newsletter. When I was launching a self-serve ads platform, I ran a lot of campaigns. This isn’t just testing the product when it’s ready; it’s about understanding what it actually takes for the customer to be successful—in and outside of your product.

1. Identify Key Questions

Begin by generating broad questions about your problem space. For instance, if you were trying to solve for collaboration across global timezones, you might ask questions like:

• What do you love about working with a global team?

• What challenges have you experienced with working with team members from around the world?

• How would you score your team on effective communication?

• What advice would you give someone who has never worked in a fully remote environment with a global team before?

• How important is communication when working within these team dynamics?

• Which of the following variables has the biggest impact on your team’s velocity?

  • Clear vision and direction from leadership

  • The ability to discuss and align in real time

  • Tech debt within our product/platform

  • Competing priorities

And so on…

When it comes to finding the sharpest problem to solve, you want to make sure that the customers you talk to genuinely feel it as a pain and not just an inconvenience or annoyance. Their perception of the problem, whether it’s real or not, is equally important when it comes to how they perceive the value of the solution.

Pay extra attention when they say things like

• I HATE having to do…..

• In a perfect world….

• The thing that frustrates me most is…

• Here’s where I really struggle…

Avoid over-indexing on things like:

• Sometimes I have a hard time with…

• I think … could be better/easier

• If I had to pick something, it would be…

2. Answer What You Can

If you are working on a new feature and have access to existing customers, start there. For most companies established companies, you want to focus on solving more problems for your existing customers first and expanding your customer base second. At this stage you can try to send out a survey with your questions to get a temperature check on the significance the problem has to your customers.

Oftentimes, you end up reworking your understanding of the problem or even which problem you are going to solve at this point in the process. For example, you might find out that communication within the team isn’t actually the problem but coordinating reviews and getting approval from leadership is where the most pain is felt.

Pro Tip: If you feel the pain of getting reviews and approvals knocked out, check out some of the rituals and processes Coda uses to ensure there is always time available for the people who need to make those decisions.

If you don’t have direct access to existing customers or prospective customers, use a tool like Perplexity.ai to gather generalized information about the problem space. I love this tool because it doesn’t really limit you to a single response; it gives you a summary of the information it found along with all of the links to the relevant resources so you can do some digging of your own.

I highly recommend saving your threads to collections so that it’s easier to find the research and use it again later. This product is so easy to use that you might just lose track of the first question you asked in any given thread.

3. Find the Hard Questions

As you gather general information, you will inevitably start finding questions that are more difficult to answer, such as, "How much is a solution for this problem worth to our customers?” or “What are they using to get around this problem right now?”

This is the point in the process where I take a little detour and start filling in the gaps around what I already know about our existing customers. This isn’t me assuming I know the answers; it’s me being mindful of the research we’ve already done and the insights we’ve already proven useful. This really comes down to respecting your team’s work and your customer’s time. I make it a (general) rule to never ask a customer for information we already have.

The most valuable answers to these questions come from the people who have already identified the sharp problem and who feel it most. Finding these people will get you the best insights into the problem and what a great solution actually looks like. Here’s how I tend to go about it:

1. Define Your Ideal Customers: Clearly define who your ideal customers are. For instance, if you're targeting mid-sized tech companies, specify their size, industry, and role in the company—maybe even identify operating models or organizational structures that amplify the pain of the problem.

Note: Even if you already have customers using your product, and you’re looking to solve a new problem for them, you should identify the segment and unique attributes that make this problem feel “sharp” to them and seek to understand why. I love how Nubank approaches new product releases/validation and the standards they hold themselves to before fully launching.

2. Use Audience Research Tools: I love to pull SparkToro data, and I do it for almost anything I work on. It helps me understand what the customers are interested in, what they talk about, who has their attention, and where they spend their time online. While not all of this seems directly actionable, it does give you insights that tell you where to look, how to reach them, and what types of things they care about — ultimately invaluable information.

3. Engage with Customers: You have to talk to customers. You HAVE to talk to customers. YOU. HAVE. TO. TALK. TO. CUSTOMERS.

I could stop there, but I won’t. At this point in the process, I try to connect with a few familiar and open customers to get some feedback on the problem and hear them talk about it from their own perspective. This helps me put messaging together that I can use to recruit new customers to better define the problem and shape the solution.

From those customers, you should ask questions that help you understand:

• How often is this problem felt? and How long does it last?

• What is the series of events that led up to the problem?

• What is the fallout of the problem?

• How many people experience the problem directly and indirectly?

• How many different ways does the problem manifest?

• What are the conditions in which the problem is most likely to appear?

• How are some customers avoiding or solving this problem? What gaps are there in the current solution?

4. Distill Key Insights

Once you've gathered all this information, it's crucial to synthesize your findings into actionable insights. This means understanding the problem and framing it in a way that your entire team can rally around.

Create Problem and Impact Statements: My problem with “problem statements” is that they tend to overemphasize the problem itself and under-communicate the value of solving it for the customer.

Unhelpful problem statement: "Our users struggle to coordinate project reviews across different time zones, leading to delays and miscommunications."

More helpful problem statement: “Our customers are feeling immense pressure and are concerned about their job security because they have an ongoing struggle with missed deadlines, miscommunication, and rework. We believe all of these issues are connected to their struggle to communicate and align with team members in drastically different time zones. In fact, we found that teams that have members in the US and Australia are shipping at half the pace of distributed teams that are within 4-6 hour time zone gaps.

Forcing yourself to be very specific about how you communicate these findings forces a natural scan of your bullsh*t radar on yourself. If you can’t communicate it in a clear and compelling way, you either don’t have a sharp problem or you don’t understand it well enough.

I could go on and on about what to do with this information once you have it, but there’s no shortage of guides, posts, frameworks, etc., covering that topic.

If you found this useful, have any questions, or want to share some feedback, feel free to reach out directly via email me (at) mikebal.com or via Linkedin.