Product Manager in the Middle - Yes, But NO

Saying yes to everything? A trap. Saying no to everything? Just as bad. Learn how to navigate feature requests like a pro with the LAD framework.

Inês Pinheiro-Kumar returns with another chapter in The Product Manager in the Middle—this time tackling a challenge every PM faces: how to handle feature requests without falling into the yes/no trap.

If you’ve ever struggled with balancing user needs and your team’s capacity, this one’s for you. Inês explores the art of making thoughtful decisions that keep both your stakeholders and your roadmap in check.

---

One of the first pieces of advice one usually gets when becoming a product manager is, “Don’t be a yes man.” This resonated with me throughout my growth as a Product Manager, but it took some fine-tuning—and a few mistakes—to fully grasp what that advice truly meant.

“Yes, we’ll fix this for you.”

During calls with users or stakeholders, I often hear about their priorities and feedback on the tools I manage—along with feature and improvement requests. While these insights are invaluable in helping me understand where my product stands and what needs attention, they don’t mean I should immediately don a hero cape and say, “Yes, we’ll fix this for you.”

I was guilty of this early on as a Product Manager. I felt like the only person listening, the one who genuinely wanted to help the “poor” users have a better experience. So, I would eagerly say, “Yes, we’ll fix this as soon as possible.” Yet, I said this so often, to so many users, that I lost track of both the requests and my team’s capacity to deliver. I would have needed years—and a platoon of engineers—to fix everything and build everything they needed.

I quickly realized this was unsustainable.

But how could I pivot without becoming the very thing I feared—someone who ignores users?

Don’t Say Yes, But Also Don’t Say No

Luckily for me, my course correction wasn’t as dramatic as some I’ve seen. Some Product Managers, after falling into the “yes to everything” trap, swing to the other extreme—saying no to everything. But this is just as damaging.

If you default to no whenever someone comes to you, you risk being seen as dismissive or simply disregarding people's input. This is the worst perception that one can be attached to in our field. The bridges we maintain to understand our product’s path—and build consensus for the next steps—can collapse faster than you can escalate an emergency.

Even when a request isn’t a priority, users don’t want to feel like their problems don’t matter. If they feel ignored, they’ll be reluctant to share feedback in the future, making user validation, pilots, and rollouts significantly harder.

So what should you do? If saying yes is bad and saying no is just as bad, what’s the alternative?

Just Be a LAD About It

This is the easiest way I found to structure my approach to these situations, and so far, it has yielded far better results than a black-and-white yes/no stance. It’s a three-step thought process:

1. Listen – Truly understand what the user is saying.

2. Assess – Validate the problem with a broader user group.

3. Decide – Determine if it should be prioritized or routed through another request process.

It sounds simple—and it is. Regardless, I’ll still share a bit on the details of each step, and how to apply them… with a bonus real life case.

Listen

Listening is more than just hearing the words someone is saying. When gathering insights, ask questions to pinpoint the affected process, the friction points, and the specific user impact. Take notes on key details to guide the next steps.

Assess

Once you have a starting point, explore the issue with other users (or user groups, depending on your user base size). The goal is to determine whether the issue is truly widespread or more of an edge case. It also helps to check previous research from design or UX teams to see if this has been flagged before.

Decide

If you’ve done the first two steps properly, you should now have a clearer picture of the issue’s impact and priority. If it’s severe, prioritize it for the current sprint or quarter. If not, document it in the backlog or direct the user to the established request process, attaching any relevant context to streamline discovery later.

Applying LAD in Real Life

Allow me to set the scene. Picture this, Berlin, 2023…

During a monthly user call, a user reported that they couldn’t export a full vendor listing—it kept breaking, forcing them to use a tedious workaround to provide partners with requested data. My initial instinct was to reassure them and commit to fixing it ASAP. But before responding, I paused.

Is this truly as bad as the user said? If this were truly a major issue, wouldn’t there be more reports?

So instead of jumping to conclusions, I asked questions:

How often does it happen?

Does it occur with all accounts?

While the user shared their experience, I listened.

After the call, I tried to reproduce the issue myself—and sure enough, the export failed every time. That week, I raised the issue in discussions with other user groups. Surprisingly, only one other case emerged. Most users hadn’t encountered it at all. Digging deeper, I realized both affected accounts had exponentially larger datasets than the average account. With this insight, I assessed.

It then seemed that this issue was related to the size of the accounts, but only very few had such big datasets to export. It became clear that while this was a pain point for a subset of users, it wasn’t a critical failure across the board. There was also an alternative (though more manual) way to achieve the same goal. Based on this, I decided not to prioritize an immediate fix. Instead, I explained the reasoning to the user—acknowledging their frustration, but also highlighting that upcoming improvements would deliver more impact than pausing work to address this edge case.

The result? The user understood our decision, remained engaged as our power user, and continued participating in feature pilots and feedback sessions.

The Diplomacy of Choice

To summarize, the issue isn’t about whether you say yes or no—it’s about how and when you make that decision. Instead, take your time to:

• Listen to the user, understand where they are coming from and validate their input.

• Assess if the issue is truly as impactful and affecting your user base as much as that one user.

• Decide if, with all the information gathered, the answer should be yes or no.

At the end of the day, product management isn’t an exact science, and you won’t always be right. But by being open, thoughtful, and clear in your approach, you’ll build stronger relationships with your users—and make better decisions for your product.

---

Missed the last episode of this series? Check out 👉