Redefining CyberSecurity

The Art of Building Security Products: Balancing Innovation and User-Friendly Design | A Conversation with Laurent Hausermann | Redefining CyberSecurity with Sean Martin

Episode Summary

In this episode of the Redefining CyberSecurity Podcast, host Sean Martin, and guest, Laurent Hausermann, discuss the process of building security products, emphasizing the importance of understanding customer needs and focusing on delivering value.

Episode Notes

Guest: Laurent Hausermann, Entrepreneur

On Linkedin | https://www.linkedin.com/in/laurenthausermann/

On Twitter | https://twitter.com/lhausermann

Website | https://cyberbuilders.substack.com/

____________________________

Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]

On ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/sean-martin
____________________________

This Episode’s Sponsors

Imperva | https://itspm.ag/imperva277117988

Pentera | https://itspm.ag/penteri67a

___________________________

Episode Notes

In this episode of Redefining CyberSecurity Podcast, host Sean Martin and guest Laurent Hausermann discuss the process of building security products. They emphasize the importance of understanding customer needs and pain points before developing a product. Laurent shares his experience in the IoT security space and the significance of gathering feedback from potential customers. The conversation highlights the role of a product manager in championing the value and experience of a product, without overselling it to security practitioners. They discuss the challenges of marketing security products and the need for realistic expectations.

The discussion explores the user experience of security products, from installation to operational ease. They discuss the importance of a well-defined product development process and the role of the product manager in bridging user experience, technology, and business. They touch on the evolving nature of product management in a world where almost everything is built using a SaaS model. They also discuss the concept of time to value, emphasizing the need for quick delivery of value to users. They also address the role of product marketing in promoting the product and supporting sales, including the creation of collateral such as sales decks, briefs and papers, user testimonials, and webinars.

The conversation concludes by discussing the organizational structures and responsibilities for product management and product marketing. Sean and Laurent highlight the need for a clear understanding of the product manager's role and the distinction between product management and product marketing. They emphasize the importance of a collaborative product development process, where the product manager serves as a bridge between various aspects of the product.

Overall, this episode provides valuable insights into the world of building security products, emphasizing the importance of considering customer needs, user experience, and marketing strategies. The conversation is informative and thought-provoking, offering practical advice and discussing the challenges faced by security product teams. The host, Sean Martin, and guest, Laurent Hausermann, bring their expertise and experiences to the discussion, making it engaging and relevant for listeners in the cybersecurity industry.

____________________________

Watch this and other videos on ITSPmagazine's YouTube Channel

Redefining CyberSecurity Podcast with Sean Martin, CISSP playlist:

📺 https://www.youtube.com/playlist?list=PLnYu0psdcllS9aVGdiakVss9u7xgYDKYq

ITSPmagazine YouTube Channel:

📺 https://www.youtube.com/@itspmagazine

Be sure to share and subscribe!

____________________________

Resources

Inspiring Post | Unlocking the Secrets of Cybersecurity Product Teams: https://cyberbuilders.substack.com/p/unlocking-the-secrets-of-cybersecurity

____________________________

To see and hear more Redefining CyberSecurity content on ITSPmagazine, visit:

https://www.itspmagazine.com/redefining-cybersecurity-podcast

Are you interested in sponsoring an ITSPmagazine Channel?

👉 https://www.itspmagazine.com/sponsor-the-itspmagazine-podcast-network

Episode Transcription

Please note that this transcript was created using AI technology and may contain inaccuracies or deviations from the original audio file. The transcript is provided for informational purposes only and should not be relied upon as a substitute for the original recording as errors may exist. At this time we provide it “as it is” and we hope it can be useful for our audience.

_________________________________________

voiceover00:15

Welcome to the intersection of technology, cybersecurity and society. Welcome to ITSPmagazine You're listening to a new redefining Security Podcast? Have you ever thought that we are selling cybersecurity insincerely buying it indiscriminately and deploying it ineffectively? Perhaps we are. So let's look at how we can organize a successful InfoSec program that integrates people process technology and culture to drive growth and protect business value. Knowledge is power. Now, more than ever.

 

sponsor message00:53

Imperva is the cybersecurity leader whose mission is to protect data and all paths to it with a suite of integrated application and data security solutions. Learn more@imperva.com.

 

voiceover01:10

And Tara, the leader in automation, security validation allows organizations to continuously test the integrity of all cybersecurity layers by emulating real world attacks at scale to pinpoint the exploitable vulnerabilities and prioritize remediation towards business impact. Learn more at pin terra.io.

 

Sean Martin  01:39

And hello, everybody, you're very welcome to a new episode of redefining redefining cybersecurity here on ITSPmagazine. This is your host, Sean Martin. And as you know, I hopefully help folks try to operationalize security in the business not to just protect what they have, but to protect the growth as well. And many of you know, I don't know if everybody knows, but many of you know, I've had a role in delivering tons of products in the past and marketing them. And today's topic is one that I think we're gonna have a lot of fun with. And I have a whole zoom in on how are you Laurent,

 

Laurent Hausermann  02:18

hey, I'm fine. Thank you, for inviting me.

 

Sean Martin  02:22

It's gonna be it's gonna be loads of fun. We're going to talk about building a product and more specifically a security product, which you've done many times, and I've done quite a number of times as well. And when I saw this post come across LinkedIn, for me, I was like, this is something we could have some some good time chatting about. And I scrapped the other topic, which will probably come back to his point. But But I think it's interesting, I think, how we can connect this to operationalizing. Security in the business, when we're talking about building security products, I think, give some insight into focus of how all security products get defined, built to be used successfully, which is not always the case, as you know, right. And I think that's the, let's just get into it. So before we do that, though, a few words about you and leading up to what you're working on. Now. Obviously, we have we have a connection from the past as well. So maybe a few few words from you. They're all

 

Laurent Hausermann  03:33

about Yes. So yeah, I'm Rob alderman, and 46 year, time is going fast. And I worked since 20 years in the cybersecurity business always in product driven companies. I was in engineering software engineer at the beginning, then CTO of a firewall company where doing ideas, VPN, web filtering, all that all this stuff. And and then I founded my own startup, named centrio. It was in the IoT, ot security, providing visibility, security, posture detection for manufacturing and utilities network, you know, SCADA system PLCs and critical infrastructure kind of kind of network. And it was nine years ago, and I just left that company in April. The thing was that we we've been acquired by Cisco in 2019. And I stayed for three and a half years to within Cisco to Oak, my team with my business within the group. And no, I'm, I'm back as, as a few weeks, I will say, in order to build something new and I'm an entrepreneur, so I like to build things and in creating products in Europe and in the US.

 

Sean Martin  05:00

Yep, I love it. And yeah, I mean, huge success with the centrio offering and obviously the Cisco acquisition there, and couldn't have been at a better time. Right. I think the that whole space of IoT and OT was something that was very untapped. I think we see a lot more of it now, of course, in recent years, but maybe, let's have a few, if you mind, maybe just a few words on starting that and understanding what the what the risks were the potential was. Because I think some of the things we you present in the LinkedIn post, its, you might have a good idea doesn't mean it's going to be useful doesn't mean people will pay for it doesn't mean it'll, it'll actually get used if it gets built in bots. We can we can talk about shelfware all day long, right? Yeah, so maybe, maybe let's start there, how? How you came up with the idea? And maybe, perhaps how you knew that there was an opportunity there beyond just succeeding and building something?

 

Laurent Hausermann  06:16

Yeah, sure. We, you know, it's, it's funny, because most of the time people think that you have an idea one day, and overnight, it's a success, which is not true. In fact, you basically need to follow a kind of process in order to discover if the idea was something, if there is a market if there is a need, is it solving, solving some things at customer side? And so yeah, I remember that in 2014, when we started, it was just about a let's look, if there is any thing to do in the industrial networks, or we had customers in the past in manufacturing, in oil and gas. And and we know that there was quite nothing, but we really, we were really not sure what kind of feature, what kind of product they were, they were willing to adapt. And, and so we we ended up building a white paper, two minute video, explaining what we were thinking about, and sending that documents in too many contacts saying, Well, guys, we are entrepreneurial, we are building a company, but we have nothing to sell yet. We just want your feedback as a, as a CEO, as a security elite leader as a control system engineering, in manufacturing, for example. And almost over a year, we were on the road, talking to people and discussing where they were in terms of security for their control system networks and industrial networks. And, and what we learned is basically at that time we, I was you know, I'm an engineer and security guy. So I was all about detections. And I wanted to build a detection to detect things like Stuxnet, you know, the attack, what occurred in Iran on the centrifuge things and it was a briefing at the time, and it was our we are going to build a product to detect that. And what we learned after that year of conversation and interviews is that basically, people don't even have an inventory. And so the first thing we should do a list of the assets, the list of devices that were connected on the network, that was the basic first thing they need to start surfing, because they have network that are so huge, you know, just to paint a car, to paint a car, you need 10,000 IP addresses 10,000 to manage your whole way or AI way in the US state, you may need something like 100,000 IP addresses for hot sensors, security cameras, payment system, digital signage, no more and more coming in to be deployed. So I mean, the network was so huge that even the inventory and not sending someone doing an Excel spreadsheet by end was something for them. So yeah, it's it's a process you have to follow in order to discover the needs of your customer and not be yeah to be open to ask open question and understand where they are. What are their current pain points and not push your willingness to build the latest technology that may come later but start by where we are people are in title so.

 

Sean Martin  09:57

Yeah, so let's let's start And then I love that kind of the view into how you think about building something and understanding what you're trying to build this article that you wrote, it's on substack. And we'll include the link to it through LinkedIn and whatnot. But it's unlocking the secrets of cybersecurity product teams. And you, you start off with looking at founders, which you were in the case you just described, and having, having a fairy tale view of of what you want to accomplish, which, as you described in the article, it has limits right very tail as limits, what can you actually do what's feasible, but then to your point you just described, the fairy tale may not be what's going to sell at the box office, right? You have to know what, what people are interested in. And then you get into what is the product and the team that that's responsible for building it? So tell me a little bit about the impetus behind writing this piece? Or the driver? Who are you trying to reach with it? And what were you trying to hopefully instill into them as a, as a call to action or learning perhaps,

 

Laurent Hausermann  11:17

shall we, you know, I, I launched three months ago that cyber builders substack, in order to share some insight about oh, you build a product security product, cybersecurity company, or you build a cybersecurity program at kind of any any kind of business, because I really feel that it's really a building process. So I wanted to be able to share insights and feedback, etc. And when I discussed that with some of my peers and top earners, one of them said to me, Well, it's, it's our No, it's, it's much more difficult than when we were a team of 10 people, because I had that vision for the product, and no, no one's really understand it. And, and I'm still the CEO of the company, but I cannot execute my vision because they have a larger team. And, and people don't get where we need to go, and they should listen to me, etc. So I said, Yeah, well, it's basically something maybe he's missing, what the protocol is within the product based company. Because basically, when you start and you grew up, your company, you end up with no one really owning the product or in your business, it could be because at the beginning, you have the CEO, with the CTO, they are meeting every day. And they they really collaborate and they share the vision of the product. But when the company is growing, at some point, the CEO become the sales guy, looking for selling the product and raising funds. And on the other end, the CTO has probably 1020 30, maybe 50 engineers to manage and end up to be the people manager first and implementing quality processes and engineering practice. And so the product is the offense of that, because if they don't hire a CPO, Chief Product Officer, no one is really owning the product code. So I wrote that piece, because I wanted to explain that a first, you should have someone in your company that is leader, Product Manager of your product or the chief product officer. But then you need to understand it's very odd job. Because in security, it's not easy as probably many other on the other business because you need to understand the security processes, you need to understand the what what kind of security your product can deliver. And if you're new in that hole, and new in the security industry, you may end up saying things like oh, my product is going to protect you against any threat or any things etc. And you end up with marketing crap. If I if I may say that some companies are still saying and most of the security partitioner are very fed up with because they everyone knew that the product is not here to solve everything. It's not a magic wand. It's something that's in part of your different strategy. It's provide you some value and the product manager needs really to champion that to understand where you can position the stuff in order to really deliver value and not oversell it To the security practitioner, while the customer of the product because if not the sales and the and all the people behind the product manager will not really be able to be successful because they, yeah, security people would say, oh, no, just another marketing claim. And I don't trust this visa product company.

 

Sean Martin  15:23

Yeah, it's a great point. And and I often look back at my time when I was responsible for building the big yellow companies sim product. And so many things come to mind, just on this point where the whole idea at the time, I had a vision of what SOAR is today, right. So kind of this whole orchestration of you have all this stuff going on. And there's some level of automation to help you help you manage it all, because you can't get Cairo all the people to do it. So that was kind of like my, my grand vision. technology wasn't in a state that allowed that to happen. Right? You're tied to open LDAP. And my sequel and bunch of technologies that were complex, didn't scale, well, you had to get licenses for this stuff. And installing and deploying it was a real pain. So there was that whole part of it, which we'll leave aside for the moment. But once we delivered something, getting it to work in the environment was a whole nother different, a whole nother ball of wax. And when I'm talking about not just the configuration, but I'm talking about the real operations, it I don't know how many times we got requests and feedback that I could use this, but I'm missing a dashboard, I'm missing reporting, I'm missing missing, how I connect this to the rest of the business. And yes, it had all the security bits, but lacked a lot in the operational bits. And, and some of that was UX as well. So talk to me a little bit about some of those points in the PC road where, again, you have a clear understanding maybe what's needed from a security perspective, but missed the mark on on some of the other stuff. And where does that land is it engineering is a product is its business that helps drive some that stuff,

 

Laurent Hausermann  17:29

I think you you're touching a very good point is a product is really about the experience you are the user is going to have with that product. And if it's super hard to install, if it's super hard to operate, if it takes too much click to get the value of the data you want. There won't be any adoptions and and basically it's it will be, it won't be a success. And it's even more important, no days that any any product today is a SaaS products sold as a subscription. Back in the day, when you and I were younger, you were selling licenses. And the great things with licenses is that you can sell a license and one and go to the next customer because you are asking him to pay a big check license. And I'm trying to be honest, yeah, but and probably many software vendors at that time does not really care about all the pilot is going to be used and they had some system integrators to take care of the customer. And so you set up the check and you come back five years later, when the you need to sell another license for a new product. Now everything is a subscription, and everything being kind of a land and expand sales tactic, meaning you you start selling. For example, if you have you're sitting by a seat of of user, you you start selling a few seats, and then you come back, take care of the customer success, which is another new hole as well in the product company, you must be sure that the product itself is easy to install, easy to deploy easy to connect to the rest of your IT systems. It delivers value very quick. That's why one of the jargon kind of thing we you will always hear about is time to value, how much time does it take to get some value out of the product. And basically in 2023 It should be two minutes and not two weeks as 20 years before. So that's I think very, very important to get these. Look at all fast you can enjoy allow your user with some value out of the product and not just think that because you are the greatest technology, they will go for it. And, and they will use it.

 

Sean Martin  20:14

Yeah, I completely agree. And I mean, there was kind of looking back in time, and I'm sure it's very different. Now, I haven't built products in a few years. But and we talked briefly about this, before we started recording, I can't, I lost count of how many reorganizations, I experienced moving from a technical product manager to a business product manager to a Marketing Product Manager to customer facing product manager. And then obviously, the market facing as well. And I think having I don't know, there was always one person to kind of lead, depending on who is at the top of the pyramid at each point in time. But it, it almost seemed like that was just one person. And they had a special lien on how are a special view on how things were to happen. And they weren't supported necessarily by multiple people under them to kind of bring all those different views under one umbrella, because I know you in your in your document of the technical marketing role as part of the product. And I think those to me, were probably sales engineers back in the day. Maybe now they're more system integrators customer success, I don't know, how do I have small startups even I mean, I was I was at a big company where resources were not endless, but certainly more plentiful than then a startup kind of bootstrapping thing. So how does security companies today kind of get those multiple views? With with limited resources?

 

Laurent Hausermann  22:11

Yeah, I think, at least, they need to make sure that they, they have a clear understanding of who is as the role of the product manager. And, and really, the first thing they need to make sure is that the product manager who is at the, the costs hold of us user experience, technology and business. And the end, the product manager should not be someone just to manage the whole map of the product issue. And we look only at the at the product itself with three other as a product as a product line of business. And, and really make sure that the manage the growth and the success of its product. Airbnb recently just announced, I guess, over the last week, that they they are mixing what they used to call product managers and Product Marketing. Because they want one guy, one person to be in charge of the product vision and whatnot, but also of the business metrics of the product. And I think that's very, very interesting, because you, you cannot be only the delivery guy that just looking at delivering new features, and just continue features, without really understanding the impact of these features in the product. Are they really used? Are they helping to grow, sell more subscription, etc? And so I think that, yeah, Product Manager is really one key role in any type of organization startups or larger company. And then you really add the, what I call product marketing in the in the in the article, but it which is more about the promotion of the product itself, or are you able to provide all the collateral to the sales force in order for them to be able to sell it and because you need, you need four point x, you need user testimonial, you need use cases. You need webinars, you need events, you need Well, tons of things, and that's really are the product marketing goals. And basically, if you look at where these two big holes are sitting in an organization, I would say that product by itself should be reporting at kind of a CPO level guy. Really sea level leader and the product marketing it really depends. I mean, as you said, sometimes it's the same CPU. Sometimes it's the sales leader. It really depends. What is the culture of the country Any, and what are the type of products they have there is companies where sales are very localized, I would say, to a country or territory, and in that make them selling tons of different products. In that case, maybe the product organization is really owning the public thing and sales, aka, geography. Sometimes it's quite different because they want sales wants to be able to adapt, or the product marketing collateral to their own country, because there is some regulation, for example, you know, in Europe, we have GDPR, you don't have in the US, you have the NIST security framework, we have the EU resilience Act, which are two different sets of regulation. So maybe you want to really adapt your marketing per region, and in that case, makes more sense to have for the marketing people in the geographies, it really depends on your your cybersecurity business securities, is quite wide topic with many kinds of products and, and people using them and etc. So it's up to whoever one size fits all kind of answer. Yeah.

 

Sean Martin  26:22

Yeah, and I think, and I'll kind of I'll kind of use something that I talked about on the show quite often, from an operational perspective, where I think security has an opportunity to not just come in and say, what you built as a business can be secured this way. Right. So you've deployed that product with these API's connected to these services using this dataset, we now have these security controls to kind of mitigate all that exposure and risk. That's kind of the after the thought view of that. And where I'm I'm saying security teams can actually help define how the business is architected, and built and deployed and maintain. So you're reducing exposure and not killing the team in responding to stuff because you didn't didn't build a quote unquote, right in the first place. So I think product marketing, or products, the product owner has the same opportunity here. Looking at kind of your point, what are the what are the market requirements for this not just customer requirements? What are the market requirements? What are the regulatory requirements? Were the operational requirements? What are the data, data data, list of requirements, challenges is then kind of consolidating those pulling them together in a cohesive story and strategy? And you mentioned the word roadmap, how do you deliver it all, eventually.

 

Laurent Hausermann  27:54

And you should also look at integration of your product into other systems. Right? I was at NSA back in April. And there were some talks about how many security products people have deployed in their network, and the people were talking about 70 8100 security products for one company. And so the person who has all that products to use, he wants to make sure you leverage is investment, when you add one more to the stack. Because if you add one more, and this is a silo, in the data on the chair, and in the UI is very different than others and, and it takes yet another training, it's very hard for him to really be successful using it. So I think, yeah, the marketing is also about well, all this is connecting to the your operation, your practice, your regulation, your other product, in IT system or security, the wharfing the customer as and, as I always argue, is most of the time with the founders or meeting of startups is don't look at things from your own point of view, look at things from them, but their point of view, it's, it's not, it's not about you, it's about your customer and, and the kind of issue he has or she has, and not really about your great technology you believe if you if you want to be to be successful, and and that's why in my substantive article, I argue argue also about what I call output based metrics and and driving by output and not outcomes vary and dialing by outcome not by output because what I see in terms of time is you know, you have some VP or you leaders say, Well, hey guys, we want to be successful. So let's build a great product and basically don't really understand. And it's not his job in the company to understand the ins and outs of what would be the great product, if you just want the team to be productive, and is investing a lot in salaries and, and funding the team. So he wants to get outcome of it. But as you don't really know, what he say is, is trying to manage it using output based metrics, like number of features delivered number of users story. And you know, in engineering, we do user story points, which are it's just a metric to compare things. It's it doesn't have any value, but some engineering leaders or VPS, as VPS, could say, I want more, so give me more, you will be better if you give me more, where on the contrary, if you were looking at outcome, he would look at his own business metrics. And put that in front of the product team, KPI and an evaluation. Like, Well, guys, I want for example, to grow my user base of x percent this year, I want this net new revenue in my in for my company. And I don't care if you deliver 10 More feature or just one. At some point, if I'm reaching my business metric, we are fine. We you don't need to end up in a over and never ending billing loop. And that's why I'm also cutting this book I am loving, and I have it on my bookshelf, and I'm looking at it every day almost is escaping the bill trap. And I am Melissa Peridot, the author is advocating for escaping that big trap where we have an issue, let's be more, we have an issue, let's be more feature. And at the end, you end up with a kind of Frankenstein product that basically they have tons of features maybe used by one user. And the pain you have at that time is you will never escape that. Because there is always one customer and most of the time won't be customer that if you say Oh, I'm going to kill this one, you will say no, no, no, I'm using it. And I have been doing million dollar review. So you won't kill this one. And I don't care if I'm the only user of that feature is great for me. So you keep you keep developing it, maintaining it, etc. So I think you should be very lean in the way you, you you create your own app and you manage your product and always look at the outcome based metrics I'm talking about, because probably less is more in such context.

 

Sean Martin  32:57

Yeah, I love that example. And the other build trap. That's a new term for me, but I've seen it where even big government entities, even if it's a lot, a lot, a lot of money, it's the name, the name on the or the logo on on the sales deck or the marketing deck that to be honest, provides value right to selling to the next to the next customer. But yeah, some off the wall weird networking environment that you're trying to support has that one feature there that that kind of holds you hostage as a as a company. And so if if you if you start off being held hostage, it's hard to break, break free of that, from my experience anyway. And

 

Laurent Hausermann  33:48

yeah, you know, I have one story to share on that is, in my first company, I was I was a CTO there. We had very large governmental entities and public companies in France and Canada. And, and they, they had contact directory requests. So for example, we I remember, we were adding an authentication feature. And one was willing to get these from the VPN certificate and the other wants to add an SSO agent and, and the second one was yet another thing and I don't remember. And it was always a balance between the usage of the toxication and the level of security that it will bring. And basically, if we were looking at all the requests coming from sales, this debt, it would have filled all our engineering for you. And I say, well, it's not possible we should not do rather than things just because it's coming from three big customers. So I said to the sales leader, I said, let's meet with them and we are going to do one thing is to put all of them In the same room, and I've done one slide, basically the x axis was security level and the y axis was UX, just to show them that it was a trade off between the two. And then I, the dot was each customer's. And then the magic happen, because they started to realize that where they were not aligned, and they started to say, oh, maybe we should discuss or I understand the burden for you. And, and after two hours of conversation, we had only one feature to develop. And I saved almost, yeah, hundreds of 1000s of Euro just with that meeting. So it was easy to do. But that's the kind of acts or tricks you need to you need to go through in order to save time. It's just Yeah, talking to people and then understand what what they are asking for and sometimes trying to escape that big trap in advance. It really happens. Yeah.

 

Sean Martin  36:09

So how about we, we switch this slightly, because I'm thinking about a lot of security leaders and practitioners that are listening to this. And saying, it's interesting how companies build products and how they get the requirements and how they prioritize and maybe make decisions. Your experience, especially now speaking to a lot of startups, where you see a lot of messaging and positioning and, and pitching for investment money, but ultimately, those translate into pitches for sales from customers. What I want is your perspective on what to look for. Maybe you can start with the investor lens, what what are some signs of companies that kind of get what they need to do they understand what the role of product is, in the bigger picture, and then perhaps how that translates for organizations looking to buy new products, and they're looking to advance tech companies, startup companies that that are doing something cool. But they don't want to make a mistake investing in somebody that's missing that big product picture, even though it sounds good in the product marketing, spins bad. But the big question in two to two lenses, but maybe some thoughts on that? I'll share mine as well.

 

Laurent Hausermann  37:40

Yeah, I have. I don't pretend to have the secret sauce of what everyone is looking for. What I would say is, especially for the people working at industrial and I mean, any end user company and and customers, my dear customers, I would say is really to start sharing their pain, their issues? What what are the problem they want to solve? And not jump directly to the solution? To really make sure that there is a clear understanding about what needs to be solved? What are the issues? What is what are the drivers behind that issue? Is it a new regulation? Is it an integration problem, is it another IT project because I don't know you want to deploy a new type of laptops or a new type of network or I don't know, really provide all the background needed, and share that with your people you are talking to because most of the time, the people you are talking to what they are going to do is to try to take notes of that, and then go back internally to the product manager. And that product manager will try to do his own synthesis, and then go back to the product engineering people, the software engineering people. And so each time someone is talking to someone else, basically you are losing some data, you are losing the quality of the signal, and you end up with the software engineering people being told we must do that. If not we are losing the customer. Which what the customer probably never said but that's the way it is presented. And then they're presented the solution because in the process everyone wants to add his own views and jump into the solution like I don't know added this feature or extending to this kind of protocol or this kind of standout. I don't know. And if you provide really the the background, the divers the issues, the problems If you are trying to solve and best, you do that, by writing writing them, then you have much more chance than the information won't be lost along the way. And the software engineer will receive your Word document, where clearly you explaining what you are trying to solve. And you say, Oh, that is it, take me two hours to code that and just add maybe two buttons or two fields in the database, and then you're done. And, and that's something I've seen many, many times where, basically, at the end of the process, what we've done is to say to the engineer, who basically don't want too much to talk to the customer, because they're afraid of it, say, Well, you are going to talk directly to the customers, we are organizing that meeting. And I just read last week, a post from Palantir, you know, the big information, data mining company, and they have a concept name, it's for deploy engineering, what were they do is they put elements and empty bullet kind of vest to the engineer, send them with the military, they are serving and trying to learn from the military, on the field. And it's it's very extreme. Okay, but it just to illustrate that idea of well, really make sure that you don't lose, what is the most precious, which are the pains you are trying to solve? And really make sure that yeah, product sales, understand it product manager understand it and software engineer and get the right, the right outcome at the end.

 

Sean Martin  41:49

Literally in the trenches. Exactly. So another thing that that comes to mind is because we're talking about engineering here and putting them in with with the customer. The other thing I experienced is overzealous architecture and overzealous design where you want the you want the perfect base on which to build. Which could take a long time, but then also make it so complex, unless unless reducing complexity is part of the design. But it can make it a lot very complex to where adding new things or responding to market changes or customer changes or threat changes, whatever changes coming your way. Makes it very difficult to respond quickly. So kind of back to your outcome points. How important is it to be nimble and not over overdo some things that can maybe hold you back in the future?

 

Laurent Hausermann  43:00

It's a It's a never ending question. I guess. It's very, very hard because for sure, I mean, great team ship. So at some point, you need to ship your software and you you never, ever will have one year or two year on just to re architecture it perfectly. So it just that that is another fairy tale that engineer likes to hear, but they never happened because there is customer they want to have some increment of value and getting new things and solving the issue. So the perfect architecture don't really exist. On the other end. Well, if you don't have that kind of thinking about the architecture you want to build and along the way, maybe adding let's say 20% of your workload reserve to improving your architecture, solving what software engineer used to call technical debt, which are the thing you put on the on the back of your your backlog and you need to solve them in order not to be pulled back each time you try to bring something new, you won't I mean, if you don't do that you won't be successful as well. And to give you an example, on my own experience, one of the thing we've done since the beginning in the central your product was to cut the part that is doing some protocol analysis. And the part that was doing the data mining of data the way we we look at the kinds of messages and vulnerabilities and all these things and these two parts were up into different components of our software stack, which was an architecture or design, we took the one part of the overall vision. And it ended up the reason why Cisco bide about the company. I mean, they wanted to integrate the that first part, the protocol analysis and scanning capacity we have directly into the networking architecture. So it was LightWave, it turns on only one core of a small ARM CPU. So I mean, the architecture design payoff on the long term, but it's, it's, it's hard to do that. I mean, it's, most of the time you encounter thing, you, you discover that along the way, and you need to re architecture as well. So it's, I don't I don't have a perfect answer there. It's always kind of a trade off. Yeah.

 

Sean Martin  45:57

I think there's never one answer, right? Because as you're, as you're talking, I was thinking with Woody, do you make a big bet on something that's has a potential huge payoff, but takes a lot of investment? Or do you try incremental things and try to find the one. Like we've seen, we've seen it all and everywhere in between, right to where the scenario situation, you end up with different things.

 

Laurent Hausermann  46:25

And, I mean, engineers need to remind that basically, if they are working in the startup, they are working in a company that has a pile of cash, and each month, it's decreasing. There, their job is to build something that make the cash goes up, and not just to survive, because if not, they are closing the company, and everyone goes, as well. So I mean, that's kind of kind of the everyone needs to make, and, and be honest, and, and open with the other saying, Well, this could be great, but it will take six to six months, or maybe later, or maybe we can split it in two or three parts. And I do this part now and the rest after so. Yeah, it's, it's, it's it should be a conversation between the team and not just engineering. I mean, product managers as well, CEOs and founders need to be part of that. Because if not, they they don't really understand what is happening. And at the end they ended up with Yeah, yet another Franklin claim product.

 

Sean Martin  47:32

Exactly. And I love the runway analogy for that because it is it is a runway, right you want you want the plane to take off before the end of the runway, but you also want it to keep flying not scratched in the water. And you don't want that plane to be a Frankenstein either. Because it knows what it's gonna look like when it starts to starts to fly along. It's been. It's been fun. We touched on a few points in the article. Of course, I would encourage everybody to read through it as it's much more structured perhaps, than my my rambling and moving us around through today's conversation. But I really enjoyed this and brings back some some memories good and bad. And some examples from you, which were super cool to hear as well. So thank you, thank you, I'd love to have you on again, we can talk talk different, different points in bringing products to market and seeing them succeed and investments and, and customer success. I mean, so many things we can talk about. So hopefully we'll come on again, at some point and we can keep chatting.

 

Laurent Hausermann  48:41

Yeah, we've great pleasure. Thanks for having me. And I'm definitely happy to come back.

 

Sean Martin  48:50

Thanks, everybody for for listening. Hope you enjoyed this and and then check out posts and connect with him on LinkedIn. And stay tuned for more episodes here at redefining cybersecurity. Thanks everybody.

 

voiceover49:10

Pin Tara the leader in automation security validation allows organizations to continuously test the integrity of all cybersecurity layers by emulating real world attacks at scale to pinpoint the exploitable vulnerabilities and prioritize remediation towards business impact. Learn more@plantera.io.

 

sponsor message49:36

Imperva is the cybersecurity leader whose mission is to protect data and all paths to it with a suite of integrated application and data security solutions. Learn more@imperva.com

 

voiceover49:54

We hope you enjoyed this episode of redefining security podcast if you learn something new and as podcasts made you think, then share itspmagazine.com with your friends, family and colleagues. If you represent a company and wish to associate your brand with our conversations sponsor, one or more of our podcast channels, we hope you will come back for more stories and follow us on our journey. You can always find us at the intersection of technology, cybersecurity, and society.