Matt Duench: Welcome everyone to today's episode of the Mistaken Identity Podcast.

[00:00:03] I'm very excited today to be joined with John Gannon. John, welcome to the show.

[00:00:08] john gannon: Hey Matt. Thanks a lot. I'm really happy to be here.

[00:00:10] matt duench: Really excited to have you today. Maybe give everyone listening today a bit of your background and you know, what your current role, uh, is.

[00:00:17] john gannon: Sure. So I'm currently the founder and c e o of Venture Five Media and Venture Five Media is a company that builds buys and backs, uh, creator led businesses. Previous to that, I have a long career in. Product management and, uh, enterprise software cloud, B2B in general, uh, with companies like Digital Ocean, Amazon Web Services, uh, and even earlier on, prior to cloud, the precursor of Cloud VMware, which I was a part of in the early two thousands, as the company was really starting to hit its stride and, and take off.

[00:00:57] matt duench: I'm really excited to have you on the show today to talk a little around, you know, product management that process some of your product leadership experience as well. And even a common thread, I think of like build versus buy in the software industry. But maybe to kick it off and thinking about your time at Digital Ocean, you know, very high level, what was your approach to product leadership there and how have you seen that sort of evolve over your, uh, experience?

[00:01:23] john gannon: So my approach to product management has evolved over time, for sure. And funny enough, and, and actually has nothing to do with, uh, the current podcast, but, uh, given there's, uh, there's a podcast from, from Okta, um, at Digital Ocean, I worked with someone who, uh, really mentored me in terms of product management.

[00:01:45] A gentleman named Nick Wade, who's now part of the Off Zero division at uh, at Okta, and Nick really taught me an approach that is really focused on how do you enable the individual team members to really have. Agency and control over what they're working on. And as a product manager, there's the whole sort of like product manager's, the CEO of the product.

[00:02:15] I actually don't believe that. Uh, I think the product manager is more like the, uh, executive producer or the producer if you want to kind of compare it to making a movie. So you think about a producer, they don't, I mean, they, they make a lot of decisions. But they are not sort of the boss of everyone. And so they really have to figure out, how do I get the best out of my actors?

[00:02:36] How do I get the best out of my sound people, right? How do I get my best out of the wardrobe department? And so for a product leader, I think the analogies would be, how do I get the most impact out of my design team? How do I get the most impact out of individual engineers? How do I get the most impact out of software architects?

[00:02:55] How do I get the most impact out of the security team that I need to work with to get my product launched in a secure and stable way? So that's how I think about it. It's a little bit different. I, I think, than, uh, sort of the, the product manager is sort of like the overarching leader. Uh, I don't really buy into that.

[00:03:14] And, and I think the only way you really create a truly empowered product team is to actually have individuals on the product team be empowered.

[00:03:22] matt duench: Yeah. I, I really think you need that collaboration. Right? And I really like how you, how you characterize that because I think typically what product managers, or at least the industry and uh, and the function of product management has done is do exactly that is say, you know, the product manager is the CEO of the product.

[00:03:39] Where I really, I think it takes a village, and I really like this idea that you kind of brought forward about collaboration. And it taking a, a cross-functional team to develop really great products. Um, maybe talk a little more around that. What's your experience been in working with some of these engineering and software development teams to really drive that collaboration so you can, you can achieve these outcomes that you're trying to achieve?

[00:04:00] john gannon: As a product manager in terms of trying to really foster that team environment where everyone feels comfortable and and included in terms of contributing to not only sort of like the daily, here is the feature we produce, but also to really connect with the team mission and sort of the, the why of, of why a thing is being done. Just like kind of really tangible, tactical things. I'll, I'll bring up that I think could be helpful for listeners who are in product leadership roles. And when I say product leadership, I don't mean necessarily product management. It could be you're an engineering manager on a product team, you're a design lead, right?

[00:04:38] Product leadership comes from everywhere, but, I'll give one very specific example from, uh, a recent quarterly planning process that we ran and, and it was company wide, but each team ran their own, uh, their, their, their own, uh, sort piece of it. And so the, I think the prevailing sort of standard way that a team would do that is they would say, okay, team. Here's the process that we're gonna follow, and we're gonna have meetings on this day, this day, and this day we're all gonna get together. We're all gonna show up. And there's a book that I read that, uh, I've read it a few years ago, and it really influenced how I think about, uh, not, not communication by itself, but sort of communication in groups, is a book called Community by Peter Block. And this book just has some really unique ideas that I had not really considered in terms of how do we gather groups, how do we gather people, how do we honor and include everyone there? And so one of the ideas that came from that book was that when you are creating a gathering of people, that people need to be there willingly.

[00:05:47] So if you think about, uh, like a work meeting, right? Someone's manager's like, okay, like these five people, like you have to come to this meeting. But for quarterly planning, I was thinking, Hey, you know what? I want folks to be really bought into this plan and, and I actually want them to create the plan. I don't want to create the plan.

[00:06:05] I want to shepherd the creation of the plan, but I want everyone to really own this plan and make it their plan. And so one way that I did that is I made a point of saying at the beginning of the process, We are gonna go into quarterly planning. We are gonna have some, uh, some meetings that we will, we will gather if you want to focus on something else during those times.

[00:06:31] If you don't feel it's a good use of your time, I am a hundred percent supportive. Go do what you need to do in terms of whatever feature you're working on or, you know, whatever. Whatever you, you feel like you need to work on that day. And there's no penalty for this. There's, you know, I'm not trying to fake you out like I really mean it.

[00:06:48] Uh, do what you feel like you need to do to make the biggest impact to this team. If you would like to gather, you know, I'll send the meeting invite. I'll flag I'm flagging everyone as optional on that. And if you'd like to come, come, we, we'd love to have you, but if you don't come, that's totally a hundred percent fine.

[00:07:08] And I repeated this a few times cuz people aren't, probably, aren't used to hearing that. Like, here's a meeting you don't actually have to show up to. And I think it did contribute to that quarterly planning process in terms of people being really engaged and excited. I mean, we had really, you know, hour long plus meetings, which usually can get pretty, uh, tedious right? In large groups and just super energy throughout, like going over. But people still super fired up and these were all people and, and actually the whole team did show up. But they were there because they wanted to be there. And so, so I think that's like a, it's actually a really easy thing to do. Like any product team could implement that in any planning cycle, uh, immediately. They could even do it in sprint planning. You know, some teams plan a sprint, uh, completely with the whole team. Some teams maybe have a few representatives, but as a product leader, You could make that sprint planning optional, and the people who really want to be there will be there. The people who don't, don't. And that's, that's actually okay because it's up to them, right? It's their time.

[00:08:10] matt duench: Think that's a really good thought on, you know, bringing the people into the team and motivating them around an outcome and a goal. Thinking about how products get built, successful products get built, what do you think goes in, or what does it take to build a successful product?

[00:08:28] john gannon: A few things I would say define the success of our product. You could certainly argue that it's how much did the cash register ring right, in terms of the, the revenue value to the company and the enterprise value that that generates for a company. But you know, that's not why people work. That's not why people show up, right? People show up because they wanna feel like they're contributing to something. And so I think aside from hitting those goals, and, and most people on most teams are very motivated by that, right? They're like, gimme a goal. I want to hit it. Uh, but they also wanna feel fulfilled in their work. They want to feel like they grew, that they were stretched, that they were put in the situations that maybe made them feel uncomfortable because it was, it was a growth opportunity and they rose to the occasion.

[00:09:12] So providing those kinds of opportunities, I think is, is a successful, uh, part of a successful product, uh, creation and, and launch and rollout. Another piece that doesn't really get, I think, talked about as much is we really focus in as product leaders on like, engineering product and like design, right? But to launch a successful product, particularly at larger companies, there are a number of different constituents that one needs to, uh, you know, bring on board and get buy-in and. It's very different when you are approaching, say, your finance team as a, a, a group that is separate from the product team.

[00:09:53] They're actually an extension of the product team. You, you, you need to price your product. You need to make sure the margins are, are, are, are the way that they should be. Uh, you need to make sure that you're, you're, you're charging tax for the products, right? And, and all these sorts of, of things, uh, marketing the products and. So one of the things that I also tried to do is, uh, and we had a great program manager who, who facilitated a lot of this, but bringing along those other groups and making them part of the greater team, recognizing them for their contributions. and really making them part of the team and making them bought in that they can help make this product successful. Right. They are a part of this and they're not sort of a, you know, separate group over here that like, oh, we, we, we sort of just have to work with them cuz that's like a check the box thing, but actually bringing them in and making them a part of it.

[00:10:46] matt duench: Yeah. I think at the end of the day, right, all departments have a stake in the success of the business, right? So it, like you said, I think it's critically important that we think about the adjacent stakeholders as part of the adjacent product team and bringing them all along. Finance, legal, operations, et cetera. It just, it, it just shows you how many things go into creating, you know, a successful product. Um, maybe thinking a little around the process of how a product gets made. Right. Could you describe some of the ups, the downs? I assume it's not a linear, you know, sort of a path to, you know, ideating on a product and, and launching or creating it. What are some of the ups and the downs and even the highs and lows of, of that product creation process or that product management process?

[00:11:30] john gannon: if you're working in a, I'm gonna do air quotes, agile environment, is that you're constantly adjusting your plans. Your vision should be solid, but your plans are constantly adjusting, right? Sprint to sprint. You're really evolving as you learn more, as the product develops, et cetera. One of the things that I've found is as you're getting closer to a key ship date, you become, uh, very keenly focused on, uh, where can we cut scope safely? And learning that skill, I think is critical to any product leader, be they coming from the engineering side of the house or product side of the house, design, et cetera. And I'll give you a good example of that. So at Digital Ocean, I was, uh, I was product manager for our marketplace. So we worked with a variety of third party vendors, brought them kind of into the fold and made their offerings accessible to our customers in a very seamless way.

[00:12:29] And so one of the parts of the marketplace launch was we were launching, uh, a front end site for the marketplace, but then we also had a vendor management platform where the software vendors could go in and, and manage their entry in the marketplace, uh, if you will.

[00:12:46] We had split up the delivery of this. So we, we launched the front end first to customers and then the vendor side of things was pretty manual in the beginning, but we knew we would build out a self-service system for them. And we kind of worked on that, uh, in parallel, but it was gonna ship later. And I remember sitting in a, uh, actually probably on Slack initially with one of our senior front end folks. Who was saying, you know, did, did the right thing and kind of raised the flag and say, Hey, I, there's this feature that, that you want that was related to, uh, uploading logos. And he's like, I don't think, like, we're not gonna be able to get this done by the, the ship date. And so fortunately in that case, because we started with a very manual process for those vendors to manage their listings, we actually were just using a Google sheet.

[00:13:36] Downloading the information and then running it through a script that one of the engineers on the team, uh, had put together. And so because we used that Google form for at least a few months, we actually knew how the vendors were interacting with their side of the equation. And we knew through that, that the, the logo upload was not actually that important.

[00:14:01] Like the, the, they would upload a logo once and then they were done. So we figured, hey, worst case we can sort of add these by hand for people if they need to. We don't need to hold back the whole, you know, ship date just for this thing. And so I would say that's, that's sort of a down, that led to an up in the sense that, yeah, obviously we wanted to ship that before we got out the door, but when push came to shove, we took a good hard look at that feature.

[00:14:25] It was actually a hundred percent fine to cut it, but had we not taken that approach earlier to say, we're not gonna go and waterfall this thing and build this big vendor backend where we actually have no idea, like how the vendors want to interact with this thing. That really saved us a lot of grief throughout that whole product development process. Now, the flip side of this is that one could argue that maybe we, uh, we're doing it in that way with the Google form and the, the manual scripts for a bit too long, right? And that had some operational overhead for the team. So there was a balance there. We learned a lot. The trade off was that we maybe lost a little bit of engineering bandwidth because they needed to manage more manual processes.

[00:15:08] matt duench: Yeah, that's, I think that's great intel. One of the things I was thinking about when you're, when you're talking, is around the customer feedback and how it's integral into the product delivery and development process as well. How, uh, what, you know, what experiences do you have in sort of, ways and points in the product delivery life cycle where you're pulling that information, uh, from customer feedback to kind of get that back into the cycle so that you can iterate on that, make things better based on customer feedback. Do you, do you have any experience doing that or where have you seen that fall effectively within the product delivery, uh, life cycle.

[00:15:41] john gannon: We had some pretty strong UX designers on the team and we were usually able within, say a week, if we had a concept of a new feature or something, we would, were thinking about delivering the, uh, the UX lead would usually partner up with probably an engineer, uh, someone, uh, on the front end, the back end.

[00:16:01] And they would be able to come with, uh, not a sort of pixel perfect design, but. Like sort of a, a set of screens that someone, a user could click through and to be able to get some feedback. So that was something we would always push ourselves to do, is if they, we were gonna undertake something that was, you know, I'd say medium to large, that we would try to put pen to paper, so to speak, get that in a, in a, a Figma mockup that we could then go to one of our marketplace vendors or go to a digital ocean end user or a couple and, and really show them that and see how they interact with it, hear their feedback.

[00:16:36] In terms of other ways to get feedback, the, I think the challenge in today's product management teams, uh, or rather product teams, is that if you are in a, say a SaaS company that's doing, I would say 10 million plus a year, the amount of data that is coming out of the systems and from the customers, et cetera, it's, it's frankly overwhelming.

[00:17:01] And so part of what you need to do is, Really try to figure out, you know, what is the feedback you really need to pay attention to and listen to, uh, what is the feedback cycle that you need to look at for certain types of data versus other types of data. Uh, so, so anyway, it's not an easy solution, but you do need to kind of keep your eye on all those sources as a, as a product leader.

[00:17:25] And I'm sure now with, uh, AI really kind of, uh, taking center stage, I think. This, well, hopefully in the coming years get easier for product leaders to really sort through the, you know, digital ocean. I think we had, I don't remember exactly, but I think it was like a double digit number of places besides directly talking to customers that we could get information about what customers are doing and it's like totally overwhelming.

[00:17:50] So, uh, I think there are, there's an opportunity in the market for something that can kind of help PMs, uh, in product teams solve that.

[00:17:58] matt duench: And so when you think about building an experience within the product, right, of how users interact with your product, what are some elements to consider from that customer experience to build that you're building into it? What are some misconceptions within even customer identity per se, that that customer, that product managers really need to be thinking about when they're building that, uh, that experience?

[00:18:17] john gannon: At Digital Ocean, one of the things that, uh, was definitely important to our customers was the concept of, uh, team accounts. So if I'm an individual digital Ocean customer, I have an individual account and I can sort of do whatever I'm gonna do.

[00:18:29] But if I'm working with a whole team, the team needs to have a certain level of access. I need to be able to add and remove people from those teams. And depending on the individual roles within the teams that I set up, those team members should only have certain levels of access. And so, Uh, thinking through all of that as a product manager actually took quite a bit of head space because you, you need to think about who should have access to the resources, who shouldn't, how should that be managed?

[00:18:58] And then not only do you have to sort of build that into the product, but then there's actually quite a bit of testing that goes on there as well to make sure all those different cases work. Uh, there's also, uh, another really interesting thing for us was, An existing customer who is already in the platform, they start using a new product versus someone who signs up brand new for the platform.

[00:19:23] And the first product they're gonna use is your product. What is that experience like? Because they're gonna be different than a customer experience for someone who is already on your platform. And that was always an area too, where it's like, okay, we gotta take a step back, we gotta do some brainstorming, get on the whiteboard and make sure we're capturing all the relevant.

[00:19:41] Uh, all the relevant cases so that either type of customer is gonna get a really, uh, seamless type of experience. The other side of that, for the, one of the products I worked on the marketplace is we had like digital ocean end users and, and that was like its own thing, but then we also had these vendors, right? And they had their own needs around. Authentication and who can do what within the vendor sandbox, so to speak. And so we, we sort of had that like two times over versus, uh, a typical product team who maybe would just be servicing, uh, an end user.

[00:20:17] matt duench: Yeah. You made me think about, uh, a point around experimentation when you were talking about testing as well, right? Like I, I think experiments are really key to driving those customer learnings and, you know, getting the outcomes that you're trying to drive to. Just based on that insight, what are, if you can think about maybe some experiments or tests that you've run in the past, what are some of the most impactful experiments that you've ever run? What, you know, what, what were the outcomes? What'd you learn? What in, what inspired you in the first place to even conduct that experiment?

[00:20:43] john gannon: Experimentation is something I could talk about for a long time, and, and, and I actually really picked up quite a bit of, uh, methodology and, and best practices around that. Actually from my time prior to Digital Ocean, I was a product manager at Amazon within their display advertising business where experimentation is. Is, is very much part of the day-to-day there. And so working with data scientists and folks who had worked in the online, uh, advertising industry for, for decades really started to get an appreciation for data and, and also not taking data at face value, digging in to really understand what is the data actually saying.

[00:21:29] And how to set up true experiments that really have testing control groups. The word experiment gets thrown around constantly and, and, and I'm as guilty of it as anyone, and saying experiment could mean many things to many different people. If you're talking about doing multi-variate testing where you have a test and control group that is a specific type of experiment.

[00:21:53] And that in the world of, of SaaS and, and, and you sort of, uh, product led SaaS, if you will, that I think is often what people are talking about around experimentation and in terms of specific experiments that, uh, were particularly notable, impactful. I would actually flip it to say that building the muscle within a team, that you have a culture of experimentation and this is something you do.

[00:22:22] Uh, just as part of the, the, the day to day, that is actually the more important thing because the more experiments you do, the more chances you will have to actually come to some kind of an insight. If you're only doing two experiments a year, chances are you're not gonna get an insight because the chances that one of those two experiments will reach a level of statistical significance is, is, is probably not great.

[00:22:46] Uh, unless you really, really know what you're doing and you're, you're an expert on this kind of stuff. So the key is really to build a culture of experimentation. And so, you know, we got to the point on our team at Digital Ocean, where our UX lead was actually driving a lot of the experimental definition and really thinking about that as she was designing the UX for a specific feature.

[00:23:12] And, you know, that really helped us make sure that we were able to get those experiments into production much easier versus just, because a lot of times it's the product managers like, oh, like we should run an experiment. But if you're not really baking that into the team process and that understanding and that buy-in within the team and really getting everyone involved, then you're gonna be doing, you know, if you're lucky a couple experiments a year, which is just, you're not gonna, you, you're, you're gonna have to get very lucky to learn something impactful.

[00:23:42] matt duench: Yeah, I think, I think a key there is, like you said, it's not, it's, it's staying away from the buzzword of experimenting or experimentation. Right? And it's about having like clear. Clear outcomes, a clear process for what you're trying to deliver. Um, one of the things I was listening to in a, in a podcast you did a little while back, uh, just talking about, you know, uh, minimum vial product and, and how you need to, like, how do you actually know when you've got a good mvp? I, I'd love to hear your perspective on that. On an mvp, how do you know when you've got a good mvp? What does that look like?

[00:24:15] john gannon: I was talking about before that example of where we had to cut scope on that release and that MVP that we used was actually a, was a Google sheet, I mean a Google form, like that was the mvp. So I actually super strongly about, uh, low code and no code MVPs as a way to learn. A lot before you start laying down code. Because the example that I gave around, uh, this, this vendor portal in our marketplace, if we had just started on day one and like did some designs and like built the spec, we would've overbuilt the thing by 50%. Whereas the approach we took, we actually ended up building, you know, I think probably, you know, probably within 90 to 95% of what we actually really needed, like we probably missed, you know, a couple of small things, but, we were able to, uh, you know, the, the logo example is a great example. We could have spent two weeks specking that logo feature, but hey, at the end of the day, it didn't end up being important, so we just shipped it later. You know, we like slipped it into like a subsequent sprint. You know what I mean? And that that's a feature that you, you, you know, you could argue, we, we could have even spent more time on had we not known than, Hey, this is not gonna be something that gets used a lot. Intuitively, I guess it's a logo, right? So maybe, maybe we should have known that at the outset, but we actually had the data cuz we could see how customers were interacting or rather vendors were interacting with that Google Forum, which was our M V P in that case.

[00:25:42] matt duench: That's the key cuz what I was gonna say around product management is I always feel like MVP gets thrown around, right?

[00:25:47] john gannon: Oh yeah, that's another one. Experiment and mvp.

[00:25:50] matt duench: Mvp, let's just hit on all the buzzwords. But I feel, I feel like it's exactly what happens with product, like product teams is that they'll, they'll say, okay, we just need an mvp. Especially if you're early in sort of your, your SaaS journey or really just your application building journey. You're saying, I need to get time to market, I need to get to market fast. We just need an mvp. But like how do you know when you've actually got a good mvp? What does good look like? What is, what is a good mvp? Well, I feel like a good MVP is having really like well defined. Both exit criteria for how when you launch the, whatever the product is, but even just something you hit on there of, of bringing the teams along and having very, you know, succinct testing criteria and looking at how it's being, uh, interacted with your, you know, quote unquote mvp, uh, is something that I find really interesting. But yeah, I mean, if you've got additional perspective, I'd love to hear on, you know, how do you know when you've got a good mvp and what is an MVP in the first place?

[00:26:45] john gannon: Yeah. Yeah. Hindsight is, is always 2020. And so one of the things in thinking about the use of the term mvp, and how that gets thrown around as much as the term experiment with multiple different definitions depending on who you ask. I, I would actually, just looking back, I don't think even talking about an MVP is the way to like even using the words MVP at all.

[00:27:10] I think it's more about we are trying to solve a customer problem. W the customer has a bunch of different problems. What's the first problem that we want to attempt to solve for them, and how quickly can we ship something that we believe hypothetically could solve that problem? That, to me, is an mvp. Uh, again, not a big fan of the word, but I think that because some people might think, oh, an MVP means the same thing as like a customer beta, which I, I don't actually agree with.

[00:27:44] Like, I think an MVP is. Is, uh, is sort of its own thing, but, um, yeah, I, I think that, uh, because the term gets so misused, it probably just makes sense to stop using it and just focus your product team on. Here's the customer problem we're trying to solve. Here's the hypothesis we we have about how we can solve it for them.

[00:28:08] Here's the first attempt at that. Here's the important key metrics we're gonna look at. And oh, by the way, You're kidding yourself. If you're gonna look at 20 metrics, you're not, you need like a couple, like one, two, maybe three. That's another thing that I think, uh, while we're on the topic of things that, you know, experiments, the guy gets thrown around.

[00:28:30] MVPs is another thing that gets thrown around. And then there's, uh, the, the, uh, oh, you know, we, we need to have 75 KPIs for this product. And I, I used to work at Amazon, so it was like, To the nth degree where, um, you know, KPIs and, and data for everything. And one thing I took away from my Amazon experience in a very positive way was that awareness and thought around data. But on the flip side, I realized we don't need to go that crazy with 372 different metrics for a single feature like. We, uh, we probably just need to focus on like one or two, uh, which is why, uh, one of the things that started to implemented digital Ocean more broadly was the concept of an activation metric for products.

[00:29:20] And I really like that concept because, uh, the way that our, uh, chief product officer sort of defined it is, it, it, it's, it's the metric that a product team thinks represents truly active use of our product, right? So for a digital ocean product, it wouldn't be. Uh, logging in like that wouldn't be a relevant activation metric cuz the person didn't actually get any value.

[00:29:43] But for the droplet product it could be customers spins up a droplet maybe. Right? But, but you know, leaving it to the teams to really kind of talk about and debate what is that active use metric. So, uh, that was something that really started to get pushed pretty heavily, uh, sort of, um, towards the end of my stint there by the, the cpo.

[00:30:00] And, and I thought that made a lot of sense and, and I think, you know, pretty much any product team. Should have an activation metric for their products and recognize that, uh, a, it will change over time. And b, it will actually take you time to instrument that activation metric. It's not like you wake up to, well, some small startups, you know, maybe they can turn on a dime, right?

[00:30:18] But most product teams at a bigger SaaS company, they're gonna need to, uh, you know, plan out, okay, how do we measure this thing? The thing you want to measure. Yeah, sure. Ideally you'd want to measure it, but it's gonna take half your engineering team three months to implement.

[00:30:32] It's like, okay, well is it, is it worth it to measure based on that or is there another activation metric that like it? It's like maybe 80% as strong, but like we could implement it in a week.

[00:30:46] matt duench: Thinking about activation metrics and all of these things and how you track the success of a product in the feedback loop. How can you be sure that you're building the right thing?

[00:30:56] Like even in terms of prioritization, are we working on the right feature? Are we work on the right capability? Maybe give some insight, and it might be based around some of the activation metrics that you just talked about, but. How can listeners, folks in the product, you know, uh, realm, domain, how can they be sure that they're building the right thing?

[00:31:12] john gannon: Uh, if I had the answer to that, I would, uh, probably be retired on a beach right now, but I'm still working. The, uh, I mean, I think it's, what, what's, what's more important to focus on is building that culture where you're able to rapidly generate test hypothesis, generate and test hypotheses, and then learn and then repeat the process. Because nine times out of 10, you're not gonna nail it the first time, but if you get more reps in, you will quickly get to a point where you are hitting the mark on the things that you're trying to hit the mark on.

[00:31:54] Now that that's not a hundred percent like you, you could be totally off the mark with just the vision and the strategy. Of what this product should be. But in most cases, you launch a thing and it's like, some of it seems to be working great, and some of it's like, well, why aren't they using this feature?

[00:32:10] Why aren't they doing this thing that we had expected? And then you've gotta just kind of iterate on that. So I don't think there's really, I mean, unless you're Steve Jobs and there's only one of Steve Jobs, right? I don't think you can really nail it the first time. At least not, not, not normal mortals like myself.

[00:32:23] matt duench: I think you're right. Obviously, if, if we all had the answer to that question, we would all be retired and you wouldn't need product managers because we, we would just know what it takes to build exactly, you know, amazing products that, uh, customers love. 

[00:32:34] john gannon: One thing in terms of, uh, you know, figuring out like what is the right product to ship and, and having more of a chance to get it right besides the team culture. Aspects of generating ideas, being able to rapidly ship those ideas to test hypotheses and then repeating the process is also, and this was something that I, uh, you know, sort of learned from, from, uh, from Nick who I was talking about before, is really being able to let us take a step back and let people do the jobs that they want to do and love to do. So there were things I remember I would actually debate with, um, not Nick, but, but another, uh, manager I had worked for where he was, um, sort of very, uh, opinionated on the amount of hands-on testing a product manager should do on a product and. My take on that was very different than, than his, because I was thinking about it like any product manager in terms of trade offs.

[00:33:43] Like I could test a corner case myself for two hours, or I could spend those two hours, uh, you know, digging into data and coming up with like the next. Sort of major thing we wanna work on next quarter, what's the higher value thing? Especially on a feature where maybe it's like not, maybe it's the logo upload feature I keep talking about, right? Like, I'm like, why would I spend two hours on that? So anyway, uh, so, so I think that's one piece of, of that philosophy. Um, you know, in other pieces, you know, some, I think product managers would really get into the weeds on, uh, How the feature is like visually designed and my approach was, hey, UX lead, you know, UX really well front end, you know what's possible and you know when to pull in the back end team to make sure that it's all gonna stitch together.

[00:34:38] Yes, I'll come and give feedback once we have some mock-ups and, and things like that, but I don't need to sit in the, uh, you know, every individual featured designing session. Right. That's. Uh, that's probably not productive for the team. Doesn't let the team run as fast. And, you know, I I, I have the opportunity to give my input at, at some point.

[00:34:58] And, and actually you have the opportunity not to take my input, right? Like, uh, in, in most cases it's like, have you thought about this? Have you thought about that? I mean, a lot of, I think what a product manager needs to do is, is ask, ask questions and authentic questions. Not like leading questions, but questions that are, Hey, have you thought about this?

[00:35:19] Or, Hey, if we do it this way, then this other thing's gonna happen. Can you talk to me more about that? And so through those conversations, you get to a better end state for a product, and that end state's not gonna match a hundred percent. Maybe what you, as the PM had thought six months ago when you envisioned this thing.

[00:35:40] But the end product is going to be something that's close enough to that and that the team is really bought into and really excited about and has really had a hand at shaping and owning

[00:35:50] matt duench: Yeah, you're, you're really hitting on a theme here around innovation. Another, another buzzword to throw, to throw out there as well. So we've got innovation, uh, you know, we've got, uh, a couple of

[00:36:01] john gannon: innovation. MVPs.

[00:36:03] matt duench: Yeah. MVPs Innovation. What else can we throw in there? Biword bi buzzword business Buzzword bingo. Um, but thinking about that concept around, really, cuz I think like innovation is all around how we can help our teams move faster towards that, that common goal. That outcome of launching our product, right? So when we think about building versus buying in that concept, right, of does my team, my product management and so, or software delivery team or software engineering team or engineering team.

[00:36:32] Do we spend cycles or spend energy on building something that we maybe don't have necessarily all of the in-house capabilities for today? Or do we look at buying something that can help us move faster, that can help us innovate quicker, that can help us launch that product faster? Any thoughts or any stories you have on this concept of building versus buying, uh, that you can think of?

[00:36:56] Build vs. Buy

[00:36:56] john gannon: Build versus buy is something that comes up a lot as a product manager, and sometimes it comes up at the feature level and sometimes it comes up at more at the product strategy level. And both are very different types of discussions. At the micro level, I remember as part of our, our marketplace. We were building a lot of the management capabilities for the marketplace, uh, third party vendors to manage their, their apps in the marketplace.

[00:37:24] And there was an element of what we were doing that, uh, the engineering team could certainly have built out, or we could have used a third party solution. Uh, Zapier was the one. Uh, so it's a, a no code solution and we were using it, uh, sort of tied in with some of the processes to fire off web hooks in, in certain cases when vendors did certain things.

[00:37:48] Uh, anyway. I remember that that was sort of viewed as, as very hacky, uh, and, you know, you know, something that we, we didn't, uh, necessarily want to keep for the long term. Uh, and, and that was sort of, I, I think a few of the engineers on the team felt that way. Um, what we ended up finding is that it actually worked flawlessly for, for a couple of years.

[00:38:14] And, uh, I think it may have gotten replaced at some point. So, you know, there's, there's some things that I think as a product manager you may have an intuition like, Hey, this is more something we can just like, get something off the shelf. But, um, you know, part of it is like, even if that's possible, you wanna really make sure the engineering team understands like, Hey, these are some other options out here.

[00:38:38] Here's why they might be helpful to us. On the flip side, there was the example I gave earlier about. Uh, how we had, uh, created, uh, instead of creating a whole vendor portal to manage vendor applications in the marketplace, on day one, we, we started with a Google form and some backend scripts that one of the engineers wrote.

[00:38:57] And in that case, I would say we went a little bit too long in terms of like running with that versus starting to, to build out that, that actual kind of application for, for those vendors to use. Uh, I, you know, I don't think we were, uh, you know, many months late, but there's probably like a month or two where it was like, it got kind of tedious and painful, and maybe we should have started a little bit earlier.

[00:39:21] So, you know, you can sort of see on both sides of the ball. That's not really a, well, I guess it is kind of a build versus buy, right? Instead of building. Uh, an app right away you are, uh, I mean, you actually, you're getting a Google form for free, right? You have to really pay for that. But it's, uh, you, you, you bought a free thing to help you solve the same, the same problem.

[00:39:39] matt duench: To introduce another buzzword because, uh, you know, why not? I think, uh, we're, we're up to four now, or this will be four, but when we think about this, this theme of innovation, um, and this, this buzzword of disrupting or being a disruptor, right? What's, what would you say the importance of being a disruptor in, in the tech industry is and, is it more important for a large company or a smaller firm to be the, like, be more of the disruptor to disrupt more?

[00:40:05] john gannon: You know, that's where I think culture and leadership comes in. Do you have a culture that's willing to engage in those conversations? And actually you, you're not gonna pick every single wild, random idea that comes through, but like to really believe you work at an innovative company, you have to see some of those stories emerge and some of those, those new products emerge and, and, and get worked on because folks who work in tech, they generally like to uh, they like to work on new stuff, right? A lot of engineers, if you're like, can you work, do you wanna work on a brand new product? Or like, do incremental improvements to an existing, like, it's always gonna be the first for like 95% of them, right? Same for product nature. I mean, I was the same way. And so if people don't believe that that is an opportunity where they are, then that that larger company's just not gonna have any real chance to disrupt. And, and those people are probably gonna go elsewhere and, and do that somewhere else.

[00:41:01] matt duench: I think this has been really good so far. Um, so just quick hits will be around like fun stuff, you know, things you're thinking about, what you wish you would've known in the past, et cetera. Um, so first question I'll start off with is a fun one and kind of like a bridge or a segue to what we were talking about around in innovation. What's the number one tech development that you're most looking forward to?

[00:41:21] john gannon: I am super excited about where AI is going. I, uh, leave, uh, chat, GPT open on my computer all day, and I'm using it pretty much every single day to get real work done in my business and, and I'm only scratching the surface. There's so many other things I could be doing with it related to my business. I just like haven't been able to yet just time-wise. And so I am just so excited to see because pretty much every company is gonna implement, you know, I would say chat GPT is sort of the leader in open ai. Right. I, I think over the next 24 months to see pretty much every software company like implement that to enable new use cases. It's just gonna be really awesome and exciting to be in tech cuz like every product you use, you're gonna see, oh, now it does this like really cool thing because of, of AI and it's gonna make me so much more productive or allow me to create things I couldn't create before. Open up new product opportunities. So I'm like a full, I've drunken the Kool-Aid on ai. 

[00:42:28] matt duench: I can't believe we made it to the, nearly the end of this episode, and we've only just mentioned AI now, but I fully agree with you that's, that's something that I'm really looking forward to as well, is I think just the developments that we're seeing daily in, you know, LLM models, new ai, uh, plugins, et cetera, things that are coming. I'm super excited about that. Next question. Uh, what's the best tech advice that you've ever gotten?

[00:42:49] john gannon: If you don't mind, I wanna flip that in terms of the best tech advice I would give. And so for anyone who's building, uh, a career in tech, broadly defined, I would say, uh, learn how to manipulate data from the, uh, command line. So if you use a Mac or you know, windows to a certain extent, but you know, I would say more, it's more applicable for Mac users is cuz one of the things I do all the time is, I take files, I need to, um, sort of reformat them or like get an answer outta some data.

[00:43:28] And it's, it's, it's the type of thing where pulling it into a spreadsheet is like, it's like a little too cumbersome. And frankly, I'm not that great with spreadsheets, but, uh, I have a system administration background, so I know a little bit of command line stuff, but here's the rub. Going back to the AI thing we just talked about, I am finding myself constantly going to chat G p t saying, here's a line from a file. All the file lines look like this. Tell me how I can make sure that I print the second field in the fifth field of the line, and it's like almost always gives me exactly what I need. And that's crazy to me because now it's like, wow, I just became 10 times more productive, a thing that would've taken me an hour to go and stack overflow and look up and hack around with literally this thing spits off the code.

[00:44:15] And so I'm super excited about that. Some people, I think, also kind of fear that, which. I understand, but just the, the impact in terms of productivity is, is just gonna be huge for people who really do start to experiment with these, these technologies or, or use them in products that are gonna start to implement them over time.

[00:44:35] matt duench: Definitely, definitely agree. I think you get to understand how when you ask better questions, you get a better output and it just iterates on itself, right? You get the output, you're not happy with it. You ask better questions, you get a better output. Uh, it's just, it's just amazing where that text's going. What about the, uh, your favorite thing? What is the favorite thing that you're either reading or watching right now?

[00:44:56] I'm not doing a lot of reading or watching right now, other than the Boston Red Sox, but, uh, I don't think that's maybe, uh, relevant to the conversation.

[00:45:03] Well, it would be cuz I'm a Jay's fan, so.

[00:45:05] john gannon: Oh, okay. All right.

[00:45:07] matt duench: You had to live anywhere in the world, where would that be?

[00:45:10] john gannon: So I'm in New York City and I'm super happy here. So I, uh, I, I'm, yeah, I, I think I'm already, I'm already there. Uh, wouldn't mind, uh, maybe having a place somewhere, uh, warmer in the winter, but, you know, I think in the coming years, maybe that's a possibility. So I can scratch that itch.

[00:45:27] John, thanks again for joining this episode of the Mistaken Identity Podcast. Maybe give our listeners a sense of where they can find you online. How do they stay up to date with what you're working on?

[00:45:36] Yeah, happy to share that. You can go to john gannon blog.com or on Twitter, I am John m Gannon, and either of those places are a great way to see what I'm up to.

[00:45:49] matt duench: Awesome. Thanks so much again for joining the podcast.

[00:45:51] john gannon: Thanks, Matt.