Episode 9: Product Management and Beta Programs

Jon Janego, GitHub

Episode 9: Diving into Product Management with GitHub's John Janego

In the 9th episode of the Launch Gravy Podcast, host Larry Weber speaks with Jon Janego, a Senior Product Manager at GitHub. They discuss John's extensive background in cybersecurity and developer tools, his transition into product management, and his role at GitHub. Jon elaborates on working with the GitHub supply chain security organization, specifically within the dependency graph and dependency management tool, Dependabot. The conversation also explores the intricacies of product management, including managing stakeholder expectations, the importance of beta programs, and maintaining effective communication with engineering teams. Jon concludes by offering valuable advice for those new to product management.

Connect with Jon Online: Jon’s LinkedIn

For more of the Launch Gravy Podcast, watch on YouTube, or listen on Spotify, Amazon Music, and Apple Podcasts

Connect with Launch Gravy on LinkedIn

Transcript:

• Introduction and Welcoming GitHub's Jon Janego

  Larry: Hey everyone, and welcome to the launch gravy podcast. I'm your host, Larry Weber. And on today's show, I'm going to be speaking with Jon Janego, a senior product manager at GitHub. Jon has an awesome background that is steeped in cybersecurity, application security, and developer tools. And I am super, super excited to dig into his world of product management.

  Hey, Jon, welcome to the launch gravy podcast.

  Jon: Hey, Larry, thank you for the warm welcome.

  Larry: All, good. All good. So, let's dig in.

  And prior to that, as a research analyst at Silicon Angle and the cube, Jeff, so glad to have you on. Welcome to the launch gravy podcast.

  Jeff: Hey, Larry. Great to be here.

  Larry: Hey, so, so let's get into it. Tell me how you got to where you are now. Get into what is your origin story here?

• Jon's Role at GitHub

  Larry: You are a senior product manager at GitHub. Can you tell us a little bit more about your role, your responsibilities there, and maybe like a brief overview for folks, maybe all three people out there that don't know what GitHub is.

  Jon: Yeah. Okay. So, so I work at GitHub. GitHub is the home of open source. It is the world's largest source code hosting and a [00:01:00] developer tools product in the world. It's been around for over a decade and is where software developers of all sizes, all areas of expertise from students to professionals do their software development almost every day. I've worked at GitHub almost a year. And as you said, I worked in developer tools and at other companies before that. So, I get up specifically. I work on the security products team. I work in the GitHub supply chain security organization on a part of the portfolio called the dependency graph and a tool called Dependabot, which is the world's largest used platform. SCA tool.

  Larry: So SCA for those that don't know it. What is SCA?

  Jon: SCA is Software Composition Analysis. It is a way to analyze an application for potential risks in the software dependencies that it's using and GitHub as [00:02:00] host of literally millions of software repositories, checks the contents of those repositories for potential vulnerable, dependencies that they're using and automatically suggests fixes to those dependencies to make the world have a much more secure environment.

  So yeah, that's what I work on and get help. It's been great so far.

  Larry: No, that's great. Yeah. Sorry about that. When I hear the acronyms, it's like things that come, come common to us sometimes. No, it's all good. It's just education for the masses here as, as we get out there.

• Journey into Product Management

  Larry: So, so a question for you specifically on product management, can you tell us how he got into this as a profession?

  Jon: I personally got into product management through the practitioner route. It's kind of like a second career for me, I guess, if you want to think about it like that. I started up my career in systems engineering and systems integration and then moved into a consulting [00:03:00] role. Then I moved into working for an AppSec product company.

  And then while I was at that product company, I managed to talk my way into my first product management job. And it was mostly just due to, I think, having experience with the, with, within the industry and like a lot of experience with the product and a lot of experience with customers, having been in consulting role.

  And then I guess it's been, you know, the rest is history. So, I think my path, I think is, is like, I I've met a lot of product managers and I think people come at it from kind of two paths. They either come from like the, my path where they like were in the industry as like a user and then somehow or another got connected to a product.

  Or they come at it from the, I don't know, the business and marketing side where like they're an entrepreneur or came on marketing. And then from that point, got involved with the strategy parts of the software business. I think by both have their strengths and [00:04:00] weaknesses also. But, um, yeah, this has been going well for me so far.

  It's been almost, almost a decade, actually.

  Larry: Oh, that's awesome. Question for you is coming in from a user and kind of an expert and then you're like, move into the product management. Did you, part of the catalyst for that? Was that, did you just, man, the product's not working that great. I want to fix this as a user, or is it more, I want, I want to control over the future.

  I want to, I want to build, you know, like, like what, what was some of the inner, inner feelings for that? I always, I always questioned that.

  Jon:. Yeah. Yeah. Um, it's, uh, I mean, to be honest with you, it was probably a little bit of both of those things. You know, it was. And a little bit of it was just sort of the career strategy side of it too.

  You know, like I think having been a user, like I had a pretty strong perspective on what was good and what needed improving in the product I was working with and having been in consulting, like a lot of the times I was working, like [00:05:00] help with implementation or using a lot of other software products in the, in the same market.

  I had a pretty broad perspective on what the strengths and weaknesses within the industry were. I think. That kind of gave me the idea that I would be, I'd have a, that my perspective was a valuable one to continue to help grow our business there. Then I'll, like I said, because I mentioned from the career perspective, like I said, I was in consulting and.

  In engineering role where I wasn't internal systems, I was always traveling and working with customers and stuff. No, part of me was looking for a little bit of an out from that role. Like I was starting a family at the time and looking for, well, looking for something a little more stable. And I think from a traveling perspective, that's definitely true from a stress perspective.

  I'll say it's a little bit less true, you know, but I think it's a unbalanced. I enjoy it a lot. And I feel like I have a lot more control over my, um, my [00:06:00] destiny than like working as a consultant. We're just waiting for. What's your next assignment. And yeah, that kind of,

  Larry: yeah, no, it's interesting. I, my background, a long, long time ago, I did tech consulting and it's funny how I got into product marketing.

  And I think it was really, I mean, to explain complex technology so many times to different personas, different people, different users. They're like, Oh, this kind of fits. This looks like a career working on this. So yeah, someone

  Jon: can pay me to do this all day rather than the other stuff. You know? Yeah,

  Larry: absolutely.

  Absolutely. Awesome. So.

• Day-to-Day as a Product Manager

  Larry: I want to dive deeper into your maybe day to day as a product manager. And I'd like to know, is there any launch gravy and where we really start looking at kind of nuggets of detail of truth from launches, from products, from bringing things to market. And so, I'd love to kind of, cause you have an awesome background and great companies you worked for.

  Can you tell me like maybe some real-world walkthroughs of products that, that maybe you've managed and launched, take us through what the product [00:07:00] was, who is your audience and. Like from a product management perspective, what was your role and, and what challenges did you face?

  Jon: I mean, yeah, that's a, it's a good question.

  Cause I think, you know, just thinking back to when I was first moving into product management, like I would, I like ask my friends in the team, what's your day to day like, and it's actually hard to get a straight answer about it because the day to day is very, it varies from day. It varies day to day, you know?

  So, um, So it's, so to talk about, I guess, kind of what my day to days are like now and like what some consistent things have been like across my different teams has been almost always I've been paired with between one and three engineering teams. This is again, only based on my experience, but there's almost, as a PM, you usually have a, a close partner in an engineering manager or like an engineering director.

  And you kind of get, you have like what's called, I guess, [00:08:00] responsibility without authority, you know, like my, I helped the team sort of design, like what the direction of the product should be. I make some strong opinions about some specific parts of it and the longterm strategy of it, but like the actual delivery of it owned by the engineering team.

  So on a day to day basis, what that means is like working with the engineering managers very closely, just to make sure that we're on the same page about what's the current priorities, what's the current status of how things are. Are going, um, because a, I just want to make sure that their priorities of what they're working on align with what I am saying that business priorities are, and then keeping track of the strategy or sorry, keeping track of the timing.

  So that I know how to manage the rest of the launch activities around it. I think a big part of the job that I do is like expectation management of all of the different, I guess, stakeholders, both internal and [00:09:00] external, and serve as a little bit of umbrella for the engineering team of making sure that they can stay focused on.

  Doing the hard work of actually writing software. And then I get to do the work of about that software and telling people when it's going to be ready and telling people that it is ready and how great it is and all that stuff. So day to day is, is a lot of staying in sync with, with them. A lot of like, but then, you know, there's of course, how do I decide?

  Like, how, how do we decide what the strategy is? Right. You know, um, yeah. So from that, there's a lot of, that comes up in a lot of ways, talk to customers as much as possible. I don't think I've ever turned down an invitation to speak with a customer. Those conversations kind of come up usually through talking to sales people or talking to user groups or meeting people at conferences or other sort of public settings like that.

  I also do like outbound reach out through, you know, like, uh, public discussion posts or public or like email soliciting some [00:10:00] feedback and stuff like that. So meeting with customers to just understand their needs and trying to aggregate all of the feedback I get from those people into something that's coherent of a strategy.

  And then there's also like the paying attention to the rest of the market and like rest of the And it's not slacking on the job. If I were to go surf. Around all of our competitions, websites and understand what they're up to, or watch YouTube videos of demos of their products or try out their own products myself and stuff like that's part of the job to understand like, what are other people doing?

  What, what, how does that relate to what I'm doing? How does, What can we do differently from them that's going to make us differentiated and, and that kind of thing. But

  Larry: yeah,

  Jon: I think it's an interesting mix of internally focused activities, like managing expectations without internal stakeholders, managing the work, progress, keeping track of progress, reporting status and all that kind of thing with.

  [00:11:00] Also talking outside to everybody else to make sure that what we're doing actually makes sense. Yeah. That's kind of the day to day. I don't know if it, that it's still as if I were talking to myself a decade ago about what my day to day is like, I still don't think I'd have a clearer picture of what it was, you know, but, um, And there's every day is different, I guess, you know, but it always revolves around those types of activities.

  Larry: No, that's great. It like you touched on one thing. I want to ask a question to drill down on one of them is around, uh, conflict and potential conflict with engineering. And it goes, Hey, we do this. Engineering does that. But like, can you talk us through a little bit on how you would actually get through an impasse or you don't have to name names or anything like that.

  But it's more like one of these things is like, how do you do that? How do you get through that?

  Jon: Well, I guess conflict usually comes up in a couple of forms in my job, like working with engineering specifically, it's usually about, in my experience, it's usually been about pressure, I guess, you know, like [00:12:00] I'm getting pressure from something.

  So I want to make sure that the engineering team is aware of that and like why it's. Like why I think it's important customer needs or customer

  Larry: demands or something like coming down to critical situation.

  Jon: Yeah. Oh, we have a customer and they're due for a renewal in a half, in six months or something, and they're really upset about missing this feature.

  So let's talk about how we can do that. Sometimes the conflict comes up. Well, yeah, we can go do that, but we can't, then we'll have stopped doing the other thing you told us as a priority. So like, you can only have one. I think like the thing with, you know, product management and engineering management too, is, you know, like there's only, you know, there's only so many hours.

  In the day or month to, to do the actual building of stuff. Right. You know, so like, so it's always, it's always a constant shuffle of, of, of what your top priority is, you know, and you can't do everything, you know, cause like if everything [00:13:00] is a priority, then nothing's a priority, you know? So like the conflict always comes, conflicts are always.

  You know, sort of of that nature. So, but I mean, I prioritize working closely with engineering almost over everything, you know, because I think like, uh, us being on the same page, having a harmonious relationship, like will, you know, pay off in, in it'll pay off, I guess, you know, so, um, That that fortunately hasn't come up a lot in my experience, not to say it hasn't come up, but I think like how I've tried to mitigate it is sort of, um, a like staying close, closely communicating with my partners in engineering.

  And be, I guess, like, you know, empathizing with them, you know, like I think this is sort of like my, I think I have an advantage of having a reasonably technical engineering background where I can understand the, [00:14:00] like the switching costs of moving from one thing to another and like why it's not just as simple as just, you know, just do it, you know, I think I, I can really empathize with that a lot more, um, you know, Just by having a little bit more experience with it.

  I never, never put myself on the level of the engineers or the engineering managers. I work from technical ability, but like I have, I know enough to. Hopefully make, you know, my interactions with them, um, go smoother and you know, so. Yeah.

  Larry: No, it's I think resource, understanding the resource constraints and commitments and, and having that knowledge walking in specifically when you have a conflict, I think is so, so wicked important because, and having that knowledge, like you do, right.

  You, you know that going in, like, I just can't walk in there and tell them they're going to, you know, build out this new component overnight. Right? Like you understand, Hey, this is going to take a couple of months.

• Managing Stakeholder Expectations

  Larry: And, and it moves me into, it's kind of a second question here is, is the idea of, and you brought it up was over communication and keeping [00:15:00] all stakeholders aware.

  I feel that is maybe one of the most important things sometimes, and you might disagree, but of product management, it's like, Yeah, man, you're like the center of the universe, like driving the business here. And you're all these different cats in different directions. We're talking right now with engineering, right?

  We're talking product marketing, demand gen, legal, other parties that are here. And you have to be that center of the universe. So I don't know, maybe a question for you on this would be, is like, how do you personally, you know, John, how do you, how do you manage. Communications. How do you manage these different stakeholders in your own personal world?

  Jon: Yeah. Like I said before, I think a large part of the job is expectation management. So, so I think going in like taking that apart is sort of understanding what people's expectations are and then, and then like understanding what they need to know when, when they need to know it. So I think, I think the challenging parts of it, I think there's two different types of [00:16:00] communication paths there needs to be.

  I mean, I think. Like with the sales team and like the customer success team and like with the product marketing and externally oriented team, I think has a very different group of needs of communication than like the internally oriented, like with engineering and other product leaders and stuff. So. I guess I can talk about both of them.

  The, I think with the, uh, particularly with sales, because they're like an easy target. I think the key thing I think is important to keep in mind with a product manager is what is, what is, why is sales asking about something like it? Like my entire product career has been in essentially B2B, even though I work at GitHub where there is like a.

  Direct to consumer component of it. It's still mostly a B2B business. There's sales teams and that kind of thing involved in a lot of the day to day conversation with, as a PM. [00:17:00] And so B2B business, if you've never, you know, I guess for those watching who, who haven't experienced it, there's usually fairly long sales cycles.

  There's usually. Um, a fairly, what we'd call high touch sales engagement process where there's one or one or more sales people involved in sort of meeting people inside of a customer, trying to nurture the relationship, it can take. Multiple quarters to build up the relationship, to get to the point of them, of the customer deciding that they want to do business with you.

  Because these are big decisions. Usually when you're talking B2B software, it's like tens of thousands of dollars of purchases, if not, if not higher. So it's not a decision that customers make lightly. So

  Larry: swipe that credit card.

  Jon: So when I'm talking with a, so if I'm talking to an account team or a sales team, like If they're asking, say, well, customer needs this, you know, the answer, like the why behind that question or the why behind that [00:18:00] statement is usually the customer will not give us their business in the timeframe that we're looking.

  If, unless you do this thing and like the timeframe is also very important thing because there's two different timeframes at play in any B2B transaction. There is, there is the customer's timeframe in which they're willing, like looking to make the decision.

  Larry: Mm

  Jon: hmm. And then there's the sales person's timeframe in which they're looking to land the deal.

  Yeah.

  Larry: Those things may not always

  Jon: line up and like, that might, that second part may not be like the most widely talked about thing outside of the sales business, but like, it is a hundred percent true. I know enough people in sales team, they would not be upset at me for saying something like that. It's not a, it's not like a secret salespeople work on commission that's called sales, right?

  They have targets for a given quarter. Or a given half or a year or whatever. And like oftentimes, like they're trying to meet those targets on a certain timeframe. So sometimes, [00:19:00] so sometimes that's like why, how this turns into making decisions from a prioritization perspective is sort of like, well, what's the why actually here, is this a problem because the customer needs this in order to do it?

  Or is it a problem because the salesperson. Needs it to make their number. Like I've had a salesperson literally tell me, well, I'm not going to go on vacation this quarter, unless you ship this feature and I'm like, But what does the customer need, man? You know, um, and, uh, so I think like understanding sort of the root cause behind like the, that like helps understand the, the expectation management there, and I think, you know, I guess getting back to it and kind of rambling there is like, um, telling, telling them the actual, what they need to know.

  They don't necessarily always need to know the details. Like I can't. You know, I could, I could say, Oh, well, you know, engineer X is working on this feature and this sprint, and it's hitting QA at this stage and blah, blah, blah, they don't care about that stuff. They just want to know, like, when are they going to be able to [00:20:00] show it to a customer so the customer can make the decision so then they can finish the deal and move on to their next opportunity.

  So keep it very targeted and also keep it very accurate as far as keep it very accurate, because if I say, well. We're looking to land this in Q4, but you think it's actually going to land in Q2. They might make a whole plan around that thing happening in Q4 that could just fall apart if they have, if so it's most important to make sure that they get truthful information that's relevant to them, I guess.

  So,

  Larry: yeah,

  Jon: so that, I mean, that's kind of like what I was saying about communicating externally. I could talk about communicating internally. I think I almost have sort of an inverse relationship in that I try and keep things in perspective. It, the, we're writing software here. It's usually important, but it's not, it's not like a, like an international emergency, right?

  I, I think, you know, like using like the pandemic as an example, you know, like there was time sensitive. [00:21:00] Guideline or there's time sensitive needs around developing like vaccines for COVID, right? There's people dying and that kind of thing. Like when I'm writing, like when my team is working on building a new feature X, like people are not going to die if that doesn't happen, like in April versus May or something like that.

  So, but that said, there are business things associated with hitting those goals and nobody wants to. Disappoint people or look bad to your management and stuff like that. So it's kind of a careful balance there. I, I try and strike, and I think that's, we're having like open and like frequent communication with like engineering leadership, especially is important because, um, they understand like the timelines.

  I, and like the business are looking for, so then they can use that to help sort of influence the timing of their scheduling of people and that kind of thing.

  Larry: That's why we have goals, man. It's a line on these goals, these timelines. Sure. They might slip, but you know, it's that kind of the light everyone's looking towards and [00:22:00] that end zone.

  So. It touched on a couple of things and I'm going to, I'm going to segue here a little bit, but it's all related. And if you're looking at it from a communications perspective, right, and keeping these stakeholders at bay, and the one thing that's moving around here is the product. And because like, I'd think about all these different times where, you know, You know, Oh, this is coming out.

  And then is it coming out? Like sales already kind of sold it to people and, you know, it is super important to make sure we're honest internally and externally, like, Hey, keep people at bay, this is not coming or this is coming, but it's the idea around, I would say like the MVP, the minimal viable product, and the first thing that gets out there, it's a twinkle in your eye first and foremost.

  And then I'll. Oh my gosh, we have something here and it might not be perfect, but you know, that's when we start getting users and others eating from it and playing with it and getting the feedback.

• Introduction to Beta Programs

  Larry: And this gets into my next area I want to talk to you about. And that's the idea of, of something I know you've had experience with beta programs [00:23:00] where you're getting people to come on board, try something that might not be complete yet, might have some empty promises, but there's a whole program in place and how we do it.

  So. Like maybe I'll back away a little bit, but could you talk us through a little bit of your experience with beta programs and how you approach that?

  Jon: Yeah. So I've, I mean, I personally have run probably four or no, I mean, like depending how you want to label them, I guess, you know, I've run some pretty long, big beta programs that I've also been part of a large scale product launch that had a one year long plus like beta programs.

  So seen it done in a couple of different ways. So I guess, you know, like the thing with.

• Balancing MVP and Lovable Products

  Jon: If you mentioned MVP, and I think that that's like an interesting concept, especially like in, in the beta land. I, and I think I'm not actually totally sold on the idea of an MVP. I think like that might be true in some circumstances, but I think depending on the [00:24:00] market you're playing in, like the definition of viable.

  Is, is going to be, is going to, is going to be more than just a viable. Like, I think like viable, if you like play dictionary about it, it's sort of like it can survive, right. You know, but I think like survival is not enough if you're like in a, in a competitive market, like. So it needs to be, it needs to be, I guess, the phrase I've read is lovable.

  So minimum lovable product. That's something that we've been talking a lot about internally recently. So, so, I mean, I think like it's always kind of a tricky balance of in my experience, it's kind of a tricky balance of there's a couple of things with a beta program.

• Challenges of Early Beta Releases

  Jon: It's like, when do you want to show people what you have, because.

  If you show people something too early, especially in like a public beta, it might actually like work against you. Sure. On the other hand, [00:25:00] if you're launching like something completely brand new, there's a lot of value of getting that early feedback from a trusted group of users, you can sort of do the, like the, the idealized product management, like.

  Release fast, test it, release again, test it type of cycle. And I guess just to be honest, like I haven't personally been involved in, in too many where they've been like that. My experience of beta programs has usually been where we had a pretty good idea about the viability or lovability of the concept that we are putting out there.

  And. And wanted to get it in hands of people early so they could see what we're doing. It's like a directional promise. Rather than like a, a full on like testing the market, is this going to be a new business type of thing? And I think some of that has just been like my experience [00:26:00] with working at companies of different levels of maturity.

  Like I've never worked at a zero to one bootstrapped startup. I worked at a pretty late stage startup on that. I worked at a. Major big company. And now I'm working at GitHub is a pretty medium size, but mature company also. So if I was working at a brand new startup, like founding one myself or something like that, like my advice would be very different, but that's not what I work in.

  I don't have the experience in that. So I'm not going to like, yeah, sure. Sure. Yes. You can tell you exactly how you launch something as a startup when launching like.

• Feedback from Established Customers

  Jon: So when you're working in like a large established sort of B2B type of field, like it's often like you're like releasing additive features onto things that you're already doing, or you're like adding on new new products onto part of the existing portfolio, but you already have a group of users established as the core of your business, which is why.

  You're working there. I mean, like [00:27:00] you have like, yeah, meaning when I worked at, when I worked at a company called Veracode, we had like maybe 10, 000 something customers. GitHub has millions of customers, literally. So if we're launching something new. You have these established customer bases that you can go to and test things against them.

  But you're also having to frame it in the con in the context of what does this do for them?

• Managing Beta Programs at GitHub

  Jon: I'm actually working on a beta program right now for something like that. We're sort of adding some new capabilities that are fairly iterative to an existing part of the product, but we still have it under beta to get the feedback from people to make sure that like our direction is on target.

  But also to say, Hey, we heard you. We are working on this. You can have an access to it early and tell your friends about it, but just understand that it will still take us a little while before it will be finished. And I think, especially like in like. Our relationship with established customers, like that level of trust [00:28:00] is an important thing to show people also that I think I'm spoiled and working in developer tools and my customers are developers, so I can tell them, yeah, we're working on this, but it's taking longer than expected.

  And here are some of the cool, complicated, technical reasons why it's taking longer. And oftentimes they get it. They're empathetic to it because they're also developers. They're also working in a similar industry. That's not going to necessarily mean they're going to be happy about it, but at least they can understand like we're writing software.

  And yes, sometimes things go wrong and it takes longer than expected. You

  Larry: know, they get it, but you're also communicating with them too, right? You're keeping them, you know, Hey, this is what going on is going on. And I think that's, that's definitely a benefit as well.

  Jon: Yeah. And I, and I think that that's, you know, I think.

  My approach with talking with customers, especially like in the product management team is I think, I think back to when I was a user and like, I never was able to talk to one of the product managers for the companies of, [00:29:00] for the tools I was using, and I think I try and make myself accessible to customers.

  And I don't want to build this up to be like, I'm some super special person that customers should be happy to be talking to per se, but I think like. Since my job is to listen to customers and prioritize the building of things that customers are interested in or say that they need. Me talking to a customer is valuable for me, but it's also valuable for the customer to show that I, that like we as a company are listening to them.

  So I think a little bit of, you know, like a one hour conversation between me and a customer can like pay off for months or years because they remember, hey, I was able to talk with, or I was able to meet, you know. A product manager for such and such a product. And even if they don't have any direct feature requests or whatever, they'll remember that we went out of our way to spend some time with them.

  So I think that, you know, keeping that open communication with people is important, which is a cool part about working at GitHub too, you know, like GitHub is a very open company. Like you can, a lot [00:30:00] of our products are open source developed in public, like the Pandabolic image, or we just recently changed the license on it to make it even more easy to contribute to as an open source project.

  So it's particularly open compared to some other companies that I've worked for. So it's my, It's very satisfying to have that sort of align with like how I like to talk to customers too. Any GitHub customers listening, you know where to find me. Yeah,

  Larry: no, with, it's interesting too, with, with the GitHub, I'm assuming, and I could be wrong, but I'm assuming that your beta program list is a lot bigger.

  You have a lot more, Hey, at least something out of the wild. And I know it's probably open for folks versus places you worked that might've been like, Hey, we can have 10 customers

  Jon: check this out. Exactly. I mean, I, and GitHub has sort of this, um, privileged position of having a super engaged user base. But we've also built in some tools to make it easy for customers to sign up for beta programs too.

  Like there's, you can opt yourself into like the early [00:31:00] release channel. And then if you've done that, you can just like, I as a product manager can add a feature to that channel and people will just automatically get access to it. So I don't even necessarily need to. Do outreach to them. They'll just, they've already accepted that they're getting new stuff all the time.

  It's like being in the. IOS beta, which is like, you get a notification that, Hey, some new feature just came out and suddenly I've got it. So GitHub is, you know, made a point of doing that. And as a PM, like it's super, I mean, it's super great having that sort of tooling and sort of infrastructure around that versus in other companies, there's.

  More hoops to jump through, I guess I'll say.

  Larry: Yeah, I do want to ask a specific question on this. I'm thinking of the big and small companies I've worked for. And as I said before, like, yeah, we only have 10 users on this. Getting feedback from those users, usually large enterprise, or people that are already, like, using your product day to day, they'll call you on the phone and tell you.

  And that's good and bad. It's good that you're getting that feedback. It's also That's bad. You only have a head of them or a handful versus what you're dealing with as a level of [00:32:00] scale.

• Gathering User Feedback

  Larry: And so maybe a question I have for you is how do you get the feedback? And like, how do you get the feedback from so many different users out there?

  Um, so I'm giving you a throw in your shade and some of the product, is it, is it. Is it, do you have a specific feedback channel that you're expecting to then build into the product? Or are you listening to social media and like, you know, scouting out on Reddit somewhere, waiting for like vibes to come in?

  Jon: You know, it's interesting. I mean, like, I think, like I mentioned before, I mean, I get up specifically, it's like this mix of millions of, or, you know, millions of sort of individuals. Plus a lot of big companies who are also. Investing a lot of money with us too. So I think like it's, um, you kind of have this balance of, of, of individual users, even maybe students, high school students or, or younger, you know, like saying, you know, like, Hey, this thing broke my project or whatever with a guy who's [00:33:00] working at a large bank writing mortgage clearing software or something like that, like things that are on a scale wise just have very different type of impact.

  And I think the way that like. So like from, from hearing the feedback point of view, you'll rarely have a hard time getting feedback from those big customers. There's so many internal support systems around talking to those customers that. If I don't hear from the customer directly, I will hear from the salesperson and all of the customer

  Larry: support

  Jon: team who got a ticket from that customer.

  Or like that kind of thing. So that's rarely a problem, but getting feedback from larger public is actually harder than you would think it would be. I think like you can, you can sort of see the engaged users through analytics and do direct outreach to them or. GitHub has a pretty decently active sort of user forums and [00:34:00] stuff where you can see things.

  But honestly, I think that my approach has been, and maybe this is good or maybe it's bad, has been to look at proxy, like try and like proxy out what people, like different persona, like this person is this persona, this person is that persona. And also I think understanding the differences. And similarities between what the needs of an enterprise big customer are versus what the needs of an individual customer are.

  And I think like sometimes those needs are overlapped perfectly. And sometimes those needs are divergent, but I think the, um, trying to prior, you know, like sort of balancing out like those, Is, is sort of the tricky part when you're working on such a broad, a broad thing. Oftentimes, of course, you want to solve for the many, but also like I recognize like probably the high school student working on their project for fun is not really that interested in building a SAML integration [00:35:00] with the.

  With the global active directory server or something, but like, that's a super important feature for the enterprise customer. Can't spend all your time on what the, on what like the individuals need, just because that's the reality of business. Right. You have to, you have to make money. All right. Well,

  Larry: it's true.

  It's, it's a part of, it's like really understanding your customer base. Uh, I mean, it gets back to the thing about personas and things like this, isn't even like the types of users. It's like. You have your buyer, you have your user, you have your influencer, and there could be different levels of who your users are into what space and what function, and you have to weigh that out.

  And at the same time, not over indexing on like, no diss to the students, but like, if you, all the students feedback is, you know, you can't listen to just that because you do need to listen to the banks, the large enterprise, those other mission critical situations and weigh out for the product, where do we want to lie where with regards to the customer feedback and then tying that back into like, When is it ready to go?

  When can we release this into the wild? When is good enough, good enough, [00:36:00] or not just minimal lovable product, like, you know, or the standard lovable product or something ready to go. So I think, I think that's, that's all important things that someone needs to think about as, as you weigh these different feedback loops

  Jon: in the

  Larry: product.

  Jon: And I think understanding, and this is where having like a clear understanding of what your business's needs are is really important to you because the business needs of a startup are going to be different than the business needs of a public company. Public companies for better or worse always have, you know, are trying to balance growth and margin.

  Like you want to keep making. You want to keep growing your margin or you want to keep having a positive margin, at least so you can keep growing your customer base. You're trying to optimize for growth, right? Because the life cycle of a startup is you grow it as big as possible. Then you sell it at the peak of that growth.

  Somebody else who will then turn it into a [00:37:00] profitable business. Probably that's the typical software startups, you know, process. So you may make trade offs of, you may make trade offs that are optimizing for growth versus optimizing for income. You know, just to be frank, you know, like it's enterprise businesses are harder to land, but they also usually have more money to spend.

  So that's why you see companies. That's why you see companies go after that market, like a, a bank is going to have extremely large it budget. So they will, as part of the business, you, you want to try and be part of that budget spend, but if you're just trying to build something to get a ton of users. You can, you can optimize for those users.

  And that's actually exactly what GitHub did. Like I wasn't at GitHub at that time, but I've been a user for a decade plus, you know, they started as an, as like an individually targeted company, grew really, grew really big, got acquired by Microsoft and then made a pretty [00:38:00] successful sort of, Not pivot, but like a pretty successful expansion to working with enterprises as well, while also not forgetting about the individual user base.

  I think it's been. Uniquely successful as a company.

  Larry: Yeah, no, no, totally. And, and like, look, you get back to as being a user again, too. That's one of the nice things about GitHub as a company too, is you're not just like you're, you're part of the organization, but you're also your user. You facilitate, and that's not always true.

  Many companies as even a product manager, you're not actually using the product per se in the day to day, but here I use it

  Jon: every day. You can, you can, you can look at, well, At least I can look at my contribution graph and see exactly when I was on PTO. You know, like I, it's pretty busy every day making issues or interacting with customers or whatever.

  But when I'm not at work,

  Larry: yeah, doing that,

  Jon: you know, so.

  Larry: Yeah, no, no. Very good. Hey, I, I, we're getting close to time here and I know I wanted to ask you a question on [00:39:00] pricing. I'm going to hold that off and hopefully we can have a panel discussion or something at some time. But in closing, I, I, you know, we had a lot of great conversation around.

  Product management, kind of core things around it and digging into the, the products and getting it in the market and getting users and getting feedback and things like that for folks that are maybe new to product management or coming into this, or maybe they've dealt with it before and they're like a salesperson.

  They're like, Oh, what's product managers do? Like, like how do you, do you have any recommendations for maybe. People new to product management and how, you know, how they should maybe think about entering into this space and maybe bringing products in the market.

• Advice for New Product Managers

  Larry: Any advice or any guidance you would give to someone new in this field?

  Jon: Yeah. I mean, I think back to what the, some of the stuff I did when I was first as a product manager. And I think the advice I would give to myself and whatever advice I give to new. PMs that I've worked with where it's like their first job. I have worked with a few where it's like their first, you [00:40:00] know, PM job.

  And it's, it's a, just kind of shut up and listen. You know, like I think there's, there's like this, I think that in new PMs, there's a lot of sort of online scuttlebutt amongst, you know, how do I break into PM? It's like the super, there's this idea that it's like a prestigious. Job that is going to be super powerful and that kind of thing.

  And it's, it's a fun and complicated and interesting job, but I don't know if it's as prestigious and glamorous as it might seem from the outside as a, as like a, a, a new graduate or something. So I, I think where people sometimes might struggle at the beginning is they come in with a lot of super. They come in, people come in super idealistic and like with a ton of ideas and just try and start ramrodding them through the system without actually.

  Slowing down and listening to what is actually the current state of affairs. At least I know that I, I did [00:41:00] that. Like I went from being a, like a, not a user, but the, uh, when I was working, you know, when I worked at Veracode, I worked in the, in sort of the customer success team, and then I moved into the product management team.

  So I'm like, yeah, I know what all these customers need. It's like, let's start doing it. And now that's me calling the shot. I'm like, yeah, it's not quite that simple. You have to understand like what the team is actually working on. What takes time to do what they're trying to balance. Cause like you can, you don't have the full picture at any given moment, but I think, especially when you're new, you don't have the full picture, even as much as you might think that you do from doing your homework from the outside.

  So I think that that's a big part. Like I said at the, you know, multiple times, you know, trying to establish a good relationship with your engineering team, I think has been really important for me, I think I can think of no. Reasons why you would not want to have a good relationship with your engineering team.

  So establish that even if you're not near their best friend or. Understand everything that they're doing, like [00:42:00] building empathy with what they're, what their day to days are like, what is important to them. Um, and what will help them feel successful is, is really important because I think like at the end of the day, like you as PM.

  Are trying to make your customers happy and make, and by making your customers happy, you're trying to make the business successful. That's like those two things. Ideally, or like it's a virtuous cycle. And if the business is successful, that people who work for that business will also reap the rewards, whether that is just having a happy working environment or having more financial rewards or whatever it is that's important to them, but I always keep in mind like that.

  I'm trying to make the business successful and that We are all coworkers and we have different roles. I'm trying to make it successful in my way and try and support you in helping make the business successful in your way. So, um, I think that [00:43:00] that's a real important attitude to take. Um, also, I guess the final thing I would say is.

  Talk to as many people as possible. Talk to the customers, any, never turned out a customer, never walk away from a chance to meet a customer. Talk to the salespeople as much as possible. Talk to your marketing team. Like there's, you'll never know anything about, you'll never know everything about the business, but you can get like.

  You can get a finger on the pulse of everything. If you talk to enough people representing different stages of it, you're still not going to have perfect visibility into anything, but like if, if you talk to enough people in a bunch of different places, you can start to get a pretty good feel for things and having sort of those feelers everywhere, I think is really important part about being in product because that helps you build your intuition, which helps you make decisions faster, which helps you make better decisions.

  And we'll ultimately just lead to a stronger product and a stronger team.

  Larry: Yeah, no, I think [00:44:00] that makes a hundred percent sense. And I agree. And I think what you touched on with the engineering team is how I viewed when I was in product marketing, like being with product management, you have to be besties.

  And unless you were In the trenches together, working together on it. This is why I wanted to get to pricing of areas is look, there's so many interdependencies you have with these different teams. And if you don't over communicate, if you don't have these synergies, you don't have these relationships.

  You've probably been there too. I've been in companies where it's fallen flat on its face and it's been not a good experience. And the best experiences and those best launches, those best outcomes and best, honestly, Day to day living arrangements for just me being a human. And I have been, when you have those good relationships internally.

  So I'm on board a hundred percent with that.

• Conclusion and Final Thoughts

  Larry: So, Hey, John, we got to go here, but thank you so much for being on the podcast. It was been great talking with you. And hopefully we can have you back on and chat through more and dig into something like pricing.

  Jon: Likewise. Yeah. This has been great. Thank you.

  Larry: Awesome, John. Hey, take care.

  Jon: You [00:45:00] too.