What key activities do you do to validate problem statements?

I recommend thinking about these questions:

1) Is this worth solving?

• What is the problem statement? Who are the users?
• Is this a real problem?
• What is the TAM? What can we influence? 
• What is the definition of success

2) Why us? Why now?

• Are you the right team/org/company to solve this problem?
• Should you work on it now? What happens if you do not?

3) How Might We break up the problem? What sub-problems should we go after(repeat steps 1-2) ? 

In general, the main thing I look for when validating any problem or solution is data. As a PM, it is important for you to figure out where to get the right data for what you are validating.

For example, if it's a problem statement around a user need or pain point, the first step would be to run user research panels to get data directly from users or potential users. I recommend you augment that with market research data such as independent analyst reports, research reports published by competitors of their user base, and related user data available to you such as broad user surveys.

Validating problem statements requires a user-centered approach that involves collecting data through user research, defining the problem statement, prioritizing the problem statement, developing a hypothesis, creating a prototype, testing the prototype, and iterating based on user feedback. Let's talk about each of them in a little more detail.

1. Conduct user research: The first step in validating problem statements is to conduct user research. This can involve talking to users, observing their behavior, and collecting feedback through surveys and other methods. The goal is to identify the pain points and challenges that users are experiencing and to validate that the problem statement accurately reflects their needs.

2. Define the problem statement: Once you have collected data through user research, you can define the problem statement. This should be a clear and concise statement that accurately reflects the user's pain points and the problem that needs to be solved.

3. Prioritize the problem statement: Once you have defined the problem statement, it's important to prioritize it. This can be done by evaluating the impact of the problem on the user and the business, and by assessing the feasibility of potential solutions.

4. Develop a hypothesis: Based on the problem statement and user research, develop a hypothesis about what the solution might look like. This can include assumptions about user behavior, design elements, and other factors.

5. Create a prototype: Create a prototype that addresses the problem statement and hypothesis. I prefer creating low-fidelity prototypes to avoid users getting distracted by branding and styling.

6. Test the prototype: Test the prototype with users to gather feedback and validate the problem statement. This can involve user testing, focus groups, and other methods.

7. Iterate: Based on user feedback, iterate on the prototype and refine the problem statement as needed. This can involve making changes to the design, modifying the hypothesis, or re-evaluating the prioritization of the problem statement.

When you are thinking about problem statements, you need to first rephrase the problem as a hypothesis, then try to gather as much as data as possible quantitative (usage patterns, experiment results, etc) and qualitative (user research), analyze competitors trying to solve a similar problem, creating prototypes and lightweight experiments. The most critical and fun for me is customer research. This information can be gathered through surveys, interviews, focus groups, 1-1 discussions or observational studies. The insights you gather can help to validate or invalidate problem statements very quickly. 

It really depends on what the problem statement is and the hypothesis is. If it's about learning from existing needs and behaviors I conduct interviews, surveys, and sometimes observational studies to see firsthand how users experience the problem. This helps confirm whether the problem statement reflects real user challenges.

Once your trying to understand if your solution hypothesis is valid, it's then time to figure out the cheapest thing you can build (maybe even just use humans) to validate if you're on the right track. I have a talk on that https://www.youtube.com/watch?v=dcbO24G4sh4