Cybersecurity Product Teams - A Podcast

Balancing Innovation And User-Friendly Design: The Key To Building Successful Security Products

Hi all 👏

I am taking a week off for summer vacation (road to Berlin 🇩🇪 to enjoy the city), but I will let you with a podcast I did a few weeks ago. I had the pleasure of being invited by Sean Martin to discuss my post about Unlocking the Secrets of Cybersecurity Product Teams.

Sean’s podcast is called “Redefining Cybersecurity.” I love its pitch:

Is cybersecurity being sold insincerely, bought indiscriminately, and deployed ineffectively? It must be made consumable, usable, and honest if we want it to be genuinely effective. To protect ourselves, we must begin by operationalizing security. Executives recognize the value of investing in information security for business growth, brand value, partner trust, and customer loyalty. We're working with executives, business owners, and practitioners to redefine cybersecurity.

It was great fun to be part of the show. I hope you’ll enjoy watching it!

Have a great week, and see you next week :)

Laurent 💚

---

Transcript Notes

Sean:

Welcome everyone to a new episode of Redefining Cybersecurity here on ITSP Magazine. Sean Martin here, your host. My goal with this platform is to help individuals operationalize security in their businesses, secure their current setup, and foster business growth. Many of you know I have previously worked on marketing and delivering products, so today's topic is definitely in my realm. I am excited to have Laurent Hausermann from Cyber Builders with me. How are you doing, Laurent?

Laurent:

I'm doing well; thanks for having me.

Sean:

Great. Today we're discussing building a security product – a process you and I are familiar with. A particular post from you on LinkedIn captured my attention, and I thought, let's chat about this! I scrapped our planned topic (we'll get back to it later on) because I believe this conversation can help people better grasp how security products are defined, built, and successfully used – which doesn't always happen, as we know.

However, before diving into this, why don't you tell us about yourself?

Laurent:

Sure. My name is Laurent Hausermann, and I've been working in the cybersecurity sector for two decades now - always with product-driven companies. I began as a software engineer before becoming the CTO of a firewall company that provided VPNs and web filtering services. Then, I founded my startup called Sentryo nine years ago - we offered visibility, security posture management, and threat detection and monitoring for manufacturing networks, utility networks - anything involving SCADA systems or PLCs.

I just left that company back in April. Sentryo was acquired by Cisco in 2019, and I stayed for 3.5 years to hook our team and business within the Cisco group.

Now, I am back as a free will, as an entrepreneur, free to build new ventures!

Sean:

I love it! You've had considerable success with Sentryo, and its acquisition by Cisco was a bonus! You managed to tap into what was then an untapped space of IoT and OT.

Please tell us a bit more. You might have an idea, but it doesn't mean it will be helpful; people will use it and buy it. Can you tell us how you identified this opportunity?

Laurent:

Absolutely! People often think that successful products come from having an idea overnight - but that is rarely the case. One needs to go through a process: identifying if there's a market need for the idea, whether the concept resolves any customer pain points, etcetera. When we started Sentryo in 2014, we explored possible opportunities within the industrial networks space based on past experiences in the manufacturing and oil & gas industries.

We found ourselves creating an explanatory video and whitepaper instead of being sales-oriented- there was nothing concrete to sell at that point; however, we could get valuable feedback from control systems engineers and security leaders using our resources.

We reached CISO at a manufacturing company saying, “We are entrepreneurs, we are building a new security company, a new product, and we’d like to have your expert point of view.” It was very successful, and we learned a lot.

Mostly, at the time, I was thinking of adding a lot of threat detection features to the product, which is important, but we learned that most companies don’t have an inventory! So we planned to have the

Sean:

Let's dig deep into the process of constructing security products mentioned in your article, unlocking the secrets of cybersecurity product teams…

Laurent:

First, it should be noted that it benefits the startup greatly to have someone solely responsible for managing the product- unfortunately, many startups end up without such individuals as their companies grow. However, it's crucial to acknowledge building a product in this field isn't easy due to the amount of understanding required: understanding of security processes, deliverables, etcetera.

Therefore, the chief product officer or other person handling the role must know how to position their product effectively across customers’ defense strategies, consequently building trust among them.

Sean:

Absolutely. Referring to your piece on Substack, there’s a discussion about understanding what's needed from a security perspective and delivering operational bits like UX, etcetera… How important are these aspects when it comes to developing a product?

Laurent: Quite frankly, Sean, they're critical! A product should be judged by its user experience- if it isn’t easy to install, operate or navigate, then users won’t adopt it no matter how great its feature set may be.

In addition, unlike selling licenses, products are now sold via subscription models. Therefore customer success becomes crucial as sales methodology shifts towards “land-and-expand,” making speedy delivery of value increasingly crucial for retaining subscriptions.

Once again, remember that time-to-value should ideally be measured in minutes rather than weeks!

Sean: Great points, Laurent! In your document, you enlisted technical marketing roles as part of the product- how do you see them fitting into the whole scheme? Those roles were probably taken by sales engineers earlier or today and may be played by system integrators or customer success teams; nevertheless, they’re all crucial cogs in ensuring the smooth operation of our mechanisms.

How to do small startups even? I mean, I was at a big company where resources were not endless but certainly more plentiful than a startup kind of bootstrapping thing. So how do security companies today kind of get those multiple views with limited resources?

Laurent: Yeah, I think, at least, they need to make sure that they have a clear understanding of the role of the product manager. And really, the first thing they need to ensure is that the product manager is at the crossroads of user experience, technology, and business. The product manager should manage the product's roadmap and look at the product as a business line. Ensure he manages the growth and success of his product.

AirBnB recently announced that they are mixing product managers and product marketing because they want one person to be in charge of the product vision and roadmap, as well as the business metrics of the product.

You can't just count new features without understanding their impact on the product. Are they being used? Are they helping to grow and sell more subscriptions? So yeah, having a product manager is key in any organization, startup, or larger company.

Then you have what I call 'product marketing,' which is more about promoting the product. Can you provide all the needed collateral to Salesforce for them to be able to sell it? You need PowerPoint decks, user testimonials, use cases, webinars, and events - all part of product marketing roles.

If you look at where these roles sit in an organization, I'd say that products should report to a CPO-level leader. And for product marketing, it depends on the company's culture and type of products.

Companies, where sales are very localized per country or territory may have different products. In this case, maybe the product organization owns all the products, and sales are per territory.

Sometimes it's different because sales want to adapt all their marketing collateral to their own country due to regulations like GDPR in Europe, which isn't present in the US; you have the NIST security framework, which we don't have in Europe.

You may want to adapt your marketing per region, which makes sense when someone handles product marketing in those geographies. It depends on your cyber security business. Security is a broad topic with many products and people using them, so it’s hard to give a 'one size fits all' answer here.

Sean: Yeah, and something I often talk about on this show from an operational perspective where I think security has an opportunity...

Laurent: You can consider looking at market requirements separately from just customer requirements – regulatory and operational requirements should also be considered. Perhaps consolidating those into a cohesive story and strategy would help when mentioning a roadmap...

The idea is not only to count new features but also to look for integration into other systems. The person with all these products wants to leverage his investment when he adds one more thing to his stack...

It's not about glorifying your technology but rather looking at things from your customer’s point of view – addressing their issues and problems is vital if you want to be successful...

For successful outcomes, don’t simply focus on delivering a great product or increasing output metrics like the number of features delivered or several user stories... Instead, look at your business metrics by putting them in front of your team. We must deliver “outcomes,” not “outputs.”

An example of outcome would be “Aim to grow my user base by x percent this year or aim for this net new revenue for my company...”

Try to escape what Melissa Perry calls 'the build trap' – 'we have an issue, let's build more.' You might end up building redundant features that will not escape being used because there will always be some customer somewhere who uses them...

Maybe being leaner in how you create your app or manage your product by always focusing on outcome-based metrics would help - sometimes less is indeed more...

Sean: I like that example. "The Build Trap" is a new term for me, but I've seen it happen where even big government entities (even if it's not a lot of money) want to see their name or logo on the sales or marketing deck. This adds value when selling to the next customer. However, some off-the-wall, weird networking environments you're trying to support may have one feature that holds your company hostage. Starting as a hostage makes it hard to break free from my experience. This has been my experience with the situations I've been involved in.

Laurent: Yeah, I have a story to share. In my first company, I was the CTO. We had large governmental entities and public companies in France and Canada with contract victory requests. For example, we were adding an authentication feature, and one customer wanted to use the VPN certificate, another wanted an SSO agent, and a third wanted something else. It was always a balance between the usage of the authentication and the level of security it would bring. If we had fulfilled all the requests from sales, it would have overloaded our engineering team.

I realized we should not do redundant things because they came from three big customers. So, I suggested to the sales leader that we meet with all of them and discuss the situation. We put all of them in the same room, and I showed them one slide. The X-axis was the security level, and the Y-axis was the user experience. The dot represents each customer. They started to realize that they were not aligned and that there was a tradeoff between the two. After two hours of conversation, we had only one feature to develop. With that meeting, I could save almost hundreds of thousands of euros.

The key is to talk to people and make them understand what they are asking for. It's necessary to escape the building trap in advance.

Sean: So, how about we adjust this slightly? I'm thinking about the security leaders and practitioners listening to this and finding how companies build products, determine their requirements, and prioritize and make decisions interesting. Your experience, especially now that you're speaking to many startups where you see a lot of messaging, positioning, and pitching for investment money, ultimately translates into pitches for sales from customers. What I'm looking for is your perspective on what to look for.

Starting with an investor's perspective, what are some signs that a company understands what they need to do? They comprehend the role of their product in the larger scheme of things and how it translates to organizations looking to purchase new products. They seek to advance cool tech and startup companies, but they don't want to risk investing in someone who doesn't have a clear product vision, no matter how good the product marketing sounds. It's a complex question with two viewpoints, but perhaps some thoughts could be shared.

Laurent:

I don't pretend to have a secret source of what everyone wants. However, I would suggest to industrial and end-user companies and my dear customers to start sharing their pain points and issues instead of jumping directly to the solution.

It's essential to clearly understand what needs to be solved, the underlying issues, and the drivers behind them. Is it a new regulation, an integration problem, or another IT project? Providing all the necessary background information is crucial when discussing the problem.

Each time someone talks to someone else, some data and signal quality are lost, and the software engineering team is left with incomplete information. By providing background information, drivers, and issues in writing, there is a higher chance that the information won't be lost along the way. The software engineer can then receive the Word document with a clear explanation of the problem and solution and work on it more effectively.

I have seen many cases where the software engineering team doesn't want to talk to the customer because they are afraid. Still, it's essential to ensure that everyone involved understands the problem well, including product sales and managers.

Palantir, a big data mining company, has a concept called "forward deploy engineering," where engineers are sent with the military to learn from them on the field. While extreme, it illustrates the point of making sure that the problem being solved is not lost in translation.

In conclusion, share your pain points and issues and provide background information to ensure the right outcome is delivered, even if it means getting in the trenches.

Sean: Yes, exactly. Another thing to consider is how to integrate engineering efforts with customer needs. One challenge to avoid is overzealous architecture and design, which focus on creating the perfect foundation to build upon. This can be time-consuming and result in unnecessary complexity, making it difficult to respond quickly to changes in the market, customer needs, or security threats.

In light of this, balancing the desire for a solid foundation with the need to be agile and responsive to change is important. Striving for outcomes rather than perfection can help strike this balance. Ultimately, finding this balance is ongoing and requires ongoing attention and effort.

Laurent: It's very, very hard because for sure, I mean, great team ship. So at some point, you need to ship your software and never, ever will have one or two years to re-architect it perfectly. So that is another fairy tale that engineer likes to hear, but it never happened because customers want to have some increment of value and get new things and solve their issues. So perfect architecture doesn't exist.

On the other hand, well, if you don't have that thinking about the architecture you want to build and along the way, maybe having, let's say, 20% of your workload reserved for improving your architecture, solving what software engineer used to call technical depth, which is the thing you put on the back of your backlog and you need to solve them in order not to be pulled back each time you try to bring something new. If you don't do that, you won't be successful either.

And to give you an example of my own experience, one of the things we've done since the beginning of Sentryo was to split the software component that is doing some protocol analysis and the one doing the data mining of this data, the way we look at the kind of messages and vulnerabilities and all these things. And these two parts were in two different components of our software stack.

On day one, we took an architectural design for our software stack, which included two components. This was part of our overall vision. Cisco acquired the company to integrate the first component, our protocol analysis and scanning capacity, into its networking architecture. It was lightweight, running on only one core of a small ARM CPU. Although the architectural design paid off in the long term, it was difficult to achieve. Most of the time, you encounter unexpected things along the way and need to change the architecture. So, I don't have a perfect answer for this. It's always a trade-off.

Sean: Yeah, I think there's never one answer, right? Because as you're talking, I was thinking, would you make a big bet on something with a potential colossal payoff but takes a lot of investment? Or do you try incremental things and try to find the one? We've seen it all and everywhere in between, right?

Laurent: In the scenario situation, you end up with different things. And I mean, engineers need to remember that basically if they work in the startup.

Engineers working for startups must remember that the company has a limited amount of cash, which decreases monthly. Their job is to create something that generates more revenue and keeps the company afloat. Otherwise, the company will close, and everyone will be out of a job.

This trade-off should be discussed openly and honestly among the team, including product managers, CEOs, and founders. It's essential to discuss trade-offs, such as delaying a project for six months or splitting it into smaller parts. Otherwise, the result may be another Frankenstein product that doesn't meet anyone's needs.

Sean: And I love the runway analogy because it is a runway, right? You want the plane to take off before the end of the runway, but you also want it to keep flying, not just crash in the water. And you don't want that plane to be a Frankenstein.

Well, Laurent, it's been fun. We touched on a few points in the Substack article. Of course, I would encourage everybody to read through it. Thanks for joining. I'd love to have you again. We can discuss different points about bringing products to market and seeing them succeed.

Laurent: Yeah, great pleasure.Thanks for having me, and I'm happy to return.

Sean: Lovely. Thanks, everybody, for listening. I hope you enjoyed this. Please check Laurent's post and connect him with LinkedIn.Stay tuned for more episodes here on Redefining Cybersecurity.

Thanks, everyone.