The Product Management Leaders Podcast
The Product Management Leaders Podcast
Turning Failure Into Opportunity, Producing Greater Outcomes, Improving Internal Processes (with Kit Swain, VP PM @ Relo Metrics, GumGum, Deloitte)
Hi all, we are excited to share the fourth episode of The Product Management Leaders Podcast with you!
Our aim with this podcast is to connect you with some of the top PM leaders and share their real-world strategies and tactics for building world-class products.
In today's episode, Grant Duncan speaks with Kit Swain, the VP of Product at Relo Metrics (GumGum), a Series E startup. He has an MBA from UCLA’s Anderson School of Management and started his career at Deloitte, so he has a unique perspective to share.
Leave us your thoughts about the episode and subscribe to be notified of the upcoming ones!
This podcast is sponsored by Voximplant, the leading serverless communications platform and no-code drag and drop contact center solution.
Voximplant enables product leaders and developers to integrate communications into their products such as embedding voice, video, SMS, in-app chat, and natural language processing and it enables customer service teams to run their whole operation from one place.
Join over 30,000 businesses trusting Voximplant such as Burger King, 8x8, and Hyundai.
If you have any questions, tweet Grant at twitter.com/grantmduncan
Grant Duncan 0:05
This is the Product Management Leaders Podcast in which you hear from some of the top PM leaders about their real world strategies and tactics for building world class products. It's sponsored by Voximplant, the leading serverless communications platform and no code drag and drop contact center solution. Voximplant enables product leaders and developers to integrate communications into their products, such as embedding voice, video, SMS, in app chat and natural language processing. Join over 30,000 businesses trusting Voximplant. Now let's jump into the show.
Grant Duncan 0:42
Hey, this is Grant Duncan, your host. I'm speaking with Kit Swain, the VP of Product at Relo Metrics (GumGum), a Series E startup. He has an MBA from UCLA’s Anderson School of Management and started his career at Deloitte, so he has a unique perspective to share.
Let's dive into it.
Grant Duncan 1:01
Hi, Kit! Welcome to the Product Management Leaders Podcast. I'm Grant Duncan, your host, and I'm excited to be speaking with you today. So to start off, can you share a little bit about yourself, your role and the company you work for?
Kit Swain 1:16
Awesome, Grant. Thanks for having me. It's great to be here. I'd be happy to go through those. So I lead our product team at GumGum Sports. We have a team of two other product managers that report to me and GumGum Sports is an artificial intelligence company that works in the sports sponsorship industry. We work with sports teams, leagues and other properties, as well as agencies and brands, to help them understand the exposure of their sponsorships across broadcast, streaming and social platforms, to help them evaluate the overall performance of their sponsorships.
Grant Duncan 1:58
Very cool. And how long have you been there now?
Kit Swain 2:01
So the company itself started back in 2017. Within GumGum's larger organization, which does ad technology. And I've been with GumGum Sports since 2018, I came in as the first head of product within GumGum Sports. They had a nation product at the time, they have had a few clients that they had been working with. And I was brought in to build out our product organization, build out product processes and drive product strategy for the organization. So I've been there for just over three years now, which in startup terms, as I'm sure you're familiar, can feel like a lot longer.
Grant Duncan 2:44
Yeah, yeah, totally. Time flies sometimes. So you mentioned that you have a couple of people on your team right now, how do you structure the team? How do you break out roles and responsibilities between you and them?
Kit Swain 2:58
So that's interesting. When I came into the organization, the team that we were working with, because we came over from our advertising side of the business, was splitting time between advertising and sports. And so at that time, we had an opportunity to really structure the team, how I wanted, how we wanted to have a product and engineering team structured within the sports organization. And so we have two primary products that we manage, we have our internal operations product, which is how we ingest all the data that our clients care about. It's the backend system that really serves as the backbone for our entire product. So we have one team that's solely devoted and committed to our internal products, and any API integrations and anything that has to do with data ingest. And then we have a client facing products team, and that product team and engineering team are fully focused on our client facing products. So anytime that our clients are going to be interacting with us through our software, that team's responsibility is to identify the go to market strategy, identify how we're going to communicate anything that is ultimately client facing from a product marketing standpoint. And to build out the products that our clients use. Today, we have a single software platform. But that's not to say in a few years that we might not have multiple products on that side of the house. So we split it up that way. But those two teams are highly integrated, as you can imagine, because our internal product serves our client facing product. And so there's a lot of collaboration and cross team functionality that needs to be worked on between both product teams.
Grant Duncan 4:54
Hmm, yeah, that makes sense. And when you think about, you know, on a quarterly or monthly or weekly basis, what are the top metrics that you are tracking and reporting on?
Kit Swain 5:08
Yeah, for us, again, that's going to be dependent based on the product or the product team that you're talking about. So for our client facing product, we use an analytics tool for our software called Pendo. There's a lot out there, there's Pendo and Mixpanel, and Google Analytics. So there's a lot of different ways that you can track how your clients are using your product. And for us, you know, we look at our daily active users, our monthly active users, the types of core metrics that are important to SaaS businesses. But a level deeper than that, we also look at what activities they're doing in our platform. And we have some key activities that are really drivers of value for our clients. And so our metrics that we've tracked, have evolved over the years. Initially, we were trying to drive more usage in our product. But, because we're an efficiency platform for our clients, the more time that they spend in our product isn't necessarily indicative of a good user experience. And so it's changed over time. And now, we're more focused on identifying the correlation between certain activities that they are engaging with in our platform, and things like NPS scores and renewal, to really understand what's driving value, plus the qualitative conversations that we have with our clients. But we've identified three or four key actions that clients typically take in our platform, things related to downloading data out of our platform, that they can then share with their internal teams or with their partners. And so we try to measure our success based on you know, how frequently our client base is using those features. Or if we're releasing a new feature, whether that's, you know, driving up additional value for our clients, we may issue a customer satisfaction score to understand if they're having a positive experience with that new feature. And ultimately understand if those actions that those clients are taking are leading to higher NPS and higher customer renewal. So a lot of the metrics that we measure on that side of the house are related to product or feature specific engagement. And then on the internal side, we it's all about efficiency. It's our operations team. And so we want our internal processes operating as efficiently as possible. We also conduct an internal NPS to understand how satisfied our internal team as with the tools and features that were releasing for internal operations, but a lot of it might have to do more with the availability or the speed with which we get access to data that we are serving to our clients. And so we utilize Looker, which is a data visualization tool to collect all of our data internally, and be able to run reports and metrics about the performance or the efficiency of our internal product.
Grant Duncan 8:15
That makes sense. And you mentioned something interesting for the client facing product there. You talked about there are three to five key, I think you said key activities, if users do this, you'll have greater outcomes. How did you identify those three to five things? And how long did that process take?
Kit Swain 8:38
For us, it starts with talking to our clients and understanding how our clients are using our product. And you have a fairly good sense, especially in working with our customer success team, about which of our clients are engaged with the data that we're providing, which of our clients are happy with the services that we're providing. And so it's a combination of talking with those clients that are really satisfied with the product that we're providing and talking to clients that may not be as satisfied and understanding what are they doing in our product. And so then based on those initial conversations, you can develop a hypothesis, you know, we've got five pages on our platform, you've got a limited number, but you can say, you know, 20 different activities or actions or features that a client could engage with. And so you narrow that list down and you say, Okay, we have a hypothesis that these are the features that our clients are engaging with, that are leading to higher NPS scores, higher customer satisfaction, increased likelihood of renewal, and then you compare the data. You actually extract that data out of Pendo and you look at, okay, these are customers that rank highest on our satisfaction score, what are they doing the most of and you can see, okay, well, we thought they may have, for instance, been downloading a report out of our insights page, downloading like an Excel file, and they could take and manipulate an Excel or run pivot tables off of. But then you find out that actually, the more satisfied customers are more likely to be downloading pre generated or auto generated reports. And so you may have a hypothesis that these are the five actions that are really driving customer satisfaction. But then when you pull the data out, it's a lot more apparent what your clients are actually doing. And so that's what led us to that realization, or an identification of what we believe to be those key drivers of value.
Grant Duncan 10:41
Yeah, that's really interesting. And you're even doing that kind of like data gathering and manipulation yourself that you think your clients might be doing in a different fashion. How long do you think it kind of took you and the team to say like, okay, we think these are a few of the top, because us at Voximplant are kind of going through a similar thing right now. We're trying to revamp our onboarding processes to get higher adoption. And, you know, figuring out like, what are the key activities that if they do this, they'll really have a great experience? You know, it's a challenging process.
Kit Swain 11:25
Yeah, it definitely is. And it took us a while, I wouldn't necessarily say to narrow down what those key activities were. But once we figured out, that's what we wanted to look into more. And similar to what you're saying, going through onboarding is a really good example. Because we want that time to value to be really quick, because if a client is able to log in within the first couple of weeks of acquiring your product, and using your product, and have like that Aha moment where they're able to have that really positive experience, they're going to be likely to continue coming back and getting value out of your product, and will likely increase the renewal when the time comes. On the flip side, if they don't have that moment, in the first couple of weeks, whether they're not the buyer of the software, or it's not their core job to use your software, it's likely that customers not going to come back, or it's gonna take a lot for your customer success management team to go through another onboarding session and walk them through the value that they should be getting out of your platform. And so definitely, time to value is important. But getting back to your initial question, you know, for a long time, initially, we wanted our clients just to be in our platform and using our platform. And we viewed that as success. And I think that's a you know, every organization has to start somewhere, when thinking about what your North Star is. And so for us it was, you know, how many users from each client are logging in. First, it was getting able to get access to that data, it took us a long time to get access to the data that we needed to be able to have an idea for how they're using the platform, not to go too much into the different tools that we were using. But one of the tools that we were using, we just didn't have the expertise or ability to get access to the data in the way that we now do with Pendo. And so it would have been impossible, there was so much manual work on our side, just to understand which clients were logging into the platform, how much they were using it. So just any metrics at that point, were an improvement over what we were doing initially. And so it's a process of evolution, it depends on where your team is within that process. So the first thing is having the right tools to be able to get access to the data that you need. And once we had access to the right tools, identifying those key actions or activities, that wasn't the most challenging point. But I would say, you know, it probably took us two plus years, from the time that I had started the company to get to the point where we are measuring what we're measuring now. And I'm sure in another year, we'll have gotten even a finer perspective on on what our clients should really be doing and an improved understanding of what success looks like in using our product.
Grant Duncan 14:23
Yeah, yeah, that's super interesting. Super interesting to hear. I think what you said too, was intriguing in the beginning, you kind of knew what were some of the key things that should be happening. But to find that number or like you know, you take Slack, like a certain number of messages sent is a key metric for them. That, as you're saying, can definitely take time to refine that and figure that out. So it's really good insight.
Kit Swain 14:51
Yeah, and I think for us just to expand on that, we have an idea for what we want our clients to be doing more of, but what you just said like number of messages in Slack or something. Where I would love to get is, we know that when our clients log into the platform and do this within the first seven days, or the first three times that they've logged into the platform, that they're more likely to log in the next time, and, you know, twice as fast as other other clients, or when they perform this activity, or they download a report out of our system, you know, four times a month, they're twice as likely to renew, than clients that download two times a month. Like getting to that point would be would be great. But will definitely take some time. And I think it also depends on the volume of data that you have access to, if we were a company that had 10s of 1000s of users. So we're, we're a b2b software. So we've got hundreds of users, but we don't have 10s of 1000s of users. So we've got a limited set of data to be able to build those insights off of. And if we had 10s of 1000s of users doing activities, then it would be I think, a bit easier to really narrow in and hone in on on what those were. But that's where I would love to get and I think the more data that we have, and the more data points that we have, will help us get there.
Grant Duncan 16:11
Yeah, yeah, totally. I think that's probably how most people listening feel at some level. So one of the important things is thinking about trade offs and prioritization. How do you balance, let's say, an important request for some new important feature from a multimillion dollar customer versus some new feature or product you have on your existing roadmap?
Kit Swain 16:42
That's a great question. So if we had a multimillion dollar client request, the first thing we'd want to do is scope it out. Because we take all of our client requests, you know, super seriously, and we want to make sure that we are building a product that is of value to our clients. And the first thing we would look at is, is this something that is narrowly specific and only going to address one client's needs? Or is this something that will add value to a lot of our clients, and is more in line with our overall product strategy, and therefore, in line with our business strategy? And so, I mean, when thinking about customer requests, I think the first step that we want to do on our side, is understand what is the need behind the request, not just that I want this feature, or I need this piece of information, but it's understanding, what are you really trying to do. And in some instances, we've even found that our clients just don't understand our platform well enough to be able to get the data that they may need. And so they may ask, oh, we need this, or we want this type of feature. But then when you boil it down to the need, it may be something you're either already addressing, or it might be something that fits in with your roadmap. And so it's definitely a balance, and we go out and talk to a lot of clients. And we get a lot of requests in that process. And part of the job of a product manager is explaining to your clients, or walking your clients through your vision, and how your product is evolving. And so for a company like us, who's in the sports sponsorship industry, an industry that's been around for a long time, and we are one of these new entrants bringing technology into the space, to be able to explain that the product that you have today is not going to be the product that you have in a year, and these are things that we're working on, is different than how the industry is used to operating. And so for us, it's explaining our vision, explaining what we're working on. And some instances, you have to say, you know, that's really great input, we'll add that into our backlog, we'll ask other clients about that, and we'll just keep you abreast of where that ends up coming along with the product that we're working on, while also highlighting other things that we know are going to be adding value to that client as well. And so it's not saying yes to every client request or not being able to say no, because sometimes you have to be able to say no, and we've even had clients who have said, you know, we're fine if it's not high on your priority list, just let us know. And so, you know, sometimes you have to be just honest with with your clients as to where that falls, because everybody can understand product from a fundamental level, because everybody is working on their own priorities. And you only have the bandwidth that you have, so you have to make trade offs and you have to prioritize certain things. And so, being able to clearly communicate what your vision is, where your products going, the value that you're going to be adding... you may not always retain all clients, but you'll continue to grow your client base and retain a good majority of your clients in doing that. But there's also specific requests that, to be honest, if you have, in our case, a multi $100,000 client that comes to us with a specific request, if it's a couple of Sprints worth of work, there's a good chance we're gonna listen and potentially even do it within the quarter and continue to demonstrate value for those clients, because those are really important clients to us. And, you know, not every client request is equal. And you have to think about it that way.
Grant Duncan 20:42
I'm sure to be able to even prove some of those quick wins is also even like retention play, now they see that you're responsive to them. But yeah, what you said makes me think of even more questions that are interesting. So you talked about talking with your customers a lot. Do you have a structured process for that? Or does it naturally just happen enough for the way your company operates?
Kit Swain 21:11
That's a great question. It doesn't necessarily naturally happen, we have to work very closely with our sales team and customer success team. And the great thing about GumGum Sports, in my experience, is that our sales head and our customer success head, agree that product should be out and talking with clients, I know that not every company is that fortunate, sometimes there's friction between the sales team saying, you know, these are my clients, or these are my prospects, and I don't want products coming in here and, you know, messing things up for me or something like that. And so I think the first thing is, you have to have a really strong relationship between your product organization and other stakeholders within your own organization. And for us, what we try to do is develop a regular cadence where we're releasing features, we're prioritizing features on a quarterly basis. So we're agile in the manner that we're evaluating things that we're going to be working on. But we're also saying, okay, we're going to make a commitment in the coming quarter to this feature. And before we do that, we want to make sure that we're out talking to clients, showing them designs, getting their feedback on things, you know, we may have four or five things that we're trying to decide between, maybe having our clients force rank those features that we may be considering for future development. And so we try to have that cadence, where every quarter, we're out talking to a handful of clients, hopefully more than a handful of clients, to get that feedback. And so that's part of it. But then there's also these other projects that might come up. And that's, again, where collaboration with your sales, and your customer success team will come in handy. And that might be, okay, not only in our regular development timeline, that we want to have these conversations, but there's also a partner that we're thinking about going to market with, or they have some features that are complimentary to things that we're working on. So we want to go and talk to clients specifically about this potential partnership that's on the horizon, and get their feedback about whether the data that we would be able to bring in from that partnership would also be valuable. So there's a couple of different ways. There's one, you want to have that regular cadence. And the second is when things come up where you need to get in front of clients, it's making sure that you have that relationship with your sales and your customer success teams to be able to have the, you know, the ability to in front of clients on a regular basis.
Grant Duncan 23:49
Yeah, I think that's awesome, too, when you can build that relationship where they want to bring you in, like, Oh, this guy, he's gonna help us keep this customer or close this deal. That's really great that you have that. So another thing that you mentioned a minute ago, also brought to mind... You talked about sharing the roadmap and what's upcoming - Now, what's today, might not be what's there in a year, it could be better. Walk me through what that product roadmap deck looks like.
Kit Swain 24:19
Yeah, that's something that has definitely evolved over time. And I go back and forth on in terms of the best way to present that internally, as well as to clients. And so the first thing that I walk through with both our internal teams and our clients is our product vision. And so understanding the sponsorship market and what's going on in the sponsorship market, where our product fits in to the sponsorship market and the needs that it solves for our clients, but also where we envision our product evolving in the future. So maybe now we're narrowly focused in one corner of the market. But there's two other major opportunities for us, maybe one is a competitive threat where competitors came in and started offering something in a specific area, or it's just a big opportunity for us to not only provide more value to our current clients, or maybe there's a new market within sponsorship industry that we can provide value to, based on the evolution of our products. So it starts with sponsorship market, where we fit in, where we see ourselves evolving, and then it gets down to the nitty gritty. And I start always, in terms of talking about our product roadmap, with talking about what we've delivered. And for clients that have been with us for two or three years, it's showing that, you know, our product roadmap isn't just this list of things that we want to work on, or may someday get to. But we want to demonstrate that we've added value in the last three months, the last six months, the last 12 months. And so I'll highlight four or five projects that we've delivered in the last 12 months, especially when I know that it's a client that's been using those features, or that's added value to their organization. So that's where we'll start. And then the next thing is...
Grant Duncan 26:08
That's smart, you can kind of show, all right, hey, I'm delivering, and now we're going to keep delivering more.
Kit Swain 26:14
Exactly, and the easiest thing to talk about is what are we working on now, because what we're working on now, if it's a project that might take, you know, two or three months, or four or five months, you know, you're 90% sure that you're going to deliver that project unless something out of the ordinary ordinary happens. And, you know, you get midway through and it's deemed infeasible or just deemed not to be adding the value that you think it might be adding, then you might change it. But it's 90% certain that you have a date that you're delivering to. And so you can share those projects that you're working on now, that's a very easy conversation to have. And then typically, where we've evolved a little bit is we used to show, okay, these are projects that we're thinking about, like, let's say that we're in q1, and I show what we're working on in q1, these are projects that we're thinking about working on next quarter, and then the quarter after that, and the quarter after that. But invariably, things are gonna change. So for us, rather than doing that, what I'll show is, these are projects that we're working on right now. And then these are like, maybe four or five projects that we have on the roadmap for the second half of the year and beyond. And, you know, I don't want to be vague or mislead our clients. But it's also important for them to know what our product processes are, that we prioritize on a quarterly basis, and that things change and that we're evolving. And they need to trust us as a partner that we're going to evolve and make decisions that are going to best meet their needs, ultimately. And so rather than saying that we're going to be able to commit to something in the latter half of the year or an upcoming quarter, it is these are things that are on our roadmap for the future and beyond. And, you know, we've had instances where we have clients that are very demanding, and this was a couple of years ago, but you know, we're working on this in q1, we're working on that in q2 and q3, we're thinking about that in q4. We're thinking about that. And then we get an email from a client, because we shared this in a newsletter, and it says, Have you delivered this yet? And, you know, we prioritized it. But we missed, we didn't communicate back to our clients that, hey, this got reprioritized. So they just assumed that it was going to be delivered in that quarter. And so we've learned from that a little bit. But yeah, it's, it's definitely, from my perspective, not just about what are you going to be working on. But there's a whole narrative that leads up to what you're going to be working on, that tells the story of how your business operates, how your team operates, and what your vision is for the company.
Grant Duncan 28:41
Yeah, yeah, that's cool. I think listeners are gonna love that. I imagine you'll see some PowerPoints being reworked after this. I like to hear it. So how do you effectively work with engineering teams, a key partner for any product team?
Kit Swain 29:00
Absolutely. For us, it starts with bringing our engineering team early on in any project that we're going to be working on. We view the engineering team, not just as a team that's going to be building what we ultimately, design... or the requirements that we gather. But we want an engineering team that's going to be a partner in the entire process. And so, one thing that's important is that you have engineering managers and engineering leaders who understand the product vision, and aren't just thinking about things from a technical perspective. You definitely want the tech-focus people on your team, the people that live and breathe infrastructure or any of those types of things, but you need people who also can think about things from a product standpoint and ask the questions, so that you don't pigeonhole yourself into building something that's going to need to change when you start working on the next feature. And so for us, in our quarterly planning process, before we even take our projects to our executive team to say, these are the things that we're going to be working on - we're meeting with our engineering team, we're providing them with the feedback that we've heard from our internal stakeholders, from our clients, from the market. And we're saying, okay, these are the three projects that we're thinking about prioritizing next quarter, let's go through the high level requirements, you know, they're not written into user stories with all the acceptance criteria at this point. But in general, these are the business requirements for how this functionality... you may have some really low fidelity mockups that you're showing, but you're talking with the engineering team at that point, to see, okay, they know how our product operates, do they have any feedback about the way that we've designed this, or questions about how it needs to operate, and also understanding what's the level of effort, so that we can narrow down and make sure that we're not overextending or over committing our engineering team when we take projects to our leadership team. And so we talk with our engineering team early on. And so our engineering leaders know about the projects that we're working on, the functionality that we're delivering, the value that it's adding for our clients, before we even write a single line of code for any of these features. And then once that takes place, and we commit to the work, and we've communicated to the exec team, we had a product alignment team with the entire business, that also includes our engineering team. And so now the rest of the engineering team is seeing what we're going to be working on, what we've committed to. And then after that, we have all the standard ceremonies that you would expect. You've got your sprint kickoff ceremony, you've got your story pointing, you've got your design sessions, you've got your retrospectives, your demos, all of those things. And it's really taking the engineering team, from, again, the beginning of the product, and vision of the product through the development and testing and an ultimate release of the product. And so for us, yeah, engineering is an absolutely critical relationship, and important that they are involved throughout the process as early as possible.
Grant Duncan 32:10
Yeah, that's great that it even starts all the way back at quarterly planning. Very cool. And you talked about, you know, following typical agile methodologies and practices. What do your Sprints look like, is it two weeks, three, one?
Kit Swain 32:28
We do two week sprints and for us, we've never really adjusted it. I mean, the only time we'll have any types of adjustments are around the holidays, or when something like that comes up. And in those times, usually what happens is a week sprint, it's just like, how do you... I mean, it's just too fast of a turnover, like to go through the planning and talking about the requirements, and then the development work. And, for us, we usually just use that week where the engineers can work on a passion project, or can tidy up some tech debt or something like that. And then three weeks feels like an eternity. It's like, okay, if we have a sprint that goes three weeks, it seems like it's forever between... and we do continuous release, continuous deployment. But it still seems like a long time between the time when you're starting a sprint, to the time that you're going through a demo and updating the business and the stakeholders about the development. Two weeks is just a nice in-between timeframe. And so for us, you know, we've always done two weeks, and we have, like I was mentioning, the standard cadence. And it's the right amount of time to figure out how much work a team can deliver in two weeks, and enough to move something forward so that when you're going through your next demo, it's not like an update on something that's in progress, or something that the team is working on, or the button change from this color to this color. It's actual - this is functionality that the team has been able to work on and deliver in those two weeks. So for us that two week timeframe is that happy medium. It's an interesting question, because when I started with the team, we set that two weeks, and there was a lot of discussion at the time about how long it should be. And all the things that we've reconsidered and redesigned as it relates to our product processes and our engineering processes, that's not really ever something that comes up because I think it must just be right for our team.
Grant Duncan 34:27
Very cool. What are one or two things that you have changed about your product processes?
Kit Swain 34:34
Well, the prioritization and the planning process that I walked you through from the previous question has changed dramatically in terms of when the engineering team is involved, how we estimate level of effort, all of that kind of stuff. That's been an evolution over the three years that I've been here. I think we've gone through a number of iterations on stand up. I still don't know if we've nailed the right way to do stand up, but yeah, I think we've tried, let's just do it over slack, or let's do stand up every other day or let's change how we talk about things that we're working on. What we've settled on or where we are currently is the classic - What did you work on yesterday? What are you working on today? Do you have any roadblocks? And really trying to focus the time where there may be roadblocks so that collaboration can happen quickly. I think it'd be great to get an engineer's perspective on this question. But for me, something that's been great about how we've changed things, and it came from our engineering teams request. But we moved all of our Scrum ceremonies and all of our meetings to before 10am pacific time, so that the rest of the day could have time for flow activities. Because what happens when you don't do something like that is you have your stand up at 9am, or 9:30. And then you have a story pointing session at 10am, and then maybe another requirement session or something that comes up at 3pm. And then it's just like, these 30 minute meetings that are placed throughout the calendar. And there's not really, from day to day, a good flow that the team can get into. And so a couple things, one, we've moved, company wide, to no meeting Wednesdays, which, for me has been really great, because it's opened up that time, if I do have client meetings, it's a great time to do client meetings. But more specific than that, it's a great time to have time to really think deep about a specific thing that I'm working on whether it's strategy related, or whether I'm just trying to get some stuff done in a specific time allotment, it's a great time to be able to do that. And that's the same thing that we've done with the engineering meetings is moving everything before 10am. So you might have like two or three meetings back to back early in the morning. But you know, your meetings are done. A lot of times, if you have things that are coming out of those meetings, you have the afternoon to work on it, or it just opens up, you know, hours in the afternoon for engineers to just be focused on delivery and focused on the things that they're doing. And so I think that, for me, and I hope for our engineering team, has been a nice change. And that's happened during COVID that we've done that.
Grant Duncan 37:17
Yeah, I mean, it seems like a great idea. I try to batch my meetings as well, for similar reasons. But even having a whole whole day without meetings, I'm sure is even better.
Kit Swain 37:28
Yeah, everyone values their Wednesdays. And initially, what it calls for, and you know, still, to some degree, are extremely busy Tuesdays and Thursdays. But I think it also, it weeds out certain meetings that aren't the most important, because it also causes you to reevaluate all the meetings that you have, I mean, we have a team that's based in the UK as well. And so in the mornings, a lot of the larger org meetings or big team meetings are in the morning to accommodate our UK team. And so you can't have an operations meeting with product, and a sales meeting with product, and account management meeting with product every week, when you only have certain limited time slots to do those. And so you figure out the right cadence to meet and make sure that the the meetings are not just status meetings, but work is actually getting done and tactics are being implemented or strategy is being communicated. That they're really, again, you know, there for a reason. And so it's been good for that standpoint as well.
Grant Duncan 38:35
Yeah, that's awesome. How do you partner with engineering in bringing on some kind of new solution or technology for you to use as a company? So you know, you say, Hey, you know, we want to think about adding in this kind of option for us. Can you share more about how you collaborate to make those kinds of decisions?
Kit Swain 38:59
Now are you talking about a tool that's going to be primarily used by the engineering team or a tool that's going to be used by the rest of the organization? And maybe the engineering team is going to have to do some potential work to integrate it with other tools?
Grant Duncan 39:13
Yeah, good question. I'm thinking more something that will be used by product and engineering. So like, let's say, let's say Pendo, as an example. Some kind of tool like that.
Kit Swain 39:23
Yeah. And so your question is, how do we evaluate that? And how do we ultimately bring that into our technology stack?
Grant Duncan 39:29
Right.
Kit Swain 39:31
Yeah. So for us, the first thing I think would be to do some type of full RFP, or if not an RFP, at least get a handful of competitive quotes and understand what's the technology that's out there in the market. It's interesting being on this side of it, because for a lot of instances, our clients are going through the same thing where they're evaluating us as a product. So I feel our clients do, and going through this process brings to light a little bit of how they approach their process. But, you know, no two products are going to be made the same or made perfectly. And so for us, it's identifying what are the most important things to get out of the tool or technology that we're going to be bringing on. It's also not inundating our team with new tools and technologies all the time. So, like for us bringing Pendo on, I want to make sure that our team has adopted it, is getting the value out of it, before we go and think about another product tool to bring on. And there's a ton out there that are very valuable. But when you have a team of three people who are responsible for so much, you can't be bringing on three different new tools in six months, or you're gonna have tool fatigue, just getting on boarded and using it. And so, you know, for us, we try to stretch the limits of some of the tools that we have already or that we use, until we just decide, you know, we have to, we have to find a better way to do this. So an example might be, you know, we use the Google suite for a lot of things like I imagine most companies do. And you can use Google slides or Google sheets for so much, whether it's project management based or product planning, when there's definitely tools out there that can do things better than Google slides is designed to do. There's Asana, there's Product Board, there's all these product management type tools, prioritization tools, that I've sat with some sales people from these different organizations to hear their pitch and understand what their product is capable of. And I imagine that we'll go there at some point, but it's really identifying the right time to make that move. It's bringing people in, again, early on in the process. I think that's probably a theme of this conversation... So I was in consulting before I was in Product Management at GumGum. And something that you never want to do with a client, especially in a client meeting, is surprise your client in a way that's unexpected for them. So you want them to be, especially if you're presenting to them and their boss, you want them to understand or know what you're going in with. And so I take that same philosophy at GumGum Sports and you know, whether it's with features that we're going to be working on, with new technology that we're going to be adopting, any of those types of things. I want my team on board, I want them to be bought in, understanding what I'm evaluating, if they want to be part of that process of sitting in on those demos, sitting in on that process. If it's going to impact our engineering team, I want our head of engineering to be bought in and understand the different options we're evaluating. So for Pendo, I was our internal champion. And I don't know if all of our clients have something like this. But I built a deck internally to say, you know, this is where our different teams are going to get value out of this product. These are all the capabilities that it has. I'm going to be the one that's going to be the in house expert on how it works, so that I can go and train the other teams and identify people who will be champions within their teams. And so now our customer success management team uses it, our sales team uses it to some degree, our product team uses it probably the most. But yeah, it's a process of having people on board and bought in before you say, okay, we're going to spend $30,000 on this tool or technology for the next year.
Grant Duncan 43:41
Yeah, yeah, that's a great point. Now, I think PMs will probably be going in and building a new deck as well.
Kit Swain 43:51
I came from consulting. So if it's about a PowerPoint deck, you know, you're gonna hear it from me.
Grant Duncan 43:58
There you go. Yeah. Every consultant has to be good with PowerPoint to some degree.
Kit Swain 44:02
Absolutely. Absolutely.
Grant Duncan 44:04
So you know, this is common across pretty much any job, but especially, it's important when you're making product decisions. How do you recommend other PMs deal with failure or issues that arise?
Kit Swain 44:20
Yeah, I, the thing that I try to convey to my product team, I also have a small operations team that I manage, is that you shouldn't view inability to achieve something as a failure. There's other things that you should view as a failure- failure to prepare, failure to adequately, you know, do your due diligence or be detail oriented in your approach. Those are true, you know, blunders of a product person, but failure of a feature or failure of delivery,you should address those things head on and you should do full retrospectives of what went wrong. Maybe through failure, you can learn something that will even transform your business in a way that you didn't foresee before the failure. And so I'm definitely a person who wants to convey to my team or to other product managers that might be listening that you shouldn't be afraid of failure, but you should try to learn from it. That may not be like the most original piece of wisdom out there. But you know, it doesn't mean that you yourself, or you - your team failed. That means that you came up with an idea, you vetted it, you did everything you thought you could, you tried to deliver something that you thought was gonna add value to your product, and it didn't. And then it's about learning why it didn't. And if you're unable to do that, then that is a different type of failure of the product team. And so that's how I approach it. And it's really just about learning and turning failure into an opportunity to improve.
Grant Duncan 46:08
Great insights. You mentioned briefly there that you have an operations team, can you share a bit about what they work on?
Kit Swain 46:17
Yeah, so that's our internal operations team that interacts very much with our internal product to manage our client data. And so what we identified, so this is actually a new role for me, as of January of this year, what we identified was, you know, there's a lot of opportunities for improving our internal processes that we've been working on from a product standpoint. But by me now, leading this operations team, I get to work much more hand in hand with how our product work gets rolled out to the team, I get to help define how the processes work, because something that you don't want to do with an internal product that I've learned over the last couple of years, at the same time, is change your process and change the product simultaneously. If you're going to do something, you should change your process before you change your product, so that your product meets the needs of the optimal process. Otherwise, you're defining a product for a sub optimal process. And even if you would build a perfect product, it's still going to be suboptimal. And so by taking over this portion of the operations team, we can do both in tandem, I can work with a team to say, Okay, what are the challenges that we're facing as a team, what are the opportunities for product to support to better enable our business to scale. So we're in a period of growth right now. And we are we're scaling our business. And we need to scale in a cost effective manner, we can't continue to just add headcount or add team as we add clients. And so what we're looking to do is redefine how our processes work. And, you know, again, some of my consultant background helps come in and take a look at the process, break it down, and hopefully refine it in a way that's better than it was before. And then on top of that, apply product, to be able to make it even more automated or efficient. And that's freeing up, we've got a lot of really great employees, we've got a great team at GumGum Sports. And so what we want to do is we want to free up their time that might be doing the mundane or tedious type of work, so that they can really be adding value to our clients. And so that's what we're really focused on. So as we grow, there's more opportunities for the team that is doing some of that more manual data management on the back end.
Grant Duncan 48:50
Yeah, that makes a lot of sense. A company I previously worked at had a similar thing, where they put their operations kind of business oportunities team under the product team as well, to create some of those similar structures that you just talked about. Alright, if you had a magic wand, and you could solve any product management problem, what would that be?
Kit Swain 49:14
Yeah, that's a tough one. I mean, there's definitely some obvious ones, but I still want to be employed at the end of the day. Haha! So I don't want to just, you know, solve all of the the product needs, which I think would take a long time to do. But for me, it's really understanding and being able to apply frameworks to various parts of the product experience. And so my magic product wand would be, whatever we're working on, to know what the best framework is that somebody else has designed and developed so that we're not reinventing the wheel and to be able to apply that framework to our specific thing that we might be working on. So if it's a design framework, and you're thinking about what's the optimal design for your product for your clients, thinking through, what are the ways that we should approach design from whether we want design that's elegant versus functional, versus, you know, potentially flawed, but works for the team. So if there's like a framework that we could apply to that, or if there's a framework, an ideal framework for prioritization, I know there's frameworks out there for just about every piece of the product puzzle. But I haven't found all the ones that absolutely work. And so I continue to read up on product, I listen to other product talks like this, to hear how other people have done it, and have learned from their experiences. And so for me, the magic wand would say, Okay, this is the problem. And then somebody says, oh, here's a framework that will help you solve that problem.
Grant Duncan 50:43
Yeah, that's a good one. Very cool. How do you explain what you do to your family or non-tech people?
Kit Swain 50:54
A lot of my family or non tech people didn't know the work that we do is actually a business out there, that we're measuring the exposure of sponsorships that appear on the screen and broadcast and social. And so it starts with explaining what our business does. And then I talked through how our product works and how our clients use it. And the best way to do that is through an example. So I pick my favorite sports team, which is the Kansas City Chiefs. And I say, okay, the Kansas City Chiefs are working with Hy-Vee, a grocer in the area, and the Hy-Vee has sponsored various assets in their arena. And our job is to measure the amount of exposure that Hy-Vee is getting for the Kansas City Chiefs. And so then what we want to do from a product standpoint, is build something so that our clients at the Kansas City Chiefs can get access to that data, and use it to improve their sponsorship business, or use it as part of their sponsorship business lifecycle. And so my job as Product Manager is to work with our clients, understand how they're using our product, and design the strategy, work with my team on building out how our product works, so that they can ultimately use it. And so it's definitely a tall task. And sometimes I get blank looks. And I really savor the conversations that I have with other product managers, because you're able to talk through product things without having to go into detail about how product works.
Grant Duncan 52:30
Yeah, yeah, totally. I think that's a good example. And I think you're right that, you know, for a lot of people that is new to hear, and probably interesting. Well, Kit, thanks so much for coming on. Really appreciate your time today. One last question for you here. Who is one other PM leader that you think we should have on this podcast?
Kit Swain 52:51
Yeah, um, so there's a lot of great PMS]s that I've learned from from going to various conferences or reading articles or blogs. A couple that I've seen at conferences, Matt LeMay, talks a lot about creating a safe environment for your product team. And he is someone who I've learned a lot about from various product conferences. Of course, most product managers, I imagine are familiar with Marty Cagan, and his writing from the Silicon Valley Product Group. So you know, if you could get him on the podcast, I would highly encourage it!
Grant Duncan 53:27
Please come on! Haha!
Kit Swain 53:29
There's somebody in the LA area that I like to talk about product with, who I've never worked with, guy named Mark Geller, who is the co-founder and CFO at Happy Returns, down here in LA. And he's worked with my brother, who's an engineer at another company in LA. And he's just somebody that I really enjoy talking product with. He's got more product experience than I do. And so I like to bounce ideas off of him and hear how he's managing product at his company. So I would highly recommend Mark.
Grant Duncan 53:59
Cool! Well, we'll try to get them on. Again, Kit, thanks so much. I think our listeners appreciate your insights, and have a good rest of your day.
Grant Duncan 54:13
Thanks for listening to today's podcast, and thanks to our sponsor, Voximplant as well. If you're looking into how to improve your communication and customer engagement, check them out. Lastly, if you enjoyed this episode, please leave us a review and tell your friends, so that others can find it more easily. Have a great day. And feel free to reach out to me, Grant Duncan, if you have any questions you want asked in our next episode.