Episode 126: Unleashing the Power of AI in Product Management and Cybersecurity with Steve Wilson, Chief Product Officer at Contrast Security
In this episode of Product Thinking, Steve Wilson, Chief Product Officer at Contrast Security, joins Melissa Perri to explore the dynamic world of product management. They dive into the intersection of customer demands and technological shifts, how to harness the power of AI in product management, the integration of AI and Machine Learning for enhanced cybersecurity, and how product managers can meet both user needs and security requirements.
Steve is a dynamic software executive with a keen focus on business growth. With a remarkable track record in constructing powerful platforms and fostering exceptional teams, Steve brings valuable expertise in general management, product development, and marketing. Beyond his corporate achievements, he is also a distinguished author, captivating public speaker, and ingenious inventor.
Throughout his illustrious career, Steve has held prominent leadership roles at industry-leading companies such as Citrix, Oracle, Sun Microsystems, and Cassatt Corporation. His extensive background encompasses diverse domains, including product management, software development, cloud computing, and artificial intelligence. Notably, Steve played a pivotal role in shaping early concepts in cloud computing, solidifying his position as a true trailblazer.
If you enjoyed this episode, make sure to subscribe, rate and review on Apple Podcasts, Spotify and Google Podcasts; instructions on how to do this are here.
You’ll hear them talk about:
Steve is a staunch believer in "persistence of vision". He states that product managers face the challenge of managing customer demands, stakeholders, and new information while staying true to their long-term goals. Although it's essential to resist constant pivoting and say "no" to distractions, he acknowledges that certain events can reshape the entire customer landscape. As the industry questions the impact of ChatGPT, Steve emphasizes the importance of sensibly evaluating technological shifts and adjusting roadmaps when necessary. Balancing persistence and adaptability is key to achieving meaningful progress.
Steve is confident that product managers who take ChatGPT seriously will be glad they did it in a year’s time. Initially skeptical of the chatbot, he soon recognized its potential to transform businesses. His team quickly identified short-term opportunities to integrate ChatGPT into their products and improve customer engagement and marketing. They even fed product documentation to the chatbot, eliminating the need for customers to read lengthy manuals. Recognizing the game-changing nature of ChatGPT's plug-in architecture, Steve incentivized his team to develop innovative solutions, leading to demos and increased adoption within the team.
The future of cybersecurity encompasses the integration of AI technologies, pattern-matching engines, and machine learning into security products. The rising capabilities of chatbots and the sophistication of phishing attacks, including deepfake techniques, pose significant challenges. Moreover, the emergence of code-writing bots intensifies the need for proactive security measures. Organizations that promptly embrace these advancements will become better positioned to address the evolving threats and gain a competitive edge in cybersecurity.
There is a parallel between how we think about security and how we think about quality, known as the Iron Triangle. Project managers often face tradeoffs between quality, features, and time to market. Adding security as a distinct factor or grouping it with quality helps to address technical debt. Performance and quality also play crucial roles. Tackling these challenges comes down to allocating dedicated resources and effort. By involving the team in finding ways to enhance security, you can prioritize projects based on cost-benefit analysis, treating them like other tasks.
In today's industry, it's common to have a platform team alongside feature teams or service teams. Platform teams usually consist of technical product managers with a coding background who maintain a strong relationship with the engineering team. They serve two customers: the end users and the product owners of the services. It's important to understand the pain points of both customers and establish trust between the platform and service teams.
When working on B2B products, the user interface may not be as crucial as design thinking and customer empathy. Steve learned this through his experience at a startup that was pioneering cloud computing. Despite showcasing impressive features, they failed to sell any products initially. It was only when he directly asked a prospect about their problem Steve realized they hadn't fully understood their needs. This highlighted the significance of clear communication and identifying customer pain points.
Episode Resources:
Transcript:
Steve Wilson - 00:00:00:
People skills, the empathy skills. I ask this in every interview that I ask about a product manager. What's the most important quality that makes a great product manager? And almost anybody who the first word out of their mouth is empathy or something that's a direct map of that, I will hire them.
Melissa Perri - 00:00:18:
Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole, the systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perri. So when you came into Contrast, you mentioned that you had to really oversee the vision, pull it together, lead the whole product strategy. Were there any points in those early days where you had to pivot that product strategy based on any worldwide events or situations? I know security is such a hot topic right now.
Steve Wilson - 00:01:12:
Yeah, I'd say the most dramatic thing that happened as an event was just about a year after I joined. We'd been working on building out a broader version of a portfolio where we went from kind of a single product vision to building a larger platform. And there were some parts that we had pieces of, one of which was around a feature called software composition analysis, which really helped you look at open source software and is it secure. And we had some good features, but it wasn't a very hot part of the market. We were de-emphasizing it a little bit. Lo and behold what happens in December of A few days before Christmas, a major vulnerability is disclosed in an obscure piece of Java software called Log4j. Log4j is a piece of software that is so old that I was still writing code when this was first put out. It was over years old and by our best estimates, was used in a million applications around the world.
This had a CVE score, which in the security scale of It was the most severe vulnerability you could have where it was just easy to take over complete systems. So we had a very exciting couple of weeks helping customers figure out where these were and how do you remediate it and how do you fix it. And we felt like we were very successful at that. What became clear after that is this software composition analysis feature, went from kind of a backwater, was in the top of everybody's list, to the top of every CISOs list. So now all of our customers who were not asking about this feature, who maybe literally had weeks before been telling us, not top of my list, not my big focus, we kind of had to digest that this was a big change. And I think at first, maybe we were a little resistant to it. Like, no, we've gotten consistent feedback that this was not the top of the list. But really that was a point where basically every customer that we had or wanted was impacted by that in a very real way that put it on the radar of management with buying power up the list, and all of a sudden it changed the priorities. And that part of the market has gotten a boost. As a result, over the next few months, we had to retarget big parts of our roadmap. And that meant... Moving resources, it meant changing commitments that in places we'd said, hey, this other part of the portfolio, this is the important part, this is where we're placing the resources, had to push out deliveries or decommit to things so that we could move things around and focus on this part of the market that had gotten really hot. And that's a really challenging thing to do.
Melissa Perri - 00:03:55:
Yeah, for sure. And I feel like too, in some of those situations, some of the teams could be like, hey, why are we like blowing up our roadmap because we heard this thing is out there that we need to look at. And I've seen in cases where people could lose morale if it's not handled correctly. Like, what do you do to help rally the team and execute that really well?
Steve Wilson - 00:04:15:
Yeah, well, look, in general, I'm a big fan of what I refer to as persistence of vision for a product manager. As a PM, you are dealing with customers and salespeople and stakeholders and managers who come to you every day with a new thing that they heard that's the most important thing in the world. And often your job is to say no to these things and stay the course and stay true to your vision because what you are trying to get done is large scale impactful and requires persistence over time to get done what you wanna get done. And so if you pivot every time a customer says something or your boss's boss went to a meeting and somebody told him a thing, you're not gonna make any progress. That being said, you asked me a question about, was there like a world event that changed things that you had to react to? And in hindsight, this was one. This was not a customer conversation. This was not three meetings that you had at a conference. This was an event that impacted every single customer you had or could have. And so on the flip side, you need to have, be able to not just by reflex say, no, I had this on my roadmap. I'm going to stick with my persistence of vision. You have to be able to look at something like that and say it changed. And the thing actually that I'm dealing with right now is ChatGPT. That is a thing where the industry is saying, is this a flash in the pan? Is this the next Cryptocurrency, NFT? It's not by the way. But the question is, how do you want to sensible way, make decisions about how a shift in the technology landscape needs to start impacting your roadmap and start changing what you're doing.
Melissa Perri - 00:05:58:
Yeah, so what did you do when ChatGPT came out and everybody went nuts? I love it too. But what did you do to like evaluate your product strategy to say like, hey, should we be utilizing this? Should we look if it's a flash in a pan? Like, what was your thought process? Understanding it, trying to figure out how to apply it.
Steve Wilson - 00:06:16:
That's a great question. And I'd say we're still very much in the midst of this. And I'd say everybody's going to be in the midst of it this year. But I think that the product managers who are taking it seriously are going to be really glad that they did a year from now. But when I first saw it in December or January, and I'd heard little bits about it, I was I lived through a previous generation of AI stuff that I was very excited about that kind of didn't really materialize. And so I came in very skeptical. Once I really started using it, I realized this is different. And you know, it was just a chat bot, but you all of a sudden start to think about, how's this really gonna change businesses? we started getting together and talked about what are the very short-term things that we could do that would start to be impactful and. You know, across our business, some of the most interesting things is we started with like really integrating this into our products is going to take a lot of time and thought.
Using this to change how we engage with customers and generate marketing materials and things like that, those were very quick pivots where we can start to take advantage of the technology. And then how could we use some of these technologies to make our customers more successful even prior to getting it in the product? And you know, the... guys put together something where they fed all of our product documentation to the chatbot. And now you can ask the chatbot any question about how to use the product and it can answer you. The customers don't have to read the documentation anymore. And so those kinds of things, like how do you gain experience with that? But really, one of the things I did is when the ChatGPT plugin architecture came out, somebody said, this is the iPhone moment for Chatbots. Like this is the moment it takes off. I certainly lived through that. So I just went on the engineering Slack channel and I said, I'm putting out a bounty. Anybody who can get a hold of the APIs for that and figure out how to write a plugin and show it to me by next Friday gets Lo and behold, I had demos showing up in my email box by the next week. And then we used that to follow on, build a larger scale hackathon with innovation events and brown bags. And now I have a big part of the team understands these technologies and is helping build a roadmap for what we're going to do with them this year.
Melissa Perri - 00:08:34:
That's really cool. So it sounds like the point of the hackathon may not have been to exactly find the next crazy innovative thing. It was more to like teach everybody how to use it and start thinking through it.
Steve Wilson - 00:08:45:
Yeah, I mean, when it's a shift that big, look, here's the thing you say to product managers is the worst thing you can do as a product manager is just try to make a feature because there's a technology thing that's neat. But it's constant thing you fall into. Like that's cool problem. But what you do need to do is have a critical mass of people who understand the technology, who can get together and talk about it and think about it from a customer perspective. So getting it out there, getting some people inside the company who could touch it and feel it and build a demo leads to getting more people to see it and understand it and think about it. And this process we've been going through, I think we've been able to build a really interesting strategy around what we want to do, over the next months for this, where we deliver small things that have impact early, but aim for some bigger things that will actually either become product features or even one that we have in mind that hopefully creates a new market for us next year.
Melissa Perri - 00:09:43:
Yeah, I think that's a fantastic way to get people up to speed on those things. I think a lot of people think about hackathons as, oh, this is where our next innovative product is going to come out of the hackathon. Occasionally, that works, but I don't see it work all the time. But having a hackathon to go deep on something new, that's a really cool idea to get everybody building stuff with it so that they actually try it and think through it and get to learn it. That's awesome. That's really cool. I wanted to add that too. When you're thinking about AI and as it relates to cybersecurity in the future, what kinds of trends do you expect to pop up?
Steve Wilson - 00:10:19:
Well, I'll tell you the first serious thing I decided to do with ChatGPT is I decided to see just sort of a test whether this was real. What does this thing know about cybersecurity? Because it was a thing I know about, so let me ask it. Turns out it knew a lot. I had this long conversation with it the first weekend, and I realized, I think I just wrote a book.
Steve Wilson - 00:10:41:
And then what I did is I sat back and I said, if I was going to use this to write a book, what would it be? And what do I want it to be? And I sat there and I sketched out some ideas and I said, well, I'd want to write a book on cybersecurity and artificial intelligence. What's the impact on the industry going to be? Something everybody could read. So I want it in the tone of like a dummy's book. I wrote a paragraph about that, and that became the prompt that I gave to the chatbot, and I said, write me an outline. You know what it did? Wrote me an outline. Then I had a conversation over the next half an hour saying, change this, do this, do this. And eventually I got to the point, I said, write me the first chapter. And again, I had a conversation over the course of a weekend. I wrote some things, it wrote probably of the text. And last week at RSA, a month after coming up with the idea, I had hard copies in my hand that we were handing out to people at the booth. But getting back to your question, what does this really mean for security? It's something I gave a lot of thought to. I think there are serious, both offensive and defensive considerations in what this is gonna do. And it's interesting because from a product perspective, I know people in the security industry have been thinking really hard about how to leverage earlier gen AI technologies. And I worked on a product like that at Citrix, which we called Citrix Analytics for Security, where we could measure the keystrokes and mouse clicks that were going on in Citrix environment and find people spoofing other users and change their risk scores based on risky behavior. And we were actually building machine learning models of how all the users act. And it was really cool. And so you've been seeing more and more of that in recent years where people are building sort of pattern matching engines based on machine learning into their security products, looking for intrusion and things like that. What's interesting with the chat bots coming along and that capability growing so dramatically is that threat vectors are now crazy.
You know, the biggest worry in cybersecurity is sort of the lowest tech one, which is phishing. And it's email phishing and it's also spear phishing. These things have suddenly dramatically in the last few months gotten so much better. Yeah. You know, we used to joke about like the Nigerian Prince Scam, where you'd get like this little chain letter that was incredibly poor English asking you to send money. And all the phishing training you take says the first thing is like, is it really written in good English? Is it grammatically correct? Because if it's coming from somebody in North Korea or Russia, it's probably gonna show those signs. Well, they don't anymore. They're all perfect. They're all flawless. And now you look at deep fake technologies and all of these things. People can clone your voice from a three second sample. The next phishing attack you're gonna get is gonna be your spouse calling you on the phone, asking you for the bank account number and her voice and her cadence. And that's where this is all going. The next one is with these advances in the bots that can now write code, is they'll write self-modifying code that will be running around the internet. And it's already doing this, looking for vulnerabilities and your security by obscurity isn't gonna work anymore because, the things that used to require human hackers are gonna be automated and times as fast. And so it's gonna be a pretty rapid escalation in the cybersecurity space where the companies that do adopt more of these technologies quickly are gonna be at a real competitive advantage.
Melissa Perri - 00:14:05:
Wow, that sounds ridiculously scary for what it's going to be. I've already seen some of this happening and it's blowing my mind just how crazy people are getting into hacking stuff. So that's glad you're working on it. Glad you're trying to fix it. But that's really interesting. I think it's going to pose some challenges too for leaders as they're trying to think about how do I prioritize security, right? That is one of the big things we talk about with Chief Product Officers and CTO's. How do we make sure that we're prioritizing the things that you need to get done, right? Versus just the net new features and building the stuff that may be strategic on those areas. So what's your advice for like... CPOs and CTO's, when they sit down and try to negotiate this, what should they be looking at for security? How should they be staying on top of it so that they know what's coming up and what could be helping with that?
Steve Wilson - 00:14:57:
Yeah, I think in a lot of ways there's a parallel to how you think about security with the way you think about quality and every PM has had to make this trade off you know what you call it the iron triangle I got quality I got features I got time to market. You could put security in as another box there or treat it as a sort of similar super box with quality and just talk about sort of technical debt and non-feature oriented capabilities. And you could put performance, security, quality all up there with all those illities that you know make a big difference in your product. So you need to find ways to firewall off time, resource, and effort to deal with those things because otherwise they fester. And... One of my first real jobs, I did a startup right out of college for a few years, but my first real job is I accidentally wound up as a member of the Java team in the late 90s at Sun Microsystems developing Java. Anybody who's old enough to remember the early days of the web, the only thing you knew about Java was it was really slow. And later it got as a reputation for being insecure, but beginning it was just slow. As it grew, it got slower and slower and slower because nobody wanted to deal with that. And there was a point where I was still writing code and I sat with my boss and I said, well, how about if I just go fix it? And he looked at me like I was crazy. It was just, it was a constant, it's slow. I can't deal with it. I convinced him to let me spend some time on it. And lo and behold, I came back with a list of projects that would make it a lot faster. And all of a sudden that let the management team start to think about how do I prioritize what I want to do. And so those non feature oriented things like performance, like security, one approach is say, well, I'll take of my capacity and work on them.
There's something to be said for that. But beyond that, if you can start to get specific, if you can go to the team and say, how can I make security better? Not go make it better, say, how can I make it better? Let them come back with five projects. And then you say, great, what are the pros and cons of these? What are the costs of them? That gets you into a place where you can use your product manager language to talk about them. Here's the benefit, whether it's a sort of direct customer benefit, like a new feature they're asking for, or what's gonna make me secure against these things, or it's gonna make the product faster, whatever it is, I can look at that benefit and I can do a cost benefit analysis. I can stack rank it, I can prioritize it, and I can treat it like the other things I'm doing.
Melissa Perri - 00:17:32:
Yeah, so when you're looking at this too, do you try to dedicate any specific amount of time to these types of things? Like, I know some people do some boundary times where they say like of dev work or or of all dev work is gonna go towards those backend type things. Do you ever do that or is it in flow?
Steve Wilson - 00:17:51:
You know what I've fallen into doing here, which I like is we had a good conversation between the engineering and the PM teams about what do we want the ratios to be between sort of sustaining tech debt management, innovation. But then the other thing we had to do was we had to actually figure out how to measure it. And so we had to build automated systems that weren't just licking your finger and holding it up in the air where, engineers are actually entering enough data into JIRA tickets in the right ways that you can create an automated flow where you can then look back at the end of the month and say, how much time did I spend on? these different major categories. So then what you can do is you can measure it. And the first thing you do is, if you want to say it's that's pretty useless if you don't know what it is. When you measure it, it might be And it might be for a good reason. So then what you start to do is say, all right, are these appropriate to the life cycle of the product and the company that I'm in? If you're in an early stage startup and you're spending a lot of time fixing bugs, that's probably a systemic problem. You don't spend more time fixing bugs. You step back and you say, what project do I do that's gonna change the architecture so I have fewer bugs? On the other hand, if you're in line, then you start to manage to it, and you track it month over month. And if things start to get out of whack, then you decide whether that makes sense. Or if you wanna make a conscious shift where you say, I'm spending X percent of my baseline, but I want to move more on this. Like maybe I'm willing to take more risk on technical debt for six months because there's been a big shift in the market and I need to jump on it. But you make that as a conscious decision.
Melissa Perri - 00:19:30:
I really love hearing you speak about that because it's super top of mind for me right now. Like I'm deep into writing this book on product operations and it's one of the big things that we suggest is like measure what you're spending your time on. And I've gone into organizations and done that. But as soon as we start to go ask the engineers to either, you know, pull their time out of JIRA or start tracking their time, they immediately are like, no, you're not big brothering me, right? Like, what are you doing over here?
Steve Wilson - 00:19:58:
You know what I will say is that tracking time causes engineering allergies. My view on that though is it's not about any individual engineer, how they're spending their time because they're terrible tracking that anyway. One of the reasons we went to things like t-shirt sizing for features is because statistically it doesn't matter to be more specific than that. If you're dealing with story points and t-shirt sizing, and adding those up at the end of the month, it's probably as good as having somebody time track. I think actual time tracking gets really demoralizing for the engineering team, so I don't do it.
Melissa Perri - 00:20:36:
Yeah, totally agree. So I was gonna ask you what your system was, cause I feel like even sometimes they get allergic just like being measured. So we'll go to, you know, T-shirt sizing or things like that. And it helps a little bit, but I've always tried to explain it to them. It's not about holding you accountable to a date. It's about me being able to see, hey, if we take on this work, is this a one-year project or a two-year project or a three-year project or a two-month project or a two-week project, cause we can't really gauge it. So I feel like people don't start it cause they're worried about that time tracking. What do you do to kind of automate getting those insights? Like what kind of system do you use and how do you kind of translate those T-shirt sizes or anything else into something where you can look at it and say, oh, this is like something that's gonna take a quarter or this is something that's gonna take a month or something like that.
Steve Wilson - 00:21:22:
I'll be honest, there's still a fair bit of art in terms of how that works. And for me at my level, I've gotten to the point where I'm pretty dependent on having a strong management team that's able to combine some real world data with a lot of real world experience. And I'd say coming into this job, I had some parts of the engineering team that were more mature than others. And there were times where I felt like I just had to say like, look, I know you've been here for a long time working on this and you say it's going to take that long, but I don't believe you. And people would just look at you aghast and I'd say, I've done this for a long time. I know I'm new to this and you try to be somewhat humble about it, but I'm like, I just don't believe you. Let's go back to the drawing board. Let's get a little more specific about that and break it down so we can look at it. And I think as a leader, you need to have the guts to be able to say that. Over time though, as you do get your teams more coherent, you get them stable, they're working on things for a longer time, they will better self estimate.
The other things you need to do though, is build a high degree of trust between your product management teams, your engineering teams, and ultimately your sales and customer success teams, where you want to be able to set aggressive dates for things and say, we should be able to get this done in days, and I want to, but I'm not gonna tell you it's gonna take so that I'm sure it's gonna happen. So I wanna be able to press the teams to be aggressive without setting the wrong expectations with things like sales, customer success, and even customers themselves. And so you have to build in that balance where you're able to, especially with your internal teams, really clearly communicate about what you're trying to get done, what the expectations are, and keep people in the loop, as you run into unexpected consequences or things that get in the way.
Melissa Perri - 00:23:18:
Yeah, so build the trust and then we can actually talk about things and it's not like somebody's going to get punished for missing something by a week at the end of the day.
Steve Wilson - 00:23:25:
It's amazing. You can be in a job for two, three years and have somebody say something like that. Well, I'm going to get beat up if I don't make this schedule and say to them, we've been doing this together for three years. You've missed five schedules. Show me the bruises. They're not there. And they'll kind of go, okay, all right. But people do have that. I think they get trained into it really early in school where you miss an assignment and there's a deadline and people are scared about it.
Melissa Perri - 00:23:50:
Yeah, that's a good point. I never even thought about that, like, stemming from the school days, but that makes a lot of sense. So with your team too, that we were just talking about, a lot of the work that you're doing is kind of like that unseen product development, right? It's what we talk about in other organizations as backend product development. Stuff that's not sexy and has like a cool UX and you can swipe through or anything. And a lot of organizations, I think struggle with how to collaborate between platform teams that build things like security and the user-facing team. Or how do the platform teams do product management, right? Like a lot of those questions pop up. So for you, when you're working with your team, how does product management, I guess, differ doing some backend products versus, you know, the things that have a super hard and fast UX or a lot of workflows that you can test really easily with the user and just see if they can use.
Steve Wilson - 00:24:43:
Yeah, well, I think there were two questions embedded in there, so I'll tease them apart a little bit. So one of them was when you talk about having a platform team versus feature teams or service teams. That's a really common thing these days. My last two big product areas have been built like that. Both the Contrast Secure Code Platform and Citrix Cloud, which is what I worked on last, were both SaaS products built on a common platform where we had multiple services that we sold distinctly. And we had different product management teams that maintained the platform versus the services. I think that your platform teams As a rule, not surprisingly, tend to be more technical product managers. They tend to be not always, but often ex-engineers who kind of came up through a coding background who can have that very sort of shared relationship with the engineering team, but need to have that more customer focused vision and who can also hold in the head the fact that they have two customers. One is actually the end customer who will see their services bleeding upwards, whether it's the identity management service that actually is running the login screen, which is the face of the product.
Their other customer are the product owners and PMs on those services. And so you need to be able to keep both of those in mind, that true end user customer, and your internal customer, which is using your services. And they're a very cranky set of customers because they in fact have no choice in their buying patterns. Their only choice is actually to be super subversive and go around you. And so setting up, again, that trust dynamic between that platform team and the services team sitting on top of it is really crucial. The other part of your question though, is I think in some ways the more fun one, which is if you're working on a product that is not something where the, it's not a B2C type product, it's a B2B product, it probably has a user interface, but that's probably not the most important part. It may seem counterintuitive, but that's where actually design thinking and customer empathy are the most important. And I got a big dose of this. I said I was a son in the late nineties and early two thousands and I left for a couple of years to go do a startup. And we were actually, the short version is we were trying to invent cloud computing and we invented a lot of cool stuff at the time. And. We had the ability to show sort of like, here's your farm full of servers and here's where all your workloads are and you could watch them move between servers and we could take customers in the data center with like a big set of bolt cutters and they cut cables and things would move. Every customer left the demo going, that's so cool. And their eyes would sparkle and we'd think, man, it's just as soon as, you know, we're showing beta versions of the product, as soon as this gets done, we are gonna make so much money.
Everybody wants it. We didn't sell any of them. Oh no. Not one, like the first two quarters after we introduced it, none. I was still on the engineering team at that point, and I was frustrated. I just bought a ticket from Silicon Valley to New York. We had a lot of financial services types that had been the prospects who trialed the software and had been the ones who said, this is so cool. I remember actually sitting with a VP of IT at Lehman Brothers, which famously went out of business for being super arrogant, not long after that. But I'd worked over the phone with this guy for four weeks on a proof of concept. He was super geeked out and super enthusiastic, and we went through this long list of things that he wanted to see, and we could do every one of them. But he didn't buy it. And so I just showed up at his office and we had coffee and I asked him why he didn't buy it, and I'm going to edit out the extra spicy New Yorker parts of the commentary. But he said, Steve, it didn't solve my problem. I remember just being flabbergasted. We'd worked together for four weeks. He'd given me lists of what he wanted to see, and we showed it to him all and he thought it was really cool.
No else to say other than what was your problem? You know what he did? He described it to me in really clear English in a few sentences and you know what? My product didn't solve that problem. I'm like, how did we get a year into building this and like all the way through a POC and nobody knew what your problem was? And interesting thing for the product managers, again, I was a VP of engineering at that point, and I flew home and I told everybody this, and all I got was everybody really mad at me. Told me I was crazy, you know, get it Steve. Three, four weeks later, after everybody being mad at me, they asked me if I would run product management and Ken could run engineering. And that was my first job as a product manager. I just like leapt into running product management because I was the guy who was willing to show up and say, what is your problem? Not only did I get a clear description of the problem, I got a clear description of the pain. He's like, how bad is that problem for you? He's like, Steve, if I don't solve this problem, it's gonna cost the company million next year. Well, it's like I need to build a new data center in New Jersey if we don't solve this problem. It's like, wow. And that problem was solvable. That was a thing we could solve. It was not a huge leap from where we went.
That's why he could think our product might solve that problem for him because it was really close. And that's the trick, going back to your question about those infrastructure product. The user interface can be glossy, people love it. But until you get deep down into it, the actual match between that and the customer problem with those infrastructure products is not always obvious. Being able to get somebody to express their really clear customer pain to you, and you having a product management and engineering team that is savvy enough to come up with unique solutions to that pain that people will pay for, that's the difference between you being, well, turned out VMware or being the company I was at that nobody's ever heard of, because it turned out VMware solved that problem. And VMware was a very small company at the time and we could have been VMware instead if we'd understood that problem a year earlier.
Melissa Perri - 00:31:09:
Yeah, there you go with the whole opportunity cost on not doing product management right from the get-go. What happened though? Why didn't they ask what their problem was? What was the product team doing?
Steve Wilson - 00:31:20:
It's tough to say when you look back on it and when it wasn't me who was the product team at the beginning, but I'd say the general thing, and I've seen this multiple times in my career and even been guilty of it, which is. You see an opportunity, a general opportunity, where you understand that there's a general hole in the industry, and you get sucked into and excited by some technology that's in that area, and you get too excited about the technology and you don't focus enough on the pain. Again, you feel that validation when you show something to a customer and they say, that's cool. And that's become a watchword for me ever since is really talking to my product managers about differentiating. That's cool. I like that. I love that with that solves my problem. I would pay for that. Those are two very different things. And the first one gives you that dopamine rush in your head. They like what I did. You take the note and say, I love this, this is fantastic. And you run back and show the quote to your boss that validates what you said. Those are not validating words for a product manager. Those don't count.
Having a customer who's bought your product, who a year down the road says, I love your product, that's true validation. Put that up on the wall. You love that because that customer understands what they're getting and they still love it and they love you. That's awesome. Customer who saw his demo, who says, I love it, Or you say, would you like this feature? And they say, that's great. That's zero validation. That's nothing. You have to get underneath that. You have to get down to what problem do you have that this solves? Am I sure this is gonna solve that? And is it something that you're gonna have a budget for this year? Otherwise, it really doesn't matter.
Melissa Perri - 00:33:07:
So when you're hiring product managers, look for their aptitude to do this, to see if they'll fit well into the cybersecurity world too. What types of skill sets or traits are you looking for to say, yes, I want you on our team?
Steve Wilson - 00:33:22:
That's a great thing. And I would say, look, I'm a big fan of having PMs who are technologically savvy. But I'd say way too often people assume that it's hard to teach the technology stuff. And so they'll take the technology savvy over the soft skills. And I actually think it's way harder, bordering on impossible, to teach somebody the soft skills. How do I interface with customers? How do I interface with an engineering team? People who are smart will come along and learn the technology. And if they've built a great relationship with the engineering team, the engineering team will teach them the technology or back them up on the customer calls or the sales training or whatever it has to get done. So I'd say the people skills, the empathy skills. I ask this in every interview that I ask about product manager, what's the most important quality that makes a great product manager. And almost anybody who the first word out of their mouth is empathy or something that's a direct map of that, I will hire them. When they come back with, well, almost anything else, I will probe them about why that is and give them a chance to get around to that. But I've seen too many examples of somebody who's super deep in the technology area, has a ton of experience, who winds up being an ineffective product manager because they don't have those soft skills.
Melissa Perri - 00:34:44:
Yeah, those are the ones too that I see really make or break an effective product manager and product leader too, right? I've run into so many people who want to be a CPO like you and they haven't mastered the empathy for the people inside the organization, let's say, to build those stakeholder relationships. Like, they might be great at the customer part, but they've been building great products for it, but also having that empathy for your fellow leaders and for your stakeholders and for the sales team and that.
Steve Wilson - 00:35:12:
The sales team, it's shocking how few product people have true empathy for how hard the job of a salesperson is. And that's one of the things is getting them out there, not just meeting with the customers who own the product. That's great. Like getting out on those early sales calls where people are basically saying, I don't get it. Boy, that's gonna build you some empathy really fast.
Melissa Perri - 00:35:34:
Yeah, that's a great way to learn Trial by Fire right there. You'll hear everything that you wanna hear about the product. I like that. Well, this has been so great talking to you, Steve. My last question for you really is, what do you think is the future of cybersecurity? What's it gonna look like? And what should we be paying attention to as product managers as things start to evolve?
Steve Wilson - 00:35:55:
Yeah. So I think one of the big shifts that's happening, and it started with two big incidents, one of which was Log4j we talked about, the other one was SolarWinds, which was a pretty big security incident. It's causing a shift where the governments of the world are waking up to cybersecurity. The United States now has executive orders from the president and a new cybersecurity strategy, that are dictating that you move past what I'll call a check the box approach to cybersecurity. So much of security is compliance driven today, where the requirement from your customers or the government is that you followed the process, that you ran the test, that you checked the box. Nobody's been brave enough to say the requirement is your software or your environment is secure. And that's changing. And that's starting to change buyer mindsets. It's going to take a while, but that's a huge opportunity. And being able to say with some confidence that my product is really going to change your cybersecurity outcome, that's going to be a big shift for parts of the industry that you're moving past that check the box attitude. The other one I touched on earlier is I think we're going to see impacts of artificial intelligence across industries, cybersecurity is going to be a place with a huge, very immediate impact. And again, it's going to be both offensive and defensive. And so SaaS companies of any type are going to need to think about their security as quality as something they're probably going to have to invest in more, or they're going to be putting their customers at risk in this environment. As things escalate companies in the security business, they really need to be thinking about how am I going to, in an orderly, well thought out way, integrate more of these technologies into my defensive products, because it will make a big difference and you're not going to be able to keep up if you don't.
Melissa Perri - 00:37:59:
definitely things to be paying attention to as we watch this all unfold. So thank you so much, Steve, for being with us. If people wanna connect with you or read more, maybe read the book that you just wrote, where can they find you?
Steve Wilson - 00:38:12:
You can find me on Twitter @virtualsteve. That's one of the easiest places to grab me. Great.
Melissa Perri - 00:38:18:
Well, I hope everybody goes and checks out Steve and his work after this. Thank you all for listening to the Product Thinking Podcast. Next week, we will be back with another Dear Melissa episode where I answer all of your questions. So please go to dearmelissa.com and let me know what you're thinking about.