Turning Failure Into Opportunity - From Episode 4 of

the PM Leaders Podcast

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 opportunities 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.

See original Content @ https://voximplant.com/blog/turning-failure-into-

opportunity-from-episode-4-of-the-pm-leaders-podcast