Episode 7
· 42:32
Welcome to Beyond the Pipeline Podcast. I'm your host, Vivin, and I will be in conversation with leaders in ops, marketing, and sales to unpack some cool stuff in the rev ops space and about how ops helps in building a healthy and a sustainable pipeline. Welcome to the 7th episode of beyond the pipeline podcast. Today's episode is all about getting reporting right in B2B SaaS companies. We've all come a long way when it comes to reporting, thanks to some cutting edge tech out there.
Host - Vivin:But like anything else, it's not the tech, but the people and the process behind the tech that really determine if you're getting the right data and the right insight. To discuss this with me today is Justin Norris, director of marketing ops at 360 Learning and host of the much acclaimed RevOps FM podcast. This is a topic that I'm sure a lot of you all in ops would relate to. I certainly did, and it's definitely helped me structure a lot of my thinking around building reports. Let's get right into it.
Host - Vivin:Justin, welcome to the show.
Guest - Justin:So glad to be here, Vivint. Thank you for having me.
Host - Vivin:Yeah. My pleasure. Justin, like every other episode, I start off with a question which is not really the topic. And and the question is very simple is, how did you end up in operations? Right?
Host - Vivin:And and it's it's a story that is unique for every guest, and would love to hear your part as well.
Guest - Justin:I think like many operations folks, I ended up here accidentally. I was an English major by trade and learned fairly quickly that, there you have limited options outside of academia with English in terms of, you know, a set career path that it prepares you for. So I went into copywriting. I thought I'd try my hand at business copywriting, and from there, got into marketing. I was very interested in marketing, the psychological aspect, understanding customers.
Guest - Justin:So really grounded myself in that. And then moved into a start up where I was the 3rd employee, the first marketing hire, and really wearing all the hats from a marketing point of view. You know, reskin the the product, helped hire STRs, tooling, systems, demand gen channels. So I was doing it all, which was a great sort of boot camp and education and all of the fundamentals of marketing. But I found that I kept being inclined towards systems.
Guest - Justin:You know, like, I just love getting my hands on tools. Got my 1st Marketo instance. This was, you know, well over, it was 13 years ago now, I would say. And just really was was drawn in that area. Even though operations, marketing operations at least wasn't even a thing that I could articulate at that time.
Guest - Justin:But I kinda fell into it that way. And then at a certain point in time, you know, you hit a threshold of, like, how much you can contribute within the organization that you're in, within the place that you're in. So at that point in time, I said, let me go over to the consulting side and, and really specialize at this, which I did for about 7 years. And then at another point in time, I was like, actually, no. I'd like to be closer to the business again.
Guest - Justin:So move back in house from there.
Host - Vivin:Got it. Yeah. I think I think one thing that's common is everyone starts off in a start up doing everything where operations is just one part, and that's how they stumble upon operations. And that's how I did as well, where you end up doing everything, operations is just a part, and then you see the amount of gains that you can do with and, actually, operations is one area that not really everyone wants to get into, and, you know, I think it solves a lot of problems. These are problems that no one else wants to solve and you probably wanna get into and, you know, start looking at tools, processes, and start solving them.
Host - Vivin:And that's that's what really got me into operations.
Guest - Justin:And how else do you know? I mean, I I I do think that's the great thing about being in a start up is that, you really have no idea when you start your career, start working, like, what you actually like. You might have some thoughts. Maybe some people have a set career path, like doctor, lawyer, accountant, or whatever. But if you're just in this general mix of business y stuff, until you try your hand at things, you don't really know what you love love doing, and then you find those things.
Guest - Justin:So Absolutely. Yeah. It's great to have that opportunity.
Host - Vivin:Alright. So moving on to the topic of the day, Justin, which is reporting in b two b SaaS companies. And, you know, I think there's no doubt that data and reports, they're paramount when it comes to making decisions in any organization, not just b to b SaaS companies. But I feel like nowadays, there is a lot of data and reports being thrown around. I feel like there's almost like an information overload or maybe, you know, what do we call, like, a reporting fatigue.
Host - Vivin:When do you think this sets in? And in my personal opinion, I've seen this in, you know, early stage companies where you have to go to 2, 3 tools to find your reports. You have multiple teams coming in with different standards of reports, and, you don't really have a single repository. And even to get the easiest of answers, it becomes very difficult. Right?
Host - Vivin:So do you see reporting fatigue setting in? And when do you think or when do you put a stop to generating reports day in and day out?
Guest - Justin:I don't think we can ever stop the the generating of reports, but I think the way that we communicate and share that information within the company, can have a big impact on that that feeling of fatigue. I'm an English major, as I said, so I am not a person who can look at a dense slide covered with KPIs and just, like, understand it instantly. I can I can find my way, but it takes an effort for me? I work with people who can look at those dense slides and be like, oh, yeah, and and see it. And I I envy that ability.
Guest - Justin:But it takes effort for me. But I I think even for most general business consumers, that approach of just, like, dense KPIs slide after slide after slide, We go to sleep. It's very boring. It isn't helpful, typically. There's no sense of priority or hierarchy, to information a lot of the time.
Guest - Justin:There's a a long time very well known data thought leader, Avinash Kaushik, who worked for Google or maybe still does. He talks a lot about data puking, where you just like and and it's sort of a disgusting analogy, but it's it's accurate. So I think the job of the skilled analyst or or the business communicator is to create that story around the data. Mhmm. And I I almost liken it to archaeology.
Guest - Justin:Because if you think about archaeology, you know, we go into the ground or we look at all sorts of, different data points, ice cores, pollen samples. There's lots of different things you can look at in archaeology. But you you start with those facts, and then you need to paint a picture. And if you think about, like, National Geographic documentaries or those sorts of documentaries that are made for a mass audience, They do a really good job, not necessarily, the accuracy of of how they interpret facts I'm talking about here, but just creating a story that the average person can get into and can understand, or at least that vision or that picture of the past. So I think I would liken that to what the analyst or the business communicator needs to do with their data to tell that story, focus on a few core KPIs.
Guest - Justin:You can do a deeper dive into things to illustrate a problem or or highlight how you arrived at something, but it has to have that story telling framework in mind. And when I think of the people that I work with that are the most effective at doing this, my boss is really good at it, our head of marketing. Her background is product marketing, you know, so storytelling. Or our COO, he's from management consulting. He former McKinsey.
Guest - Justin:So, again, very strong on communication. So I think it's that is the ability that's critical, and that can then alleviate that fatigue. Because I think the fatigue comes from just being bombarded by numbers without context, without story.
Host - Vivin:Yeah. Absolutely. I think that also connects to the way an ops person grows. Right? Because if all you're doing is creating reports on Hub Spot and Salesforce and just giving it to people to, you know, analyze and get insights out of it, you're just being the person who builds those reports and not able to analyze them.
Host - Vivin:Right? And I think that's also like, anyone who's out there listening, I think if you're not able to analyze or give stories out of the data that you're preparing for your team, I think that just keeps you at a very low level at ops. I think the next level of ops where you need to really build is you know, creating those docs where you really have a story built out and sharing those with the consumers of the report, mostly leadership. And if they do have doubts, then the second level could be the raw data that they probably want to dive into and get more insights on. I think, yeah, I mean, that's a great call out, and I think that's something that I've learned over due course of time as well.
Host - Vivin:Alright. So, Duston, I think the next bit that I really want to get to is as ops folks, all of us get hit with a lot of requests from across different teams, right, especially within marketing, especially if you're in marketing ops. You have content reaching out. You may have the digital team reaching out to you and a lot of other teams reaching out to you to prove ROI of their efforts and initiatives. And that's okay.
Host - Vivin:Right? Because as ops folks, you're the center of the platforms and systems and reporting, and that's okay for people to reach out. But I feel like some reporting might be very impulsive in nature. Right? Someone somewhere is probably talking about, hey.
Host - Vivin:You know? This data point would be really great to have. And that data you need or that request immediately hits ops, and ops starts working on it. Now these impulsive or these reports that are used one time and then never used again, impulsive reports that are probably required at that point in time and not even looked at when the report is shared. As an ops person, what are the right kind of questions you should ideally be asking to filter the request that come through.
Host - Vivin:Right? Is it even worth your time to be looking at all the reporting requests that comes through?
Guest - Justin:Yeah. It's a good question. I think there's different types of requests, and it's important to understand sort of what, domain of the business the request is related to. So one of the the core things we all have as a business, right, is this operational rhythm of, regular repeatable reporting, like things like funnel metrics, channel performance, revenue Yeah. That happens, you know, on a weekly, biweekly, monthly, whatever cadence.
Guest - Justin:And those things should really be standardized, and they should have, you know, the right drills so you can go in deeper into the information. And you don't want those things changing too regularly because I think the predictability and the familiarity there is important. So that type of reporting, I think of it as a product in the sense that, it is something that ops builds and maintains for the organization. It has new features. So maybe it's a feature request for that product.
Guest - Justin:So in that case, it's, you know, how how important is it? How urgent are we actually going to use it? You know, you you stress test it in all those ways, and should it be incorporated into that product. The second way I might think about it is or the second sort of domain that a request could relate to in my mind is performance management. So this is a case where something is wrong, something is broken in the revenue engine.
Guest - Justin:It needs to be fixed, and the team is digging deeper than than usual to try to isolate that problem. And this is an area where I think, at least at the scale of organization that I typically work at, like the the start up scale up space, you want to be very reactive. You don't want to stand in the way and be, you know, you know, we're behind on opportunities this month on pipeline, but I don't think I can you know, it's it's not a it's not a good look. It's not a good career move. I don't think it's the right business decision.
Guest - Justin:We're behind it has to be a hands on deck or all hands on deck solution. And then ideally, these can become standardized over time. So as you go through that routine a few times, say, alright, if performance is down, this is the 20 step process that we follow. We look, you know, we navigate down through all the different layers of the funnel, And so we can standardize those reports as well, and make those less ad hoc. And then I guess the 3rd domain or the 3rd type of request is more, I think, kinda like what you were alluding to in your question, kinda innovation type requests.
Guest - Justin:These are like the the what if or I wonder or we're blue skying it. There are new initiatives. There are new ideas. And those can have a wide range of urgency and impact associated with them. Could be a report that maybe never gets even looked at.
Guest - Justin:By the time it's built, the person's already moved on in their mind to something else. And so you you do need to be really rigorous there, like you said, to evaluate that. And I would look at, you know, time line. Is this is there an upcoming event? And we wanna pull a report of a certain type of prospect that's at that event so we can do some outreach, and there's a very specific need associated with it that has a clear outcome.
Guest - Justin:Makes sense. If it's just like a general what if, it's hard to understand, who's asking for it plays into it quite frankly. There's there's always that aspect that needs to be considered. But ultimately, you know, you you you perform some kind of impact analysis. What decisions are we gonna make?
Guest - Justin:What activities are we gonna do as a result of that info? And then if it can't be done right away, you know, you don't have to say no, but you can backlog it. And quite often, that backlogging is a forcing function by the time you get back to it. Like, hey. Is this still relevant?
Guest - Justin:And the people like, actually, no. I'm I'm good. So sometimes that allowing it to mature a little bit can be helpful.
Host - Vivin:Yeah. I got it. And I think, you to your point where, you know, you end up saying no or, let's say, deprioritizing it for some reason or the other, right, I think enabling self serve reporting is is also a great way to ensure that I mean, it's a win win situation for both parties. Right? Because, one, it reduces dependencies and ops.
Host - Vivin:2nd, you get your data faster to get moving. Right? And while, you know, self-service is great for both the sides, I think it's mostly on ops to enable that, right, in order to make sure that and and a lot of things practically, what I've seen is people are not really good with tools, and it's not their fault. Right? Maybe the tool by itself is intuitive, But the way that you've set up the data architecture within the tool might be so complex that it's probably hard for people to understand which property do I need to pull, which object is it that I need to create, what kind of report types I have.
Host - Vivin:It becomes very difficult for a very normal person who's probably used bare minimum of the tool to understand how to create reports or how to look at data within the tool. Right? So what would be, let's say you know, and it mostly comes down to enablement. But if you do want to start, if you're just stepping into a company, you wanna start enabling users to do many things on their own, including reporting, where do you start in terms of enablement?
Guest - Justin:Yeah. It's such a big question. I mean, I agree with you that self serve is the ideal, particularly for more mature users. What you want to avoid, I don't know if you have those, self checkout things at the grocery store, you know, where they have where you you have just like a screen, and as a a shopper, grocery shopper, you can just, like, check your own items, bag your own items. The challenge I see with those is that they're always breaking.
Guest - Justin:They're never working quite well, and so there's always, like, a a store employee there that's constantly having to go between the different self checkout things and, like, help people. They're frustrated. Yeah. So it's, like, we're trying to self serve, but ultimately, probably they're still saving some time. And if you just have 1 or 2 items, it's fine.
Guest - Justin:But they're not fun to use, and they're frustrating. And it still involves a lot of time from the employee in that case to go around and solve problems and, you know, resolve issues. So you have to make sure that whatever system you're setting up actually does enable true, self-service. And you have to know what is the escalation point where you bring in an analyst or the data team or or some resource above that when the self serve is inappropriate. The the few things I think about in terms of actually enabling that to happen.
Guest - Justin:So number 1 is, like, where do you do it? I I don't know if this is a controversial take or not, but a lot of people like to rag on Salesforce reporting. But I I think it has one of the most powerful reporting engines that's ever built. A lot of organizations, these are the ones that I've worked with, are on Salesforce. I think that is probably the ideal starting point for for self serve.
Guest - Justin:You know, I've worked with, like, tools like Looker on and off for more than 10 years. I've yet to see one where, anyone beyond, you know, an analyst type profile could use it comfortably. Just something to do with bumping into limitations. There's still the interface feels technical. Even most salespeople or sales leaders can create a Salesforce report.
Guest - Justin:Plus, you're close to the data. That's another key point. If you ever had the experience, like, looking at a report and you're like, I wanna see what's behind that number, and you click and, like, nothing happens. It's a very frustrating feeling. In Salesforce, usually, everything is drillable.
Guest - Justin:You can go down to the row level. You have that trust that I understand what this data is comprised of. You users are already working there. You can go into a record and take actions. The gap between action and insight is very close.
Guest - Justin:So I actually start there, at least for most organizations. Obviously, there's limitations in terms of bringing in other data. And so then there's, like, the hard skills aspect, like, how do I build a Salesforce report? Report? And I think that's the easiest part of the problem to solve, because there's Trailhead courses.
Guest - Justin:People can learn how to do that. The challenge beyond that, and you touched on it, is understanding the data that you're actually working with. And this one is definitely, well, there's some shared responsibility, but I think this is an ops problem. We need to get those irrelevant fields out there. You know, most people work in a Salesforce org that's now over 10 years old.
Guest - Justin:I do. And, again, the archaeology example, you know, there's different layers. Like, you can almost see fields related to different periods of the business where people had a certain idea or vision of how they wanted to operate. They created fields for that, and then they changed their minds 3 or 4 years later. New people came in.
Guest - Justin:They created other fields. And so all that history is just there. And if you're a user that's like, I don't know, region or number of employees or country, like, you can have, like, 6 different fields for each of those data points. No idea how they're populated. No idea where the data comes from.
Guest - Justin:No idea which one is accurate or not. So we need to do our job and clean that up. We need to ensure that labels are up to date. Like I work for a French company, so some of the older fields, the labels are actually in French. I can figure it out.
Guest - Justin:I can translate them, but there's significant friction there. So having up to date labels Yeah. Clear nomenclature, description fields, help fields, having that actually populated. Our team now does a great job of whenever a new field is created, they will link in the description field back to the original request so we can get all that business context, surrounding that field. And and ultimately, having a glossary for users.
Guest - Justin:And then knowing how to filter as well is, like, the next thing. And and and this is the risk with self reporting. You've probably seen this too, where like 5 different users, like, create different reports, and they're like, hey, my report is broken. It doesn't add up. And of course, it's because they've all filtered on region in a slightly different way or filtered by a team or
Host - Vivin:Yeah.
Guest - Justin:They don't know how to identify new versus repeat business in the same way or opportunities credited to marketing or sales in the same way. So I think the distillation of that is if your data is a mess, nothing works. And then creating, like, a safe environment where everything's kind of labeled, everything is clear, and then just, you know, enabling the users on the tool, which I think is the easiest part.
Host - Vivin:Got it. And and the other thing that I would probably add is a lot of the requests that I get is possibly already a report when the request comes in, just that the person is not aware that the report already exists that addresses the same use case. Right? So I think just like a data glossary, you could probably have a report defining what each report does.
Guest - Justin:Absolutely. We just I just wanna I just, built that as I my colleagues on the sales upside, they had created, like, a reporting library, which I thought was an amazing idea. So we just did that for the BDR side. And, yeah, it creates that clarity of, like, here are the list of reports. Here's what we maintain.
Guest - Justin:Here's what we are responsible for. You go build something else, that's great, but we can't, you know, we can't own the the accuracy of that.
Host - Vivin:Yeah. Got it. And to your point where you were talking about, you know, building dashboards and reports out of platforms like Local Studio or Tableau, you know, sure, it's not something that you can double click into and, you know, figure out what's underneath the data. But do you think at what point do you think a company can move from, let's say, system related reporting like HubSpot, Salesforce into a more complex system of Snowflake, Fivetran, Tableau, you know, all the SQLs, do you think it's an upgrade or a downgrade, Or at what maturity level do you think a company should probably think of moving into a more complex reporting system?
Guest - Justin:I think it probably has still has to happen at a relatively early stage because despite all the great things that I just said about, Salesforce reporting, you inevitably do run into limitations, whether that's with the data model or your product data that you wanna splice it with is not there. And you don't honestly wanna be pushing all of that data into Salesforce. So I think it's probably as early as you can get the skill set internally to build and maintain that infrastructure, which realistically might be around 100 people, if not a little bit earlier. It's never been easier to build out that stack. I mean, you can literally go in less than a day and spin up Fivetran and Snowflake and Tableau.
Guest - Justin:Spend a bit of money, but you can get it all going and start bringing in data and and stitching it together. Like, it's just never been easier to do that. And that was not the case, like, 8 years ago, 8 or 9 years ago. And I remember really thinking about, like, oh, I just because I was in the consulting side. I would love if we could offer, like, a cloud based completely cloud based sort of BI solution.
Guest - Justin:And those tools were kinda out there, but it was not nearly as common as it is right now. But you need you need that maturity to be able to to be able to build those reports. And and so probably, the way I think of it, if we come back to, like, the different domains, the operational rhythm reporting in those dashboards, probably living off of the warehouse and living in Snowflake. And some ad hoc reporting potentially, there, but more often than not for, like, truly new sorts of requests, I think bringing it back to, to systems. And then having a data governance process and and team and sort of counsel that makes sure that the data is clean and consistent between systems.
Host - Vivin:Got it. It. Got it. And and just one question is, how important do you think it is for ops folks to know languages like SQL and, you know, learning how to use visualization tools? You know, I'm pretty sure there are a lot of data analysts who's going to be, you know, there helping you out with these, but do you think it adds on to your skill as an ops professional to be knowing those languages?
Guest - Justin:I mean, I I definitely do. Guess, I don't think it's that important, because I don't really know SQL myself. I know it, like, well enough that every time I need to do something, I'll go and, like, Google it. I guess now I would use chat gpt to write the SQL query for me. So, but I all those all those skills are an asset.
Guest - Justin:All those skills make you, more dangerous. I think it I think it just depends at what level you wanna work at. And you may find this is the same. I'm curious if you relate to this, I guess. But I have always found that I flex to fill gaps that are around me.
Guest - Justin:So if we're like, oh, we need to do this thing, and and nobody knows how to do it. Like, they're like, okay. I'll I will figure that out. But right now, I have a strong data team that I work with. I have no need and no incentive, really.
Guest - Justin:And and perhaps at the stage of the career that I'm at, it's not, like, my main focus to be adding that on to my, my resume. But, yes, I absolutely think it's an asset. But maybe maybe it becomes less necessary, perhaps, with the rise of, like, AI and tools and things like that where you might be able to, like Yeah. Structure your data with natural language queries.
Host - Vivin:Yeah. Yeah. Yeah. I mean, as absolutely relate to that part where, you know, there is a gap that you probably have to depend on some other team to fill. And and that's something that drives me to start learning.
Host - Vivin:I mean, I didn't know SQL until very recently when I had to depend on an agency or someone else to help me out with certain queries, but then I every time I had to reach out to them, it was a pain because the lead time to turn things around, making them understand the business part of, what you're really trying to achieve because they're coming in only with the tech skill. Right? So I think the fact that you understand the business with some skills in terms of tech, I mean, might be a very basic SQL skill, but I think it really helps you in, you know, turn things around faster and also have the context about the business while you're, you know, bringing in those technical skills.
Guest - Justin:Necessity is the mother of invention. Right? You do what you need to do.
Host - Vivin:Yes. Absolutely. Like, I think the next topic is is something that I've thought about quite a lot, and I think I've experienced this in my previous roles as well, is is about biases when it comes to reporting. Right? And these these might not be biases that you really want to bring in into your reports, and some common kind of biases that I see is, you know, this is you know?
Host - Vivin:And data is something that is is basically based on who's building up the report. Right? If I want to prove something right, and I think it's called the confirmation bias, if I'm not wrong. But if I really want to make sure that a campaign looks pretty in the eyes of the leadership, I can do it irrespective if the core data proves wrong. There's always a way that you can possibly make a data point look better than it is.
Host - Vivin:And there are different ways to weave data around how you're trying to save the story just like you said, and you can build a story around how your campaign worked out really well. Right? And I've done it in my previous role as a program manager where I wanted to make sure that, you know, my numbers are coming out right. You're not fudging data. You're not faking data, but you could still say it in a very different way, which looks pretty.
Host - Vivin:Right? As an ops person, I think it's very important to make sure that you don't take sides. You need to bring out the actual picture because it helps everyone around it. It helps you take the right decisions. It helps, the leadership understand what's actually happening on ground.
Host - Vivin:Right? How do you, as an ops person, how do you make sure that these biases don't creep in, and how do you make sure the right kind of data is being presented?
Guest - Justin:Yeah. We're all biased, like you said. Right? And Yeah. I mean, it's so funny.
Guest - Justin:Look at any social, political issue today, and everybody has data to support. You know, you can find data about why you should eat meat. You should find data about why you shouldn't eat meat. You should find you know, every almost every topic. There's people on both sides, and they all have their data, and they all have their data points.
Guest - Justin:And I think the most important thing is cultural. And it's you as an ops person can influence it, but honestly, it goes beyond just ops. It's do we have a commitment as a company to objectivity, to rationality, to understanding reality? And and is there an ability to put forward different points of view and to dissent without consequences? And I think if you have that Yeah.
Guest - Justin:It doesn't mean that you necessarily don't have bias, but it means that you have a, like, a dialectical process through which people can challenge each other. So I don't know. This assumption doesn't seem right. What about this? What about that?
Guest - Justin:And you can work towards a shared and hopefully more accurate picture of reality. If you don't have that, culturally, you're gonna be in trouble because you're gonna be the person saying, what about this? What about that? And then you're gonna get shut down by the c x o whatever or by the CEO who's only interested in hearing the thing that supports her his point of view. So finding a company that has that, I think is is really important.
Guest - Justin:You gotta choose the environment that you work in to the extent that you can. Not everybody can these days, it's hard. But to the extent that you can, choose where you're gonna invest your time. I feel really fortunate that, you know, rationality is a big part of, the values and the work methodology where I work. Doesn't mean we always agree, but you're everyone is free to, like, put forward that, that point of view and and to put forward, like, a fact based perspective on why they see things the way they do.
Guest - Justin:I think the cognitive bias tends to be in the so what, because the the metrics usually are are pretty factual. Like, we have so many leads. We have so many opportunities. Is this good or bad? Like, what are the consequences?
Guest - Justin:Sometimes a KPI can rise or fall, and someone may make a big deal out of something and start like a fire alarm. And you're like, well, actually, if we look at it in context, the drop is not meaningful. It's not statistically significant. So reasonable people can disagree, I think is the other thing. But we need to have that that back and forth process to kinda sharpen the sword and figure out what, truth is as much as we can.
Host - Vivin:Yeah. Absolutely. I agree. I think the part of culture that you're saying, I think the bias creeps in because you're probably you probably have an unconscious feeling that, hey. If I don't show data which looks good for a particular campaign, I get shot down.
Host - Vivin:And because of that fear, you end up probably looking for data that makes your campaign look good or anything that basically looks good. The other part is, and I've I've kind of felt this in in a lot of companies, is about the way that ops team report the reporting structure of ops teams. Right? Because when ops team is aligned to marketing sorry. Marketing ops is aligned to marketing.
Host - Vivin:Sales ops is aligned to sales, and you have a pipeline problem where you're probably dipping in almost all metrics. Marketing comes up with a story which makes marketing low score saying that, hey. You know what? You've done this right, and I think the sales efficiency is going down. And sales ops comes with a different version of the story saying that marketing is probably not giving us good quality leads.
Host - Vivin:Right? So I think the reporting structure and I I probably don't have an answer here, but I think the reporting structure for ops teams probably falls apart there where you're take taking sides, and maybe that's where a central ops team or a central structure where ops reports into a CRO, and then you're looking at a holistic view of the organization or the pipeline and not taking sides. Do you have a comment there in terms of structure possibly taking a say in in these biases?
Guest - Justin:Yeah. I mean, they it absolutely does. The first thing I'll say and just your point about, like, everybody wants to report data that makes them look good. I think that's true. But there's a weird, like, career hack that I've noticed where you can actually build a lot of credibility and trust by reporting data that makes you look I wanna say makes you look bad, but that isn't favorable to you.
Guest - Justin:Obviously, you don't wanna, like, show up and be like, you know, I'm I'm an idiot. I don't know what I'm doing. It's more just if you're running a a program and it's not going well, then step being the first person to step up and say, like, we are behind. Here's my analysis. Here's why.
Guest - Justin:That builds so much trust because everyone if someone is just constantly the good news and I can do no wrong, are you really gonna trust that person? You know, whereas if we all know that nothing is perfect, but if someone steps up to the plate and takes accountability, accountability and responsibility goes so so far. So I think, you know, building a culture where that's normalized is great, and that alleviates a lot of that pressure to be like, I'm right. I'm right. We're good.
Guest - Justin:You're bad. You know, that very immature, behavior in my opinion.
Host - Vivin:Yeah.
Guest - Justin:And then, you know, coming into, like, how like, the different teams, certainly, unification helps. And I am I am a big believer in that. But I don't work in a centralized ops structure myself, And we don't have that problem, I think, because in part commitment to rationality and then shared, systems, shared data models. You know? Yeah.
Guest - Justin:If if I'm reporting out of, like, Marketo that has a different data model and a different view of the world than what my sales team and sales ops counterparts use, then we're not gonna ever see eye to eye. I think when it comes to core business metrics, we have those standardized. And so at that point, there really is one version of the truth in terms of the facts. The interpretation can vary. But I think in in in my experience, and maybe I'm fortunate, like, we are hardest on our ourselves.
Guest - Justin:And I think that's really how it should be rather than trying to avoid accountability. So, again, you know, cultural. I think a lot of it starts there the more that we we talk about that.
Host - Vivin:Got it. Yep. Yep. Makes sense. And I think what you also alluded to data and insights, every company has data, and every company has a team that basically being able to make changes based on those insights and also create a feedback loop between the data team and the team that really needs to take action on those insights.
Host - Vivin:Have you been in any situations where you ask for accountability on the insights that you generate. Right? It can't be just that we keep generating these insights. You don't see any action. You don't see any feedback loop in terms of what has happened from those insights and what more data is required to make those insights more crispy in order to, you know, make sure that the follow-up action works out well.
Host - Vivin:Have you encountered any situation like that, or have you set up a feedback loop anytime during your career?
Guest - Justin:Yeah. Definitely. I think this is the single most critical issue. I mean there's many critical issues, but without this part, this taking action, we don't have any impact. It's all kind of a waste of time.
Guest - Justin:So it takes us to the heart of the matter and and what are the roles and responsibilities within that process. I think that prioritization is a really important piece here, like, coming back to that reporting fatigue question because, you know, we live in this universe of infinite information. There's so many different data points we could look at. And if you have too many things, you won't take action on any of it. It's like, oh, this is interesting and that's interesting and that, like, you're kinda, like, wandering around in a data haze.
Guest - Justin:One of the techniques I learned it from my COO, but I think it's it's a technique that's around there. It's this notion of a KPI tree, where you look at, like, what's, like, the core things we're trying to do as a business. We're trying to produce revenue. Alright. What are the the key things that lead to revenues?
Guest - Justin:Like, we have so many leads, so many opportunities, so many close won opportunities. And then you, like, continue to break those down. Like, well, what leads to an opportunity? It's like, well, did we follow-up with the lead? Did we have a meeting?
Guest - Justin:Did the they attend the meeting. Did the and you keep breaking it down, breaking it down. And you end up with all the KPIs that are actually, you know, directly related to those core things in kind of a logical sequence and in a logical hierarchy. Once you have identified that these are the KPIs that actually matter, doesn't mean that there's nothing else that's potentially interesting, but these are the ones that we need to really own to make this business work. Then there's an accountability process.
Guest - Justin:And I think we've all had the frustrating experience of, like, trying to do this in an ad hoc way. But I think if it's structured in the sense that, like, where you have regular meetings, where, like, if you gotta stand up in front of your peers as an executive or as a leader of some kind of manager and say, like, yes, I did this or didn't do that. That's the sort of thing that motivates people to act. Or if their boss is talking about it in a 1 on 1 or if they have to present on it at an all hands. So, again, culture building that culture of shared accountability and a regular business readout of those core KPIs.
Guest - Justin:We actually have a philosophy, to some extent of, like, manual reporting, which again is counterintuitive, but, like, having people fill out spreadsheets of of things. It's like, why we have the the tool here. Why not just, you know but in doing that, it brings people closer to their data. It forces them, creates a certain friction that you want to force people to look at certain KPIs. But, yeah, there's still frustrating situations, and the functional business owners need to own the action, but I think ops can be a forcing function.
Guest - Justin:And that's another way that ops can, you know, like you said, elevate yourself from just being like the reporting desk where it's, like, here's your report, kinda like delivering a pizza, and being a more strategic, more impact oriented function. Say, hey, what did we do with this? Is this KPI moving? Are we taking this action? It's a really powerful shift I found.
Host - Vivin:Got it. And I think even even when it comes to ops teams, like you said, right, if you're able to nail down your KPIs, what matters to the business the most, and you gear your insights towards those KPIs or those core metrics that matter, then you can also prioritize your insights or your effort in finding insights that affect those outcomes the most. Right? Because any insight is not worth acting upon. Right?
Host - Vivin:You might have an insight, which is probably great, but if it doesn't impact directly those core metrics or KPIs that you're after, then you're probably, you know, wasting your effort in finding those insights. So I think that's also one way to maybe prioritize the way that you look at data or the insights that you're trying to find.
Guest - Justin:Yeah. That's totally true.
Host - Vivin:Yeah. And and I think, we'd definitely be missing out at you know, especially since we're talking about reporting and if we miss out on this topic, which is the single source of truth. I think everyone talks about this. Everyone chases this, but very rarely have I found someone finally saying that, hey. You know what?
Host - Vivin:We have a single source of truth. In your experience, is that even worth an effort? Sure. I mean, you probably don't want to navigate between, you know, 5 to 6 different tools to get data. But, honestly, I feel there's always going to be some level of data that you probably have to manually report or go through, let's say, x number of tools to find.
Host - Vivin:But what's what's the best balance there, our like you say, I mean, is is there a way to do this, in a frictionless way?
Guest - Justin:The answer is probably a bit different at different stages of a company. Right? Like, I've never tried to create a a single source of truth at, like, a 10,000 person company or a 100,000 person company. So we're talking probably completely different challenges. In the context of, like, sub sub 5000, sub 1000, I don't know what the the number is, but a company of that size.
Guest - Justin:I think it's an achievable thing, but it kind of depends on what we mean. If we mean the single source of truth that's gonna answer, you know, the be the magic 8 ball that answers any question that we ever have and every data point we could ever possibly want is there. And we will never need to look at another source tool. It's probably not realistically achievable. By which I mean, like, yeah, you could do it, but the cost and effort of doing it would be way, way, way outweigh the benefit.
Guest - Justin:So I think coming back to, like, what are, like, the different domains of reporting, you know, the operational rhythm, troubleshooting, and then more innovation. Things that are operational rhythm definitely be in the source of the single source of truth. And, again, it's never been easier to do that on a technical level. Get Fivetran, get your Snowflake, get your Tableau or your Looker. You're off to the races.
Guest - Justin:You can pay with a credit card. Where it gets sticky and where it gets challenging is the definitions, is the enablement of people on how to use that. The rigidity of data warehouses where every new question that is not already baked in now requires data teamwork. Oh, we've got to build that into our data model. We've got to write that query.
Guest - Justin:We've got to you know, so with that power comes a certain rigidity. I've yet to see a system that just can, like, suck in data and then provide unlimited flexibility and, like, you know, effortlessly stitch together those relationships. And maybe we're gonna get there, like, get closer to that. But today, my experience, even trying to do something as simple as blending SalesLoft data and Salesforce data to say, like, I wanna, like, bring in all the activities and stuff from SalesLoft, and then I wanna bring all the, all the opportunity information in from Salesforce. Even that can, like, be such a big project because there are subtle differences in how, you know, oh, a meeting over here is like this and a meeting over here is like that.
Guest - Justin:APIs are not all completely consistent or logical. So, oh, we can't filter this like this. So now we've gotta, like, suck in everything and then go to this other endpoint and get this other data point and then filter it by that. And so again, it's all doable, but you're spending money in human time by doing this. So, yes, a single source of truth, but for what?
Guest - Justin:And you have to, like, you have to make hard choices and prioritize what you want there. And where you say, actually, we're just gonna report on this out of the source, system, the, like, the the point tool, and that's okay.
Host - Vivin:Alright. So, Justin, I think that brings to the end of the segment. We'd love to probably ask you a few more questions, but I think that's the time that we have. But I'd love to have the last segment with you, which is, again, it's got nothing to do with the topic. 3 very random questions, that I have, and please feel free to answer it in any which way you'd like.
Host - Vivin:My my first question is basically, what's the one truth that very few people agree with you on with respect to ops?
Guest - Justin:I don't know to what extent people don't agree with me about this, but I don't hear as many people talking about it, which is that ops should be accountable for business performance. And that's just something that is kinda normalized in the culture where I work, but I know that a lot of ops teams or I've heard this attitude expressed, like, well, we do x y z. Like, we deliver the systems or we fulfill your tickets. We give you your campaign whether it works or not. You know, that's sort of on you.
Guest - Justin:And you can understand having that separation of powers, but I think that is a very limiting, mindset for ops. So I'm actually a big believer that we need to be partners in performance management and be like a kind of coach and challenge things where they don't make sense and have that as a part of our
Host - Vivin:role. Yeah. Absolutely. I mean, I think tying the ops, outcomes to the business is one of the biggest things that I think will help ops understand their value and obviously help the business understand how important ops is to the entire outcome of your business. Right?
Host - Vivin:My second question is, you know, I think there's a lot of talk about what's gonna change in the next 5 to 10 years, what are the new technologies that are gonna come out. What do you think will not change in the next 5 years?
Guest - Justin:Yeah. I'm gonna go out on a limb and say that I think that most teams will still have their data as a mess in in 5 years. It's probably not a a very bold prediction, but it's not something that AI can easily fix. Maybe it can help in some ways, but, since AI is is based on the data that you provide Intuit, if the underlying data itself is a mess, you know, how how easily can we fix that? Maybe we will see some some improvements there.
Guest - Justin:But, honestly, I think it's a huge challenge. I think it requires discipline. There's never enough resources. It's hard to prioritize, data debt payback projects. So I think that we will continue to struggle in this area.
Host - Vivin:The last question, Justin, for the day is is what quality do you think, is most critical for ops folks? Creative thinking, communication, speed of execution. And and the last time I asked this to my guest, she also added another option, which is learning to say no. So which one do you think works best?
Guest - Justin:Am I allowed to add other options too? Or do I have to do I have to put that? Yes.
Host - Vivin:Of course. I'll probably pass it on to the next guest.
Guest - Justin:They're they're all I'll stick with your your original. I mean, I think they're all important. If I had to pick 1, I would say communication. Because if you can't communicate, then none of the other things matter. You can be creative as you want, but if you can't communicate, then you won't get buy into your ideas.
Guest - Justin:You can execute quickly, but if you can't communicate, nobody will know about it properly. You won't, be recognized. You won't be be able to get people on board with what you're trying to do. So So I think communication is a prerequisite for all of the other things, especially as you, move from being an individual contributor into leadership and beyond. So I'm gonna pick that one.
Host - Vivin:Got it. Got it. Alright. So, I think that's wraps up our time for the day, Justin. Thanks a lot for doing this.
Host - Vivin:Thanks for the amazing insights. I've personally learned a lot. Again, like I said, I think we could have gone on for a longer time, but I think this has to end somewhere. So, again, it was a privilege to host you, and, yeah, I would love to connect again sometime.
Guest - Justin:Me too. Thank you so much. I really, enjoyed it.
Host - Vivin:Cheers. Thanks. Thanks, Austin.
Listen to Beyond The Pipeline using one of many popular podcasting apps or directories.
