Symantec Product Lead on Not Chasing the Shiny New Object

Transcript

Dimitry Shvartsman

Hello, product management world, and welcome to another episode of Product Talk. My name is Dimitry Shvartsman and I lead the cybersecurity platform product management team at PayPal. I’m a strong believer that two of the most fundamental elements of a successful company are cybersecurity and product management. I’m excited to discuss both with some of the world’s top experts in this field. My guest for today is Michael Dubinsky. Michael, welcome. It’s great to have you. Can you please introduce yourself?

Michael Dubinsky

Sure. Thanks, Dimitri. Pleasure to be here. So my name is Michael Dubinsky. Today, I am the head of product at Symantec. I lead the network security portfolio, as well as the what’s now known as the Symantec enterprise cloud platform. Where we bring together a lot of the threat protection data protection capabilities across all of the control channels. We have actually joined Symantec, through an acquisition of an Israeli cybersecurity startup called lemonade security, where I served as the VP of Product Management. 

I joined lemonade security from spending about four years at Microsoft as the Head of Product Management for one of the security solutions. Today, it’s rebranded multiple times. Right now it’s Microsoft defender for identity. That was the product I owned, and also incubated parts of Azure Sentinel. During my time at Microsoft. Before that, I was the founder and CEO of a startup. That’s where I learned a lot of the business skills and some of the product management skills. 

And prior to that I was in different technical roles like field engineering at Microsoft. or now what’s mostly known as DevOps in the one of the intelligence units in the IDF. So that’s basically my background.

Dimitry

Amazing. I already have six different questions. Just just relate to your professional past. So we’ll touch on that. Before I dive into and deviate little bit, can you tell me why product management? What made you choose it as a career?

Michael

Sure. So first of all, I started in the IDF. As a developer, as a software developer. I spent six months writing code. And that’s basically the amount of time it took me to realize that I don’t want to be a developer for the rest of my life. I am great at scripting. I love POCs. Building production grade code is not something I can do or want to do. And then kind of intuitively in the IDF, I moved to more of a project management, product management DevOps. it was everything combined together. 

And after doing some technical roles after I discharged from the IDF, and starting, you know, my own startup, I realized that in product management is basically the opportunity to bring things that I like. and other people think I’m good at, which is technical skills. Especially for technical or security product, right? 

I’m a huge believer that you gotta have technical skills in order to be a good product manager for technical products. 

So that’s one thing. The other thing is the business skills. So one thing I realized when doing a startup is that I really like this challenge of Product Market Fit understanding what are the interesting problems? What are the key problems, facilitating that innovation process. how can you bring a bunch of smart people to solve a very valuable problem for customers and have those customers actually pay for your ability to solve that problem? 

That’s a very interesting challenge, kind of understanding and you know, identifying those problems and also the ability to be innovative or creative. You know, when you work with UX people, when you think about flows. It’s basically the whole world is open when you have a good problem to finish in. And you can be creative with your solution. And I really liked that about product management. So it’s basically a combination of multiple things that I really, really like. And I enjoy doing.

Dimitry

Phenomenal. For our listeners who don’t know, just a small clarification. IDF stands for Israeli Defense Forces. So a question about something you’ve mentioned, pivoting from your initial exposure to being a product manager to much a drastic shift and opening your own company. There’s a lot of product managers that shift and open their own companies. We’ve seen that a lot. what were the key learnings from your initial steps as a product manager that you took to being a CEO and founder or predominantly a founder of your startup that you found to be extremely successful?

Michael

So actually, my first product management role was after I co founded the company. But you know, in retrospect, I can say that a lot of the skills you learn about understanding the customer’s pain. and you know, different techniques, like jobs to be done. or understanding the customer job to be done versus focusing on you know. I want that button or I want, you know, this thing to do that. those kinds of things. That’s key to successfully building any kind of product. Whether it’s a startup, when you think about the MVP, and you gotta find you know, those five design partners that would actually be willing just to spend their time trying to deploy your broken product in their environment. you need to find a valuable problem to solve. 

So how do you go about that? How do you interview the customers? What kind of questions do you ask? That’s all product management skills, which are critical. In early stage startups, whether you’re the CEO or CTO doesn’t matter. As long as you’re a co-founder in an early stage startup, you’ll have the responsibility for identifying the problem, solving the right problems, and building the product market fit. That’s kind of the biggest learning.

Dimitry

Phenomenal. I’m gonna put a pin in it, and I’m sure that we’ll get back to it. So our series is about zero trust, and the products that are built in this fairly new space dominate the company that you were with prior to the current one. It was very early offering a product within this space. What it was like to build a product for such a young space? 

Michael

I think from like innovation perspective, or, you know, the internal, how you think about the problem. The fact that there is, you know, an innovative framework. because eventually zero trust is a framework. It took a while for the industry to understand, including myself and everyone what exactly zero trust is. But basically, zero trust is a framework that kind of guides you’re thinking about, you know, how do you look at policy enforcement? What are the different controls you want to allow the customers to apply in, you know, their access policy or their security policies or things like that. So looking at the framework, and basically saying, this is a permission to innovate. This framework is basically something that’s going to change how people think about how they define their access policies. 

So now we have an opportunity to innovate within our product. you know, compared to the legacy solutions, which allow, you know, private application access, basically, the VPN solutions. in order to provide better security and that framework, guided our innovation process. That’s basically the license to innovate. Right? So we started thinking about the policy model, for example, and what are the different controls, right? That’s kind of taking this philosophy of zero trust and basically saying, well, now what are the problems our customers have? What is the innovation, you know, that the zero trust model allows us to think about? or drives us to think about that will be helpful in solving the existing problem? That’s on the good side? 

I think on the challenging side, other than, obviously, the market education. and you know, you go to people, and initially, at least when 

You mentioned zero trust, it means very different things to every person you meet. 

Right. So there is that challenge. And the second thing is also eventually, you know, no one. Maybe now some companies have like a zero trust budget. But initially, no one had a zero trust budget, right? I’m a huge believer that you’re not selling a product to the customer, the customer is buying a product from you. And that’s a huge difference in how you think about it, right? So it’s not about how you sell the product. but it’s about what are the really valuable problems that customers have today, that you can help them solve? 

And zero trust just becomes this thing of, oh, and by the way, you know, it will adhere to this thing. which, you know, if you’re your CEOs, or if you know, the CFOs, or whatever. you have a good excuse, quote, unquote, but you still need to have that problem. And that solution, regardless of whether it’s a new market trend or an existing market trend, it doesn’t really matter. Right? So that’s kind of the negative of it. So you still need to think in exactly the same way. And then you just plug zero trust into your messaging. That’s basically how we thought about it.

Dimitry

So I want to stay on this for a second, if I’m kind of plugging the early stages of the framework, and I completely agree, I’ve been interviewing different guests, and there are different approaches. And there are different solutions right now in that space that tackle different aspects of zero trust. But back in the day, what was the main role, as you saw of you as the product manager, in not only educating the customers and potential customers, but also shining a light to this new field? And explaining why there should be eventually a budget why it is a real problem? What was the the main, I would say, responsibility in terms of the product market fit? from your standpoint? 

Michael

I think from a customer facing perspective. to that point, the biggest thing, we didn’t have a product marketing team. So in the early stages, I had a UX person, and another product manager reporting to me. so that we’re doing a lot of the work and you know, the tactical product management and working with, you know, our existing customers to drive the product. 

From my perspective, the biggest problem was figuring out the product market fit, right. 

That was the biggest problem that we needed to tackle. And in order to do that, basically, we use zero trust. the concept of zero trust, to kind of explain to the customers, what are the gaps in their existing architecture? Right? From a security perspective, why is the concept of least privilege is so important? What are the different attack paths that may happen or happened in real world scenarios when, you know, you’re not enforcing the least privilege access model. or when you use, you know, flat, full network level access across the board or things like that. 

So it was taking these concepts from the zero trust framework and the problems it is solving. and positioning, first of all those problems as problems, right to make sure the customer kind of goes in northern says like, Yep, I get it, I have a full flat network access to my production environment, in AWS, I get the challenge, right, the customer is nodding. And it’s like, oh, by the way, you’re not the only one, the whole industry is broken. And that’s why we have the zero trust concept. And here is how we can help you solve this problem in your environment. And by the way, our product adheres to the concepts of zero trust. 

But again, the focus was very much on Yes, you have this problem. Yes, we can help you solve this problem. Here’s how we do it. Oh, and by the way, it adheres to the zero trust principles, right? That’s kind of the mental model of that.

Dimitry

So I want to ask you, for our listeners, what was the most useful tool out of your toolbox as a product manager to help really flush out the problem? 

Michael

So what I was doing, basically, it’s a kind of a framework that over time. I developed and I use it in multiple cases. And basically, it’s based on this concept of, you know, the jobs to be done. and the innovation framework of overshot customers, underserved customers, things like that. And you kind of try to identify the customer problems using that method, right? What is the customer job to be done? What are the existing solutions is that, you know, an overshot customer, underserved customer. things like that, with the ultimate goal is, you know, making this Geoffrey Moore’s positioning statement, this template of, for target customer who has this need, that needed to be the outcome of that exercise, right. 

So you iterate on the customer problems on the jobs to be done on the market on the existing solutions, with the end goal in mind of creating the Jefferson word positioning statement. 

And then that served as the basis for then creating the page and the graphics. and kind of, you know, the key messages and things like that. But that was the framework we use. in order to say, well, you know, we have those five different hypotheses of what we can do with the product, right. And those policies can serve, you know, three different target markets. you could go for enterprise. you could go for mid market. you could go for tech companies. you could go. so now you can do everything in a startup with 20. Developers, right?

 You got to pick one, you gotta do it very, very basic, and then iterate. So which one is it? So that was our model of you know, let’s create the policies for each one the jobs to be done the positioning statement, and you know, a B test, email blast speech to customers, just see what works. and then basically on what sticks, you kind of start iterating and presenting and then improving until you get to a solution that the customer say yep, that’s, that’s really what I want that hits the spot.

It’s even before the solution it’s it’s even like getting to the point where the customer wants to see the solution. It’s about Yes, I have this problem. Yes, it’s important for me. Yes, your solution. Basically what you’re telling me about it makes sense. Now I’m ready to look at it. Right. So that first part is what we needed to pass. in terms of, again, whether it’s the slide decks, or whether it’s the email message. or whatever the case is, in terms of demand generation.

Dimitry

So that’s really relevant to startups and smaller companies that last bit. and Luminate was acquired by a large enterprise, what it was like to integrate a product into an existing ecosystem within the large enterprise.

Michael

So I think that’s interesting, because I’ll actually use the comparison, you know, both with Microsoft and with Symantec. because there is, you know, the big coughing and how the integration looks. but then there is also the company culture. And, you know, Microsoft was very interesting to see because it was right when Satya became the CEO and kind of the company culture changed. And also in Symantec, right. Symantec was acquired by Broadcom, which was a huge change in terms of how the company operates. 

For the better, I must say, in both cases, that was for the better, right? Microsoft is very evident, maybe the industry is not well versed in what happened in Symantec as part of the Broadcom acquisition. But again, it was very, very good in terms of, you know, how Symantec executed it. So I think the biggest challenge is that the people that make the buying decision for the startup company, are not the people that make the decisions on the priority of the integration. Right? Interesting. 

So you have the bizdev person that says, well, DTNA is something that strategically as Symantec we got to have. because Symantec was traditionally very, very good at identifying market trends and kind of making the acquisitions right. So I do think that the previous leadership at Symantec did have this idea of sassy or SSAE. Or, you know what now, Garrison processes the vision and the understood. whereas the DNA fits into that, and they understood the logic behind the acquisition. why it’s important for the portfolio. 

But the person who made that decision, versus the head of product for, you know, the product that you needed to integrate with. 

Which is, you know, the Cloud Suite, or the Cosby solution and Symantec ace. or, you know, Azure AD and the defender portfolio in the Microsoft case, are not the same people. 

So you finished the acquisition, you’ve done the, you know, the HR, the admin part, everything of the integration. you got the new laptop, you know, you’ve done all that part. And now we actually starting to think about integrating the product. And it’s like, it’s so low on the priority, because they have this huge backlog of things that customers are shouting at and are broken and not working. you know, like, like every product, right? 

It’s no different. And then you’re kind of sitting there and you’re like, Well, I’m a startup. I don’t know how to be enterprise ready. I need those integrations. And now you’re kind of, you know, fighting to get those integrations done and prioritize. then that’s kind of the biggest challenge I saw as part of the integration.

So it’s a resource allocation, as well as now you’re no longer the main product. you’re a product within the suite of other products that require prioritization. Which you’re dependent on in order to deliver on your roadmap, because you were not acquired to replace something you were acquired to kind of close the gap or extend the portfolio. Right?

Dimitry

That’s, that’s really interesting. staying on this now that, you know, post acquisition integration was spoken about the challenges of prioritization? What are some of the main differences that you see in product management between large companies and startups? Give me the good, the bad, and the challenging.

Michael

So I think the biggest thing in big corps versus at least the startups I worked with, I worked at, it’s not necessarily true for all startups. And I’ve seen other examples as well. But it’s the amount of tag that in the amount of cycles. it takes across the board, product management, engineering UX to handle that tag that right. the more mature your product is. the more lines of code you have. the more customers you serve, then, you know, the more that you have to handle, which impacts a lot of the daily work, right? When you go into prioritizing features in a startup. 

It’s like all about well, I just talked to this customer. Here is a new problem, you know, let’s start thinking about it. 

Versus in Corp. It’s like, well, we have this tech diet, and we have those 20 use cases that the customers are shouting, and we have this and we have that. And it’s like you’re starting from a backlog of stuff that is broken and you need to fix. And only then you know, and then it’s the prioritization fight of, well, the new feature is more important and less important. Should we do this? Should we do that? dependencies? So that’s a huge, huge difference.

I wouldn’t say good or bad necessarily. By the way, I do want to stay out of this because the fact you have the material product. which is serving, let’s say 20 of The largest World Banks. and you know, the retailers and stuff like that, that’s not necessarily a bad thing to have. So yes. Right, it’s not simple to serve Wells Fargo or to solve Lloyds or whatever. 

The second thing is also, you know, in a startup, at least illuminate right? The founding team, and the executive team was great, really amazing. And, you know, I still work to this day with Nene who’s the VP r&d. She’s one of the best, if not the best engineering teams I have ever had the chance to work with. And when you see, you know, in the startup, she was building the team from scratch. So she had her agenda. She had her philosophy on how the team should operate. And it’s like, the culture is what she built in corpse. It’s like a 15 year old culture, right, that changes obviously, over time. 

But it’s not, you know, one person build a culture from scratch, you know, how that operates, you know, people that don’t fit the culture leave very quickly. 

Or, you know, being held to live very, very quickly. It doesn’t work that way, in corps, right. you see one team with one culture and another team with another culture. and, you know, some challenges here, some challenges there. The whole digital transformation thing, you know. every single company, you know, corps were not born in the cloud. So you have this challenge of culturally transforming the engineering themes from operating, you know. Legacy model to in a new model. which something, you know, in a startup, it just, it’s born in the cloud, it’s new, it’s cloud native. There is no other way. Right. So I think that’s also a big difference.

Dimitry

Super interesting. So, you know, we’re, we’re in cybersecurity. And it’s a constantly changing space, zero trust is no longer a brand new concept. It’s been around there, multiple offerings, different products. How do you account for all these changes. when you build roadmaps, and roadmap of roadmaps, given the scope of your products and the size of the company that you’re in? 

Michael

So I think, you know, there is like three different aspects. when you think about specifically in cybersecurity, right? When you think about it, number one, there is let’s call it the tactical efficacy. Whether it’s threat efficacy, you know, how do you detect threats or block threats or data efficacy? How can you detect, you know, that sensitive data better or across new data sources or things like that? That’s, I call it more of a tactical roadmap. So yes, it constantly changes. There is always new attack vectors and things like that. But it’s like, you know, in my case, today, we have a team. mostly engineering focused on threat hunters and researchers, that they’re leading the efficacy.

Most of the decisions are tactical, right, based on kind of new malware samples or things like that. Sometimes you need to make a bigger decision. So a bigger decision could be, you know, do we want to support a specific flavor of Linux? Right, which means developing, you know, the endpoint agent to support that flavor of Linux? Or, or do we want to support, you know, some native cloud native database on AWS, you know, for Data Detection, things like that. But those are still I call it tactical decisio.. they impact the roadmap. you put it on the roadmap, you know, which is customer facing once you’ve made the decision or kind of, but that’s very, very tactical, right? You kind of respond based on the efficacy landscape. So that’s one thing. And that’s how we manage it. 

There is a efficacy team. When a prioritization call is needed Pm is being engaged and you know, we help make that decision. 

The second thing is, let’s call it the customer facing feature set. When I look at the customer, obviously, we’ll look at the persona so you know undermines responsibility to have the key personas, which is the networking team across the full stack, whether it’s secure web gateway, the cloud firewall, you know, the Z DNA, the private network access, as well as the sock team. Right. So how do we output the data, the detections, how do we help trashing false positives, false negatives? So when we think about feature sets, we think about those personas, right. then, obviously, we talk to them what do the problem like every other product. I don’t think this is unique to cybersecurity. you have your persona, you know. there is the problems across the lifecycle of onboarding, operating, you know, whatever the case is. 

so you go you interview, you create that roadmap based on that. I think what I’m trying to do as an agenda, and I think it’s very important, cybersecurity, in general is yes. you’re doing your thing. you’re building your features. Do that in a way that would be easy to integrate with other solutions, because you’re never going to be the single cybersecurity vendor for whatever company right. So whether it’s API’s, whether it’s the ability to export using standard schemas, whether it’s, you know, even the basics will have when you say username across the entire portfolio, it’s username, it’s always a UPN. It’s not the samaccountname here and the UPN there and the email address there, because, you know, the customer would just lose the ability to correlate. 

So it’s those kinds of things that I think it’s very important to be responsible in the cybersecurity aspect. 

So it’s not cybersecurity unique. But there are some, you know, specifics in the cybersecurity market, which I think we need to deliver across the board. And I think the third thing is those trends like zero trust, or the cloud, native security, or, you know, whatever the case is, and I think here, you know, it really depends on the company agenda, specifically for Symantec, and Broadcom today, the agenda is don’t go and chase the new shiny object, right? Because when you’re thinking about your existing customer, and you have, you know, a good customer base of all the Fortune 2000 companies, which are your existing customers. They’re not chasing the, you know, the new shiny object, right? 

Maybe in POCs, or lab environments, or they want to play around. They’re not going to productize. Like, you know, six months old startup in terms of their entire SOC and the entire Kill Chain, right? It just not gonna happen. So kind of the philosophy for Broadcom is look, we’re focusing on what we’re focusing on, we know our agenda. If a new shiny object matures and comes up, we can always acquire, right? So I think having that focus is also very important. Because every year there’s a new shiny object. If you’re constantly chasing those, what are you building? Like? What is the problem you’re solving? What are you helping customers do better? POCs for new trends? Well, maybe there is a startup for it. Right. But I don’t know.

Dimitry

I gotta say that this is a brilliant advice. And if you know, out of our entire conversation, I would recommend to take this just one thing. Although you had a lot of brilliant inputs. But this one thing of focus. I think it’s a lot of the times very challenging. Especially for product managers that talk to a lot of customers, to stay focused on what you’re trying to resolve. Of the pain point. I’m not saying you have to be set in your mind and not pivot. I’m saying that you also need to be very, very focused. And distinguish between chasing after the wrong thing, versus chasing after the next shiny thing. So I think this is a fantastic advice.

Michael

Thank you. I actually, I want to put a little bit more emphasis on that because for, you know, two very interesting scenarios are actual things that happen. Number one, you know, there is Gartner and Forrester and all those analysts. and you know, they have their trends, and then are providing whatever guidance, but it’s still their opinion. Don’t forget that. And I had a situation where one of the analysts, you know, we’re presenting the roadmap. and they were saying, Hey, why are you building this feature? And no one needs it. we haven’t heard about it, you know, for many of our customers. I was like, Fine, you’re entitled to your opinion, you know. my opinion is that we prioritize that feature we’re building. And it’s very, very important. 

And lo and behold, three months later, we have 15, better customers and those features, which are the largest banks in the world. So it’s like, I get your gardener, but I’ve validated those problems with my customers. I know that this problem exists. I know it’s real, we’re going to help them solve it. So you know, that’s one thing. And the second thing, you know, a sentence I heard a while back. And all this keeps resonating, is you see another company doing something, right? Whether it’s your competitor, whether it’s this shiny, new object that is doing X. and it’s like, Whoa, this is cool. Everybody’s getting one that you never know. if the entire pm team is looking at that company is now sitting in a room looking at their metrics, and they’re like, Why is no one using that feature? 

You literally don’t know if that’s the case. So don’t assume. Right? That’s kind of the key message on that.

Dimitry

Phenomenal. I always try to wrap up with this same question. If you were to travel back in time to give your younger self and advice when you were starting in product management, knowing what you know, today. what would it be and why?

Michael

So first of all, don’t panic. I think that’s the best advice ever. I’m not the first one to say, you know, Tigers Guide to the Galaxy said much, much better. But don’t panic, whatever happens. Don’t panic, right? There are always problems. There is always downtime. There is always the issue. There is always unhappy customers. don’t forget, that’s one thing, or maybe in a better way, like take things in perspective. Right. 

But I think the biggest thing and it took a while to realize is that you’ll be successful by owning the problem and facilitating innovation. As a product manager, you don’t own the solution. You’re entitled to an opinion for a solution, that’s fine. But eventually your responsibility is to talk to the customer to define the problem in the clearest possible way that you can for the other smart people. the UX folks, the architects, the engineers. like you have so many smart people around you that know technology that know what’s possible with, you know, modern technologies in the cloud, things like that. So much better than you. don’t try and solve the problem. Focus on defining the problem. 

And that’s also another quote, you know, Albert Einstein. if I had one hour to solve the problem and spend 55 minutes thinking about the problem and five minutes thinking about the solution. You need to spend more, you know, to think about the solution. But defining the problem is the single most important thing you can do as a good product manager. And then facilitating innovation, brainstorming sessions, being able to bring the right people ask the right question, right. Focus on that, and you’ll be successful.

Dimitry

Phenomenal. Michael, it’s been a real pleasure speaking with you. Thank you very much for the station. And for the awesome insights. I’m Dimitri Schwartzman. And I hope you will join me again as we continue our series of podcasts on product management in cybersecurity. Please don’t forget to subscribe to our podcast Product Talk and leave us a review on Google Play. Or in the Apple Store.