To Build Trust, We Must Stop Rediscovering the Problem
Many times, as product teams, we send out mixed messages without even realizing it. We ask other areas to bring us problems instead of solutions. “Don’t tell us what to do; tell us what’s wrong” is a phrase any product manager has either said or at least thought.
But what happens when they actually bring us problems? All too often, we respond with: “We need to do a discovery.” And instead of focusing on how we can solve the problem, we begin a discovery of the problem itself. This is counterproductive.
The result? Frustration. On all sides.
Stakeholders become impatient. “But I already know what the problem is! Why do you need months to discover something that is already clear?” It’s a common question and, to be honest, a fair one. After all, we asked them to trust our way of working. We asked them to bring us problems, and when they do, we seem to question the validity of what they’ve brought.
This behavior is not only inefficient; it undermines the trust we want to build with other areas.
What Should We Do Differently?
When a stakeholder brings us a problem, we need to show confidence. If we ask them to bring us problems, we need to honor that request by accepting the starting point and focusing on discovering the solution.
This doesn’t mean ignoring the possibility that the problem could be poorly defined. It means starting with confidence in what was presented to us. If doubts about the problem definition arise during the solution discovery, we go back to the source: We talk to the stakeholders again. If they can’t clarify it, we talk directly to the customer.
What Does This Change in Practice?
- Initial confidence: When we receive a problem, we start from the assumption that it is well-defined and focus our energy on understanding how to solve it.
- Continuous feedback: If we realize that something is unclear during the solution discovery, we return to the person who brought us the problem. This creates a dynamic of partnership instead of resistance.
- Speed and focus: By not wasting time “rediscovering” the problem, we speed up the solution discovery and deliver value faster.
A Practical Example
Let’s say the Customer Support team brings us the following problem: “We are receiving many complaints from customers who can’t complete the registration process on the platform.”
What many product teams would do at this point is start a discovery to validate whether the registration process is really the problem. This could involve interviews, data analysis, and other activities that could take weeks, if not months.
Instead, we should assume that the problem is real and start exploring solutions: how can we simplify the onboarding process? What are the main pain points? What improvements can we test quickly?
If, during this process, we realize there are doubts about the nature of the problem, we stop, go back to the support team, and ask: “Can you explain this part more clearly? If not, let’s talk to some customers to understand it better.”
It’s Not About Skipping Steps; It’s About Focusing on the Results
Here are some additional examples of problems that stakeholders might bring:
- The Customer Support team reports an increase in complaints about delayed deliveries.
- Data shows that many users abandon a critical step during checkout.
- Operations identify bottlenecks that delay internal processes.
These examples help illustrate that when areas bring us clear problems, we need to trust the validity of the problem and focus on finding effective solutions.
Discovery is a fundamental part of product development. But we need to be more discerning about where and when to focus on problem discovery versus working directly on solution hypotheses. Doing discovery of the problem when it has already been clearly presented by stakeholders is a waste of time and undermines trust.
By showing that we know how to handle problems brought by other areas and focusing on solution discovery, we build genuine partnerships. We asked for problems, so it’s time to show that we know how to solve them.
Trust isn’t built just by asking for it; it’s built by delivering results.
Workshops, coaching, and advisory services
I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.
Digital Product Management Books
Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:
- Digital transformation and product culture: How to put technology at the center of your company’s strategy
- Leading Product Development: The art and science of managing product teams
- Product Management: How to increase the chances of success of your digital product
- Startup Guide: How startups and established companies can create profitable digital products
