As a product manager, you probably feel comfortable talking about discovery. You say you’re exploring problems, validating assumptions, and making sure you build the right thing. However, in practice, many discovery conversations are still centered on a proposed feature, not the actual problem behind it.
This tends to happen because stakeholders often approach PMs with solutions already formed. In these cases, it feels natural to move straight into delivery mode. You ask smart questions, clarify requirements, and leave the meeting feeling productive. But sometimes all you’re really done is make a bad idea more detailed.
This is one of the easiest traps to fall into, especially early in your PM career. The good news is that it’s also a pattern you can learn to spot and interrupt.
In this article, I’ll walk you through a simple framework I use that can help you shift the conversation from features to problems to outcomes so you handle discovery with more intention.
Somewhere, a feature you worked hard on is sitting unused. You just don’t know it yet.
Imagine you’re a PM and Sarah, your support team lead, walks into the meeting with the energy of someone who’s already made up their mind.
“I have a great idea. We should add a chatbot that helps users write better support tickets. It would guide them through a series of questions until we have all the information we need. That way my team spends less time going back and forth for ticket details.”
You open your notebook and take notes. Or maybe your AI assistant does it.
“That makes sense. Just a few questions. Should the chatbot be visible on every screen or only on the support page? How many questions should it ask before submitting? What fields do we need to capture? And how do we know when the ticket is complete enough to submit?”
Sarah answers each one confidently. The discussion goes on for about 30 to 45 minutes to clarify all necessary details. There’s a sense of relief that this time all the details have been defined before the refinement with the team.
Nobody asks why users were submitting incomplete tickets in the first place, how they were doing it today, or what the support team actually needed to change.
Three months later, the chatbot goes live. Sarah is the first to try it. She comes back the following week.
“This is really cumbersome. Users have to answer eight questions before they can even submit. Half of them just give up and go back to writing on Teams. My team is still chasing the same information, just now we have a chatbot nobody uses.
Turns out that the feature shipped on time, but the problem was never solved.
Have you ever experienced something similar?
I know this has happened to me a few times. And it’s not shameful to admit it, since junior PMs are often handed the requirements as part of the process. Stakeholders come with solutions, and you feel like translating them into user stories for the developers to build.
Now, I invite you to take a closer look at your job as a PM and the questions you ask using something I call the three lenses framework.
It’s about three modes PMs operate in: solution-focused, problem-focused, and outcome-focused.
The solution-focused lens is all about taking the request and delivering it efficiently. You ask about scope, edge cases, and acceptance criteria.
The problem-focused lens is all about getting curious about the AS IS — how things work today, who’s affected, and what they’ve already tried. The solution can wait.
And the outcome-focused lens is the one where you’re looking for the optimal path for business value. You zoom out to what success actually looks like for users and for the business six months from now.
As you progress through your career, you’ll start to be more aware of these lenses and apply them strategically and intuitively.
If you’re just getting started, my goal is to give you some hints and starting points that you can practice to help build this muscle.
The first and easiest step is to play back what you heard before jumping to questions. It’s a way for you and your conversation partner to ground yourselves in the discussion and make sure you’re on the same page. Let’s see how this would play out for Sarah and our PM.
After Sarah talks through her chatbot idea, the PM replies:
“So if I understood correctly, you’re saying that your support team often receives tickets without enough information to act on them, and the idea is that a chatbot would guide users through a series of questions to fill in the gaps. Is that right?”
The moment this is out in the open, questions start to rise naturally.
This is the perfect moment to be genuinely curious and start asking some clarifying questions about the AS IS state. Don’t think of it as a you against them moment, but think about what would you ask your colleague if you were talking through this over coffee?
Let’s go back to Sarah and see how this could unfold.
“So if I understood correctly, you’re saying that your support team often receives tickets without enough information to act on them, and the idea is that a chatbot would guide users through a series of questions to fill in the gaps. Is that right?”
Sarah nods. “Exactly.”
Now you start getting curious about the AS IS situation.
“And how are users submitting tickets today?”
“Oh, all over the place,” Sarah says. “Some use the app, some email us directly, some just message us on Teams.”
“And when the information is incomplete, is that happening across all channels, or mostly in one?”
Sarah thinks for a moment. “Mostly Teams and email, actually. The app form is better because it has required fields.”
“So the users who already use the app form — they’re giving you what you need?”
“More or less, yes.”
The PM writes something down: if the app form works, why aren’t more users using it?
“One more thing. When a ticket comes in incomplete, what does your team do?”
“We write back asking for more details. Sometimes it goes back and forth three or four times before we can even start working on it.”
“And how long does that take?”
“Days, sometimes. It’s really frustrating for everyone.”
“So what you’re saying is that the problem is channel fragmentation and the fact that users don’t know what information to provide. That’s really valuable. Let’s see how we can actually help the support team.”
And now for the final move, switching to the outcome lens. You want to lead with “one last thing,” a question to let the stakeholder describe success in their own words.
“Okay, let’s imagine it’s six months from now and the chatbot is live. What does that mean for your support team?”
Sarah pauses. She wasn’t expecting that.
“Well… my team will finally have all the information they need when a ticket comes in. No more back and forth. They could just start working on the problem straight away.”
“And how does that change their day?”
“They’d be less stressed. Less time wasted chasing people. More time actually solving things.” Sarah is warming up to the idea now. “Actually, we could probably handle more tickets with the same team size.”
The PM nods, then pauses.
“And now let me ask the uncomfortable question: what could go wrong?”
Sarah frowns slightly. “What do you mean?”
“Well… what if users find it frustrating to answer eight or nine questions before they can even submit? What if they just give up and go back to Teams or email?”
Silence.
“Then… we’d be back to square one,” Sarah says slowly. “And we’d have spent three months building something nobody uses.”
“Exactly. So before we commit to the chatbot, what’s the smallest thing we could test to find out if users would actually engage with it?”
You have actually framed it as an act of care, not skepticism. You’re protecting their success, not killing their idea.
Can you feel it? The quiet satisfaction of having shifted the conversation without the stakeholder noticing. That’s where you want to get to.
I want you to look at these lenses as a ladder: they build upon each other, and all play a role in shaping your solutions. However, you can enter the conversation at any level, and work your way throughout them depending on how the conversation unfolds.
You have the power to shift the conversation just by shifting the lens you’re using in your stakeholder interactions.
Where to start tomorrow? My advice isn’t to try to master all three lenses at once, as it’s a muscle that requires training.
Start small and in your next stakeholder interaction get curious about the AS IS. Ask one or two questions about how things work today before moving into requirements.
If it feels uncomfortable, stop there and go back to documenting. That’s fine. You’ve already done more than most.
Finally, try to reframe asking questions not as being pushy but caring enough about the outcome to make sure you’re building the right thing. Good luck! Comment below if you have any questions.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
CPO and PhD Jen Wang covers “The Zone of Absorption” and why product teams are struggling to build when AI is shifting faster than anyone can keep up.
Explore four product team structures, when each works best, and how to choose the right model for speed, ownership, and clarity.
Learn how code-style reasoning helps product managers make sharper decisions, surface edge cases, and write clearer requirements.
A practical framework for product leaders to prioritize better, reduce noise, and focus teams on what matters most.
Learn more →
