🎙️ New podcast: We're launching a Q&A-style talks with product management experts
Learn more
The role of a product manager is as challenging as it is rewarding, with success depending on the ability to align teams, manage resources, and meet customer expectations.
In this interview, we explore key lessons from Gabriel Hopkins, the Chief Product Officer at Ripjar, offering insights into the daily challenges of the job. You’ll learn how to align product management teams, make strategic decisions about building versus buying, and stay focused on the metrics that matter. This interview is a must-read for anyone looking to sharpen their product management skills and drive their team toward success.
Aligning teams as a product manager is a complex and ongoing task. The more I think about it, the more different kind of permutations I put on it. It’s essential to understand that the work of a product manager should never be viewed in isolation. Product managers play a crucial role in creating cohesion within organizations. It’s equally important that product managers understand how they align with each other and with the broader organization, ensuring that everyone shares a clear view of your products and their direction is key to maintaining alignment.
However, achieving and maintaining this alignment is a lifelong endeavor for most organizations. It's not something you do once and forget about; it requires continuous evolution and responsiveness to new situations. While I don’t claim to do this perfectly, it’s vital to regularly assess how well you’re communicating the overarching message and ensuring alignment across teams.
From a practical standpoint, the organization I work at has two main products, each managed by a separate product manager. We also have a third product manager responsible for the platform that supports both products. This setup works well for us.
When it comes to aligning teams effectively, having a clear span of control is critical. In my view, it’s also important that product managers have end-to-end responsibility.Â
This concept might be controversial, but I often see organizations where product management is split between "product managers" and "technical product managers." In such setups, the product managers focus on customer interaction and ideation, while the technical product managers handle development tasks and liaise with the engineers. I believe this division is problematic and often leads to failure. It results in two people being responsible for the same outcomes but with vastly different perspectives.
Instead, I advocate for product managers who can span the entire process—from understanding the market and customer needs to writing stories and working closely with engineers. This doesn’t mean they need to be technical experts, but they should be capable of engaging with both the market and the development team. While this requires a unique and sometimes hard-to-find skill set, it’s worth the investment.
In my view, it’s essential for product managers to have end-to-end responsibility, allowing them to oversee the entire process—from understanding the market and customer needs to writing stories and collaborating closely with engineers.
When you have multiple products and product managers, it’s okay to have some managers who are more technical and others who are less so. However, maintaining a clear span of control is vital. If you have more product managers than products, you can divide the product into clear segments or assign supporting roles where one manager takes the lead, and another acts as a deputy. The key is to avoid unnecessary links in the chain, which can complicate alignment.
One final point I want to make is that product managers often overlook the importance of ensuring that everyone in the organization understands why we’re doing what we’re doing. On a Monday morning, product managers should ask themselves whether the sales team, graphic designers, senior leadership team, and everyone else are aligned with the organization’s goals. It’s a challenging task, especially with the demands of keeping customers happy and delivering new features, but it’s crucial for creating a successful and cohesive product organization.
Yes, it can be especially daunting in certain regions, I’ve found. In the US, for instance, you encounter many individuals who identify as product marketers—these are business-facing product managers who can deliver a great presentation at a show, impress everyone, but when it comes to understanding the backlog, they’re clueless and direct you elsewhere. It’s a real challenge to find the right people.
What I’d say is, don’t give up. A couple of years ago, the recruitment market was almost impossible, but it’s much better now. From my experience, we’ve been able to hire some real megastars in this space. It’s possible to strike a balance. However, if you had to lean one way, I’d argue that deep technical knowledge isn’t as crucial as finding someone who is confident enough to sit with an engineer and work things out together. They might have to ask a lot of “this might be a dumb question, but...” type questions, and that’s perfectly okay.
The problem arises when you have someone, especially in a waterfall environment, who’s essentially a marketing person saying, “I think the product should do X,” and then they send that idea down the line and wait to see what comes back. In my experience, nine times out of ten, you’ll end up reworking the result extensively. While I’m sure some people have made it work, you’re often doubling up on effort or getting subpar results.
It’s important to keep this structure in mind and work towards a more integrated approach. If your organization is transitioning, you can take gradual steps. However, as soon as the person writing the requirements doesn’t feel a deep sense of ownership for the outcome, the whole process starts to break down. This often leads to finger-pointing and other negative behaviors that hinder progress.
Sure, it’s probably not a popular opinion with everyone. A few years ago, there was a lot of talk about the idea of the product manager as a "mini CEO." This term implied that product managers were ideally positioned to make all the key decisions about a product—what should go where and when. However, I think this sets a bad organizational precedent. It can be very disempowering for others on the team.
There are schools of thought where organizations have insulated the product and engineering functions from the rest of the business, allowing them to focus solely on building software. This approach mirrors the concept of separating technical product managers from business product managers, which I believe is flawed. When you remove these functions from the broader context of the business, you’re unlikely to create great software.
The goal in any organization is to build the best possible product for the customer—something that delights them. But this doesn’t happen by having one person, no matter how intelligent, sitting in a room and coming up with ideas in isolation. To be clear, I’m not suggesting you go to the other extreme and build software just because one customer requests it. The key for a good product manager is to synthesize the different inputs from across the organization.
In most firms, you’ll have a senior leadership team (SLT) with various agendas—whether it’s operational savings, technical upgrades, or driving innovation. While innovation can come from product managers thinking deeply about things, it often stems from something a customer says, or something the CEO hears from a customer. For me, it’s crucial that product managers are trusted members of the organization and not seen as being in an ivory tower.
This brings us back to your previous question—finding the right people can be challenging. But you want product managers with whom the salespeople and customers feel comfortable. In my organizations, I expect product managers to speak with customers at least once a week, often more frequently. They should be looking at the market, understanding what others are doing to avoid being caught off guard, and, most importantly, listening to customers.
Customers won’t tell you exactly what to build, and you should be cautious if they try. But they will indicate something they need that isn’t working, and it’s the product manager’s job to figure out how to address that with the technical authority within the organization. This role isn’t about sitting in an ivory tower and dreaming up ideas in isolation.
The goal in any organization is to build the best possible product for the customer—something that delights them. But this doesn’t happen by having one person, no matter how intelligent, sitting in a room and coming up with ideas in isolation.
Of course, you need to allocate resources for innovation, which might be more unconventional. That’s always a challenge. But if you think these innovative ideas will come from just one person, you’re mistaken. They often come from a variety of voices—data scientists or others in the organization who have contact with customers. It would be a waste not to leverage that input.
So, while it’s not a democracy, and you do have limited resources that need to be used effectively, it’s vital to listen to those voices across the organization.
The first thing I would say is that if you find yourself in a situation where customers are coming to you with specific requirements and expecting them to be done within a set timeframe, you're essentially operating as a professional services organization. This approach may work for some, but it’s not ideal for all aspects of a business.
In our case, we deal with very large customers who are accustomed to getting things done on time. Because of this, I spend a lot of time building trust with these customers, holding regular roadmap sessions. People buy products because they want the continuous improvement that comes with them. On the other hand, people who buy bespoke software often expect to get exactly what they want, on their timeline.
It’s crucial to invest time with customers, ensuring they understand the reasons behind your decisions. We meet with each customer at least once a quarter to review what we’re doing and why. Of course, there are still customers who demand immediate results. The worst scenario is when a customer was promised something months ago, and you’re not just trying to meet a current deadline, but struggling to meet a past one.
Regarding the potential conflicts between product management and development teams, I haven’t encountered this issue much because we spend time with customers upfront, capturing the requirement from end to end to ensure it works. A good solution architect plays a key role here. We’re fortunate to have a strong team of solution architects who work with customers to understand their needs. Ideally, we try to deliver solutions using existing functionality, minimizing the need for changes. But if that’s not possible, we aim to implement solutions that benefit all customers.
To take the question a bit further, just as you see technical product managers who seldom interact with the broader team, don’t think your engineers should never be exposed to customers. In fact, it can be incredibly beneficial, especially at the right time. The same goes for your UX team—they love seeing customers and going through these interactions. These sessions can re-baseline a conversation. For example, if a salesperson tells a customer "no," the customer might think it’s a money issue. But if you involve an expert who actually builds the software and asks highly relevant questions, you can have some of the best customer conversations possible.
As a leadership team, it’s important to have a clear strategy on how to handle these interactions to avoid them being abused. But overall, I would embrace this approach. Most customers, in my experience, are reasonable when you walk them through a logical explanation. They may realize that what they originally wanted isn’t quite right, and be willing to approach it differently.
This approach aligns with ideas from Rich Mironov, who emphasizes that it’s not the product manager’s job to do everything on their own. Sometimes, asking for help and involving other resources can generate more positive outcomes. Of course, you need to be selective because disrupting others is expensive, but it’s worth considering.
In general, when it comes to alignment in an organization, I’d advise anyone in a senior leadership team not to fall for the "squeaky wheel" effect. Just because one customer is making a lot of noise doesn’t mean their issue is the most important. You need to evaluate what’s genuinely critical to keep all customers happy and avoid unnecessary tasks. Nothing is more valuable in a software development company than development time. Stripping out expensive, unnecessary tasks is crucial.
In general, when it comes to alignment in an organization, I’d advise anyone in a senior leadership team not to fall for the "squeaky wheel" effect. Just because one customer is making a lot of noise doesn’t mean their issue is the most important.
We’ve had situations where we’ve flipped functionality back and forth because different customers wanted different things. This kind of coordination is vital, and it ties into collective memory and software architecture, which, while challenging, ensures you’re spending resources wisely.
Absolutely. I think the number one characteristic is the ability to stay calm under pressure. As a product manager, you’re often challenged multiple times a day with situations that could easily push you to your limits. The product managers we all respect are the ones who can take a breath, let the initial emotion pass, and then respond thoughtfully.
A great product manager also needs to be an empathizer. When someone comes to you with a problem—say, a sales guy with a seemingly crazy feature request—they’re not coming to you because they’re clueless. They genuinely believe in what they’re suggesting. It’s important to respect that and approach the conversation with empathy and compassion, while still being firm in your response. So, maintaining composure in challenging situations is crucial.
Another important trait is the ability to set aside your ego. Going back to the idea of product managers as “mini CEOs,” it’s vital to recognize that others will come up with ideas, and you need to be open to evaluating them fairly. We all have biases, and understanding those biases—and doing something about them—is key.
Of course, experience plays a significant role as well. The best product managers are those who know their product, space, and industry inside and out. This kind of expertise often comes with time, and those who possess it are invaluable.
One more piece of advice that I’ve found inspiring comes from Matt LeMay, a product management expert. He talks about the importance of being willing to “buy the doughnuts.” If the situation calls for you to do something as simple as running down to the shop to get doughnuts to unstick a problem, then do it. Put your ego aside and facilitate the discussion. That’s my go-to mental model: “What can I do to unstick this?” because, usually, you’re not brought into a situation when everything’s going smoothly.
Honestly, my gut instinct says Slack. Slack can generate some really strange, bizarre behaviors. It’s like the “squeaky wheel” phenomenon all over again. Everyone has their urgent issue, and once they’ve tagged you in a Slack channel, it becomes your problem, whether you saw it or not. I think it’s crucial to make sure we’re using the right tools for the right tasks.
For example, I’ve seen bug triage done on Slack, and I don’t think that’s the right place for it. It often generates unnecessary emotions and frustration. Similarly, I’ve seen Slack being used as a pseudo-Jira, which doesn’t work well. Jira is designed to be a productivity tool for planning, and I believe using the appropriate tools will lead to much better outcomes.
I feel a bit like I’m harking back to a bygone era before instant messaging, but I’ve been amazed at the pain and suffering that platform can cause. Of course, Slack has undoubtedly helped many people with their productivity, but it’s important to recognize when and how it’s being used effectively.
I’ve thought about this before, and I'll give you a product-related answer in a moment because it’s an interesting way to approach it. But first, I believe that if product managers aren’t aligned with the company’s goals, they’re probably not thinking in the right way. So, this may be a bit controversial, but I think new revenue is the key metric. That’s generally what the company is working towards. In a commercial company, new revenue is critical, and I’d focus on a split between existing and new customers.
This may be a bit controversial, but I think new revenue is the key metric. If you’re generating additional revenue from both new and existing customers, it’s a sign that your product is extremely valuable.
If you’re generating additional revenue from existing customers, it’s a sign that your product is extremely valuable. Similarly, if you’re gaining new revenue from new customers, your product is also highly valuable. You should be concerned if either of these isn’t happening—it’s a clear sign that your product isn’t working as it should. While it might not be entirely your responsibility, it’s a strong indicator of a problem.
From a product management perspective, I’d say the lack of excess releases is another key metric. If you find that you’re doing a lot of extra releases, it suggests that your production process isn’t running efficiently. These additional releases are costly, not just in terms of productivity, but also in terms of morale and other factors. One thing we strive to do as an organization is to minimize unnecessary patch releases and stick to the release goals we’ve set for ourselves.
To some extent, yes, and we're continuing to build more features. We’re fortunate in that our experience is a bit different from other areas in the RegTech or FinTech world. Often, we’ll have customers who deploy our software in one location—let’s say, for example, in France—and then they decide to roll it out in Germany, and eventually to 15 or 20 other locations. That’s a great sign; it shows the software is working well, has credibility, and becomes a critical part of their infrastructure. This is positive from several metrics.
In our case, there are some opportunities for module upsells, but it’s more about identifying new areas of the business or finding new ways that different parts of the business can utilize our product. That’s why it’s crucial to engage with the customer, understand their business, and work through their challenges.
I’ve seen other companies do well with a constant upsell approach. The pricing dynamics are interesting—if you’re adding a small cost, say $5 more a month to a $50/month service, that’s manageable for most customers. They can usually get that signed off without much issue.
However, we’re often dealing with higher costs and a big platform that’s used in different ways. So, it’s important to avoid making customers feel like they’re constantly having to pay more just to fully use the product.
It’s a careful balance. You don’t want customers feeling like they’re being nickel-and-dimed—getting to the checkout only to find out they have to pay more than expected. That’s not a good look for building trust. But yes, we do consider modular offerings. For example, we just launched something new called Copilot, and it will have to be modular because that’s how the cost structure works.
We’re fortunate in one way because most of our go-to-market strategy involves a small number of large customers—tens of them, really. This allows us to meet with them regularly, as I mentioned earlier, at least once a quarter. From a product management perspective, there are often several interactions with these customers each week across the organization. We’ve built a solid level of trust through these ongoing engagements. We share our roadmaps with them and get valuable feedback in return.
However, there’s always room to do more. One approach that isn’t quite right for us at this stage, due to our size, is user forums. In my previous roles, I’ve found face-to-face user forums to be incredibly effective. The virtual ones, in my experience, tend to be less productive. But when you can have users discussing their successes and challenges with the product in a no-blame environment, it’s a fantastic way to gather feedback.
The best-case scenario in these forums is when Customer A hears Customer B talking about their experiences and learns something new that they can apply to their own use of the product. That kind of peer exchange adds tremendous value.
In summary, we rely heavily on face-to-face interactions for feedback, which has worked well for us given our customer base. But in a larger organization or one with many smaller customers, you might want to consider running user forums or even conducting user surveys to reach a broader audience.
The value of online feedback forms really depends on the context. When I worked at Worldpay, for example, we were dealing with a much larger scale, primarily in the SME (Small and Medium Enterprises) sector, where we had thousands or even tens of thousands of customers using the platform. In that setting, we implemented a Net Promoter Score (NPS).
NPS added value in a couple of ways. First, it made it impossible to ignore certain issues. For instance, if your NPS is negative—say, a score of minus 50—it’s a clear signal that something needs to be addressed. By the way, I’m not quoting Worldpay’s current NPS; I have no idea what it is now. But that kind of data can really spur organizational action.
Another aspect is the verbatim comments you get from such surveys. While most of these comments come from dissatisfied customers, they can be invaluable, especially in a one-to-many product setting. Some feedback might be just one person’s bad experience, much like what you see on Amazon reviews, but within those comments, there can be real insights. For example, the leader of the customer service section would go through every single comment because that’s where some of the real gems were found.
So, I wouldn’t entirely discount online feedback, depending on your context. However, in my current role with our particular customers, using online forms wouldn’t be appropriate. They’d likely be annoyed and wonder why I didn’t just call them directly. But in other settings, especially where you’re dealing with a large number of customers, it can be a useful tool. I wouldn’t dismiss it out of hand.
I approach this question in the context of building software components. We do build many of our own internal components, but there are a few key factors to consider. First, you need to ask yourself if what you're planning to build will be significantly better than the current state-of-the-art solutions available. For example, we’ve built our own name-matching software because we are, essentially, a name-matching company. It’s what we do—help people match data with their customers. Our ability to excel in this area and outperform the market is a major advantage. We can highlight that in our marketing and use it as a selling point.
However, it’s easy to fall into the trap of thinking you can build something better just because you can. I’ve been there myself as a tech person—thinking I could write a better email client or something similar. But the reality is, you probably can’t, especially when there are plenty of solutions out there that are either free or very affordable. So, with each component, you need to evaluate whether you can truly surpass what’s already available. If not, don’t waste time and resources trying to build something that might not be as good as what you could simply acquire.
This evaluation process should be case-by-case, and it’s important to revisit these decisions regularly. We do this in our organization. For example, five or ten years ago, certain components we built had no good open-source alternatives. But now, some of those alternatives are better, so we reevaluate them every six months to a year as these questions arise. This way, we ensure that we’re not wasting resources on building something that could be more efficiently obtained elsewhere.
Ultimately, the money you spend on building something like an email client—especially if it doesn’t measure up to market standards—is money you’re not spending on differentiating your core product. So, it’s essential to have a good sense check on whether to build or buy and be willing to change course as new options emerge.
We've spent nearly an hour with Gabriel and learned plenty of useful information about the team alignment from a product manager's point of view. You can look forward to more interviews with inspirational product leaders and contribute questions you're most interested in. We'll ask them in our next episodes, and our brilliant guests will provide answers.
You’ve just read an interview from our podcast, where we speak with product leaders who share their experiences. Follow us on Spotify or YouTube for more episodes.
.png)
.jpg)
.png){kind=logo}
