Leader Spotlight: Aligning customer feedback and expectations, with Ryan Poppa

---

Ryan Poppa is Senior Director of Product Management at DNSFilter, a cybersecurity company that specializes in content filtering and threat blocking. He began his career as a systems administrator at Open Text Corporation before moving to Bank of Montreal as a security analyst. Ryan then worked as an engineer at FSC Internet and nCircle Network Security before moving into security-specific roles at Scotia Capital and Rapid7. Before joining DNSFilter, he worked in various leadership positions at Cisco, Google, and DeleteMe.

In our conversation, Ryan talks about one of the most challenging aspects of product management — that customers are very good at telling you what their problems are, but often struggle with explaining the solution they need. He also shares the importance of not being afraid to say no to customer feedback, and how people often appreciate hearing this definitive answer and the context behind it.

---

Closing product gaps

It’s sometimes hard to come into an established organization and identify or suggest improvements. When you first joined DNSFilter, what was your process for determining how the existing product strategy was aligned with actual customer needs?

The big danger, especially for someone like me who has been in the cybersecurity space for a while, is natural bias. It’s easy to come in thinking you know what you’re talking about and have the answers to questions because you’ve asked them before. It’s really important, at least from a product management perspective, to walk in with a clean slate and start asking questions from scratch.

You’ll often work with internal stakeholders, executives, sales teams, customer support, and customer success teams — all of whom have their own perspective into underlying challenges. When you talk to customers, you sometimes learn something different than what other teams have previously said. Maybe they have a unique perspective, so my advice is always to start listening. Hear what the strategy is and where the company’s trying to go. Try to understand what the underlying focus is and how the current roadmap aligns with the strategy.

Are there insights and things that would force or cause me to want to change the roadmap? The answer is always yes. But I think I have to be careful, especially as someone new into an organization, to not jump to conclusions.

You’ve mentioned working in the cybersecurity industry for some time. Since breach headlines or compliance deadlines often cause customers to be reactionary, as a product leader, how do you prevent that urgency from creating short-sighted product decisions?

This happens every single day — there’s always a breach or emergency going on. It’s important to remember that these situations are often very emotional. When you think about something like a breach, someone’s trying to solve a problem quickly because someone else is relying on them for it.

It’s challenging to balance because when customers are in this situation, they want an answer yesterday, as we like to say. My default answer is that you should find a way to support them. Understand their workflows to try to solve the problem, what you’re trying to go through, and then build motions to prevent the next customer from going through this situation.

I personally use this as an opportunity to learn where the product has a gap. It’s also a chance to help see where customers don’t understand how your product works, and you can often jump in to teach them. Being able to understand that and use it as a teaching opportunity to your customer is great. You can either build better workflows in the product, write better documentation, or train customer support teams to prepare for this. Oftentimes, you’ll find that your product does support this situation, but it may not be obvious to the customer.

Understanding the persona and their problems

When collecting and receiving customer feedback, how do you balance insights and priorities from hands-on practitioners (like security engineers) vs. that of executive buyers (like CISOs)?

Their priorities often don’t conflict, and the reason I say that is because they think about the same thing differently.

CISOs or executive buyers think about the holistic problem as, “I need to protect my users from going to malicious sites.” But they stop there. There might be underlying requirements or features they need, such as integrating the rest of the security system and receiving an email when something goes wrong. Those kinds of things are high level, so these stakeholders are just looking for a solution that works. They have considerations like price and high-level features.

When you talk to security engineers and practitioners, however, their jobs are a little bit different, but they’re trying to solve the same problem. The underlying goal is to enable security practitioners to convince the executive buyer that their decision was the right one. So, security engineers are trying to make their day-to-day better and workflows stronger. But in the end, they’re actually looking to see if the product works and how they can prove to their boss that it’s worth the time and money. And that’s hard.

How do you convince someone who doesn’t see the day-to-day operations that this tool is worth it? How can you prove that it actually translates into something valuable? This is why I’m a huge fan of listening to the security engineer or person on the ground. We understand a lot about what these users are trying to do and how they’re trying to share their story with the executive buyer. In the end, the security engineer is a canary in the coal mine for what an executive buyer truly wants.

How do you make sure that you’re ready and able to speak those two different languages?

It all comes down to understanding the persona you’re talking to. What is their driver, and how do you solve problems for them? You have other personas, too. From a security perspective, there are end users in the equation as well, but you don’t want them to even know that you exist. The product should work without them even realizing it’s there. But for a security engineer, they want to understand not only that it works, but where things are going wrong.

The executive buyer, on the other hand, just wants to know if their users were breached. Those are very different questions that they’re trying to answer. As you collate them together by talking in different ways and asking various questions to each of these personas, you’re able to translate that in a way that they need to hear it.

Iterating based on customer feedback

What’s your approach to turning customer feedback into clear, actionable product requirements? Can you break down what this looks like in practice?

I’m going to say something controversial: customers are very good at telling you what their problems are, but they’re not good at telling you what the solution is. From a product management perspective, you then end up focusing on the latter because the way that you get feedback isn’t directly from the customer. You may be going through a game of telephone via customer support or sales, and they’re trying to solve an underlying problem.

I try to understand directly what the customer is trying to do. They’re always going to focus their solution on their narrow perspective and experience, which is not a bad thing — it’s just what they know. But they don’t know every single customer and persona that you’re talking to. That’s why it’s important to understand what they’re trying to solve more than anything else. That way, you can apply it to a more general use case.

I like to ask the customer directly, “What are you trying to do? And what does that actually look like?” Once you get that, I’m a huge fan of iteration and testing, going back to the customer, and showing them what you built. Then, I say, “Can you give us feedback in terms of what it looks like? Does it solve the problem?” Sometimes they’ll say yes, sometimes they’ll say no, and sometimes they’re impartial. This is where testing, learning, and iterating are crucial.

Can you share an example where customer feedback helped you identify a blind spot in your roadmap? How did you turn that into a strategic win?

In a previous role at a vulnerability management company, one of the biggest challenges that our customers had was with our reports. We would run a scan of their environment, produce a ton of vulnerabilities that we found on their system, and hand their administrator a list of what we found. They would be prioritized in some way, but it was up to them to figure out how to fix these issues.

We learned that this was very challenging for our users because we were putting the onus on them to interpret the report, understand what it means for them, and take action. We came up with an idea to translate the list of vulnerabilities into remediation steps for users.

We also realized this was a big communication gap between us and our users. They looked at our solution as an expensive one because it would take them weeks to go through the list and determine what’s important. If big vulnerabilities were coming out, they had to react to them. How could they hire people to interpret all this data in a way that actually makes sense? A lot of organizations decided to pick the items they thought were most important first, which left that gap in taking action.

Overall, this was a great example of us trying to listen to what a customer’s trying to do, watch them go through the underlying pain, and realize that the product wasn’t intended to fix them. It helped us answer questions for them that they probably didn’t even expect us to do.

On the flip side, have you ever acted on customer feedback that led you in the wrong direction? What was the signal that told you it was time to course correct?

This happens a lot, and it comes back to that game of telephone I mentioned. Oftentimes, you’ll hear from a customer that you need to do X to improve the product. You say, “OK, I understand what that means.” You ask them questions, they provide feedback in terms of what that looks like, and they say, “I need X to do A, B, and C.” You go off and build it, but then they come back and say, “No, this isn’t exactly what I expected.”

Customers often expect that your solution covers their narrow problem when they previously described it as a very general issue. That happens a lot because, as I said, customers are very good at describing problems, but they’re not necessarily good at describing solutions. This isn’t their fault, but this is where being able to iterate, test, and learn as fast as possible is key. You need to understand if customers will see value in this and if you’re making the right choice for the product.

The other aspect of this is the importance of this to the customer. Depending on who they are, some customers are very loud, especially if they’re prominent for your company. But oftentimes, their needs will bubble up because they’re the ones who scream the loudest or provide the highest level of feedback. You have to navigate not only that personality but also whether or not what they’re asking is the right iteration to make to your product.

The importance of saying no

Do you have any internal rules of thumb or frameworks for saying no to customer feedback?

There are a lot of people who are afraid to say no. It’s a tough answer to give to a lot of people, but many folks really appreciate that. People like hearing a firm answer over “Oh, maybe later.” Saying “maybe later” gives hope and can often set incorrect expectations.

If it doesn’t align with what we do, then that’s a pretty easy “no” because that’s not who we are, that’s not where we’re trying to go, and that’s OK. But for things that don’t align with the current strategy, it might be a great idea that we can pursue at some point. This is where you say, “This isn’t something that you can expect within the next 6–12 months, but potentially after.” Then, you set the right expectation.

That gives your customer options. They can either figure out another option or mechanism for you to answer the question they want or pursue a workaround. You can also get a good understanding of how important the feature is. A lot of customers say, “Oh, no, that’s OK. I need it, but it’s not really that important for me.” But they may not have told you that upfront.

I love to be honest and tell customers why we are saying no. Again, it’s not always “no,” sometimes it’s “great idea, but not right now.” Helping them navigate that is very important. I find that customers respond to that very positively.

Have you found that the ability to push back is a skill that develops as you mature in your career?

Definitely. When I was younger and first starting as a product manager, it was hard to say no. I’d think, “Well, who am I to say no to this person? Can they get me fired? Can this person escalate this up because I said the wrong thing?” Again, people really do appreciate hearing “no” sometimes. I can count on one hand how many times someone got genuinely upset at me for saying no, and this is because a lot of emotion went into it. Sometimes, it was because they’d been promised something from someone else, and I had to turn around and tell them we couldn’t do it, which caught them off guard.

This is where setting the right expectations is so important. I also learned pretty quickly that when you say no, you must provide an answer why you are saying no. You have to explain what this actually means and why. Customers tend to understand that. And for a lot of younger PMs, it’s hard for them to do because they may not have the context. It’s certainly a skill that develops as you grow in your role and career.