Scaling B2B Products for Growth Success | Amplitude VP of Product

Welcome to the show, Ibrahim.

Excited to be here, Carlos.

I'm the one who's excited to have you with us. You've been with us before. You were a speaker at ProductCon New York. You and I have hosted a few product executive dinners in the Bay Area, and I see that you are a very active contributor to the product community in general. So I really want to dive deep into some of those topics that I know are top of mind for you. Before that, you are the VP of Product at Amplitude, and I was geeking out a little bit online to see how you describe yourself. And I find it very interesting. You said that you previously operated at Box, you scaled at Twitter and you shipped at Amazon. Can you elaborate more on how those different experiences kind of come together?

Yeah, it's really interesting. You mentioned Amplitude and then those prior experiences. I actually took the role at Amplitude because I thought it blended the best parts of my prior 10 years. So, for example, at Amazon, I really understood how to be a data driven product leader and the company had an amazing strategic discipline. At Twitter, I saw rapid, rapid growth and scaling, which can sort of put, you know, push the boundaries of your people, processes, technology. And then in Box, I saw really how go to market and B2B products are built and scaled. And so at Amplitude, I saw an opportunity to do all three. Right. A very data driven product philosophy at a company that's rapidly growing and scaling as an organization in a domain where you're building B2B products for other product builders. So it really brought those three things together for me.

And I have an unrelated question that I really can't connect to what you just said, which seems like you've been collecting Swiss army knives for almost 40 years.

Yeah, I don't know. I don't know where you found that, but when I was a child, I was fascinated by this TV show, MacGyver and he always had a pocket knife, you know, for any situation. And so I started collecting them when I was a kid and I've kept up with it. So at this point I have a pretty exotic and rare collection.

I mean, they say product managers can be Swiss army knife. So maybe there is something there.

Yeah, you know, there is something about sort of the preparedness and having a utilitarian mindset that I think product managers embody.

The other fun fact that I found is that you're running for city council in Los Altos in California. So what inspired you to also explore politics?

Yeah, I mean, I don't know if I would say I'm exploring Politics. I'm just trying to serve my city. I think it's important in this day and age to be engaged in the community you're in. And you know, there's many, many ways people do that. You can volunteer to help out, you can be part of your kids school education system, you can do all sorts of community service. And I've done things like that over the last 10 years in my city and I thought it was time to actually stand up for a more official position where you can actually solve problems that are maybe not one year problems, but ten year problems. You know, as a product person, I love working on long term strategic things. And what is more long term and strategic than, you know, serving 30,000 people in a city.

And then I find all of this fascinating, Ibrahim, because it's obviously, I know product people are curious in general, but you take that to a whole new level. Between the Swiss army knives, the politics, and also content, you've been building content and investing in your own personal brand through your substack. I know you teach courses, you participated at the product school community. So how did you get started and find ways to invest in your own brand?

Yeah, it's interesting. I didn't think of it as branding when I started. I've always enjoyed writing. Young Ibrahim, if you met him in elementary school, wanted to be a writer. And so I've always kind of journaled and doodled and written for my own sort of introspection. And when I, when I left Amazon, you know, one of the strangest things that working at Amazon was I thought there was really, really good strategy and product thinking that happened at that company every day. And they didn't really talk about it externally for, for obvious reasons. They wanted to sort of play it close to the vest. But I would say that was the one thing that bothered me. I was like, we should be telling the world our approach because it's so strategic, right? And so when I left Amazon and I joined Twitter, I was like, I can talk about these things, I can talk about strategy and company and I use Twitter as an outlet. And then I slowly started discovering other platforms. I actually used to blog on Quora for a while. I blogged on LinkedIn and you know, you'd get a little bit of positive feedback, but you're kind of at the mercy of the algorithm. And one of the things actually changed the ui, change the audience and it would get lost. Like my Quora blog disappeared one day. LinkedIn has been hot and cold about it and so I kind of made a Mental note, I was like, I want to keep writing for myself internally, but when I see a product or a platform that will make it really, really easy to distribute, I'll jump on it. And so it's interesting, during the pandemic, multiple people messaged me and they're like, hey, you know, you're always kind of trying to write online. Here's a new thing called substack. And I played around with the tool and I immediately understood, oh, my God, they've simplified everything from hosting to publishing to monetizing to archiving. And so I just took a lot of drafts that I had been tinkering with in Google Docs over the years, and I just slowly started writing and sharing them. And, you know, my intent was to challenge some of my ideas and thinkings with the product community. Right. But I did not really think of it as a brand. And so over the years, I found sort of a niche writing about product philosophy and B2B products. And that has organically led to other opportunities where if you're putting ideas out there, people will come to you and say, hey, do you want to give a talk about it? Do you want to teach a class about it? And so now, without realizing it, I've kind of created a flywheel that centers around me putting out thoughtful frameworks and ideas, engaging with people, and then that leading to other avenues. And so I guess I do have a brand, but really the tagline I like to use is I'm just learning in public.

Yeah, I like that framing. I also build or create content, and my intention was never to become a quote unquote influencer. I actually think that has a lot of bad connotations, but it clarifies my thinking ultimately. Like having been able to structure thoughts and also playing with, contextualizing it to different channels. Right. That you mentioned on Twitter or X versus LinkedIn versus Substack. Now, this podcast interview is a whole new world. And in a way, it preps me to also communicate in different ways, internally and externally with other people. So I've seen the role of the product evolve to be much more external facing. Back in the day, I come from an engineering background. It was all about like being with engineers in the. In the cave, you know, and maybe writing some code. And now it's more about writing copy and being out there with your customers.

I mean, I think they're both ends of the spectrum are accurate. Like, you can absolutely find product roles that require you to go really deep into the technology and focus more inbound with design and Research. And there's absolutely roles that will require you to go more outbound and partner with marketing, sales and success. Right. And I don't think there's a right or wrong definition of product. I think it's really what your product requires, I will say, in a leadership capacity. Storytelling. Getting the point of view and the unique take on the market out there, both internally at your company and externally to the market, is a skill. Right. And so I think that's a natural gravitational pull is you. You're expected to be more of a thought leader and explainer of strategy and vision as you get more senior in your career. So that's why I think it's good to practice that craft any way you can.

Well, let's talk about Amplitude and Data. I know you are also very data driven in addition to good storytellers. So let's start with what is Amplitude today?

Yeah, Amplitude is a digital platform where you can actually understand and optimize your user's behavior in any digital property. So whether it's a website, a mobile app, could even be a smart vending machine. If you want to understand how people start and navigate through your product and then figure out where they're doing the things you want and where they're struggling to get the things you want done, you can pinpoint those, you can go deeper into it, you can understand the why behind it, and then you can actually take action to improve your product. Right. So whether it's, hey, people land on a landing page and I want to get them to sign up for my service. Right. Or I want them to add something to cart and checkout, whatever your core flow is, Amplitude will help you identify it, visualize it, and then optimize it.

And where are you trying to take Amplitude next?

Yeah, so we have a very, very strong and rich history over a decade of understanding and visualizing the user behavior and then identifying the right segments of users within your population for you to do more with. Right. So we can help you figure out who are my power users, who are my dormant users, who are my casual users, who are my novice users. And so that is the foundation of Amplitude is the understanding and the segmentation of your population. Where we're trying to go as a company is you. We are part of a larger ecosystem where you are trying to improve your product. Right. And so if you think about some of the adjacent tools that Amplitude has collaborated with in recent years, we've started to bring those more in house. So, for example, three years ago, we launched an experimentation platform because a Big, big reason people want to understand user behavior is then they want to optimize it through experimentation. Right. Over the last year we've introduced session replay capability because people understand user behavior both quantitatively and qualitatively. Right. And so where amplitude is going is as the definition of user, as the definition of digital property and as the definition of improving the customer experience evolves. We want a lot of those capabilities to either be first class citizens in our platform or the command center of controlling all of that. In an ideal world, your product is understanding and optimizing in a self healing way constantly with Amplitude being the brains of that.

And ultimately I believe these tools help you make better decisions. So you have now access to data faster and you can rely on that. So what is your framework for making decisions?

Yeah, it's interesting. I mean it comes down to the type of decision you're making. But I would say a general principle I try to follow and we try to follow at amplitude is blending quant and quality. So what is the data telling us? But then what is user research or customer feedback or support tickets also telling us? And I find there's a couple of different ways we utilize that. One is where are they saying the same thing? There's obviously alignment that that is worth addressing or fixing or improving. Right. And where are they saying different things? And that can be an interesting space to explore as well, is like why am I hearing something different from the people I'm talking to versus what the data is telling? Right. So that's two ways we look at it. The other is what I would call sort of a micro macro switch, which is sometimes we start broadly with like here's what's happening at a North Star metric. And then you use more qualitative feedback to narrow it down. Or you could start with I heard this from a segment of our customers use data to narrow it down. So I do, I do find qual and content to help us lead to the best decisions.

And for you as a leader, where there are other very capable people as part of your org, what's your rationale behind this? Deciding what is high stakes and hence you want to be involved in the decision versus what can be delegated and you are committing to trust other person making that decision.

Yeah. You know, I don't think of it as a binary trust or not trust or delegate or not delegated. I think of it as a spectrum, which is when we understand the user, the problem, the market and the differentiation. That is where I lean more towards delegation to other people and where we're navigating the unique unknown. I think having leadership be more heavily involved is helpful because there's shared learning.

Right.

And so that's how I think about it is anytime we're tackling something, I'm like, how much are we in execution mode versus exploration mode? And I try to be more heavily involved on the exploration side. And once we're aligned on okay, we intimately understand the user and the problem and how we're going to solve it, then I think you can start to remove yourself from some of the execution details.

So basically if you're saying, let's say we're in the execution mode and it's still a high stakes decision, even that this is not new, you feel more comfortable being less involved.

Yeah. I do find once you get into execution mode, you really have to sort of have a single threaded leader and a directly responsible individual and kind of get out of their way. Obviously you want to keep visibility and transparency alive. Right. But I find when you have too many people trying to execute on the same thing, it gets problematic. And so I would say oversight versus driving is how I approach it. But again, that's unique to me and that leads to me hiring and coaching a certain flavor of product person. Right. And different leaders operate in different ways. And so I'm a big believer in any operating model can work as long as the collective leadership and execution engine is aligned. I think where it gets problematic is if you hire people who want autonomy, but then you're always in the details, that can be frustrating. And if you hire people who are very high level, non execution people, but you're also talking in abstract terms, that can be problematic. So it's really about mixing and matching the leadership and the team in the right way.

And I find this topic fascinating. I know you do too. Because when we hosted our last product executive dinner, we spent good time with other leaders and it was incredible to see that people had different approaches. There is a component to decision making that I want to discuss with you, which is consensus. I see you use the word collective and involving people at the same time. Like how do you go about making sure that a decision is made even if there is no consensus?

Yeah, look, there's. I like to think of decisions as three types of decisions. And I would say most organizational dysfunction and drama stems from people disagreeing on the type of decision because there is no conversation about what kind of decision. So the three types of decisions are. I would say type one is I made the decision. I'm telling you the decision and you just need to know, because you need to execute. Right. So we as a company are going to utilize AI like decision made. Right. Type of decision number two is I am making the decision, but I need your input in order to make a high quality decision. So I want you to chime in, but it's ultimately my call. Hiring is a type 2 decision. The hiring manager is a decider, but the panel will give you a lot of feedback. And then type 3 decision is we genuinely don't know what to do at any level or across teams. And so we need to collaboratively suss it out and find it. Right. And so just to give you an example of dysfunction, sometimes you'll do an interview and somebody will come into the debrief and say, if we don't hire this person, I'm going to quit. And my response is, usually it's amazing that you have that energy, but at the end of the day it's my call. Right. And so, and sometimes people, you know, will talk to their CEO and the CEO is trying to tell them, I have decided to go after this next segment in the market. And they're like, but what about this? And it's like they're talking past each other because they don't understand. One of them sees it as a type one decision and one of them sees it as a type 2 decision. Is a long winded way of saying, I think anytime you're faced with a decision, it's important to call out who is the decider and who is the collaborator. And there's many, many models for that. Right. Like sometimes people use daisies for that. And so I think those kinds of frameworks are useful, but to me it's less about the framework and more about the rigor of consistent decision making frameworks and following through on it. So the other thing that can happen is when a decision is made and people sort of disagree but don't commit, that is very toxic within our organization. And so I spend a lot of time framing decisions, but then a lot of the work that goes into it is actually making sure people understand the why behind the decision decision, so that when they're faced with revisiting the decision in the context of execution, they will make the same call as you because you're working off the same data or the same principle, the same strategy.

I like that last piece that you shared. Because there's a big difference between making the decision and then implementing the decision. And sometimes the people who are responsible for making decision versus implementing are different.

Yeah, I mean I've thought a lot about why good strategies don't pan out. And it's not because they're not good strategies. What usually happens is it's not written down, so nobody could really digest it. It's not disseminated often enough. So there's people who never understood it. Right. Or it's not sort of translated in a way where people can make it their own. Or the people creating the strategy are in a room and they don't have access to the same data as the people who would execute it. And so there are hurdles and trade offs that they don't foresee. And so that's why I do think collaboration is very important. But once you're locked on a direction, I think it's very important to not constantly thrash around it. Right.

Well, let's switch gears a little bit and talk about money. One of the talks, the talk that you gave at Broadcom New York was about connecting product to revenue. That's a very hot topic these days. And I'm personally in favor of making product teams more accountable for revenue growth. So I would love to get your insights on that and how proteins can effectively do that.

Yeah, so the TLDR of the talk I gave at your conference in New York, which amazing turnout, amazing conference by the way, was, look, you have to connect your product work and even your go to market campaign work to revenue. And there's three ways to connect it to revenue. You're either generating revenue, you're preserving revenue, or you're making it more efficient to have the revenue you have. Right. And so I think that's not sort of a novel or innovative concept, but it kind of gets lost on a lot of PMs who maybe are not held accountable in that way. And my background, you know, I worked on a lot of internal tools and platform products at a certain point in my career. And in those teams, if you're not shipping the product that your company is selling, it's harder to connect the dots to revenue. And so I got very good at, well, while we may not be generating revenue, we are making sure the revenue we have sticks around or that it gets more efficient. Right. And so I came up with a lot of heuristics on how you can connect the dots. And so some simple examples are, hey, look, if people who use your features, even if it's not separately monetized, tend to adopt faster or retain better or get to power user state quicker, then that feature matters from a retention perspective. Right. If you own the guts of your service and Rewriting it to be more efficient would allow you to price more or operate with better margins. You are affecting revenue. And so I think one is, I'm big on teaching PMs how their product can connect revenue and then them controlling the lever that directly leads to the aspect of revenue that they're contributing and then organizing and goaling their team around it. I also think these types of frameworks are super useful because then you can identify parts of the product and teams that are disconnected from impacting revenue and you can have a hard discussion about does this even matter to the bottom line or the top line of our business? Because ultimately that is the goal of product is to provide leverage in a way that you otherwise wouldn't get.

Exactly. And I think this a lot, unfortunately a lot of teams miss that point. Like the goal for a product team is not to make the product successful, is to make the company successful as a whole. And yes, there's certain metrics that need to be optimized, but they sometimes only take it to a local maximum. And I think keeping an eye on truly what really matters most to the company, to the CEO, is going to make you a better pm, even if you're not fully accountable for all the revenue in the company.

And you know, that's a very important mindset shift because it then leads you to working on things that are beyond the pixels. So I'm a big, big proponent of the product is not just the ui. The product is the entire experience that the customer and the user goes through. Including your setup page, including your documentation. Right. Including your help guidelines. And so, you know, I've worked in environments where it's sort of antithetical to do things that are not just ship the feature. Right. Everybody's like, what is the next feature you're going to ship? And sometimes it's like rewriting my core service is the best bang for the buck or cleaning up our external facing documentation is the best thing to improve adoption. Right. And I know it's hard because we're all kind of. There's always the tendency to fall into the feature factory. But I do think when you think holistically about what is going to move the needle, you then will do product work that is maybe not as sexy.

That's such a great point there, Ibrahim. I think sometimes doing the unsexy work that is sometimes making what works better is just much more powerful than making a new thing.

Yeah.

So let's talk about harm with a scenario when product could be responsible for revenue. It's in a plg. There is a PLG motion.

Yeah.

At the same time there's a SLG motion. So product is kind of trying to decide what users am I pushing to go through the checkout directly, what users am I pushing to interact with sales and ultimately make sure that the company is winning. What are some ways to kind of navigate those scenarios?

Yeah. So I think, you know, first I'll say there's no. If you have an environment where there's both sales LED and product LED leads and revenue, I don't think it's a binary one or the other. I think one can be a lead driver for the other. Right. You can absolutely have a product LED motion that generates leads for sales. And so I think number one is don't frame those two motions as incongruent. Right. I try to think of them as there is users and revenue that you capture fully self serve, and there's users and revenue that you capture fully white glove, handheld. But in between there is sort of leads that you can nurture and move, move from one direction to the other. So that's one way to think about it. The other is, I think I always tell people there's a difference between product led and self serve. Self serve means no human intervention, but product led just means you put the product front and center. So there is nothing wrong with being product led and being primarily enterprise sales. That just means your leads come from the product itself, the product demos itself, the documentation is amazing. You don't need a human to answer basic questions. Right. The human is there for the relationship part of it and the pricing and packaging and things like that. So that's how I sort of think about those two ends of the spectrum.

Let's move into another meaty topic which is around scaling B2B products. I know it's big for you. First of all, start with the basics here. How do you evaluate the health of a B2B product?

Yeah, I mean, I'll go back to the revenue impacting framework I mentioned earlier. I look at those three metrics, like. Like, is revenue coming in and is it coming in from new or existing users? So there's a growth dimension. How sticky is that revenue? You know, are people upselling cross selling? Are you constantly having to lend newer and larger accounts? So there's a retention element. And then I also look at operating margins to understand is the revenue you're getting efficient or is the cost to acquire, you know, beating out the lifetime value of the customers you have? So I think I look at growth, retention and margins as Sort of the dimensions to evaluate the health of the business. And then the second thing I would say is you evaluate product market fit and go to market fit. And I actually strangely have a very qualitative way to do that, which is I just want to go talk to the big customers and the big accounts and figure out how consistent is the reason they bought what they bought, the use case they deployed and the manner in which they deployed it. Because if it's like, hey look, your biggest accounts are your most referenceable customers, all bought for slightly different reasons, slightly different products and are implementing in slightly different ways, you don't have a product, you have a services business. Right. And so that's one of the big things I look for is do you actually have repeatability? And that's the thing I've learned having worked in the in B2B products for almost a decade now, is getting to repeatability irrespective of whether you're going to do self serve or sales LED is the thing. Because that what's give you, that's what will give you leverage. Like if everybody is looking for the same differentiation and trying it out in the same way and buying it consistently and deploying it in the same way, then that reduces the load on go to market and product. And when you start to get to customization and specialization, that increases the load and sometimes is the death of those products. And so that's number one is just look at the core KPIs of the business and figure out how consistent and repeatable is the core flywheel.

I want to double, double click on that because yeah, productizing an enterprise product is the holy grail. That would be amazing as you, as you start having conversations with some of your largest account and realizing that everybody thinks they're special and they want something slightly unique. And sometimes the reality is that you have to make certain concessions to close, to close that deal. So when you go back to the drawing board and try to kind of connect those dots to decide what's next, what is that rationale? Like how much wiggle room do you allow your teams to close those deals and make the adjustment versus building that platform that is going to scale the way you described?

Yeah, look, I mean again the ideal scenario is there is consistency in what you're selling 80% of the time. But you know, having worked with enterprise accounts for a while now, I can tell you there is the desire for strong customization. And so there I say is just be intellectually honest about what you're doing. Right. If you are Seeing the constant need for customization, then I would say make sure you have a path to address that. And it doesn't always have to be the product. Right. I think that's where things get tricky is sometimes people are like, well, we're going to have to build this one off feature. And then when you have a very long list of one off features that you're building for one off customers, that's where the product team can start drowning and then that tension starts between sales and product. Another way to look at it is who can close the gap, because there is a need in the ecosystem for that. And I would say partners are one route, right? Having a forward deploy team on the go to market side, right. In house consulting is another way to do that. And so I think there's a bunch of different ways to fill the gap. And just being intellectually honest about how to fill the gap is going to be very, very important. So I'm not against customization. I think it's about agreeing on what degree of customization, who does the work and how to move forward.

Yeah, I like that approach to filling the gap and not assuming that the only way to fill the gap is by having engineers build a feature and maybe finding other creative solutions that will allow you to move on a little faster, such as deploying professional services or maybe even other types of partnerships. But the reality is that at some point you hit a ceiling, right? Like customers want more for a good reason and you start to consider to expand your own product line. So what are some of those strategies for a product leader to then go about product expansion?

Yeah, look, expansion is a good thing, right? It means there is demand for your workflow to be the center of a broader job to be done, which is generally a good thing, right? It allows you to sort of get efficiencies of scale because the product you've built is able to serve additional use cases, right? You can collapse different Personas together and serve core and adjacent users in a better way. And frankly, you can consolidate budget, right? So taking it back to revenue, that is the important goal of the business. And so some of the signals that I look for, you know, a very smart CRO once told me, if it's your first new product, like you just have one product and you're going to a second product, he said it should be no contention, absolutely no contention internally and externally. Like if you're debating, well, should we go here or should we go there, you don't have clarity yet. Everybody, your power users, your internal sales team, Your product team should be like, this is obviously where we should go. That's how obvious your second product should be. So that's one signal I look for. Two is, you know, I mentioned earlier, amplitude is a great tool for understanding populations of users within your product. One of the ways to look at it is core versus adjacent users. When you start to see, hey, we're getting users with a slightly different title or expertise level or ability to navigate our product, they're trying something, right. But it's not working, that's a good reminder that you're starting to see a different population emerge in your product portfolio that may need slightly different features or capabilities or entire product lines to fully do their job.

Yeah, I think that's another good point. When you think about expansion, there's so many dimensions. One can be expanding into a new type of user, but the other option could be expanding into a new type of product or feature for an existing user. Obviously there are others. So I always find that when an existing user is hacking my own product, that's another very positive sign because they're trying to get something done and find a creative way to kind of put it together. So this is really strong indicator for me to know, okay, I should make it easier for them.

Yeah. Now I'll say two things about hacking your product. One is power. Your power users will try to bend your product in all sorts of different ways. And so sometimes that can be a red herring where you're like, oh, I see users doing this, but if they're power users and they're not representative of a larger market, then that could be a waste of time to build in that direction. Right. And so I think it's very important, anytime you see users doing something, approach it with curiosity and say, is this something that more users are regularly going to be tired of doing, or is this unique to this population? That's number one. Number two is. I mean, I use the term hack loosely. If people are screenshotting your product, you probably need to invest in your reporting capabilities. If people are exporting CSVs and leaving your product, there's probably some data transformation capabilities that you need to introduce. Right. And so it's not even hacking. It's just whenever you see people jumping out of your product to finish the job, that is a good signal to explore.

And let's talk about big bets, moonshots. Some of these maybe not so obvious decisions that you have to make to scale your business. Let's say you haven't found a population that is finding great ways to Use your product. It's relatively unclear if there are more Personas that will benefit from your product or at least would be willing to pay. And you are like, okay, you know what, I have conviction in making these type of investments. So how do you go about allocating enough resources for those long shots while also listening to your customers and going for more of the short term wins?

Yeah, no, that's a really great question. I would say one of the dysfunctions that a lot of organizations fall into when they're going from single to multi product or just managing a portfolio is they put those two things in competition with each other. They're like, oh, should I build the new product for this new user and this new product, new revenue stream or the existing product? And that's just, you know, that's like saying, well do I want to exercise or do I want to sleep? It's like, no, you, those, you have to do both those things. Right? The way I say it is the competition and the trade offs should be within an allocation of those buckets. So as a company, when you're doing, let's say annual planning, you should decide, look, we think to maintain the product we have and continue to improve it and polish it, we're going to allocate X. And in order to investigate new sources of revenue or segments that we want to capture, we're going to allocate Y. And depending on the journey your company is in, X might be much bigger than Y equivalent to Y. Or even new products might be bigger than old products. Right. That is the conversation to have measure twice and cut once once you've had that conversation and then trade offs come up. It's like, do those trade offs within your own buckets. Right? You should argue about different investments on the core product and different investments in new products relative to each other. You should not try to cross pollinate because what you're basically doing is saying the group that is responsible for a completely different mission is now at odds with a group responsible for a different mission. And it's like that's not where the tension should be in the company. The tension should be what are the best ideas to improve the product we have and what are the best ideas to go after new markets. And those ideas should be relatively stack ranked again against each other. So I, I kind of avoid the trade off by having a pre discussion on high level allocation to begin with.

Yes. And, and you're saying that maybe the same team that is working on some of those short term wins can also be responsible for working on some of those long shots. Right.

They can absolutely. You, you never want to create an environment which is like people who work on keep the lights on and people who work on sexy things. So I think it has latitude. But at some point I think you do want to have sort of a lean ninja team that is out there trying things without the operational overhead that comes with the core product. Right. I think that's another dysfunction that happens sometimes. People say here's a new product idea or a new segment that I want to explore and then they overburden that team with the operational overhead and the reporting responsibilities and the check in meetings and it's like they can never go actually validate the idea. So you almost want to unconstrained new ideas to say, go figure it out, but you want to time box them and scope box them. So it's like, hey, look, it's three people for a quarter. That's what we're agreeing to invest here.

And one of the things I learned the hard way is that as a CEO, I also have to protect enough allocation for the long term because there will always be enough things going on that require attention. So having whatever the time it is, depending on quarter or other objectives, but like a dedicated slot for long term is something that I found very valuable. And another thing is for me as an executive, the time that I invest on the low, on the long term is kind of not proportional because if I want a new bet to actually work, I find myself trying to invest more time, even though short term it's just harder to prove that. Roi.

Yeah. You know, I, I used to work with this engineering leader who had a really simple framework for that, features, fixes, foundation and future. And it's kind of like eating a balanced diet. Like at certain points in your life, you might be like, look, I'm trying to have more protein or more fiber or whatever, right. But you never say I've stopped eating carbs. Like that's unhealthy. And so it always used to be. Let's agree on what a balanced meal is for this product team at this stage of its journey. And you can dial it up and dial it down, but you're very conscious about it. But anytime you take something to zero, it's very hard to get it up again. Right. So for, as an example, if, if slowly teams start creeping towards, we're just only worried about new features and we never do any foundational work. We never work on quality or performance or scale. One day you're going to have an emergency of like performance is really bad or quality is really bad. Right. And if you have a team that's like, hey, we're just constantly just polishing and bug fixing, one day you're going to have emergency of like we've stopped innovating. So before you get to the point, just maintain a healthy diet is how I approach it.

I like that. And then I also want to talk about GPM now. More and more important for product to partner. As you think about scaling a B2B business, I can imagine that some of those motions will evolve as well. So how do you go about deciding what is the right level of partnership at what stage of the growth for a product?

I mean first I would say let's decompose gtm. Like there is sales, there is demo engineering, there is support, there is customer success, there are partnerships.

Right.

And so they all have slightly different approaches and slightly different time horizons that they're operating on. Right. A enterprise sales rep may be worried about revenue that's going to book in six or nine months. A mid market inside sales rep may be working about worrying about deals that close this quarter. Right. Your partner person may be worrying about something that is like going to take two years to pay off. And so I think it's important to collaborate with and listen to all of your go to market partners regularly. Right. One of the things we do is sort of quarterly check ins interlocks on those topics. But then the second thing is to make sure you understand where your incentives are aligned or misaligned. Right. And one of the interesting things I've found is the group who is the closest aligned to product is customer success. They both fundamentally want people to use and adopt the product in a healthy way. Right. Versus other people might have slightly different motivations. And so I think it's important to listen to everybody but understand they have their own biases that they're trying to push and operating on different time horizons. And that's why the product role exists is to take in all of these different inputs and sometimes conflicting inputs or what feels like conflicting because what's good in one quarter may not be good in one year. Right. And then to make a judgment call. And I think that's the, the real craft of product management is taking in all those inputs and coming up with a solution that satisfies both the short and long term as best as you can can.

One of the potential trends that I'm starting to observe is what you said around customer success. I've seen more and more product teams that are officially overseeing customer success. They are not part of sales anymore. And they are now with product for the exact same reason that you described.

Yeah, I mean, there's. Look, there's no right or wrong org design, I would say, you know, people always ask me, do you believe in product as gm? It can work. Do you believe in, you know, one account team that straddles sales and success? It can work. Any model removes friction on some dimension and introduces friction on another dimension. And I think the thing you have to figure out is for your product, for your company, for your market, where do you want to have friction and where do you want to be friction free? And so I think that's the approach I always take.

And I would probably add also the type of leaders that you have in play, right?

Yeah.

That also influences the type of work you want to design.

Absolutely. So I actually believe any org design can be successful as long as you have the right leader for that design and the right talent to be pull it off.

Ibrahim, it's been a pleasure to do this deep dive with you on decision making, on scaling between products. And also on Andre, do you have provision on how to connect product to revenue? Those are like such meaty topics. I feel like we would go for hours. But I also want to respect your time. Thank you so much.

Well, maybe there will be a part two someday. So, Carlos, for having me.

Take care, Sam.