Austin Hay: evaluation

Transcript context

…I like this. Okay, so I've already said this and you've promised to put this at the top of the list, so I'm really excited. It's just tools are meant to solve problems and I tell that to every person I hire. I repeat it consistently at Ramp and all of my consulting gigs. And it's not just the words, it's the spirit of it. Tools are really just meant to solve problems. You don't have to buy a tool to solve the problem. You also don't have to buy a specific tool to solve the problem. And I think it embodies so much of what marketing technology is trying to do. It's trying to help people understand their problems and then actually take action on them using tools and technology that are most first party and third party. And most people just focus on the tool part and focus on the buying and integration part. And so I think if you consistently remind yourself that tools are just meant to solve problems, then you really get into a space where you as a systems' person can be an advocate for your marketer or your product people. I think sometimes there is a little bit of a tendency for people to think that people who manage and set up tools are just interested in managing and setting up tools, but really at the end of the day, we're trying to help people actually do stuff. Then there's this PPS framework that I talk about a lot, which is problem, people and system. So, whenever there's a challenge that comes up like at Ramp or in a consulting gig, I like to first say what's the problem? Who are the people involved and what system does it impact? Usually because people just jump straight to the system. They're like, hey, there's this problem, I just need to solve it with the tool. Hey, I'm trying to do X, Y, and Z. Can you just give me admin permission straight to the system? So, if you back up though first you understand the problem like, hey, what is this person trying to solve? What is their discreet issue? A great example is I'm a sales manager and I want to make it so that every time I hire somebody, I don't have to go through this really tough process of onboarding my staff. All right, so that's the problem. Who are the people that involves, does the sales manager need permission from the CRO? Do the sellers need to be trained? Is there some other confounding factor that we're not aware of why we don't want to just automate this thing? Once you have an understanding of the people and the problems that you're trying to solve, then it's really, really easy to design the system to solve that. And so that's my number one framework for technologists in particular is like don't just jump to the system, think backwards, start with the people and the problem and then move to the system solution. And then another one that I've already mentioned too is it's B and B as opposed to BVB. So, build and buy as opposed to build versus buy. e people and the problem and then move to the system solution. And then another one that I've already mentioned too is it's B and B as opposed to BVB. So, build and buy as opposed to build versus buy. People all the time just think the second that you're talking about implementing a tool or procuring a solution, it's, Hey, I want to build this thing or I want to buy this really expensive thing. Build versus buy is a very narrowly constricting decision tree. If it's only build versus buy, then you've already made the decision that you can only do one or the other, which means you're already fighting somebody at your organization. Build and buy means that both of you can win and you can actually create a solution that is not only unique but saves the company time and resources and makes everybody happy. It's more of a consensus driven approach. Whenever I hear in a meeting or a call or some discussion about how we have a tool and it's really expensive and we want to build in herself, I try to just use the build and buy framework to tee people up and say, what about the problem? Can we buy? What about the problem can we build? And where does it make sense to invest our resources and our people accordingly to get the optimal outcome? A great example is a company that I was consulting for was thinking about building their own AB testing tool. And actually we had the same problem at Ramp recently, and they're like, well, we just think we should build ourself. This is core to our technology. We have the engineering resources to do it. And they were evaluating it to build the entire system themselves or buy a third party, I think it was split.io or something like that. And the entire engagement was basically designing a financial model to show them that they could make a lot more money, save money, move faster if they just bought the third party tool at the lowest possible cost and spent all of their resources that they were going to spend building it, building around it and making it their own. And there's lots of, I hate the word synergy, it's just so yucky.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.