Prioritization is critical to successful product management. In this episode of Product Chats, John Slocum, Senior Vice President of Product at 3Play Media, dives into his prioritization approach. We discuss how to leverage data and feature scoring models to make effective product decisions. With over 15 years of product experience, John has a wealth of knowledge to share.
Time Stamped Show Notes
Transitioning from engineering to product [01:19]
Leveraging data to make product decisions [03:01]
Prioritizing what to build [05:01]
Making fast decisions [07:41]
Partnering with other departments [09:38]
Focusing on the customer’s problem [11:59]
Strategy vs solutioning [13:24]
Ensuring you’re doing the right things for the customer [16:00]
The value of open-ended questions [20:35]
Product Chats is brought to you by Canny. Over 1,000 teams trust Canny to help them build better products. Capture, organize, and analyze product feedback in one place to inform your product decisions.
Get your free Canny account today.
Kayla: Thanks for tuning into product chats. On today's episode, I talk with John Slocum who is the SVP of Product at 3Play Media and we talk about prioritization and strategy. So hope you enjoy the show and don't forget to leave us a review.
Kayla: Hey John, thanks so much for coming on today.
John: Sure. My pleasure. Thanks for having me.
Kayla: Yeah, well, in a minute or less, can you tell us about yourself?
John: I am a product lead at 3Play Media. Joined there about two years ago to lead the product function and build the team. I've been in product for about 14 years. Prior to that, originally an engineer I'll, I'll tell people I'm still a recovering engineer at this point.
John: That's, you know, the, the approach that I take to a lot of problems that we get to see in the space and, you know, really been a serial product manager across a variety of different verticals. So 3Play Media is in video accessibility, digital accessibility. Prior to that I was in ad tech space. Was in IT software, and before that and CAD software prior to that. So I've seen a few different tech verticals and am able to bring a transferable product skillset from vertical to vertical, which has been really cool.
Kayla: Great. And on that note, right. You said you started out as an engineer, so let's talk about kind of like what skillset has really worked for you as an engineer that's played to your strengths in the past, like 14 years of being in product.
John: Oh yeah. Pivot tables. Really that's it. That's nice, you know, taking a data driven approach to understanding problems and really seeking to quantify problems where we can, we can't always do that, but we can always get some data and we can generally use that to help us make decisions. And you know, where we can do so objectively we'll generally have a lot more confidence in the decisions that we're making.
John: That's been super helpful.
John: Let's stray from engineering, right? We wanna be able to calculate the answer and have confidence in that answer. That's easier in engineering situations. And then we can validate that experimentally in marketing situations and go to market. We have to be comfortable with some fuzzy math. That was one of the hurdles that I had to overcome as I was, you know, becoming a product manager from being an engineer.
Kayla: Yeah. And I think with that, like you talk about data a little bit, and I think like everyone wants to be very data driven and there's this kind of fine balance of using the data, but also making sure that you're not so married to the data and having bias around that data that you're like, oh, we must build out something this way.
Kayla: It's like, no, let's take a step back and understand our customers. And then look at the data and marry those two things together versus just, hey, let's take a look at the data. What if that's wrong, right? Or what if it doesn't give you kind of the, like a lot of times we just have that bias around data.
Kayla: And so it's, hey, let's actually take a step back. So I'm curious about like, how do you use data to act, to really leverage and make sure that you're building out the right things and building the right products.
John: Yeah, that's a great point too, if you're just following the data and you're not sanity checking, you're probably going to make some strange decisions cause you're never gonna get all the variables.
John: Right? One of the first things that I do when I start a new role in a new vertical and you know, my knowledge may be limited in that vertical. Upon joining 3Play Media I didn't know a ton about video accessibility specifically. I was in the ad tech space. So I knew media generally. I knew advertising really well.
John: I knew data. What I will try to do is get to know some of the customers in the space. Spend some time with customers, spend some time with prospects and I'll go after data that helps paint a picture. Of the market space of the segments in the market that, you know, the organization is focused on or that the organization might want to focus on.
John: And by getting that data that helps me establish my gut feel, right, as a product manager helps me kind of ground my instincts, anchor my instincts. And my understanding of the customer. So that might be an understanding of the customer's priorities, their needs, and understanding of the solutions in the space and the degree to which those solutions are addressing the customer's needs.
John: They can be satisfied with those solutions or dissatisfied, and that suggests a focus area where we might want to invest. But there's, you know, that's, that's pointing us. The data is pointing us to where we want to go do more qualitative research, to better understand a problem space. And then think about creatively, you know, with the engineers being, put the engineer hat on, think about creatively, what solutions might start to address those pain points or those needs that we're learning about.
Kayla: So you have, you talked about like data, you talked about like, figuring out what the customer wants. So you have all these ideas, right. When you're building things out, let's talk a bit about prioritization and kind of what goes into that for you when you're building out products.
John: Yeah. There's a lot that goes into that for sure.
John: And the challenge in prioritization, you know, this is really can be quite an acute challenge for larger organizations. It's, it's challenging for smaller organizations too, where prioritization can be the survival for a startup, right? And, and looking for ways to start driving traction in a market space, to start driving revenue. Then incremental prioritization in that smaller environment can be a, a little bit simpler than in a large organization, but ultimately everybody wants to prioritize. Everybody should be aligned on prioritizing for business value out of a set of candidates that might go into a roadmap. And lots of people think about business value in different ways. And so what I've been focused on, what I've been finding has worked well with the product teams that I've worked with in recent years is really focus on an ROI score, really a proxy for return on investment for some work that we might do.
John: So we'll actually try to estimate the new revenue enabled by a roadmap candidate or revenue protected by a roadmap candidate. Or on the back end side, or for considering IT focused projects, we might look at cost savings enabled by, uh, a bit of work that we might do, or we might look at future cost savings or cost avoidance. So that would be risk avoidance.
John: And in this way, if we're able to score everything that we're considering in prioritization, we then have a consistent mechanism that helps inform the decisions we're making in prioritization. So we're not beholden to the scores that we're creating, but they are decision support, which can be pretty great.
John: And then, you know, that prompts all sorts of interesting conversations around the assumptions that we're making in calculating and estimating these scores. And that's where we push. That's where we have the conversation. And by the way, that's where we bring the data back in too. Right. So that'll support those conversations.
Kayla: So with that, right. You, I think something that's probably played your advantage as like starting out as an engineer is understanding the effort because it's so important to like build out products that aren't gonna take too, too much effort, and then you kind of fail and you've spent all this time on building big products.
Kayla: So I think let's . Talk a little bit about making fast decisions and how you kind of like enable that.
John: Yeah. So effort's a, a big part of the equation, right? If you're thinking about an ROI score, your effort is going be your denominator. And, you know, you could develop a capability that is worth 50,000 dollars to the organization, and if it takes you six months to build you might not really be interested in pursuing that, right? If it takes you a week to build it's a little more, lot more attractive
John: Knowing that effort, having a feel for that effort, requires really strong partnership with your engineering, with your development team. You have to be able to trust them..
John: They need to be able to trust product and understand the context of the problem that we're trying to solve, understand the requirements, to the extent that design is involved. Understand the user experience and, and specifically what we're, what we're asking for. And then, you know, that, that quick feedback loop, you know, this will be one week.
John: That'll be two months. I need two weeks to even scope the problem to give you a level of effort back, right? That's, that's kind of how we enable that fast understanding of what a set of roadmap candidates might take to deliver.
Kayla: And you bring up a great point around just collaborating and involving, like engineering, involving design, keeping everyone kind of involved in the process rather than product saying, hey, we're gonna build this and then getting people involved it's hey, let's work together throughout the process so that obviously we're all working towards these objectives and these goals, right?
Kayla: You talked about revenue or cost savings, right? You're all working towards these goals. So it's just about, Hey, let's work together with teams and keeps team very involved so that we don't get to the end of it. And we're like, hey, we need to build this out.
Kayla: And then an engineer says "wait, that's gonna take me six months." And so it kind of throws a wrench in what you're trying to build.
John: Yeah, yeah. That back to the, back to the partnership. And I just came out of Q2 roadmap planning, right. And we have the entire product team there, all the product managers on the team, we have the technical leads involved and everybody's looking at the same set of roadmap candidates and the plan across multiple teams.
John: And we're all agreeing with each other that we understand what we're asking for. And we have a plan to get there. Generally. More or less, right. It's not always the case. Like there is ambiguity. Sometimes, we know a thing is important and we don't know exactly how we're gonna get there. And so we wanna spend a little more time there, right?
John: We want to understand the requirements and we want to start to scope out the approach to delivering the solution that addresses those requirements. And, and that can be a little more challenging to prioritize relative to a variety of other projects. But if the ambiguous thing is super important, we don't really have a choice but to proceed on that planning path and continue investigating and know that we're gonna wanna spend time on that.
John: So we have to be comfortable with that too. So getting the best definition in place, getting the shared understanding with our dev partners and anybody, you know, stakeholders involved in the prioritization process is critical so that we're not gonna get to the last week in the quarter, or we're not gonna get, you know, four months down the road and have folks asking questions about where's this thing. I thought this was coming out.
Kayla: Yeah. And I think you bring up a, like a really great point of even with the, like the ambiguity or there's like features that you're not exactly sure. Like functionality you're building out. If you always get back to that, why? Like, what is the pain that the customer is dealing with?
Kayla: Usually you can connect the dots. It's I'm guessing it just doesn't always happen like organically, it's just, hey, let's think about what challenge is this customer dealing with. And then, uh, in like a, a very positive way, there's so many options of the journey you could take to build it, or what can solve that as long as you keep in mind, like, hey, customer first, what is the problem that they're dealing with and where are they trying to get to?
John: Yeah, I love asking that question and, you know, especially where we may not have great definition on a project, on an effort. And if we stop and take a step back and try to understand what value it is that we're creating for the organization, right? If it's value in the form of a solution for our customer, who's the customer?
John: What's the customer's problem? What do they need? What, you know, what, what are we doing to create value for them? How are we creating value? How are we delivering that? And if we can't ask and answer that question in a customer facing feature project, then we probably don't know what we're doing. We probably have more work to do to define the work, to define the development, to define the solution, and then, you know, more work to do to position that to the customer as well, to be able to communicate the value to them.
John: We can, we can ask the same question on backend or infrastructural projects as well. And getting back to prioritization, if we're scoring everything, if we're translating all the, all the major efforts that we're investing in into business value in the form of dollars, and we're struggling to make that translation, then I, I would challenge anyone to say that we don't actually know why we're doing the project. If we can't identify that business value, let's stop, take a step back and try to figure it out.
Kayla: So on that subject of business value, you talked a bit about like solutioning, let's talk about strategy and looking at the problem versus solutioning.
John: Yeah. Well, we always wanna start with the problem I think. Right. Yeah. That's really, that's the pallet for the set of solutions that we might bring to market that we might decide to invest in.
John: So understanding the problems in space is, is the, you know, it's the first thing I try to do. As I mentioned, the first thing I do when I, when I get into a new vertical, try to understand the problems in the space, where are the common problems to pick market segments? What are the problems that customer A has versus customer B? What segment do they fall in?
John: Try to navigate in the, in the parlance of problems that we might find in a variety of different opportunities that the organization may already be engaged in, or is considering engaging in. And so we'll do that typically with, with research, with voice of customer activities to get out and talk to folks, and then we can work to quantify those problems as well via survey.
John: So we heard these things from this group of customers from this market segment. We can put that into a survey. There are a variety of ways we can do it. We could run an adaptive conjoin analysis for example, and seek to quantify the importance of problems, the performance of solutions on those problems. We can seek to quantify the utility of features that we might build or bring or deliver in a solution for that market segment.
John: And then we can use that to start to inform our strategy. Right. And that's just one element to inform the strategy. We need to have an awareness of the competitive landscape in that particular market segment as well. Cause if, if we're, you know, if we're building a variety of solutions that a competitor has already built.
John: They're already established, right? That's gonna be a tough road. We, we have to differentiate somehow, right? We typically don't wanna be differentiating on price, especially if we're in the enterprise space, but if we're going, you know, self serve, high volume, low friction, then you know, there's a game to be played with price and value delivery. That can be very meaningful. So we have to think about those things and we have to think about how our organization is structured to take those solutions to market.
John: Can we be effective with those motions and the solution that we're describing, given our understanding of the customer and given our understanding of the competitive landscape?
Kayla: So you mentioned, right? Like you are figuring out always going back to the customer, figuring out what the problem the customer has, but how do you throughout that process? Obviously you've mentioned user interviews, but how do you throughout that process, make sure that you're doing the right things or that you're evaluating or reevaluating quickly enough to pivot if you're not doing what's best or the best solution?
John: That we would do through, you know, we might have some friendly customers advising us.
John: Might have a customer advisory board, we would want to do product concept testing in that case. So, you know, we understand what it is that we think we wanna build reasonably well, perhaps we've built some of it, right? We, we may not even have gotten that far. We might be mocking it up. We might be selling PowerPoint slides, but product concept tests can, can be pretty low effort there where, you know, we have enough to describe the solution.
John: We take it to a customer. And ask 'em what they think. Right. Get their feedback. We might even try to sell it to 'em right. And, and see if we can get a credit card number. See if we, we get, you know, get, get a check and, you know, sell the thing in advance.
John: Actually asking for the sale in product concept testing can really get some honest responses outta the customer. Cause a lot of the time, if you're, if you're taking a concept to a customer sure. That's great. Love it. That's neat. Yeah, I'm interested. But when you're asking for the payment, that, that really, that really flips the switch and now they're really thinking about exchanging money for the concept that's in front of them.
John: So that can take it to another stage. We love doing that, you know, and, and important to do that early and often in the product development cycle to, to get the feedback as early as possible. I would say if it's, if you're getting that product concept feedback later, maybe in a closed beta or beta stage, then it's, it's too late.
John: You've already, you've already built it. You've already invested in building. And obviously you can, you can enhance, you can shift your focus. You can pivot, but if you've invested in development already, it's too late.
Kayla: Yeah. And I think you bring up a great point about actually, customers wanting to pay, because you can build out great products that customers say, this is exciting.
Kayla: I really like this, but at the end of the day, if it doesn't convert and in, in some businesses right, it may not be dollars. It may be some other conversion, but if it's not working towards your conversion goals, then you probably shouldn't build out. And so I think you bring up a great point of like, hey, would you buy this?
Kayla: Right? We haven't. And you also, haven't spent a ton of effort in it. To be like, okay, well we built out and now you won't buy it. Great. But you have that feedback of, would you actually pay money for that? And I think that's just like aligning back to company goals and making sure you're, like you mentioned before, staying connected to those objectives of like, hey, is this gonna drive more revenue or this gonna save costs and making sure that that can align to that so you're working towards those company goals.
John: Yeah. That, you know, if we're, if we're selling some PowerPoint slides and we're early in the program here and it's a flop, no sweat, right?
John: We haven't, we haven't spent a ton. We're just, we're just out in the market learning. We can also test licensing. We can test price points.
John: We can get feedback on that. Maybe the product's right, but maybe the licensing is not right. Right. Maybe we're proposing in this product concept test a licensing scheme that the customer doesn't really have control over. Right?
John: If it's, if it's, you know, event based pricing licensing model and the customer isn't the one driving the events, and maybe, maybe their customers are, I'm speaking to a, a current project I'm working on, but you know, if they don't have control over that and the ability to budget it, they, they may not be comfortable investing in it. They, you know, probably aren't. It's uncommon for a customer to say, yeah, sure I'll buy the thing and I'm not really sure what I'm gonna spend on it, but we'll see.
John: This guy's silly. We wouldn't expect a lot of success there. But that's the opportunity to get that feedback, right? Like customer might say, I wanna buy this. I can't budget for it, the way that you're selling it, the way that you're pricing it.
John: And then even, even price point, right. It's licensing model's right. But the price point's a little bit too high. Never heard anyone say it's too low and if it's, if it's you know free it's or cheap then the customer is getting what they're paying for. So, you know, you wanna think about your branding too, if you're, you know, if you're a premium enterprise brand, you wanna price as such, make sure that you're you're landing where the customer expects you to be.
Kayla: And I think a lot of that is like asking open-ended questions of like, why do you feel this way? And getting ideas rather than saying, like, do you think this is a good pricing model? It's hey, what do you think about this? Right. And getting those open ended questions because a lot of times customers will open up and say, oh, I feel this way.
Kayla: And you'll get more information than you would've gotten with like a very pointed question. You say why? And getting deeper to that why? Right.
John: Yeah, for sure. And, and that, you know, that speaks to a lot of interview technique that we, that we train for. If you're asking yes or no questions, you're going to get yes or no answers, and then let the customer lead.
John: Right? Let the customer lead the conversation. If you ask an open ended question, you never know where you're gonna go. And, could be a lot of fun. So just, you know, buckle up and go along for the ride. But then, you know, uh, drill in where, where you wanna get your feedback or, you know, where you're going to a place that perhaps you hadn't thought of as a product person pulling that thread right.
John: Follow the customer's lead. And they'll tell you all sorts of things that you probably hadn't even thought of. Cause customers do know what they want. Right? Like there's a, yeah, there's a misconception out there that customers don't know what they want. They do. They totally do. And they can tell you if you're asking the right questions, they may not know how to build it, how to get it, how to spec it, but they can, they can certainly articulate what they're looking for.
Kayla: So to pivot on that, I wanna ask you an open ended question and ask you if you were to give one piece of advice to an aspiring product leader, what would it be?
John: Oh, geez.
John: This feels like a setup. Now it's asking, it's asking the right questions and that, right. Like that's, I've been thinking about this as well.
John: It is asking the right questions for an aspiring product manager, for a new product manager, for an experience product manager. Right. We have to take step back and think about what we need to know in order to make the right decisions. And, you know, we're making all sorts of decisions all the time and we wanna make them efficiently and we wanna make them correctly more often than not.
John: We'll get some wrong that's OK. And then we have to ask ourselves why we missed? What did we miss? What, what questions didn't we ask that we could have asked that would've led us down the right path? And so this is how I learned product management as well. I had a great mentor when I started in product management at Solidworks.
John: That was my, my first gig out of engineering and into product management. And so my mentor there kept asking what I thought I needed to know to make the right decision on a product that I was suddenly in charge of that I, you know, that I was managing at the time. And so he'd ask me that question.
John: And I would say, I need to know how many content publishers are out there that are interested in a self-service content publishing tool. And he'd say, great. How are you gonna answer that question? And so I had to ask myself another question, how am I gonna answer that question? Right. I probably need to go find some content publishers that fit in our target market.
John: And then I need to think about how I can contact them, how I can get in touch with them. Then I need to think about the actual question that I'm going to ask them or questions that I'm going to ask them. And then I need to think about what they're probably going to respond with and how I can capture that in a way that answered my question selfishly.
Kayla: Great. And then on that note of leadership, what roles are you hiring for?
John: So hiring for a technical product manager, with the, you know, with the, with the data, we're doing a ton of things with data at 3Play Media in our platform, exhausts a tremendous amount of data that we have a machine learning team focused on some data science efforts that are continuously making our operation more efficient, producing higher quality in our output.
John: We want, you know, that team and other functions with a technical product manager who is focused on getting the most out of our data. We're working with some BI tools, we're working on the data warehouse efforts, and we need someone to take that and, and drive it. You know, I'm, I'm passionate about it myself, but I, you know, can't, can't do all the things that, you know, we're excited about doing.
John: So we gotta bring somebody in to drive that for us. That'll be a, that'll be a fun one.
Kayla: Very exciting. Well, on that note, where can people connect with you?
John: Connect with me on LinkedIn, primarily. You know, I'm pretty active there, available, you know, I'm responding to messages. So, you know, reach out there, you know, I'm at 3Play Media as well.
John: So look us up. You know, we're, we're building out a variety of digital accessibility capabilities. We just acquired a caption max and NCC organizations. And, and so we're, we're integrating them, getting to know the teams there and getting to know their customers. So, you know, there's, there's a ton going on at 3Play and you know, I'm over at LinkedIn. So come say, hi.
Kayla: Perfect. Well, thanks for coming on today.
John: Thank you.
Kayla: Thanks again to John for coming on today's episode of Product Chats. If you want more product management resources, head over to canny.io/blog, and we'll see you next time.