In Episode 08 I am talking to Jon Janego, who shares his experience of being a product manager in a software security industry and the challenges of a young product management organization.
Transcript (courtesy of Otter.AI)
Please note that the transcription below was generated automatically and may contain misspellings and errors. If you want to help with cleaning the transcript – please get in touch!
Vlad G 0:07
This is real world product management.
Hello, everyone. This is another episode of their real world product management. And I have a John Janego. Am I pronouncing your name right?
John Janego 0:23
Yep.
Vlad G 0:24
Okay, so John, is here with us today. Thank you so much. Can you please introduce yourself?
John Janego 0:31
Sure. So my name is John Janego. I’m a product manager for a company called Vera code based in Chicago, Illinois.
Vlad G 0:41
Thank you. We don’t have a very specific agenda. So it won’t be like some of our previous episodes when we will where we only talked about data driven decisions or very specific presentation, then do the q&a. We just want to explore with john his career path. I think there’s some interesting things that I keep seeing that, personally I’ve never seen before. And he has a very interesting experience of being Product Manager in these company. And he has a really interesting experience continuously going through the market with some of the things. So those are things I’d like to explore today. So john, why don’t we start with going on the high level through your career path? Sure. How do you how do you become a product manager? How did you become a product manager? What brought you here and what are you doing?
John Janego 1:33
Yeah, okay.
Well, you know, like everybody, or most people in the field, I don’t think that there’s a real front door. And so it’s not a unusual for me to say that I feel like I came in the side door also. So I’ve worked at this company called Vera code for almost seven years now. Prior to that, I worked in consulting role in a couple in a boutique firm. And before that I worked in a large company. So throughout my career I’ve I’ve done a lot of interesting technical work and gradually started moving towards, you know, more consultative services and joined Vera code in a in a consultative services based role. And after about two years of doing that, there was an opening on the product management team that I pursued. And I feel like still I feel like I talked my way into it. And the rest is history, I suppose. I’ve been doing it for close to four and a half years now, and has been an interesting, an interesting ride with some acquisitions and, you know, seeing our company transition from later Stage startup to for to a more middle aged startup, I suppose is kind of the state that we’re in at this point. And a couple spots in the middle.
Vlad G 3:13
You mentioned john, sorry to interrupt. I just want to make sure I get this out of you. During this episode. You mentioned that your startup was acquired. Yeah, a here and there. Yeah. And I see this as a really interesting challenge for a product manager given that you stayed given that you’re, well first of all, you kept your job and second, the companies that we’re acquiring you your your startup kept the roll. Yeah. Although I’m my understanding is with the acquisition. First thing that is to go first needs to change is the business direction or business goals. So I would love for you to uncover that because I’ve never I’ve never been that situation. Yeah. If you can could just walk maybe walk me through maybe just overview of the challenges that you as a product manager experienced throughout the, through these acquisitions through this process?
John Janego 4:12
Sure. Well, so I think, you know, something that everybody in product management, at least should be keeping in mind as sort of the overall business strategy that your company is in, in terms of, you know, what’s the CEO thinking about? And, you know, how are your decisions as a PM, you know, whether it’s for a whole product portfolio or managing individual features within a product, you know, going to contribute to that business strategy. And, you know, when I started Vera code in 2013, and when I started on the pm team in 2015. You know, we’re very much in the late stage of of a startup You know, we we’re funded by, by venture capital. And, you know, we’re on the track of the typical VC startup, you know, trajectory where, you know, the number one metric the VCs are paying attention to is growth, not not terribly focused on profitability, not terribly focused on anything other than than growth as an overall metric. And you know, that that had been informing the company’s decisions as it informs many startup companies decisions, in terms of the product priorities that they take. For various reasons. The startup stage of our of our company effectively ended by being acquired by a very large software company which which was a an unexpected, but not not actually that that terrible of an outcome to be honest with you.
Vlad G 6:05
The not great, not terrible?
John Janego 6:07
Well, you know, I mean, everything. Everything’s got pros and cons, I suppose. But I mean, I think as a whole, it turned out to be pretty, pretty benign, I’ll say. But I think one thing that was good about it, and, you know, our, the company that acquired us, a company called ca technologies, it’s one of the largest software companies in the world has been around for decades. And, you know, they, they were very progressive in terms of their approach to acquisitions. They were they were acquiring high growth businesses and basically, you know, funding them to continue on that on that growth trajectory and to, you know, gradually start nudging them towards the path of, you know, becoming a more stable part of the overall company portfolio. And so, you know, in many respects, you know, Our our point of view as a as a startup didn’t change all that much when when we were acquired because our acquirer basically said, you know, here, you know, we’re, you know, we’re invested in your success, you know, we just, we just paid, you know, a decent amount of money for you and, you know, you guys keep doing you, we’re not gonna mess with you, as long as you keep up your, you know, your growth plans and, you know, figure out a way to, you know, make this a mutually beneficial type of thing. You know, what we didn’t see coming was that about a year and a half after we were acquired, a CA itself was acquired by a much larger company called Broadcom, which, you know, made the news as being one of the largest all cash acquisitions in history. also made The news because Broadcom is traditionally a hardware company acquiring a an all software company. So, it was very odd I suppose for lack of a better term. And it was especially odd for us in the, in the part of in the part of CA who had been on the acquire e side, you know, you know because we’d been kind of doing our thing and, you know, unexpectedly had this large hardware company as our potential new owner and long story short, they decided they didn’t want anything to do with any of the you know, these startup parts of the CA business and and spun us and and several other parts of the business out and we ended up being sold By Broadcom to a private equity firm who is now our financial backing. So for those of you who have may have heard about private equity and, you know kind of has a bit of a, sometimes a negative connotation to it. Our experience with private equity in our firm is Thoma Bravo. It’s one of the largest PE firms in the world. And they’ve been excellent. They’ve been very positive and, and only only good things from my perspective, but one thing that all PE firms share in common is, is you know, they’re focused on uh, on, on profitability and focused on getting a solid return in a relatively narrow time frame compared to those in the venture capital world. You know, we had typical VC investors going on timescale of, you know, eight plus years. Whereas private equity looks at things generally from the four to five year lens. And after what after those four to five years, they may continue on with the investment. But you know, they want to see, they want to see progress in four to five years. So this is a long, a long meandering way to talk about, you know, orienting the company from from focused on growth as the prime metric driver to focus on both growth and profitability.
Vlad G 10:33
And if you have to pick between the two, you try and balance them, but you know, profitability is still a really important thing to take into consideration. So, no, it made sense. Sorry, it made sense for me that he went all this way to explain kind of like tell a bit of a history, because it makes sense in terms of your responsibilities as a product manager, to kind of address like, Hey, this is why we stop caring about AIG and started caring about a and b.
John Janego 11:03
Yeah, exactly. And, you know, I think, I think for me personally, it hasn’t, it hasn’t had to, as it made a lot of changes in the, in the way that I’ve addressed, looked at the product roadmap and sort of think about the strategy for for our portfolio, but I think it’s important to keep that in mind at the business scale level in terms of, you know, think about, you know, if I have to pick one or the other, you know, what do I optimize for and also thinking about that timeframe, you know, because, you know, in, in the VC world, or in the startup world, you know, it’s it’s sometimes a little ambiguous, you know, what you’re, you know, what your goals are, you know, what the timeframe in terms of like an exit horizon is, at least it’s, it can be ambiguous and like, You’re part of the executive team. And even within that executive team, it’s sometimes you know, it, you know, it’s, it’s not always completely everyone’s not always completely aligned on it sometimes and within, within this situation, you know, everyone kind of is on the same page of, you know, we’re trying to, you know, we’re trying to make the company as as grow as much as we can and, and keep it as profitable as we can. Which I think is I mean, overall is it’s a it’s, it’s, it’s nice to have that clarifying, you know, you know, where you stand type of thing.
Vlad G 12:42
Oh, definitely. Yeah. I agree with you. It’s always it’s always nice to know where you’re going with this and especially when you’re talking to C level execs and a try to understand. So what is it that we’re doing again?
John Janego 12:56
Yeah, exactly. And you know, and I’d worked at a start up Before that, like was acquired, like, a couple months after I left and it, it had never been spoken of frankly, like, what the what the plan was, you know, from a liquidity perspective, you know, and so I think, you know, I was probably a little naive about it, you know, but at the same time, it’s it’s like, once you’ve been through an acquisition or, you know, a couple acquisitions, you know, you start learning a little bit about, like, the business aspect of it in terms of, you know, this is, you know, this is this is how these things go. And this is what you need to be thinking about in terms of, you know, in terms of, if you have to optimize for one or two things, here’s what you should really be focusing on because that’s what the people who are paying, you are really focused on, you know, funding you rather, you know.
Vlad G 14:01
Well paying for you or funding you. Yeah, yeah. Same thing.
John Janego 14:06
Well, one’s pay for us. But you know, the the equity firm is the one funding us. Yeah.
Vlad G 14:14
Oh, I see. Yes. The Thank you. Yeah, that’s, it’s an important distinction. And I agree with you. Makes makes sense. Alright, so having said all that, and you mentioned that at some point, after the first acquisition, your job or your focus didn’t change much. But then at the second one, it did. Yeah.
John Janego 14:39
It did a little bit. You know, I think I have a pretty luxurious position of having one of us of having a pretty strong performing product. Um, I’ll say some of the things that I that I observed just through the course of acquisition was there’s um, You know, there’s changes in the company and you know, just from a personnel perspective and you also learn about your coworkers on things that you may not have otherwise learned about them, I guess also is one way to say you know, just in terms of, you know, people’s attitude towards work, people’s tolerance for risk, that kind of thing, you know, you know, and some people are more comfortable working in startups and you know, after an acquisition, just want to leave, you know, they consider the exit to be, you know, the prize and then go to the next, you know, the next opportunity to do it. Some people are more interested in building the long term, you know, thing or, and, you know, and then other other people are justifiably a little I’m sure about what to do you know what this all means for them on a personal level to, you know, when when you see these type of things happening. So it’s a, you know, it’s, it’s, it’s interesting, it’s an interesting shared experience that I think I learned a lot about myself and a lot about just business, I guess, just having been a part of and paying attention to it, you know, and as a, you know, I want to be realistic, you know, a product manager isn’t is not like a critical person at the negotiating table when, you know, these things are happening. But you know, I think in a way, won’t be I wasn’t negotiating our exit or anything like that. But you know, like working and working in this part of the business, you have a little bit of a wider angle perspective on things so you get to empathize with those how those negotiations happen and can think about is sort of like the Yeah, maybe this actually is the best thing. For us, or, or whatever, you know, which you know, other parts of the business, you may not think about those or if you think about them, it’s it’s not as part of your life. It’s Sorry, it’s not as part of your job, you know, it’s like, it’s my responsibility to think about these as part of my job. So it’s been an interesting learning experience that I’m glad to have been a part of for sure.
Vlad G 17:21
I can somewhat relate to that. And again, somewhat being the key word here I was I was present in some of the negotiations, not at the exit, but that the Partnership negotiations, I was somewhat present again, not on all of them. And and it was definitely an eye opening experience. So for the folks who don’t have the folks who don’t participate, the folks that are not present, everything seemed to be very shady. And what I’ve learned is my personal my personal view on that, nothing is what it seems absolutely nothing. thing you think that’s going on there is going on there looks like a completely different picture, whatever you’ve imagined yourself. It’s not what you think. Yeah. This is one of those cases when it’s totally not what you think there are other things that are happening, but not what you think.
John Janego 18:16
Yeah, I think the other thing that I would add on to that, you know, if anybody is in a startup, that and seeing this kind of thing happen, or you know, experiencing it themselves to be like, don’t take anything personally, that that goes on, whether it’s at the large scale level, you know, like, if your company is acquired, great, you know, or, or if it’s at the personal level, like, you know, your boss can’t tell you about what they’re doing on their last business trip, you know, like, that’s just how it is, you know, there, especially when it comes to, you know, high stakes financial transactions. There are there are laws and there rules and there’s a lot of people’s livelihoods tied up in it. So people are often operating under some pretty strict things that they can cannot say just so they don’t screw it up. You know, like, you’re talking about hundreds of millions of other people hundreds of millions of dollars of other people’s monies. Yep. You know, so one, one tweet by a pm who heard about it could screw up the whole deal, you know? So it’s, it’s businessman, you know?
Vlad G 19:37
Yep. Yeah. No, I agree with you completely that on that on that front. And a lot of things can go wrong. And they sometimes they do if you’re not careful who you say, yeah. who you talk to what you say hi, even how you say it. Yeah. Okay, cool. Thank you. That was that was really interesting. And thank you for sharing that. That It’s not every day you get as a pm you get to sit at the higher table. Yeah. And and and I appreciate that we appreciate somebody sharing, what was their experience? Because I didn’t have that bash of mine. I mean, not all the time. So I think this is a good time to switch gears a little bit and talk about the actual products that you’ve worked on. Because I think there’s a there’s a story there about what went well, what went wrong, how can we you know, leverage that knowledge for you know, for the good of mankind as the whole end product manager is particularly
John Janego 20:41
Yeah. well, so I’ll I can talk a little bit about the product I work on and our company as a whole. First off so Vera code is an application security testing company. We sell software to other people. companies to help them test for security issues. We have about well, we have six parts of the product portfolio. And I manage one of those products. Our, which is our oldest one, it’s called static, static analysis. And it’s without sounding like tooting our horn about it, I’ll say, you know, we’re one of the we’re one of the most successful companies in the space. By, you know, a number of metrics, we have pretty solid growth, we have a large number of users a good opinions of us with the analyst community and you know, happy customers and stuff. So, uh, you know, it’s a it’s an interesting business to be in Just adding information security as a whole is an interesting business. And application security in particular is an interesting business.
Vlad G 22:09
Let’s let’s focus more on products and on your experience working within the portfolio. So as a person who did all of the above, I’m really curious to see, like to hear how you guys manage your portfolio being the individual product, product managers on individual products, how do you synchronize your efforts, if there is synchronization required, or the you guys run in each, each of you running in your own separate directions? with the hope that was, you know, 20 years later, we’ll get to meet somewhere down the line.
John Janego 22:49
I’ll say that, you know, we have a we have a high level, you know, product portfolio level, you know, vision that we that we’re still executing, but The individual product teams within them is sort of a parallel play type of thing. If you’ve got toddlers, you know the phrase in that, you know, you’re kind of doing your own thing in the same sandbox. And sometimes, yeah, you know, you hand a toy off between the two of you. But oftentimes, it’s kind of you’re, you’re moving in the same general direction, but doing your own thing. And, and a lot of that is, is just from a, frankly a technology perspective, you know, we have, you know, the, our market is segmented fairly into a few different product categories, which which have some degree of technology overlap, but but not often, a lot of that. So, as an individual product team, there’s, there’s frankly, not a lot of overlap between something Like the core, you know, team of one product versus another is working on. Instead, what are our one of our core, you know portfolio differentiators is is that we have a single platform through which you can access or interface with all of your all of the different testing solutions that we offer. So that sort of serves as that connective tissue between the various parts of the product portfolio. About the teams that I’m working with, you know, is is primarily, you know, focused on, you know, doing, doing our core static analysis business, and doing a deep and not overlapping with a lot of our colleagues doing their own businesses also makes
Vlad G 24:49
sense. It makes it makes sense in the larger grand scheme of things. Yeah, it makes sense because that’s what I’ve seen in most of the As I’m thinking about different industries, not just your particular niche, or my particular niche, it just seemed to be the smart thing to do when you’re not kind of cannibalizing your own your own customers, your own audience. So if you’re at all only seen one company, that kind of stuff, stood up to product teams, and had one company support legacy product. And then another company, literally was off to the races to cannibalize the existing market, from the legacy product in in a, I don’t want to call it a hostile matter, but it was kind of because of the personalities that were behind those products. It was more or less hostile matter. It was kind of like, no, we’re going to take over your customers, we don’t care about you. And and and the team was really, you know, and weirded out if that’s the if that’s the word.
John Janego 25:55
That doesn’t sound like it’d be a fun place to work, that’s for sure.
Vlad G 25:58
Yeah, it doesn’t. If it was not meeting with teammates, you know, or other teams, so it was not and it kind of, you know, it was kind of unintentional, but I have a feeling was not entirely unintentional, it was kind of like, you know, C level execs gathered in the quarter office, you know, had a bottle of wine or something, we’re like conversating. And one of them said, Hey, listen, would that be nice if we kind of like, tried to introduce both products and see which one is better? And the other one would say, Yeah, sure. That sounds like a great idea. And they did exactly like they. They said,
Unknown Speaker 26:39
I mean, there could be a certain amount of, you know, brutal efficiency to that, but it may not be the most pleasant place to be working, I’ll say, you know, so it takes a certain type of people, certain type of person to want to do that, you know, yeah. Yeah. Well, yeah. What I’ll say is, you know, Want to add on to some of, you know, what you’re asking, you know, like us as an organization, you know, you know, in spite of our teams working, you know, fairly independent of each other. We’ve been trying to align more closely, at least institution or I guess in a process wise, because because of having this shared portfolio or the shared platform layer, and a fairly complicated product, technologically speaking, there are often you know, cross team dependencies and things that, you know, kind of can come up and, you know, let one team block the other inadvertently. So, you know, our one of the things that we’ve been trying to do in the last couple years has been to, to be a bit more Organized at a, as an engineering and product team level in terms of identifying those and playing together in a in a big group, you know, because we have a pretty large engineering team we have about 200 250 engineers or so and a relatively small product management team about you know, 10 people but you know, still it’s a it’s a fairly big organization to manage across and so one of the things our team has been rolling out well has rolled out is is the scaled agile framework, which is which is which has been interesting, you know, I think I know it has its, it has its fans and it has its detractors. I’m, I’m kind of in them, ambivalent about it, honestly. I mean, I think you know, my, my observation has been that it’s It’s been, it’s been good to have a neutral mediators in the form of essentially like the product project managers, you know, trying to look at the team at what we call the portfolio level and identify cross team dependencies. And, you know, and and helping us roll out processes, you know, because if it comes you know, because if it’s being rolled up by one team onto another team, you know, that sometimes there’s you know, some feeling of, you know, who are you to tell me what I’m supposed to do type of thing and, you know, having having a neutral, a neutral person or neutral team in the middle, helping roll it out, you know, for the benefit of the organization has been very helpful. And then, you know, other sort of maybe, what might seem like mundane things, but important things like having having Are sprint calendars be consistent between different Scrum teams and consistent, you know, naming practices and amongst our releases and, you know, things like that, you know, that, you know, you can overcome those on it, you know, on a case by case basis. But, you know, as the organization scales and you know, as, you know, people, people move in and people move out of the company and stuff, it’s very, it’s helpful to have, you know, some consistent processes that are not just like institutional knowledge but in our instead is something that’s defined and you know, everybody’s kind of following you know,
Vlad G 30:44
Yeah, I agree with you and I’m not you know, I’m not a fan. Okay, that comes out as wrong. I’m not not a proponent of scaled agile, I’m more of a I like instruments. I like to apply instruments where they belong. So for company if a team is large enough, and I think you mentioned 250 engineers, scaled agile makes sense. Mm hmm. We’ve tried, we actually implemented a scaled down version of scaled agile, and I know that sounds. For us, we’re a smaller team who the purpose of scaling up. Yeah. So it was it was done with purpose. So that exactly like you said, so it’s not an institutional knowledge. It’s a standard processes. Yeah, they’re implemented within the delivery or engineering organization, with the purpose of you no matter how many people they are, you know, 510, two teams, five teams, 2030 teams, it would be still the same process and scaled agile is really good to them because it works on a small level, and it scales up really well, which is why they call it that. Yeah, I
John Janego 31:46
Yeah, I was gonna say and, you know, like, I think one the other big advantage I’ve observed with it, as has been that, you know, for better or worse, it’s documented, you know, it’s um, you know, you know, There’s not a single, there’s not like a template of how you roll out agile. But if you’re looking for a template, you know scaled agile is one of the few that actually has processes around it, you know. So if you know that you need to do better at agile, you could either you could go a couple directions, you find a freelance agile coach, you find, you know, a couple solid Scrum masters who’ve done it before. Or you could find you know, some coaches who have rolled out a process like scaled agile and then use that as a guiding principle and flex it to whatever matches your organization. You know, and I’m not an agile coach or I frankly don’t care I care most about getting products out consistently and, you know, predictably, but, uh, you know, it’s a, it’s not a religion. It’s just something that you got to use to make to serve the ultimate goal. So it’s not wrong or right. It’s just you got to be organized. And it’s hard to be organized if you don’t have a template to go from sometimes.
Vlad G 33:08
Yeah, I think I think what you’re trying to say at the beginning is that the the good part about the scaled agile is not that it’s documented is that it’s documented outside of your organization. So you can always refer to you refer to it, when a new person comes in. You can say, Hey, this is what we’re doing. You don’t have it’s not like we’re doing our own thing. Yeah, it’s just, you know, one of the public things that we’re, we’re doing and it makes sense.
John Janego 33:35
Yeah. And, and then, like, you know, if there’s ever, you know, one thing I’ve read about in other organizations is, you know, like, title inflation or ambiguity is about what titles mean or, you know, that kind of thing and, you know, at least again, like, as long as you’re not too zealous about it, you can say, Well, generally, if you’re looking at what does this Scrum Master do versus what as a product owner do versus what a product manager do. You know, the scaled agile definitions are a good starting point for that, you know, versus like, but sometimes, you know, you can be interviewing candidates and, you know, their definition of what they did have may have very small relation with what your definition of what you expect that, you know, role to be, you know, so yep. I,
Vlad G 34:29
this is this is the part where I agree with my guests. Not Not Not what I intended, but it’s good to agree on certain things sometimes. Yeah. So let me ask you this. Let me get back to you. Let me get back at you. Since you’ve mentioned product owners and product managers. Yeah. And I’m always curious to see how your organization defines those roles. Like, is there a difference? Is there a similarity? Is there an overlap? Tell me.
John Janego 34:56
It’s complicated. I think we’ve had on the even rollout of product ownership roles, I’ll say, and I think part of it is, you know, our company has a very, very strong engineering culture, you know, it was it’s a very technical product and it’s got a really very strong core engineering team and, and a lot of desire to keep a sort of a light touch between the product management organization and the engineering organization in terms of like, defining what, you know, how the, how the pieces get built, so to speak, you know, so, the product owner roles, you know, we don’t have POS for every single team and the POS that we have, you know, are kind of play closer to a junior pm role to some degrees in in terms of defining the overall You know, making those day to day prioritization decisions about stories, but but it really just depends on the team. You know, I don’t it’s hard to generalize just because, you know, I’m talking about like eight or 10 different Scrum teams and, you know, so it’s a little bit different from every team. So you would say in every team, you have a slightly different scope for the product owner role is that what it is, so the product owner roles that we have align more with the overall product portfolio and, and are working with multiple Scrum teams in the same way that a pm is working with multiple Scrum teams. The difference from a day to day basis is that ultimately the pm gets the final decision in terms of the priorities. If, or you know can cast the tie breaking vote pios do more day to day stories. Writing and, you know, Sprint working with a scrum masters for sprint planning purposes. And but we, we try and stay pretty tightly aligned, it’s a little bit more like co pm to some degree, but I’ll just say like the, our organization is relatively small, the pm organization is relatively small, especially compared to the size of the overall engineering organization that we’re working with. So, we we kind of just, we try and work as make make product owner role be as more as much of a force multiplier as it can be, you know, because, you know, like, for example, like, you know, I work with five separate Scrum teams And sometimes they have stand up at the same time, you know, so, you know, the PEO will beat it will be at some of them and I’ll be at some of the other ones or that kind of thing. You know,
Vlad G 38:10
you mean the PO would have to be on the same five teams
Unknown Speaker 38:13
sometimes but you know, we’ll split between different teams doing different you know, depending on what what needs to be done for that given
Vlad G 38:21
that given sprint or the stage of the product release that we’re at or or make make sense so so you’ll be always not really team member he the your your appeal is more like a junior product manager who’s, who cares. Let’s maybe dramatize this a little. He cares your pod cares more about the product than he does 14.
Unknown Speaker 38:40
Yeah, I mean, the product owner works on the product management team, not okay engineering team. So okay, good. Ultimately, ultimately, they’re representing the product management teams point of view, rather than the engineering team’s point of view. Gotta go. Okay. That’s not the position as adversarial but you know, it’s like that that that tension that’s always yeah prize I agree and hopefully healthy between engineering and strategy teams.
Vlad G 39:12
Right and then that’s, that’s the good part because if you know and we’ve seen this in let’s say, I seen this in my engagements when it becomes order takers, they have no say in what to do and they end up not having a say in how to do things. Yeah. So they can be actually end up facing technological challenges that are impossible to resolve. Yeah, build this with this, you know, build me, you know, make me a shovel out of sand and you looking at this like what? Yes. And this is interesting because in my head, in my experience in my product mindset that I kind of advocate, a product owner role on his on the scrum team, so product owner isn’t interface of the team between the team and the product management team or between the team and the business, but they’re part of the team, they’re not a part of the product management, they have, you know, intimate knowledge of a product, they have intimate knowledge of technology. But in my, in my product mindset, my, my meaning what I advocate for, yeah, there on the on the other side of the fence, and it’s interesting to see how you guys are still successful, which basically tells me, you know, it’s not the part where I agree with you, it’s not a religion, they just, you know, whatever the right tool is for the job. And if it works for you, then, you know, there’s, there’s truth to it.
Unknown Speaker 40:39
Well, you know, it’s, it’s, you know, it’s not like it’s all roses, and I don’t I’m definitely not saying all the all the great things that we’re doing and all of that, but it’s, you know, it’s it seems, you know, it’s it’s worked okay. I mean, I think there was it was a subject of much debate when we even because Product Owner is a relatively new role within our organization. You know, Once upon a time, it was only PMS. And we worked with engineering managers as the day to day product owners, effectively. So when we decided to start hiring product owners, it was a subject of much debate between the product, the product management, leadership team and the Engineering Leadership Team about where those individuals would be reporting into. And, as it turned out, in this case, you know, the the POS ended up reporting into the pm organization, but I’ll say you know, like, the PEO role is, you know, still needs to be a close ally and partner of the engineering team probably closer than the pm needs to be, you know, because, you know, where there’s been challenges with with various product owner roles I’ve seen has been when there were You know, there were mismatches and expectations or conflicts between the product owner and the engineering team. Whereas you know, the pm it’s it’s great if everybody’s always agreeing as a pm and engineering team, but sometimes it’s okay to disagree. And that’s normal. But the P o and the engineering team have to be mostly agreeing at the same all the time, otherwise it can go downhill pretty quickly, I think. Uh, I
Vlad G 42:39
don’t know. I don’t know. I mean, again, I’m not saying this is this is the truth. I’m just kind of voicing my opinion. What I’ve noticed from my experience, working with engineering teams, working with product owners, and working with business analysts who are Kind of proxy product owners, but not really. What I noticed is that team needs a representative. Yeah. And that’s, again, that’s just my experience. I’m not saying this is a universal truth. But you need a representative who understands the product and understands the business, but is still a part of the team. And this being part of the team is really important. Yeah, it’s kind of like a group spokesperson. Right? They can be assured. And that is done through that reporting mechanism or being a part of the team mechanism. However, the organization is structured. Yeah, they can. They need to be assured that that person has their best interests in mind. When I was product owner. I was the part of the team. I we had a massive reporting like I was a consultant, as a matter of fact, from a vendor, who was a managing team of people from the company and people from other vendors. So reporting went out of the window. Yeah, completely. All that mattered was that I As a part of the team, I am part of the engineering team, I understand the technology, I understand the pains that they go through. Yeah, but I also understand the product, I also understand the business. And when I went to bat for them, and it really was I went to bat for them against the business owner. We didn’t have a product organization, we had product owners, and we had business owners was very, very vanilla, a scaled agile framework, circa 2014. I think, if I’m not mistaken. And what happened was, team knew that they can rely on me defending their interest. So if example if a business owner says we need to do X, and Tim says, You know what, he’s crazy. And this can only be done in this way, and then it’s going to take five years to build something reasonable. Yeah, I would go back to that to that person, to the business owner. And I would say what you’re asking for is impossible, not because we don’t want to do it, but because There are real reasons for that. And I was able to communicate with them on their life in their language on their level. Yeah. But from the technology from the technology team standpoint, yeah. And that was kind of a very valuable part. And to me was the lesson, why it should be a part of the team because I wanted to be in the business side, I wanted to become a product manager. But it was very important to me as a product owner to be on the side of the team, because then team trusts me to go and do things for them.
John Janego 45:28
Yeah, I think that that’s a good point of view about it. I mean, I am, I may have missed this phrase or misspoken a little bit and saying they always need to agree, which is might be, but I think what I meant more is that they need to be on the same page, you know, in terms of trust, trustworthiness and right. But you know, I think, you know, it’s, uh, you know, I’ll say, you know, our experience has not been a smooth one with product owners and that’s not for a lack of having great people doing damages, we organizationally haven’t figured out the best way to incorporate that role into the, into the team. And, you know, the one that you described, you know, sounds like a, you know, a good model to it that we might that might be worth thinking about, you know, so I’ll say one thing that is interesting, perhaps about or maybe interesting, but you know, like our, we tend to have pretty technical product managers on our team, or in our company as a whole. We have a very technical buyer and a very technical product. So, so our PMS are often serving as proxy customers. Which is true across the entire industry, but because we have such a technical product, we have two fairly technical product managers as well say you know, so um, The EPA empathy sizing aspect and with the engineering team comes naturally to some degree. You know, I feel like I understand how our software is built pretty well. And don’t just come and say, like, do it engineers, you know, like, I don’t care, you know. But that might not always be the case in every industry, you know?
Vlad G 47:22
Yes, I agree. It’s not it’s it. I know for a fact that it’s not and I’ve seen it. I hate to generalize. But in many cases, let’s put it this way. In many cases, it It derives it from where that product manager came from. Yeah. As an example, in, in my organization, I have a lot of product managers who came through as business analysts. Yeah. So they’re very focused on the processes. They’re very focused on using the right frameworks. They’re very focused on doing things by the book, because that’s how they were brought up. I came from I was a software developer for, I don’t know, 1215 years, then I was managing software development team. And then I kind of sort of should have been a project manager by title. But I ended up doing product management work, product ownership, Product Management work. So what happened was, I came from a technology side and I could always, just like you said, empathize with the technology team, because I was a technical person, same way you guys are, yeah. And what I noticed was, I’m way more let’s say I’m really more focused on experimentation. Let’s try this. Let’s try this. Let’s try this. Whereas people from a project management background are really risk averse. They don’t like experimentation because oh my god, we’re gonna fail. Yes, you know, they’re scared of failure because my project fail. So it’s really, you know, a double edged sword. Yeah, kind of like depends on what kind of culture you have, what kind of people you have and where they came from. Yeah, so it’s a good thing. You guys are old technically. You guys are already on the same page, I think that’s a very positive thing. You just kind of, you know, need to warm up, again, from my point of view, not that you’ve asked, but I’m gonna throw that out. Or you should definitely think about how you guys build that trust relationship. And because the whole point of all these processes, the whole point of all these mechanisms, being in place, is not to is not to really, you know, resolve things when everything’s going smoothly, but to resolve conflicts whenever there is one, and there was always going to be conflicts. Yeah. And what I think was actually my next question for you would be, how do you define the product manager role and in that in the formal way, here’s what I mean. Here’s what I mean. I always say I usually say, a product manager is the one who’s not afraid to say no to anybody.
John Janego 49:56
You might be afraid, but you have to do it. Well.
Vlad G 50:00
It means it means you still saying it, right? That’s what matters. And I’ve got I’ve got some slack when you go into consulting assignment, you can really say no, yeah, to the customer, you have to say, well, there’s another point of view on that. But as a product manager, you end up saying no, because that’s the right answer. That’s how you not waste anything that time the resources. You know, you’re not you know, pretty things up note, we’re not doing this, because that’s focused on something else. And that was really interesting. Guests experience or or approach? Yeah. So what are your thoughts on what is what is it the product manager that how do
John Janego 50:37
you define the product? Yeah, yeah, I mean, I think it’s, uh, you know, when come into product management, you know, fairly late in my career, not late, but, you know, in the mid stage of my career, you know, I’ve been working for 13 or 14 years before I started in PM, you know, and, you know, I think the what really hit me when I started Uh, you know, was, you know, you’re the decider, and I know that sounds like a stupid thing to say, you know, but like, ultimately, you’re the person who’s gotta define what the, you know what the next thing is. And, and that, you know, that can vary from, you know, the, the, the aperture on that can vary depending on on on the stage of the product or the or the, you know, the the month or whatever, you know, but, you know, it’s like, what I really am trying to do is, is making the team, the engineering team, continue to have a successful product that they’re working on and make the product that that team is building continue to derive success for the business, you know, so, you know, like you I came from a pretty technical background, and so I empathize a lot with our engineering teams. You know, when I was working in software development, you know, the thing I hated the most was not knowing, you know, what my user what my users were doing or what my users thought of the product, and, you know, what impact software I was working on had on the business and, you know, so I always think about serving both sides of it in terms of I want, I want my, I want the business to do as successful as possible, obviously, and, you know, that comes with all of delighting users and, you know, elbowing out the competition and all of those aspects of business, you know, but also, you know, keep the engineering team have having success, you know, like, I read this book a couple years ago, and I’ve read it again, called the hard thing about hard things, which is one of the best business books I’ve ever read by Ben Horowitz. And you know, One of the things, one of the things I took away, one of the main things I took away from that that book is, is just thinking about your role as the leader in the product organization as as trying to be, have a sense of responsibility to your colleagues, in addition to the responsibility that you have for your users. Because, you know, if you serve your users, well, you are also serving your colleagues well. And I try and keep that in mind. In every day, you know, sometimes it’s hard when you’re in the weeds disagreeing about things, but I try and keep that perspective in mind because you know, for right or wrong, you know, you’re the person making the decisions. That’s just that’s literally the job that you’ve been given. So I try and take those decisions seriously, so that we don’t waste time on things that aren’t important. And and, yeah, they have a Good implant to all parties involved, you know,
Vlad G 54:03
makes sense. Makes perfect sense. Thank you. Alright, so let’s move on. And I, I’m looking at my little thing here that we have a list of things to talk about. You mentioned something about challenges where you ran beta programs. Yeah. And when you when you were deploying new capabilities of existing product, and that’s kind of a very dear topic to me because I, I live this every day. Yeah, with my current product portfolio. And I live this in my previous life where I had to run after people who had no idea what I’m offering and why am I even talking to them? asking them to be my beta customers, but I had no idea what the hell being a customer is. Yeah. So tell me, what is it? What is it that you do it? Yeah, in that sense.
Unknown Speaker 54:51
Um, so Vera code is a has a pretty complicated product offering where you We we offer are one of the product that I work with is effectively taking apart our customers applications written in a wide variety of software development languages and telling them potential risks that might be involved in that so or in the in the software that they’re writing. So the process of adding support for a new language is a complicated one. It’s requires a really specialized set of skills from just a straight up r&d perspective. And the other thing is that you don’t really your research can only go so far. When you’re thinking about, you know, when you’re when you’re when you’re trying to determine what risk looks like. Until you see real world applications because, you know, our researchers are excellent at something Some of the smartest people I’ve ever met, but at the same time, you know, it’s only a couple people’s perspective on what bad things that could be going on in user software could be. So we have often run what we call Early Access Programs when we build support for a new language. And one of the ways that we license our software is, is basically it’s a it’s a subscription model, and we’re releasing features every every month. And included in those features that we’re releasing as support for new languages. It’s not we don’t license by language or you know, only let you do a certain number of things. You know, that based on when you build by your license, you know, if you buy it in January, you get all the features that we released between January and you know, the next 12 months on your contract, you know, whether it’s nothing or Whether it’s, you know, support for five new languages, and the reason I bring this up is because, you know, a core part of making a language of making support for a language successful is to see real world customer applications being tested so we can understand what those applications look like and make sure that we’re reporting risk properly. And that and seeing that benefits all of our users this has been a phrase on used recently and in different circumstances, but it’s kind of like a herd immunity type of thing. You know, we’re a SaaS offering. We test thousands of applications. And it always we see patterns of risk in some applications. If we can use those patterns to inform the what we’ll see in other users applications as well. And So the tricky part though, is starting from scratch from zero, you know, if we don’t support a new language, you know, such as Python, or something, how do you go from support it or not supporting it to supporting it, while also retaining the level of quality that your users are expecting from you. And the way that we’ve we’ve been doing this as has been through these early adopter programs where we basically, you know, gauge the interest from customers who know we know that are using these languages and you know, get them to participate in by by letting us test our stuff before we roll it out to the broader audience. And I’ll say you know, it’s a it’s definitely a mixed bag a success. And partly is just a nature of the product, you know, it’s it requires engaging a lot of different members on the customer side, and Sometimes it’s difficult to find new users if they for, you know, like, our user base is often software developers. So if we’ve, we’ve sold into a company that has, say, a Java dev team, a Python dev team and Dot Net dev team, we’re engaged great with the Java and the dotnet dev team, but we don’t know any of the people on the Python dev team, because we didn’t, you know, we didn’t support we didn’t have anything to offer them, basically, you know, and then suddenly, we have something off for them. We’ve got to build those relationships within the customer to even find the people to work with and then, you know, build trust with them in order to get get them to understand that we’re offering them something new as an experiment. And you know, men, you know, meter their expectations. So, it can it can be complicated to to find that level of proper engagement. And
Vlad G 59:58
let me let me ask you a quick question. Well, can you guys have a Salesforce that goes out and builds those relationships bizdev or sells more than one of those two?
John Janego 1:00:08
Yeah. So you know, Vera code is a b2b product. And, you know, we have what I’d call us a fairly traditional enterprise sales engagement team, you know, we have,
Vlad G 1:00:19
alright, so when do you guys start? So I’m just trying to understand the process when you guys start sharing your roadmap with them. Okay. Sure. Yeah. So.
John Janego 1:00:29
So one thing that’s might be unique about Vera code is that we have a very large services organization, you know, I mentioned that came up through that organization. Yep. Initially, we have about 100 people on the services organization. So all of our customers have a customer success manager or a program manager depending on you know, the level of engagement that we that the customer needs, who’s our day to day point of contact with with that user and, you know, we publish a roadmap. That’s About nine to 12 months forward looking and we don’t publish it on public internet, but you know, we’ll, we’ll share it with customers and I’m in pretty regularly. Basically, whenever a customer wants to talk about the roadmap, I will gladly talk with them about the roadmap. And, and that’s been one of the ways that we’ve actually engaged customers, or throughout the course of learning about doing these programs has been to engage customers in them in these beta programs or early access programs, you know, via the roadmap where we say, you know, like, this is something we’re planning to do, you know, release a couple of quarters from now. So start thinking about this is something that you’re interested in and you know, start building out that that engagement early and you know, it’s it’s a it’s it’s established a pattern where we’ve, we’ve we have our users or our program managers, you know, as proxy for our users often anticipating that We’ll be in Early Access Program, whether we do one or not, you know, which I guess, is a good thing, because it’s at least the users are coming to you rather than you having to beg them salutely. But at the same time, they’ll all say, like, it’s one thing to say you want to participate, and it’s another thing to actually participate, you know,
Vlad G 1:02:19
right, how much how much of an effort is, is how much of an effort does it requires from your customer to participate in this early access program? I mean, it depends, you know, it
John Janego 1:02:31
depends on the product, you know, I mean, sorry, guys, it depends on the specifics of the given feature, but you try and incorporate them as seamlessly into the existing product as we can. Um, but it kind of will depend, you know, we just released a new feature that required a little bit more engagement because it was something that was a new thing that we that we were doing that that wasn’t related to, or that was not as incorporated with the rest of our product suite. So that required a lot more deeper engagement with the users than otherwise. Other other programs would have been but I mean, realistically, the level of engagement tends to be a lot on behalf of the product manager, you know, because, you know, as the person defining where we’re, you know, where the product is going and you know, most involved in the day to day with it, you know, you’re the person who can speak about it most intelligently, you know, not not a salesperson, not the sales engineer or not the program manager, it’s, it’s you and it’s, it’s, it’s sometimes it’s you versus you know, 50 customers type of thing. So, you know, I used to have weeks where, in the in the heat of an Early Access Program, I’ve got literally like, you know, 12 customer calls a week, you know, type of thing. Plus doing all my normal day to day job, right? You know, we’re in the backlog and stuff and
Vlad G 1:04:05
Yep, that’s, that’s normal. That’s normal. So let me ask you had there ever been the case or however you wanted to find this? When you rolled out something in your early access program, and then based on the user feedback, you had to scrap it? I said, Nope. Not gonna do it. How did you handle that?
Unknown Speaker 1:04:24
Well, we’ve definitely slowed the release of things before, um, because based on user feedback, because, like I was alluding to, you know, our research process can only go so far, you know, until you actually hit customers, you know. I’m always reminded of a quote, I heard, I think, from Mike Tyson, saying, you know, everyone’s got a plan until they get punched in the face. You know, it’s like you’re Your product may look great until you actually have a user use it and they tell you not graded. It’s you know, so
Vlad G 1:05:08
Oh yeah, I’ve definitely been there.
Unknown Speaker 1:05:10
We so we’ve definitely slowed the release of things. My predecessor in this role I know definitely canceled a planned release based on some early access. It’s hard to say whether that was the right or the wrong decision. I’m not gonna hindsight check somebody you know, who did the job before I had it but um, it’s but it’s definitely happened to all say, you know, but the converse has happened is also where we ended up just starting an EA program. And after getting some low ish level of participation, decided to just release it, rather than keep dragging out the beta program because you know, at a certain point, you can say, the real way to test the customer. response to this is just to stop letting a trickle in and just let people into it themselves. And that doesn’t come with its I mean, that that comes with its own set of problems, because, you know, you may have released it too early and had some, you know, deficiencies and stuff but, you know, at a certain point is kind of like you gotta, you know, I really try and avoid the sunk cost fallacy, you know, but you know, a certain point, you got to say, well, are we going to do this thing? Are we not going to do it? You know, so after you’ve been working on something for, you know, six months or something I’d read I’m always biased or just like releasing it. And, you know,
Vlad G 1:06:37
you see what happens? Yeah, I know. I agree. And I’ve been, I’ve been the same, I’ve been the same of the same mind. Most of the time. It’s just sometimes certain things. You’re just can’t can’t release them because although you get the data that you want, and I keep repeating this. I’ve heard it somewhere that there are no failed experience. They’re experiments reaching data. Yeah, and I keep I keep saying like, but we’re gonna learn so much even if we fail. There’s there’s a the other side of the coin here and that is damage to the brand. If you fail too much in the eyes of a public of the of your audience, they will start thinking you’re, you know, you’re just lower cool your product, you’re always releasing something. And I’ve seen this happen to do a number of brands where they you as a product manager, I can clearly see that they’re experimenting as a user as a you know, like, I don’t really care what drill I buy as long as the next holes in the wall. Yeah, I don’t really care. I I’m I’m upset that I can’t get things done or things that are getting done are buggy, or I had some issues.
Unknown Speaker 1:07:50
Yeah. I mean, Google is a classic example of that. Right, you know, like, they know,
Vlad G 1:07:56
they’re kind of like in the league of their own.
John Janego 1:07:59
Well, yeah, but anyway, Like, they get held up so much as like this, you know, super innovative tech company in which they absolutely are. But at the same time, they will, they will release half baked experiments, get users to use them and then kill them. You know, like, yeah, that’s with apparently no, apparently No, Ill effect the brand because those users are not actually the users that they care about. But that’s,
Vlad G 1:08:25
I, again, I’m not sure I would completely agree with that. And here’s why. And, again, this may be an edge case, but just just hear me out back in the day when Google introduced the Google Docs and the whole online editing experience. And I don’t know if you remember it, there was this thing called Google Wave.
John Janego 1:08:47
Oh, of course. Oh, yeah. It was insanely amazing.
Vlad G 1:08:51
And everybody, everybody was going crazy. Like literally people were dropping Microsoft Office. like crazy. People were like, Leaving Microsoft Office Oh, finally we can do stuff online. And for free, we get things for free and align and feel free. I mean, it doesn’t get any better. Right? It was it was a pretty big movement, and I haven’t checked the financials. But yeah, I think Microsoft noticed. Let’s put it this way. I don’t know how much there was financially, but they’ve noticed. And I think that I think that oh 365 is doing better than G Suite these days, though.
Oh, you just spoiled my story.
John Janego 1:09:33
So Microsoft noticed and they and they and they told me one Yes,
Vlad G 1:09:37
absolutely. Yes, you’re right. You’re right. That’s that’s what I was getting at. Not only they noticed that they took, they took care of that they created their own offering. Yeah, but the actual the actual trick here is that because Google has this notion of which is going to cancel it. Oh, you know what you have, you know, six months to get out of it and we just gonna cancel it. was something reasonably comparable was available for Microsoft, everybody ran back. And that that is a kind of a yes, Google is most innovative company, they probably spent on innovation more than next five companies in the row. But you can’t you just can’t trust your business continuity on the company that just cancels things out just because yeah. And that’s why Google Docs is Google Docs. And oh, 365 is basically every business I know is is either using a Microsoft Office, or office 365. or something of that nature. Yeah. Almost no one uses Google Docs. And it’s more or less a stagnant product at the moment. I I’m using I’m using Google docs for some of my personal stuff. I barely see any improvement from what was there three, five years ago.
John Janego 1:10:50
Yeah. Yeah. But it’s probably not core to the business though. I mean, if you look at their This isn’t a Google podcast, but you know, it’s They’re the it’s not the core of their growth. You know, it’s not a core core, right.
Vlad G 1:11:04
But it’s a product and it’s a product. It’s a very interesting product, given that, you know, Microsoft has been around for ages since last century, right? They came in, they disrupted the disrupted the industry, they’ve offered something completely new and different. And they failed to capture the momentum because their product division was off. And Microsoft kind of did the right thing. They let Google innovate they picked up the right pieces, what what worked, what didn’t work, and kaboom. Now you’re, you’re rolling
John Janego 1:11:38
well, and it shows the advantage of having a already having the large install base. I mean, the key Oh def feature of elbow 365 is how easy it is to switch from an existing implementation that’s not using 365 to two using it, you know, it’s a pretty easy migration, you know that versus ripping everything out and turning it into a new A new stack, you know, it’s a, it shows how if you’ve got a core business, it’s easier to noodle and innovate on top of it then be the disrupter, you know?
Vlad G 1:12:12
Yep. Yep. I completely agree. So, any other challenges, except, except for? Well, you’ve mentioned any other challenges with your beta customers, beta programs. Any other lessons learned? Yeah, you can share.
John Janego 1:12:26
Um, I think just, I mean, I think the the core thing that I’ve learned through the course of doing it and I’ve been doing them for several years now, you know, probably one or two a year regularly has has been that you got to decide how long you’re going to let something run and have a launch plan. Even if that launch plan is just like, simple of it’s like, you know, this is gonna run for three months and at the end of three months is GA, you know, where I’ve personally gotten tripped up. And where I’ve seen other, you know, other products gotten tripped up, you know, like, you know, whether it’s other products that we’ve experimented with in our company or other companies as has been just a poorly defined exit criteria, you know, and you got to stick to your guns on it. And I, you know, I think, you know, going back to your, we’re going back to what I was saying earlier about thinking about the relationship with the engineering team and, and, you know, doing doing good by them. I think, I think that, you know, for the, um, you know, for the good of that relationship, you need to, you know, have a plan to release it, you know, or have a clear plan while you’re in or have a clear explanation while you’re not going to release it and go in with the expectation that that might be an experiment. But you know, if you go down the path of saying, you know, here’s a new feature we’re building, and we’re going to roll it out for a quarter, and then it will be released for everybody at the end of that quarter. You know, you should execute on that, if you say, you’re gonna execute on that, and then you don’t, you know, that’ll lose confidence and, you know, that will, that will lose confidence of many of your colleagues potentially, you know, as well as your customers just because, you know, they, they, they may not know if they can trust that it’s going to be released. You know, I, I had a, you know, in the most recent Early Access Program, I was just running, you know, one of the customers I was speaking with, and it was, it was really, it was a really eye opening thing that he said to me, which was, you know, he was like, well, I you know, I didn’t want to start using it and get and like it if if I wasn’t sure that you guys were going to release it or not. And, you know, like, I was like, Yeah, man, of course, we’re releasing it. I got like, 12 month backlog plan for this thing. And he’s like, oh, That’s all I needed to hear. And then like, you know, became one of our biggest users of it, you know, but like, you know, in his mind, he wasn’t really sure. I mean, I didn’t, you know, so having just being clear with your users and being clear with your colleagues that that’s something, you know, that, that that’s what that’s what the plan is, and do your best to execute on that plan is pretty important.
Vlad G 1:15:23
Yeah, makes sense. I mean, I’ve lived through a couple of products that had that notion of promising and not releasing. Yeah. And I’ve lived through a product that was kind of the opposite. We didn’t say anything. And then, oh, here’s something Oh, here’s something else. Here’s something else. I was like, Oh, my God, how you guys doing? So yeah, I know exactly what what you mean, this that’s, that’s useful, interesting and useful. Yeah. So let me ask you this, because we are coming up on time, pretty soon. And this kind of ties in what with what you’ve been saying? How do you measure whether your initiative, your capability feature, or the whole product is successful. How do you know? What is your measure of success?
John Janego 1:16:11
So this is a actually a question that when I was interviewing for the job as a product manager with Zero Product Management experiment, I was asked in the interview, and by by the VP of the product team, and, you know, like, I gave sort of my naive answer of, you know, like, are users happy with you or, you know, kind of kind of thing and, you know, she was like, Nah, it’s, you know, the, the ultimate arbiter of success is, is how’s the revenue looking from? You know, and, you know, I think, you know, that’s, that’s true. In many cases, it’s not true in 100% of the cases. It really depends on the scope of the product that you’re in. Responsible for, but I would say it’s a pretty good, it’s a pretty good it’s a pretty good proxy of a lot of things I’ll say. And I would say, you know, to the people I know who are in product management roles that may not have, you know, direct bookings coming into their product or, or, or whatever, you know, try and understand the impact that what you’re working on has to those bookings. And if you can see that those bookings moving in the right direction, you know, you know, trying to try and determine if you’re contributing to that, you know, in whatever is the appropriate metric for that particular product. I mean, I have perhaps the quote unquote easy perspective on this, of that, you know, my product is sold by licenses. So I have a pretty easy metric of success. You know, if we sell more licenses this year than last year. It’s doing okay, you know. But then, you know, you can look at it, you know, at the other at the sort of the smaller scale level of, you know, you know, we have a lot of different individual capabilities within that product. And I would say, you know, when we’ve released support for certain features within that To try and define, you know, where you’d like to see the adoption of it within a couple of quarters, or, you know, by the end of the next fiscal year, or whatever the timeframe that you decide, is and, you know, do what you can to, you know, to try and achieve that. But, I’d say unless you’re working in a nonprofit or something, you know, actually no revenue.
Vlad G 1:18:50
I see where you’re going with this. Just just again, I think I just made that example, last episode. I don’t remember the product. So we had a core product offering and I was developing a bunch of products around it kind of complimentary slash, doing something, something in parallel to the core product. And one of the things that we were thinking would be a commercial product was some some sort of an integration. I’m trying not to go too deep into details, but it’s a retail point of sale. So it needs it needs inventory to function. And we’ve built an integration to pull in that inventory without manual input. Pretty obvious solution, pretty obvious everything yet, no one in the market has done that before. So we were the first and we give that away. We didn’t charge a single cent for it, because it did not. It did not make any sense to charge for it. Although we were a for profit company. It didn’t make any sense to charge for it. But it gave us a huge competitive advantage. Yeah. And it resulted in a huge impact. retention. Yeah. So I always say, and I was actually if I put since they’re viewing you, I would actually like your first answer better. I understand you’re unable to expand on it and and actually say things like, hey, it’s a good proxy measure for ROI or customer retention or whatnot. But ultimately, you’re right. If your customers are happy, then they keep paying you people as your product keep paying you for the product. And everything goes well, if they’re not happy, and you’re not the only game in town, which is what usually happens then they take their business every somewhere else and your ROI doesn’t look that pretty anymore.
John Janego 1:20:42
Yeah, and I mean, I think it’s uh yeah, I mean, we’re in this we’re actually just have released literally last week, which is why I have time for a podcast now. To do a to do a release a new product, which we’re not trying For it’s a, it’s included with our existing licenses. So our measure of success for that is going to be user adoption. Right? You know, but that’s, again, it’s kind of like the feature that you just described, where it’s a, it’s a delight or you know, and it will help, you know, retain customers, it could be a differentiator when looking at competition and, you know, ultimately will still have an, a maybe more difficult to directly measure but still a hopefully attributable effect on the on the, you know, the success of the product as a whole financially and otherwise, you know, you know, and you know, I think it’s you know, and I you know, I love company, culture and, you know, fun organizations as much as everybody else and you know this alright, that sounds like a stuffed shirt thing to say which I’m totally not but you know, it’s like i think it’s it’s, it’s always important to keep in mind And I think this is something that became even more clear to me just through the, the learning process of being involved in acquisitions is like, you got to keep a, you got to keep your numbers in mind, you know, because, you know, whether you’re, whether you’re thinking about it actively or not, someone’s thinking about your numbers. So it’s, it’s best to not be surprised about it, you know, whether you’re a public company, and it’s your shareholders or whether you’re a early stage startup, and it’s, you know, you’re one investor, you know, somebody’s thinking about, about how your performance is because, you know, part of part of working in in in high tech or a part of working in a capitalistic global economy is you know, the the desire to have a return on investment and that’s, that’s why we have a pretty privileged position of getting, you know, a pretty high paid job working in a pretty interesting industry. You know, we’re all working from home still working in the tech business. And, you know, that doesn’t come by default. You know, it comes by, you know, being successful financially as in this part. Yeah. Working on
Vlad G 1:23:18
Ah, that part I can totally agree with. So as we coming up with the almost at the end of the show, I’m trying to wrap up. Yeah. Other any questions for me? And that’s, that’s my regular thing. I always ask this question at the end. If you have any questions for me. Hopefully, I will be able to answer it in a couple of minutes. So no questions about how to solve the world hunger or something, something. Let’s do something simple about product management.
John Janego 1:23:47
Yeah. Well, I mean, I think just from what I’ve read, and you know, I’ve shared my point of view on this and you know, a lot of questions I see people asking on the blog. Through the twittersphere, whatever you want to call it, as you know, how do people get into product management? And you know, which I think is an interesting question to ask, but I think we know maybe a question that might be more interesting to interesting to ask would be like, what do you think people should expect to get out of going into product management?
Vlad G 1:24:22
Oh, that’s a good one. Because, first of all, no one ever asked me these before. And the second I didn’t think of that. Yeah, you know, how come I didn’t think of that? I would imagine to I mean, I can only speak for myself, I would imagine there would be some people that would agree with this. I would, but why personal like is solving problems. And back in the day, when I had my own business, I never said, Oh, we are in web design, or we were in web development. I was always saying something very weird. Like, oh, we’re solving business problems with technology. Yeah. And I think that’s that’s why I ended Doing being the product manager. Yeah. So for me, it’s this this challenge of finding another problem to solve and figuring out how to solve it. And then actually carrying that solution from an idea where I used to be stuck at to the actual solution to the execution of that solution to taking something to the market so that people can use it. Like in one of my previous jobs, I built the product. It was actually a prototype, I built the prototype, together with another developer, we kind of put it together using rapid application development, technology, not even, you know, true coding, to speak of, we kind of put it all together, we’ll show to a director of the Department that that thing was supposed to be working at. And she liked it. She was like, Yeah, okay. And two weeks later, we found out that the big since it was a prototype wasn’t an alpha or beta. There’s no security just you know, a demo of functions that was there. So she quietly introduced it to the whole department, but a couple of hundred people, and about 50 of them started using it. So I login into my own system, and I found 50 users actively throwing production data into them. And it was well first of all, it was mind boggling. Second, I got a got a lot of flack for it. Hmm. At the end of the day, that was like, I came home when I learned that I understood that you know, everything everybody’s gonna start demanding my head because it was highly regulated environment. But I came home and I for some reason I felt better than ever before it was felt very proud of myself. And the reason why I felt very proud of myself was because I found I found this solution so good. Well, not me personally, we as a team, but as a product manager found the solution to a problem. The solution was so good that people were okay with using Barely functioning prototype, right? Right, instead of whatever the hell they used before. So it was it was that that feeling of, you know, fulfillment, that feeling of happiness is what I keep feeling as I work on other products and then finding these other solutions. That’s that’s kind of a, that’s kind of a thing for me. So that’s why I keep doing product management because I’ve switched a few careers in my life. Yeah, I love this one, probably more than anything I’ve done before.
Unknown Speaker 1:27:29
Yeah, I’m right. Where with you and me, I think I found the most enthusiast enthusiastic PMs to be those who came to it after having been in other roles because you, you’ve seen multiple sides of the fence, you know? versus like, you know, if you’re 23 or you know, you don’t, you may not have a lot of perspective on on what I think This is something that you really, you know, or I hate this word and are passionate about or, or you know, that you’re, you know that that is going to be satisfying for you personally, you know, like, you know, it’s an interesting job, and a lot of people want to do it. And I think it’s a great opportunity to learn about business and technology at the same time. But that may not be what you want to do with your life. And, you know, when you when you start a job when you’re 35 or 40 you know, it’s, you know, like, I started when I was, yeah, 35 as a product manager, and I’m like, Yes, yeah, I I’m glad that I’m doing this now versus when I was when I was younger, you know, because I have a I feel like I’ve got a little bit I, you know, you can inherit the, the perspective of having done a lot of different other things and and see the value of having, being able to take things across the finish line and satisfy your users and stuff.
Vlad G 1:29:00
Yeah, that’s great. I mean, I completely agree. And I keep seeing someone this on social media, mainly on Quora, I do a lot of Quora whoring and one of the things I see there is like, well, I’m going to get an MBA and become a product manager. Is that a good enough path? Or should they just go straight to product management without the MBA? I’m looking at these guys. And I understand they’re college kids. They’re trying to map out the path for their career, but product management is not what you want. Do something else. I don’t know. Open your own shoe store. Or go hike a mountain.
John Janego 1:29:35
And I would say to anybody who’s listening, and I’m tempted to respond to the people who asked these questions on on Reddit or core or whatever, you know, I’ll say like, as the person on the other side of the table who’d be interviewing you for that role? You know, I’m more interested in like, you know, the, the perspective you’re bringing, not necessarily if you’ve got an MBA or Yeah, or whatever it’s like, it’s like, how is your perspective going to help the success of our business? And and are you going to be able to empathize with our users and help them, you know, help them succeed by building something that they that they need, and therefore helping us to succeed? You know, you’re Yeah, you know, MBAs are great. And one of my, you know, best mentors in my career, you know, came to pm after having been gone through his MBA program, but you know, like, it’s a it’s just a tool in the toolbox. You know, it helps you learn that business aspect that, but it’s not it’s not the end all be all. That’s for sure. Yeah, I completely agree.
Vlad G 1:30:42
All right. We’re, we’re at the end. Thank you so much for being on this episode. I really appreciate it.
John Janego 1:30:49
Yeah. Thank you. It’s been a very good conversation. I appreciate you having me.
Vlad G 1:30:54
Absolutely. It’s been a pleasure. Thank you, john. And till the next time You’ve been listening to the real world project management and I’ll be your host Vlad Grubman. Until next time