Leader Spotlight: Hiring for curiosity, not just credentials, with Irina Bukatik

Irina Bukatik is currently VP of Products at Branch and serves as a fractional Chief Product Officer and consultant for startups. Previously, she was VP of Products at GRIN, Senior Director of Product at data.ai (App Annie), and held senior product leadership roles at Reflektive, Kenshoo, and Microsoft. She specializes in scaling product organizations, driving data-driven growth, and shaping product strategy across B2B SaaS and martech.

In our conversation, Irina shared her insights on hiring exceptional product managers, focusing on curiosity, problem-solving, and empathetic communication as key traits for success. Drawing from her extensive leadership experience across multiple industries, she dives into what really makes a great PM and how to spot those qualities in interviews.

---

Spotting a great PM regardless of the domain

You’ve led product teams across a wide range of industries, including martech, HR tech, data & analytics, and early-stage SaaS. In your experience, what qualities make someone a strong PM regardless of the domain?

Curiosity is one; it drives everything. Don’t be afraid to ask “why,” not just in your job but in your day-to-day thinking, too. My team will tell you I ask that a lot. One of the first things I tell new hires is that when I ask “why,” it’s not a criticism. It doesn’t mean that anything's wrong; it's just a way I understand things. PMs need to be comfortable asking “why” and be curious about the space they're in. Even if you don’t have a background in a particular domain, you can still learn it. Most product decisions come from digging deeper into the initial ask.

The second quality is the drive to solve problems — staying focused on the problem instead of jumping to the solution. That’s a life skill, a personality trait. We're all users, so we all have user experiences along the lines of, “I’m trying to do something and it doesn’t work. I want a solution.” Understanding what the problem is — being in love with the problem — is what builds strong PMs. Addressing one problem can help you see the full spectrum of solutions through systematic thinking.

Finally, empathetic communication. If I had to explain product management to my grandma, I’d say a lot of it is about translating between different languages: customer, business, and technical. As PMs, we need to be fluent in all of them. Having that empathy for the sales, go-to-market, customer, finance, and engineering teams is absolutely critical. None of that communication is about writing code or user stories. It’s a personality trait.

As a VP of Product and consultant, you’re deeply involved in hiring and coaching PMs. When you're interviewing candidates, what signals to you that someone truly “gets” product?

I ask them to walk me through a product they love, or a product they built. Strong candidates always make me understand what the problem was that they were solving, and not just what features they built. In fact, sometimes we may not even talk about features or functionality, but focus instead on what the impact was, why they love the product, or what problems it solves.

The other two signals are more about how they operate day-to-day. Decision-making is critical. We all want to make decisions with perfect data, but that rarely happens. You often have to make decisions with limited information and without getting stuck in analysis paralysis, or bias towards the status quo (which is usually worse, because then you're not really trying to solve the problem in the first place). So I look for how they made trade-offs, how they validated decisions, what they learned, and how they course-corrected.

The last one is ownership and proactiveness. They go together. If your engineering manager is swamped or there are unexpected challenges, a PM should be able to jump in and cover gaps. So I love hearing examples from candidates of something they did that no one asked them to do. How did they identify the need? What did they do about it? On the other side of that coin, I also want to know how they manage that tendency to overextend themselves, because if you say yes to everything, you might not have time to do your core responsibilities. It's important to know when to step in, but also when to step out.

Signs a candidate truly understands product

What are your favorite questions for revealing traits like curiosity, problem-solving, decision-making, and empathy?

I love asking about feedback that surprised them. You expect the user to give you some course correction or feedback, but it's always interesting to hear examples where PMs were genuinely curious about a situation and understood why their initial hypothesis might have been wrong. When they encounter a problem, do they have the curiosity and empathy to understand that their way of encountering it might be very different from how other people are experiencing it? I actually think it's much easier to build for “non-you” problems.

It's important to ask about failure. What did they learn? How did they address it? But I always ask, "Tell me about another one," because people often plan for the failure question. And it's the second one that's really revealing. People prepare for interviews. They should. When I'm interviewing, I'm not trying to see how responsive they are on the fly. Maybe the second answer won’t be as polished, but it's interesting when the first and the second example of failure don’t necessarily track in terms of their behavior.

Do you have any examples of a time when somebody who didn't have a traditional PM background was hired and they turned out to be exceptional? What made you take that bet?

They don’t have to come from a traditional PM path. But if they haven’t dealt with certain scenarios, it’s harder to take that bet. Still, they can absolutely grow into great PMs.

I once hired somebody from a customer success background, an account manager. What made her stand out was how she handled customer requests and her empathy for customers. She always provided a lot of context for the request — what they're trying to do and how they're working around the problem. Her focus was on addressing the problem rather than merely passing along that they had requested a report or a button. She’s become a great PM. But I do think it's very difficult to take a bet like that on an external candidate.

Solving the right problem, not just building features

You've said that truly understanding what the customer needs, not just what they ask for, has shaped your most important product decisions. Can you share a moment when that distinction led to a dramatically better outcome?

When I was an IC PM with Kenshoo, we were building tools for brands and marketing agencies. During a sync with customer success, the need for a reporting API arose.

At that time, we had the ability to export from the dashboard. You’d schedule the export at 10 AM, and you’d get the report. We had integrations with leading BI systems, so the need for the API felt weird. I flew to Chicago to meet the agencies that used our tool in person. At the first agency, I just listened, but at the second one, I kept asking “why.”

What I learned is that the performance marketer ran reports on their paid marketing activity three times a day. But they had other paid media like magazines and TV that were getting inputs throughout the day, and our scheduled reports only had the ability to be sent once a day. So I asked, "What if you could schedule it multiple times a day?" That worked. We shipped it that week. They didn't need to invest engineering resources on their end to code to our API. It was a win-win for both of us. We got there just by asking questions.

You’ve worked across many industries. Have you ever felt disconnected from the user’s problem? What was the impact?

Yes, at Reflektive, an HR tech company. I wasn’t the main user or the persona the product was built for. And actually, I think that’s better. When it’s your own problem, it can cloud your judgment. You think you understand it, but really, you just know your version of it.

When you don’t experience the problem yourself, you have to lean more on empathy and curiosity. That can lead to a better understanding of what users are trying to do and why it matters to them. At Branch or Kenshoo, we built for marketers. We needed to understand their business goals, even if we weren’t marketers ourselves. You don’t need firsthand experience to connect with the problem.

Reactive versus proactive product management

In your experience, what's the difference between reactive product work and proactive, insight-driven product management that really moves the needle?

If you’re only reacting to customer escalations, it’s like playing defense. If you just build the thing that was asked for — whether it’s from leadership or the customer — you end up running a feature factory.

Strong teams go deeper. They analyze customer behavior, market dynamics, and changes in the industry. They build for both day-to-day problems and anticipate the future. You don’t want to spend most of your time putting out fires. Ideally, you invest more time in user research and face time with customers, whether it’s on Zoom or going out in person. We're starting to do this more at Branch, with our designers and PMs spending “a day in the life.” We did this a lot pre-COVID, where we would just peek over the shoulder of our users.

For example, back when Google ads were all the rage and paid social was just starting, I was sitting next to a marketer watching them work, and I noticed how many screens they were navigating. Working from multiple windows gave us the idea to combine high-level reporting, enabling them to take action from a single central place. You can learn a lot just by watching your users.

Helping founders decide on hiring a PM leader

You also consult with early-stage founders. How do you help them know if they’re ready to hire a product leader?

I love working with Series A companies. They’ve usually found product-market fit and have paying customers, but they don’t yet need a large product org.

At the beginning, the founder owns the product one hundred percent. A key inflection point comes when they find themselves starting to be more removed from every customer conversation. That’s a signal. I’ll ask them if they’re spending more time managing product requests instead of thinking about the next strategic steps for the product. If so, it might be time to bring in a product leader.

Another signal is if customers are branching out, and new segmentations and validations are needed.

Finally, a big one is if engineers are constantly asking for direction. Give them a PM. You don’t want them to be blocked. Especially with today’s tools, teams can build fast, and you want to process customer feedback just as quickly. But timing is everything; hire too early, and you add overhead. Too late, and you might have to undo poor product decisions.

Separating AI hype from the reality of product work

There’s a lot of debate about whether AI will replace PMs. What do people get wrong about AI doing a PM’s job?

It depends on how you define the role. If you think of it as writing documents or user stories, yeah, sure, AI can do that. But that's not the role of a PM. In fact, I think AI is going to be very helpful in removing a lot of the tactical work so that we can focus on the core responsibilities – understanding the problem, validation with customers, and user empathy.

Strong PMs and designers who have the curiosity and empathy will be able to build new products faster and with less engineering, even with the tools we see today.

Writing code or documents — AI can do pretty well. But solving for the right problems, prioritizing which to focus on — that's still very much human. And that's the core of what product managers should be doing.

What does LogRocket do?

LogRocket's Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.