Leader Spotlight: Meshing product- and sales-led cultures, with Carlos Jimenez

---

Carlos Jimenez is VP of Product at KingMakers, a sports and digital entertainment platform serving users in Africa. Though he started his career as an engineer, a self-described “product guy at heart,” Carlos quickly found a deeper passion in understanding what makes customers tick and how to solve (and monetize) their problems with elegant software.

Our chat with Carlos centers on the sometimes shaky relationship between product- and sales-led cultures and the “dangerous” misconception that the two can’t coexist and thrive together. He talks about the pitfalls of kowtowing to client requests at the expense of the product vision and shares some tactics to build trust with sales by proving you know what’s best for their customers.

---

Product-led vs. sales-led: A clash of cultures?

Can you walk us through what it takes to transform a culture and build up a product-led organization?

I tend to be really careful when I talk about product-led versus sales-led. There’s a misconception that a product-led company is not focused on sales. I believe that’s a dangerous misconception because product has to solve a need from the market and be able to sell the product. At the end of the day, the PM’s role is to deliver value and capture value.

Having said that, I think there are companies that are really CEO- or executive management-led. I’ve been in companies that are CTO-led, that are building a product from the inside out, trying to come up with a product they would love to build without getting close to the market and understanding whether there’s a need for that product.

For a lot of sales-led companies, there’s a blurry distinction between a service and a product company. These companies are so anxious to close deals with customers that they end up giving up on the strategy and the vision of the product just for the sake of closing that client and making sure we don’t lose the lead. So they end up just building whatever product the customer is requesting.

A product-led organization is a company or a product that listens to the market. You need to be close to the customers to understand what they want and need, but that’s just one side of it. You also need to understand the product you want to build. And then, a lot of times, customers, users, or stakeholders come to you with solutions.

The product goal there is to push back on that and try to really understand their needs, not the solutions they propose. I’m a sales leader, but I tend to push back against making huge sacrifices to the product vision just to make a client happy.

I’m sure that leads to some friction…

Obviously, you get close to clients. I talk to a lot of clients. In fact, I require everyone on my team to talk to clients. If you get feedback from the market on your vision, you adapt the vision and accelerate some things that your clients are requesting — if they are compatible with your vision.

What I don’t like to do is say, “Let’s just build that thing and we’ll figure out where it fits into the vision later.” You end up building a Frankenstein because the vision or need for every client is completely different.

For any need that anyone has, there’s multiple solutions. If you don’t push back and understand your customers’ needs, you cannot build one solution for all, so you end up building individual solutions for each client, which is a mess. I think we do a lousy job when we say yes to everything.

Building trust with customers and sales

How do you build trust while also making sure you stand up for the product vision?

It’s a matter of not only saying no to stuff, but saying yes to what you really believe you need to build.

What usually helps me is to start small. I start by getting some individuals in the organization, like some salespeople and CX people, and start building trust with them. We join those meetings where they come up with the solutions that their clients are looking for and we help them navigate that conversation. This helps us understand the needs of the customers rather than just the solutions they are proposing. At that point, we can start validating ideas, create prototypes, and then go back to the clients and show them the different proposals we have to solve those needs.

Most of the time, the client doesn’t have a need for a solution. If you scratch the surface, you really understand why they have that need and what’s underneath. So once you understand that, and you go through that process of discovery with the go-to-market, they start trusting that you really understand their needs.

What happens when a customer insists you build a certain feature or fix in a given timeframe or risk losing their business?

I am all for committing. A lot of the time, in these meetings, I end up committing to something in a specific timeframe so we can keep the client or close a deal. I understand commitments; they’re perfectly fine. What I do not understand is just forgetting the vision and roadmap we’re executing because we committed to something else, and just changing it as we go for whomever in the sales organization shouts the loudest.

For example, we built an expense management solution to track what businesses are paying for each of the software management tools they use. Some clients came in really heavy in terms of wanting to manage access to these tools. When we started exploring that, it seemed insane because you need to integrate with a lot of tools and that was really complicated. But when we dug in further, we realized their motivation behind it was not about an integration but to make sure that they could activate or deactivate the users or the employees that would have access to one tool or the other.

We found a really simple, fast way to alert them, “Hey, you need to change these people to this other group, or you need to add these people into this software, or you need to remove these people from this software,” when there was an onboarding, a change of teams, or an offboarding. It was simple for us to build, simple to explain to the client, and simple for them to understand how to use. It enabled them to manage access efficiently, avoid overpaying for licenses they didn’t need, and remove access for ex-employees.

In the end, the best solution wasn’t necessarily the one-click integration the client had asked for. Obviously, that would’ve been ideal, but we found that we could deliver a lot of the value they really needed without diving into a two-year project.

Tying product goals to business impact

How do you ensure that customers’ needs — and, by extension, asks from sales — are aligned with business goals?

There’s an important balance between qualitative and quantitative data. I don’t think you can live without either. Qualitative feedback is super valuable to really understand something deeply, and you need qualitative feedback to understand what customers need.

My team has what we call close loss reasons, which are the main reasons why the sales team is not able to close a deal. In the CRM, we identify that deal as a close loss and try to define the reasons why a client would decline our offer in terms of the product. Then, we start aggregating all the salespeople’s reasons why they’re having trouble selling the product. We normalize all the data to understand the outliers that are telling us the market is requesting this and we’re losing a lot of deals.

This enables us to actually quantify and understand everything in a normalized way in terms of MRR. For example, we might find that, in Q2, if we had a certain feature or this product, we could have increased our revenue by $1 million, $2 million, $3 million, etc. So, with that, we can actually influence our roadmaps and give each team what they want.

I also like to make sure the product has, not just product goals, but business goals. Each team and each product has business goals in terms of revenue. And as we go through the year and they need to increase the revenue, the best way is to determine what the market is requesting. So they look at all this data and try to influence their roadmap accordingly.

In addition to close loss reasons, we also examine close wins. What does the client value the most? And then we also do it for churn reasons; when somebody’s leaving us, we want to understand why. We also talk to clients and prospects directly to really understand the details of that feedback.

So, with all that information, we are a product-led company, but we are also completely influenced by the market, the go-to-market, and stakeholders in our teams.

You’ve spoken about your ‘product operating system’ approach to managing and orchestrating your teams. Can you summarize what that means?

Product, for me, is a mix between art and science. It’s an art in that it’s difficult to replicate; you either have people with the talent or you don’t. But there’s a lot of science to it as well, a lot of things that you can replicate. There are certain recipes that, if you put them together, you end up having a good setup.

We have around 150 people in product and engineering. You need orchestration to make sure you’re efficient from every side. For me, it’s about making sure the product is tied to the business impact you’re aiming to achieve. So I try to make sure that we, as a team, have a North Star. Sometimes it’s revenue, sometimes it’s growth in users — the important thing is that everyone is aligned on the same goal.

Once we have a North Star, I try to create a formula to understand the levers that can actually move that North Star. Take Spotify, for example. Their North Star was about time spent listening to music. What are the levers to move that metric? Well, you can either attract more users or entice your existing users to listen to more music or come more often. Then you have to consider different dimensions such as depth, breadth, frequency, etc.

So I try to decompose the formula and understand the levers, and then those become product goals. And those protocols are tied to the business goals. If we succeed at bringing more users and making sure that they come more often, in the end, we’re going to move that North Star.

How, in practice, do you incorporate all of this into your roadmap?

At least once a year, if not every quarter, I ask teams to write up a narrative. A narrative is about understanding the context, where the product is, where you’re headed, the market, the competitors, the challenges. It’s about putting all your thoughts together, gathering feedback, and iterating. Once you have your goals, determine which teams need to complete which initiatives to achieve those goals. That’s your roadmap.

This is not a one-size-fits-all approach, but I adapt it to every organization I work with. It’s about putting some structure in place to make things a little bit more predictable and then making sure you’re creating and capturing value.

Balancing velocity and precision

What are some common misconceptions or antipatterns around product management that you see happening right now?

I see organizations doing a lot of things without thinking. I don’t know why but we refuse to think. We suddenly have an insight about something and think we need to drop everything and go build it. Three months later, you’ve built something nobody uses.

You need to make sure the thing you want to build is compatible with the vision and delivers value to your customers. A lot of the time, it comes down to precision versus speed. For me, there’s a sense of urgency that needs to be there, but sometimes I believe we go too far.

How do you strike the right balance between precision and speed?

I often see founders, as we grow, getting more and more nervous because the delivery speed has gone down, which, obviously, is going to happen because you have an overhead of management. That doesn’t really matter; what matters is precision. If you jump into a swimming pool and start moving your arms like crazy, you’re not going to get very far. But if you swim with sound technique, you’ll swim super fast.

You need to determine what you’re really trying to do: is it about outcome or is it about output? If you want to be just a factory delivering shit to the customer, that’s great. But the way I see it, it’s about delivering value, not things.

The more features that you bring into the product, the more cognitive load you bring, the less likely it is to be used. It’s a matter of solving problems with the least amount of features.

I see a lot of teams following a framework — for example, “Let’s do Spotify with a scrum.” It’s like taking your brain, putting it in the closet, and saying, “OK, now I don’t need to think.”