Weekly Knowledge Nuggets Ep. 7, Featuring Ramp's Head of Growth, Sri Batchu

Yeah, I mean, uh, just today, uh, I'm in San Francisco this week, uh, you know, we're in a WeWork that we're all working out of. There's a bunch of growth and marketing people that are in the Bay Area, uh, and so we just decided to have like a little reunion here.

So very cool. Well, kind of a great, uh, introduction in some ways to the, the episode. Welcome back everyone to Weekly Knowledge Nuggets. Uh, today I I'm very excited to be talking to, uh, my friend Sri Batchu about how growth teams use data. I'll let Sri introduce himself here in a minute, but among his other accolades, he right now is the head of growth at Ramp. And as always, I'm Nick Freund, your host. I'm also the founder of Workstream.io. And yeah, uh, Sri, with— without further ado, just why don't you, uh, introduce yourself to anyone who might be listening in?

Yeah, great. Hi, I'm Sri Batchu, and as Nick mentioned, I currently lead growth at Ramp, which is a corporate credit card expense management software for the financial operator suite. Prior to this, I was at Instacart leading growth teams there. Before that, was leading pricing and analytics teams at Opendoor and started off my career in management consulting and investing roles. And I know Nick from business school. So great to see you, Nick. Yeah, likewise.

Of course. And if you were right there at the very beginning, it sounds like Sri is in San Francisco right now meeting with a bunch of members of his team, but he just moved to New York from Austin and I haven't gotten to see him yet. So I'm excited to get together for coffee at some point in the next couple of weeks. So anyway, Sri, my first question for you, and this is honestly like for me as much as anyone, Cause I've heard explanations of this, but I never fully get it. Like what does a growth team do? And like, is it actually something different? I would just be curious, like your take on this and the way this looks at, why growth looks at brand.

Yeah. I think the practice of growth is very different based on the company and their own market motion, et cetera. And people that you see that lead growth teams come from kind of a variety of different ways, but the 3 primary paths that you see people doing are they're marketers that over time become more performance and growth-oriented. They're growth product people that are building technology to help grow a company, or they're people that come from a data and analytics background, which is kind of the category that I put myself in, that lead growth teams. And so by virtue of that, growth teams typically are some combination depending on the company of Analytics growth product as well as some functions of marketing, right? At Ramp, it is an acquisition growth product team where— so Ramp is a B2B company that is not a bottom-up SaaS product. So it doesn't have the traditional growth product team that you would see at a consumer company or a bottom-up SaaS company. Our growth product team is, is focused on acquisition. So there's an outbound automation program for prospecting that is run out of, you know, that is a technology group that's under growth. As well as there's a team focused on content, lead gen tools, SEO, the website conversion flows, et cetera. Those are the kind of key growth product elements here. As I mentioned, other teams will have much more product-oriented growth services if they have a bottom-up SaaS or consumer engagement motion, which Ramp does not today. And separate from that, we have paid marketing as well as lifecycle and email marketing and SEO that reports into the team. So what is the joint thread that pulls all of these teams together? And what to me defines growth is growth is really about high-volume, data-driven experimentation to see what works. Unlike other functions, there's, you know, for example, on the operating side, you look at your P&L and you say, okay, I need to reduce costs. You have an architecture of how to do that. It's like, okay, these are the line items and these are the teams that are working on them. These are the things that I need to make more efficient to reach my results. Growth is the opposite discipline. You'll have goals, but there's not really a clear path of getting there. It's like, okay, we have to grow 2x. Well, how do we do that? And the best way to do that is actually build a team that's focused on experimentation. So how do you drive lots of experiments? How do you make sure that the experiments are useful, conclusive, and effective and drive meaningful results? So it's really around building that culture across the cross-functional team that is driving the top line of the company. So hopefully that was helpful.

No, no, it's super helpful. My mind is exploding, but it's helpful. If, you know, experiments to regurgitate and try to summarize what you were saying, if, you know, if the guiding light or mission is, or even ML, right, is like experiments within drive growth, I would assume that you, at least the way you see, is the team owns both the experimentation piece as well as then like the ongoing like programs and investment that once you've proved out experiment, the, the experiments that work, or does that then get like handed off to somebody?

Yeah, good question. We have both in the same team, so we kind of think about certain people as surface area owners and channel owners. So there is a team that works on SEO specifically. There is a team that works on email marketing, for example. I'm just picking two random teams within my team, and they're both responsible for experimentation within their vertical and surface area. But having said that, they're also responsible for, and managing the program and getting the results overall that are targets for for that particular team, but they're also responsible for implementing experiments that others might have an idea, ideas on whether it's within the team or outside of the team. So we've got a few generalists on the team that whose whole job is to just try to push the, you know, curve, so to speak, on a bunch of different channels. And they're just trying to find the highest impact projects. And so they will work with the channel owners, like somebody has a marketing email idea or email marketing idea. Then they'll, you know, there's a process, but they'll then go to the marketing team that works on email to ship that idea. So it's a little bit of a combination. It's a little bit nebulous. I think there's no perfect structure. We are, so just for context, our growth team is about 20 people excluding the engineers. Once you include the engineers and product and design team, it's closer to 30. So, and with that kind of small-ish team, we're covering a lot of different surface areas. So, One thing that's super interesting about growth and more broadly, top line generating teams is that they're highly fragmented. It's actually very hard, even for me as somebody that has been doing this for a little bit of time, it's impossible to be good at every single piece of the growth equation. So people usually have one spike and you're working with craft experts on all the other areas. And so one of the things that we do at Ramp, which I think is unusual, is actually we do sprint planning for all of these teams together. So every 2 weeks, like each of these teams comes in and they present the projects that they're working on. And we have a common currency that we measure all of them by, like whether it's dollars of SQL pipeline or like dollars of contribution margin, you can pick as a company what that common currency is. And we just cross-prioritize all these projects. It increases visibility, improves creativity and pressure testing, and it also helps us resource allocate more broadly across the team on like where are the most impactful projects.

Interesting. I mean, that's super interesting, that last piece about the sprint planning and like the cross-team prioritization sprint planning. Super interesting. I mean, there's a couple of things there. One, you're applying sprints and agile methodology to, I mean, to some extent, to teams that traditionally haven't used that stuff. And then also just kind of the iterative nature of it, which is super— the iterative or the cross-functional nature of that, which is interesting. You had posited all this by saying that it looks very, very different company to company and you were talking mostly about ramp. Are there any specific things that you think would be helpful to call out and maybe differences at Instacart or, I mean, obviously the ramp is not your first gig, so I'd just be curious if you had anything.

Right, right. And so I would say like it's, Growth is only increasingly becoming an independent discipline over the last 5 to 10 years. Like, you know, 10 years ago there weren't really anything called a growth team. You know, it was basically marketing, right? So I think this like building agile methodology teams that aren't familiar and working this way is new. And like, I think in Ramp's case, it's particularly unique. So if you look at most B2B SaaS companies, and I'm friends with folks that, you know, do this work at places like Airtable and Notion, et cetera. And if you talk to head of growth or people there, it's actually 100% product team. So often marketing sits separate from the growth product team. And for those teams, marketing is not a big lead gen to begin with. Yeah, necessarily.

And they've got what you're describing, sorry to cut in, is like, what is the way I've had growth described to me in a way that made more, that had made sense to me in the past, but it was definitely different from the way you're describing it, right?

Sorry, go ahead. Yeah, so I think that the ramp structure is slightly more unique. I personally think it's the better way of doing it because I think it really drives more collaboration across all teams that are focused on lead generation. And one thing that we didn't talk about is because my team is much more focused on pipeline generation and we are expanding to farther down the funnel, but that's been our historical focus. And typically when you look at growth teams for SaaS businesses, they're basically, their first goal is engagement farming. You ship the freemium product, get people onboarded on the freemium product and actually get engaged and use it and then figure out what is the tipping point to convert them into a product qualified lead and run them through a sales process. So that's one whole piece of it. And then There's a retention element. So for the paid customers, how do we get them to retain and create virality in terms of referrals, which also work for free customers. But that's the surface area that growth typically looks like for a SaaS company, like a bottom-up SaaS company.

Yeah. But it's very much product-driven work. Yeah. And there's very much product teams that are more focused on top-line growth.

And so we are not that like, cause we don't have a bottom-up, you know, SaaS motion and we do have, you know, pretty strong marketing function that is helping drive lead generation, right? So, and there's other businesses that have structures that look like this, like FAIR is an example where I believe the marketing and the product teams work very closely. And so I do think it's like, a, it's a new approach to marketing. Like marketing teams are not used to working in a sprint fashion. And I also think, you know, the level of rigor across marketing teams can be highly varied in terms of how they think about ROI, not just of the spend, but, you know, of investment in technology and in other places. To drive efficiency. Um, and a lot of people kind of stop at the platform metrics like cost per acquisition or, or whatever. And there's obviously a lot more, uh, that can be done to really understand end-to-end efficiency of your funnel, uh, and, uh, and understand it by segment and, and lots of things that you can leverage technology to do better. Very cool.

Yeah, I mean, I think to your point about especially in bottoms-up SaaS companies, marketing not always being a revenue driver, you know, I think of all of the crazy ads for ass products I see in like the New York subway. And like, how could you possibly understand what that is really doing for your business? Because these are random people sitting there drinking their coffee. Um, I was going to ask you a question. Uh, oh, obviously you know, you've been at, uh, RampNow for a while. You've been in growth roles before. Like, where do you typically see like technology companies, companies in general, like investing in growth? I mean, the iterative nature of things is the way like lots of early stage companies figure things out. But when do they like brand and invest in this as a function?

Yeah, great question. I, I think, uh, first and foremost, and there's obviously other people that have done this longer that, uh, have spoken about this, but, uh, I'm very much in alignment that you don't think about a growth team until you're well past product market fit. So this would be like post-Series B-ish, because I do think like the kinds of things that you have to do while you're still in like semi product market fit and like exploration discovery phase or confirming phase, because growth is really intended to be, okay, we've got a basic product working, we know people like it. How do we scale that really rapidly? Yeah. And how do we test new channels? New product ideas, new experiments, et cetera. And so if you try to have a growth model of working before you have product market fit, I don't think it leads to great results and can lead to more complication in terms of who you're serving. I think there's, you're always gonna be iterating in terms of understanding your customer's needs and how to acquire them. But I think you need to have a clear view on what your basic product is and who you're going after and have some traction there before you invest in a growth team.

Yeah, makes sense. I mean, as you're talking, I'm like, should I be investing in a growth team now? And I'm like, no, clearly not. We don't have— we're not far enough along in our journey. So, you know, you had talked a little bit about how growth folks, you know, it's a different function, they come from different types of backgrounds, right? I think it was performance marketing was the one that you pointed to, data and analytics, which is kind of where you see your background specifically. Um, and obviously everything you've been talking about is like very data-driven. There's lots of measurement. How would you do though, just, just kind of describe the way growth teams apply, you know, data, and how is that different from like you think other parts of the business might think about it?

Yeah, uh, so there's kind of two components to this, right? There's one part of, uh, component of it that's just analytical thinking, which is growth. When you're coming up with a new hypothesis, you're able to look at past data and results of experiments to help generate new hypotheses, and you're able to score the impact. So all of our projects and sprints, we score what the impact could be on whatever our North Star metric is. And so, okay, if I make this change here, test it, I think it might work because of this past experiment, and I think it might yield X or Y result. And I think just actually being intellectually rigorous in terms of scoring the ROI of your projects will help you resource allocate as a team better. And it's not about scoring the answer correctly. You're never gonna be perfectly right. It's like financial modeling, you can put whatever you want in your Excel, but there's a lot that you can't control. But the process I think really helps you even as an individual on the team just be like, okay, maybe this project is not worth my time. Cause I did the, you know, minute exercise of scoring it. So really being data fluent and understanding how to make the right estimates and do the correct calculations on our estimations on ROI is one piece of it. And then the other piece of it is, as you talked about, there's lots of different channels and lots of different surface areas that can impact growth. And so having a team and a data model that actually incorporates all that data and makes it accessible for the team to be able to, you know, whether it's backtest things or analyze things, I think is really critical. And so we had a head of analytics engineering that joined roughly around the same time as me at Ramp, which was like fortuitous timing. Like, together we've kind of like built the, the architecture, obviously driven by his team, uh, that is, uh, needed for our success, uh, at, uh, at Ramp. And some of these things are just like basics, right? Like, okay, could we— we send out emails via multiple systems today. So we've got HubSpot for one type of emails, we've got Outreach for another type, and SendGrid for, for a third type. How do we have a unified email table with like customer, you know, tied to a customer ID that like actually helps us map the customer journey that we can use to generate more ideas and as well as evaluate our performance of the various systems and ideas that we've been doing in the past. There's like one small example, but there's, you know, a lot of standard things that you need with data, which is like server-to-server integration, thinking about what conversions mean and passing that data back onto Google, Facebook.

Et cetera.

We've tightly collaborated with the, with the Analytics team as well on some standard things like multi-touch attribution and all the trade-offs there. What are different touches? What should be considered strong? How should we rate them? And how should we use actually the multi-touch attribution data to reallocate resources across marketing channels and other products? So those are just some examples of tight collaboration with data, both on building assets as well as leveraging those assets to drive experimentation.

Totally. So a couple of follow-up questions to that. So the first, when you're putting together that hypothesis, what is the form factor of that? And again, this is idiosyncratic, I know, but it sounds like that's probably some type of a requirement before you get into that sprint planning session is at least having a hypothesis with just a bit. Is that an Amazon-style doc? Is that an email to you? No. What does that look like? Yeah.

So we, we try to keep the process element relatively light because as I said, we can, we work in 2-week sprints. Obviously they're like for larger product things or product specs that are written in documents, et cetera. But for the process of our like sprint planning, we actually use Airtable for sprint planning. And each, you know, at the beginning of each 2-week period, each team will bring their quote unquote line items of tests that they wanna run during that period. And then we've got like a, a somewhat standardized format that we have some translation factors built in. They'll be like, okay, like the website team will have like, we wanna change these 3 things on this website. And we think they'll increase conversion by X%, which means like it'll drive X amount of visitors. And then we've got a calculator in the Airtable that then says that turns into X dollars of profit or whatever. Yeah.

It's kinda like that's general, the back of envelope type of, yeah.

Like, Exactly. Potentially lightweight based on something real, right? Like it's not made up numbers. Like I do think there should be some sort of justification or intuition based on past or external benchmarks. And so like the marketing teams will do the same thing. Like, you know, we're shipping a new email or we're increasing spend on a new campaign on Facebook or whatever. And so everyone's kind of working in the same line of thinking in terms of what they're trying to accomplish.

Cool. And then is that the same kind of format of like how you present and look at results as well, or what does that look like?

Yeah. So the way we do the results piece is we, all these columns are in our like very complicated Airtable, but where we have people score the projects after they're done and say, okay, like this is what actually happened. And so we've got hundreds of these experiments where we have the results Also, it's a little bit of a manual process because we don't have a unified experimentation platform today. That is something that we are thinking about. I don't know if there's one that'll work for all of the different types of experimentations that we're doing, but we are in the pro— we are about to kick off an RFP on that. And so yeah, so people will populate the results analytically after, and we do a monthly retro actually, and we go through all of the largest experiments and the teams that worked on them, present them to the whole team on. And one of the things that I often say is like, We're very happy with failure. We actually celebrate failure because from my experience working on growth teams, trying to find that growth experimentation success rate is close to 30%. 30% is good. If 30% of your experiments work in growth, that's great. And so for you to manage a team through that relatively low success rate means that you have to build a culture that prizes velocity, 'cause you need to be running a lot of experiments and also celebrates failure when there's learning. So what I always say is like, failing is good, but don't fail inconclusively, like fail conclusively, right? Like if the experiment doesn't work and you don't know like, oh, what do I do next? 'Cause like, oh, maybe I didn't like design it right. Or like there's all these concerns, that's less great, right? But if the experiment, you know, failed, so to speak, and you didn't get the results you need, but you conclusively found out that this is the tactic that doesn't work, that's a valuable learning. And that's something that we can be proud of. So we also share those at the retros. Yeah.

Are a lot of the experiments, you know, especially when you think about a failure, right? Or something that didn't like knock it outta the park, I would assume that there's lots of experiments that like build off of each other, like chained experiments, or is it more like yes or no logic decision tree type of Yeah.

I mean, and some of them are, so they're not necessarily chained experiments. They're, so we've got like two kinds of experiments typically that we see. One is like a one-off thing where it's like, okay, we're gonna change something on the website or the way we do referrals or something like that, which is like a self-contained project. But then there's others that are like, much bigger tests. Like, so for example, let's say we said, We wanna test out a multi-channel touch approach for a specific audience. So that's like a test that would take like 2, 3 months to plan. There's like, or plan and execute. And there's 5 different channel owners that have designed copy creative, et cetera. We've done some research with case studies and then have done that. And so that is considered one test, but it's actually a very big experiment that a lot of people have worked on that we can also learn from.. So it can be either.

Super interesting.

Yeah.

So you've talked a lot about kind of use of data and that, you know, there's like a close collaboration with, I think, the head of Analytics Eng who started around the same time as you. Is there anything more broadly to share about like your relationship and your team's relationship with the data team? Uh, do you report into similar parts of the org? Um, like what does peer-to-peer collab look like there?

Yeah, great question. We don't actually report in the same part of the org. We recently had a new CMO join and my organization reports into the CMO, whereas the data organization reports into the CTO. And, but having said that, we have a dedicated growth analytics engineering team whose job is to work very closely with the growth team. And we have obviously sub-teams, some of whom are more technical than others. And the engineering team joins the sprint planning sessions of those teams and weekly meeting cadences and rituals. So they're very tightly involved in what's happening on the day-to-day part of those teams. And then trying to think if you said— Yeah, hopefully that answered all of your questions.

Yeah, no, I mean, That helps. I mean, it sounds like that dedicated analytics and team though, I mean, they report up through data. It's more kind of their matrix— matrix then is wrong, but they're kind of aligned with you.

Yeah, they're like dedicated. Yeah, exactly. Yeah.

Um, and then you talked about a little bit about them joining sprint planning, so I would just assume that there's a, there's a pretty close relationship there and a lot of collaboration happening in general. Um, super, super cool. I mean, uh, you've talked a lot about your data systems, at least in passing, but when you kind of think of the systems you're using for measurement, um, and analyzing data, analyzing and consuming results, like, are there, are there any kind of big ones that are worthwhile to call out that like your team is constantly using to measure experiments or look at results?

Yeah, we, you know, some of the tools that we use are for website personalization and experiments. We use something called Mutiny. We're still doing some web experimentation via Google Optimize, which is going away. So we need to figure out the next best platform there. And then outside of that, our data stack looks pretty standard. It's like dbt plus Snowflake plus Looker. Looker is our, you know, an BI tool that we try to pipe as much of the data as possible so that it's more democratized and everyone can, can use it and play with it. And for more complex stuff, people go into Snowflake to query. And then outside of all of these, you know, we've got for product analytics, we use Amplitude and there's a bunch of platforms have their own, you know, internal analytics tools. Tools as well.

Very cool.

Um, but we try to pipe as many events as possible via Segment into our warehouse so that we can expose them via Looker for everybody's consumption. Yeah, yeah.

I would assume that most of your team is going like into Looker and self-serving that way, as opposed to being fully technical, can write SQL, and, you know, going to directly access Snowflake or anything.

A good chunk of my team can write, uh, SQL, but, uh, but yeah, but we, but we've been trying to make data as easily accessible for as many people as possible via Looker so people don't have to do that.

Yeah, makes sense. I mean, the, the folks who can write SQL, is that like a happenstance thing? Like you have these people and they, they're smart, intelligent, driven, maybe they come from a technical background so they, they know it? Or is that like, is there SQL school there? I mean, has there been SQL cross-training?

No, we don't have a formalized training program. I do think SQL is relatively easy to pick up if you have some exposure to programming or other, you know, analytical languages. Like if you did like econometrics work or math work in, you know, querying languages and data analysis languages. I like, you know, I hadn't done that in ages since college, but I, when I joined Opendoor, for example, I had to learn SQL. 'Cause it's not like somebody else was done. And typically in hyper-growth startups, it's not like there's a separate querying team or analytics team whose job is to do that stuff for you. You kind of have to be a full-stack operator. And so that's typically what I tend to find is the people that write their own queries or ones that are basically self-taught and realize that they needed to do it to be able to be effective at their jobs. Sometimes.

Yeah, no, go ahead, please. I was just gonna say is I asked because you have Looker in there and obviously there's so much you can do to self-serve via Looker without having to know SQL. I mean, that's really one of the more value props there. Uh, so I was just trying to push to understand more who then self-serves in other ways and kind of like what some of the use cases were. I would assume no one on your team has touched like the dbt project though, right?

Uh, no, that's the— we typically obviously rely on our data engineering and analytics engineering team members.

Probably a good thing. Um, uh, well, this has all been super interesting and informative for me. I mean, as I promised the, the audience that my brain was probably gonna be exploding after the conversation, and so hopefully some others are. Um, Sri, is there anything else that you think— I mean, we covered a lot of ground in 30 minutes. Is there anything else around growth teams, the way growth teams use data, anything like you think that would be worth diving into before we wrap up?

Maybe, uh, I mean, I think the, the biggest thing that all teams struggle with, and I know there's a lot of tools being built and, uh, and, and Workstream is maybe falls into this category as well, is Knowledge management and discovery is very hard. Like we as a growth team obviously do lots and lots of experiments and fortunately we have this like Airtable thing, which is somewhat semi-searchable to see what we've been working on. And then, but there are write-ups, you know, all over and there's like platform fragmentation. You know, we use Slab as well as Google Docs and just trying to find the right knowledge at the right time can be hard. And there's no kind of unified system of that. So the reason I bring this up is I think it can partially be solved by process, by forcing consolidation of tools, et cetera. But also partially maybe it's just comfort for some people to know that this is a problem that everybody faces and deals with from a challenge perspective. And I'm looking forward to the latest tool stack. Can maybe help with that.

For sure. Well, thank you for plugging that, and, uh, I'll, I'll follow up with you about that after the call, of course. Um, but, um, no, no, I'm with you, right? And we didn't really dive that much into, um, to data knowledge or knowledge management. Obviously, I think that's super important, um, and solving these problems that you mentioned around it is, is what we do. Um, I think to your point Uh, it is a process problem as well. You can solve it through process. It's a people problem. Well, I was pushing on collaboration, right? Um, uh, how do you collaborate with your data team? Uh, but also I do think it is a technology problem, and there's an element to all three of them. And I think the kind of the best, most forward-thinking, innovative teams like yours have been able to solve a lot of that through investing in the right people, by putting the right processes into place. I like how lightweight your processes are, um, but I, I do still think there's a big, uh, a tooling gap around, you know, around knowledge management. And for me, I— it feels like we're starting to get to this tipping point where, um, uh, we've laid so much groundwork more broadly around your tooling, right? Like your data tooling, your analytics tooling, all of the growth tooling that you've been mentioning, um, that these are the next sets of challenges, at least. Of course, that's my self-serving, like, idea, uh, that people are going to start to think about it and address. So I'm with you for sure. Um, well, Sri, dude, thank you so much for joining. Uh, this has been awesome, uh, as always, especially you and your 50 shades of orange today. And, uh, if, uh Uh, if folks have questions for you, just leave them like on LinkedIn, uh, in the comments, and, uh, we'll try to get back to folks. And yeah, man, let's, uh, let's get together in New York, uh, at some point soon.

Sounds great. Thank you. All right, thanks.

Thank you everyone.

Bye.