Understand the “Problem” Space at its Core

In product discovery, one of the most crucial stages is understanding the problem space. Skipping this step and jumping straight to solutions is a common pitfall that can lead to building features - that literally, no one needs.

Imagine this: Your team is pushing for a new feature simply because a competitor has it. It seems logical because there’s a chunk of customers who might want to switch to a different tool on the basis of the feature.

However, without validating the actual problem your users face, you risk pushing out features which might not fulfil the basic checks for your most “important group of customer segments”, leading to risks around the ideas that —

• Product won’t lead to any business outcome (viability)
• It will be technically unfeasible for implementation (feasibility)
• Your most important customers won’t desire their product as it does not solve the problem (desirability)

According to a CB Insights report, 42% of startups fail because there's no market need for their product, underscoring the importance of understanding and validating the problem space.

Without fulfilling the above criteria, this approach focuses on outcomes rather than the underlying issues that need addressing.

In this chapter, we'll delve into why comprehending the problem space in product discovery is essential, common mistakes, and best practices for ensuring you get it right.

Importance of understanding the problem space

Understanding the problem space is always Stage 1 of product discovery. As a product manager, you'll often face pressure from stakeholders to develop specific features based on competitors' actions. However, focusing entirely on these demands without understanding the users' core problems can lead to misaligned priorities and wasted resources.

To avoid this, build alignment with stakeholders early on—whether they are internal team members, customers, or other stakeholders. The goal is to establish a deep, immediate understanding of your users' needs.

💡 LET’S LOOK INTO A CASE STUDY OF DROPBOX.

Identifying the Core Problem:**Dropbox's journey began with a profound understanding of a common user problem: the difficulty of accessing and sharing files seamlessly across different devices. Drew Houston, Dropbox's founder, experienced this pain point firsthand when he forgot his USB flash drive while on a bus trip. This personal frustration highlighted a broader issue that many users faced, sparking the idea for Dropbox.

What worked for them - Validation Through MVP and User Feedback:Before diving into full-scale development, Houston created a simple MVP—a screencast video demonstrating how Dropbox would work. This video was posted on Hacker News and other tech forums, attracting significant attention and great feedback from the target group of audience.

The response was overwhelmingly positive, validating the core problem and the proposed solution. Users appreciated the simplicity and reliability that Dropbox promised, which was lacking in existing solutions like FTP servers or emailing files to oneself - or even Google drive that dominated the space for a long time.

What resonated better with their users — USPs compared to competition:

☑️ Auto-syncs & speed: Dropbox introduced automatic file syncing across devices. Speed was far better than what Google drive could provide.

☑️  Security: Shareable links support password protection and expiration dates; unlike Google Drive that allowed for basic permission management.

‍Dropbox's success story underscores the importance of deeply understanding the problem space before jumping into solutions.

By understanding the problem through user feedback, focusing on simplicity and reliability, and leveraging innovative growth strategies, Dropbox was able to create a product that truly resonated with users and stood out in a crowded market.

Let’s dive into how you can effectively uncover the problem space.

Exercise for understanding the problem space at its core

1. Define what product success looks like for you: Defining the success of a project boils down to the final part of your risk vs reward assessment. What does the best-case scenario look like?
   The basic framework to follow would be to define KPIs and outcomes with expected figures in each of the following cases —
   
   1. • Viability: Think about your company’s North Star metrics such as revenue, customer lifetime values (CLV), market share or other business KPIs. If the project is worthwhile, its goals should align with any or all of these.
      • Feasibility: Define what time-to-market you wish to target as a team, what would be the development costs (within vs beyond budgets).
      • Desirability: You’d definitely want to keep track of customer metrics such as feature adoption rate, CSATs, NPS, retention, churn, and so on.
2. Gather new evidence by running comprehensive customer interviews:
   ‍

Establish “job-to-be-done” frameworks around what problems are they facing when they try to achieve an outcome, what needs and desires do they have whilst trying to complete the “job”, etc. While doing that, you need to consider —

• Who to Interview: Engage with a diverse group of users including
  • champion users (those who use your product extensively),
  • prospects who are using competitors' products, and
  • churned users (those who stopped using your product).
• What to interview: Clearly define your research questions focusing on critical product areas that you need to address. Use a combination of direct (in-person or video calls) and indirect observations (surveys, analytics) to gather diverse insights.

3. Centralize existing evidence user feedback into a single repository:
   This approach is crucial for gaining comprehensive insights into user needs and pain points apart from just gathering insights from one-on-one interviews. Make sure you consolidate feedback from various channels as follows, but not limited to —
   
   • Intercom / Zendesk for support tickets,
   • Gong / Avoma for sales calls or demos,
   • Slack / MS Teams for adhoc communications,
   … and so on.By bringing all this data together, product teams can conduct detailed analyses, identify patterns, and uncover common issues or requests. The holistic view of user feedback ensures that no valuable input is overlooked, enabling more informed decision-making and prioritization of features.

Best practices for user-centric product discovery

✅ Best practice #1: Define “feedback” for your team and connect your top active feedback sources.

Make sure that you're gathering the right feedback to build the right products by connecting the most relevant and active sources where you regularly collect user feedback from.

By “right” feedback, we mean feedback that is actionable, relevant, and insightful. It should also be representative of a significant portion of your user base, enabling you to make informed decisions that drive product success.

This type of feedback helps you understand the true needs and pain points of our users, allowing you to prioritize features and improvements that will deliver the most value.

Also, if you are using Intercom for majority of your support tickets, it would make sense to connect this source only - and not other secondary sources like email, where you might not receive quality feedback.

The goal is to generate actionable insights that is of high quality and hence, target the most active and relevant sources of feedback - depending on your case.

✅ Best practice #2: Automate feedback capture as and when crucial customer conversations pop up.

Automation ensures a continuous flow of insights, making discovery an ongoing process rather than a one-time event. By setting up automatic feedback collection from top sources of user feedback, you can maintain a steady stream of data to inform your product decisions.

There are two routes you can take with Zeda.io —

1. For Slack, if you receive any message in a particular Slack channel for feedback, it auto sends all messages in that channel as user feedback.
2. For both Intercom & Slack, let AI automate the tedious task of deciding what should be a feedback vs what should not, based on the essence of the conversation around product improvement, bugs, feature requests, etc.

Stay on top of customer feedback and be proactive about what your customers want, saving time and resources that would otherwise go into handling support tickets.

✅ Best practice #3: Segment your customers, target action on feedback.

Tagging customers with the right segmentation data becomes crucial for gaining clarity. Tag and segment users based on their company, growth stage, revenue potential, etc. to neatly sort & filter feedback for specific user segments.

On a holistic level, gaining deeper insights into customer segmentation data apart from mere feedback sentiments, helps you take a more informed decision and as a result, proactively reduce churn.

✅ Best practice #4: Try not to miss a single customer voice that lands in your website or app.

Collecting feedback from the initial touchpoint is vital. Build natively or look for low code product discovery tools that help you build in-app feedback widgets and customer portals specifically for this purpose.

• Widgets can be embedded anywhere on your website or app, allowing customers to share ideas clearly - as and when they want to share.
• Customer portals enable users to view and upvote existing feedback, promoting transparency and reducing duplicate feedback instances.

The goal is to make sure you do not miss out on crucial insights that might come up when users encounter bugs or come across feature ideas.

Wrapping up Stage 1 of product discovery

By capturing and centralizing user inputs from all your channels (new and existing), you're not just gathering data— you're building a treasure trove of product insights that will guide you towards building valid hypotheses about the problem space.

Think of it as your very own goldmine, where every piece of feedback is a clue leading you to create the next big step.

Dive in, explore, and let voice of the customer light your path to better innovation. Head over to Stage 2: Validating your key actionable with insights

See next chapter →