Transcript: Neta Coral | Apiiro | 0 to 1, Not Just in Cyber: How to Build New Product Initiatives Inside a Company

Intro

Eyal David: [00:04] Hi, this is Eyal, you're on Product Builder. We're about to start the episode, but before that, hit Follow on Spotify or Subscribe on YouTube and help us reach more ears. Let's go. Neta, how's it going? Fine, what's up? Great. We won't tell, but we've already done this four times. Anyway, with us today is Neta from Apiiro.

How Neta got into product management

Neta Coral: [00:27] Do you want to tell us a bit about yourself? Sure. So I work as a product manager at Apiiro, on our solutions team. I've been at the company for three years, and overall in cybersecurity for 12 years across a bunch of companies. Before this I was at CyberArk, and before that at another startup that CyberArk acquired. By background I'm an industrial engineering and management graduate, with a bachelor's and a master's in business administration, and that's more or less it in short. Actually, you originally came from QA too, right? Right. Originally, originally I started as QA in a student position. My first job was at GE Healthcare, that's where I started out, and that's basically how I learned about the world of product management, which was very much in its infancy back then. Wow, so I have two questions. One, how did you get into GE in the first place? What did you even study? I studied industrial engineering and management, and I got there even before my studies. I started as QA, and that was basically my leverage to get into GE. I worked there as a student in QA, and toward the end of my degree, you know, I was looking for my path, and that's how I found myself in product management. Kind of along the way, so maybe expand on that a little. Along the way, yes. Let's say that back then, and I'm really talking 12 or 13 years ago, product management wasn't as hot as it is today, it wasn't that well known. We were actually a development group inside GE that converted into a product group. We basically took ownership of the whole product within the group and opened a product management team that, at the time, consisted only of a head of product. And I watched him, because I was interested in what to do next. I looked at him and said, what he's doing looks interesting, I think it's something I could be good at. Little by little I started asking him to hand me all sorts of tasks, until he adopted me full on into his team and I became a product manager in my own right. Honestly, GE was very supportive too. They sent me to product management courses, so I was able to specialize and get to know the domain a bit better. And that's basically the path I took to realize this is what interests me and what I want to do.

Eyal David: [02:46] Lovely. So let's say that when we prepared for this episode, we started with you talking about how to solve 0-to-1 problems, or how to approach 0-to-1 opportunities at all, and then you insisted and said: not cyber, I want to talk in general about how you approach a problem like this. Great, that's our direction. But before that, just tell us for a second about Apiiro, who it's for, who the customer is, what it looks like.

What Apiiro does, who it serves, and the alert-inflation problem

Neta Coral: [03:11] Yes. So Apiiro is what's called an ASPM product, Application Security Posture Management, whose goal is basically to solve the problem of how we know what our application security posture is across the organization. That is, we have several personas we target. The organizations we target are, first of all, large enterprises in different sectors. They can be in healthcare, in retail, banks, software companies, basically all of these companies. It turns out every company like that has a sizable development organization that writes quite a lot of code, and it needs order across its whole security world. Ultimately, what happens inside every such organization is that there's a CISO who's responsible for the overall security strategy, and under them, usually in large organizations, there's a team called the application security team, AppSec. That team is basically responsible for making sure that all the code being written, the whole application, across all stages of the SDLC until it's deployed out, is secure. So it's responsible for making sure the code is scanned at every stage. And the problem we come to solve is that the number of alerts a team like that has to handle is endless. What we set out to do is bridge between the application security person and the developer who receives all these alerts and doesn't know what to do with them. Very often the security person won't necessarily know who the right person to handle the issue is, and even if they do, that developer will probably brush them off and say, this issue isn't even real, I don't use that function at all, so it's not relevant. So we basically come in to bridge all those gaps. Apiiro set itself three goals, which are different layers in how we approach an organization. The first layer is to identify what your application actually looks like, what we call "know what you have." We connect to your source code and do what we call Deep Code Analysis, DCA. It basically maps all the technologies you use and builds you an inventory of your entire software architecture. Listen carefully, because we'll come back to this. So we tell you which technologies you use, which components you have, who talks to whom. We identify what each component actually does, what data it handles, whether it's sensitive data, whether it's maybe code nobody touches, that some developer wrote on the side and that isn't meant to become anything, code that's used for documentation. We need to collect all this information to ultimately help the security person understand what they're dealing with. That's the first stage, and some customers stop at this stage, meaning it's enough for them to know what they have. Maybe I'll give an example. Say a new vulnerability comes out that shakes up the whole industry, and now the organization has to go chase every developer in the organization to figure out who uses the package that introduced the weakness. With Apiiro, that's work that takes you minutes. A very simple query in Apiiro: am I using this or that component, where, who exactly are the relevant people you need to fix the issue, and how do you fix it, and you've closed that one. That's work that could have taken days. I personally remember, in organizations I worked at, the moment a vulnerability like that was discovered, how much we had to go dig to figure out whether it affects us or not. So that's the first stage. In the second stage, we come in and say: with all these vulnerabilities flooding your system, whether they're things Apiiro scanned itself or because you connected us to other security tools, we bring order to all these issues and deduplicate them. Very often you'll get the same alert from several different systems, so all this data needs to be normalized, and we use the data we collected in the first stage to see how to prioritize all this noise for you. So what are the most important things? Once we understand which assets are most critical to the organization, and we do that automatically, we can also tell you which kinds of toxic combinations you should look at, to say: handle these issues first. That's our second stage. In the third stage, we also help you handle issues automatically. We're connected to all sorts of tools in the organization, like ticketing systems, your Slack, your GitLab, all your pipelines, with the aim of alerting you as soon as something interesting comes up, and also helping you fix it. We actually tell you how to handle the issue in your specific context automatically, open a ticket for the developer, write a comment on the PR, so basically close the loop as well. Close the loop, because the only way you can really cope with all of this is through automation.

Eyal David: [08:16] Just before we continue, click the link to the Product Builder WhatsApp group in the episode description and join the community. There you can continue the discussion, ask questions, and be the first to get updates on new Tachles episodes. We're waiting for you there, and now, back to the episode. I wanted to ask you, okay, well, we can also really talk here, you talked about the SDLC process and how it has basically changed since Copilot came in, and code that basically comes from outside, we can talk about that for a moment. But in general, we came to talk about 0 to 1, and my question is, is that something common at Apiiro?

The SDLC is changing: AI and Copilot

Neta Coral: [08:53] 0 to 1. New initiatives? Relatively, yes. I mean, we started as a system that looks only at the world of code. That was the first world we entered, with the goal that you want to be as far left as possible in the SDLC, to solve problems fast, as early as possible so they don't come up later. Yes, maybe we should explain that, it costs more money. It costs more money, really, and also... exposure. Exactly. It's much easier to solve a problem the moment it pops up, deal with it right away, and not wait until it reaches production and you have to start rolling out fixes to customers. By the way, you asked about 0 to 100, so let's say 0 to 1, we even look further left than the code. We look at the organization's tickets, to identify security issues already at design time. To see whether we're already spotting, I don't know, some new API that isn't written well enough. Shift left as much as possible. And in parallel we also shift right. Why? Because we want to know the context of that code, where it goes afterwards, and we simply look as far right as possible to understand how it all connects within the SDLC.

Eyal David: [10:00] So I'll ask it again, basically: is this a company that encourages 0 to 1? Why, actually? We really believe in innovation,

Neta Coral: [10:08] and to stay competitive in the market you constantly have to keep up with the market. And it's quite a market. A market with tons and tons of competitors, and we basically compete in many different verticals. I mean, it's a system that does lots and lots of things, and in each area we have a different kind of competitor. So yes, we always try to be innovative. I'll also say that our customers, as they scale up and as we move into the AI world, we see there's a huge amount of code and lots of things coming in, so naturally the volume of alerts keeps growing. And at the same time, organizations also want to consolidate tools. They don't want a million tools where each one does one specific thing in the organization. So our goal is to expand to cover as many stages as possible for the organization, basically a one-stop shop. If it's enough, it's probably worth it. Yes, that's the idea.

Eyal David: [11:08] Cool. So now, let's call it the proliferation of code that comes from writing that isn't done by a human,

Neta Coral: [11:18] so it creates new problems. It creates new problems. This code that gets written, even if we managed to tell our developer what standardization we expect from them security-wise, which isn't simple to do, the AI certainly doesn't know it. It doesn't know our organization's policies, it doesn't know the standards. It was asked to solve a certain problem, and that's what it solves. It's not looking left and right to check that the code is written in the most secure way, the way we expect it to be. So that adds tons and tons of new risks that we want to make sure are handled properly, and to help the application security person do their job properly.

Eyal David: [12:05] I think that's the whole idea, but there's another issue here too, there's also the issue that maybe I don't necessarily want to share my context as an enterprise with some collective or another.

Neta Coral: [12:13] You may be right. From what I see in practice, it's rare to find organizations that are saying no to AI right now. Because it's the Wild West, okay. It's definitely the Wild West, yes. So all the more so, it's an even hotter potato. Totally.

Approaching 0→1: why expand and what's the goal

Eyal David: [12:30] So let's take this a step forward. All sorts of 0-to-1 opportunities started rolling to your doorstep, I started thinking about things, maybe we'll take this as an example and run with it. Yes, okay, so basically when we come... and we said we'd keep this not necessarily about cyber.

Neta Coral: [12:47] Not necessarily cyber, I'm talking generally now. I think these are tips that can work in any organization, in any field. And the first thing we want to ask ourselves is basically: why did we decide to expand? What's our goal? And there can be several different goals here. Whether it's because we're trying to meet the need of an existing customer who came and asked, like I said before, tool consolidation: come and give me an answer to this problem of mine too. That's something we deal with a lot. Second, maybe we want to reach a new customer audience, and a new audience can even be another team inside the same organization that's already our customer, or it can be a new customer, so serving additional teams. And it can also be, and this is a case we run into, I'm sure all of us do, when we basically need to get a foot in the door, and a customer comes and tells us: I need to have such-and-such in the system. To be qualified to submit a response to that customer's RFP, I need to have something specific in the system, and that's also something I need to address. So my first thing is to identify the reason I'm entering this new initiative, and that's how I steer the solution, the breadth of the solution I bring. Meaning, take the opportunity and analyze it, and analyzing it really means understanding what it might be worth and what it needs to deliver. What it's worth, what kind of solution, yes, what kind of solution I want to give. Do I now need to give a full-blown solution that could replace an existing system for the customer, or do I need to give a point solution to a specific problem, where it's enough for me to do x, y, z to say I have it? That's how I go into this thing. Once I have that answer, I can move forward and start the research, understand what I'm up against. That is, first, technology research. At least in my case, I live in a field where there are new worlds of technology I don't necessarily know. I don't come from a development background, so it's also a new domain I may need to learn, as well as the security aspects within that domain, again in my case, that's something it's important for me to know. Here I get help, because my field is the world of development, so I can lean on the colleagues I have around me. Give me some tips, tell me how this and that works. But if for a second we took that away and tried to adapt it,

Market, domain and competitor research done right

Eyal David: [15:28] then we could basically find relevant personas and talk to them as a start, and come up with some questions? Of course, I also suggest finding relevant personas,

Neta Coral: [15:38] and also, honestly, we all work with AI, so let's consult it and hear what it knows. We may also have a field that's defined, or maybe it isn't. We may have analysts who already tried to define it and produced reports that survey the market and its main competitors for us. By the way, there may be an asterisk here: very often we hear buzzwords when we enter a new field, and everyone talks about them a bit differently. So on one hand, you should be careful. I don't know what people mean when they say X to me, and if everyone defines it a bit differently, then maybe I have certain expectations from the customer who talked to me about it. On the other hand, maybe I have an opportunity here: I can shape and define what this thing is if it isn't well defined in the market yet. So I do that, and like you said, I also want to talk to my customers. If I have customers who came and asked me for this, that's the most ideal thing there can be, because they can be excellent design partners. I basically sit with them, dig in with them, and try to understand the problem: why your current tools don't solve it for you, where maybe the current tools did solve it but not well enough. Because I'm entering something new here, I have an opportunity to improve and do better. So existing customers are great, and it's also important to mention customers I lost. Maybe a customer did a POC with me and I lost them because they said, you're not strong enough in this and that area, you're missing this. A customer like that, whom I lost, probably isn't doing a POC only with me. They're probably also looking at my competitors and doing POCs with them, and they can tell me what they have that I don't. What else would you ask them, actually? What I want to do is basically come and define what that ideal solution is, the one that, if I had it in hand, would serve all the potential customers I could reach out to. So with all these people and all this data I collected, I put together that ideal solution and draw it, in my mind's eye, or not even in my mind's eye, actually on a board, on some sheet of paper. I draw it and start understanding it down to its smallest details. Are you trying to get feedback on it at this stage? Not yet at this stage. Something like two years ago, I think, the hottest area in the security world, or application security, was something called Software Supply Chain Security, which basically means not only how I secure the code but how I look at the application holistically, right? How my whole SDLC is secured. And that wasn't necessarily my customers' main goal at the time. I mean, they were still focused on the things I was helping them solve, things I already had. But I still knew it was something strategic I needed to add to my product in order to target customers I don't work with yet. How did you reach that understanding? Basically customers, lots of customers we tried to approach told us, honestly, no, you're missing these and these capabilities in the product, I'm going to another vendor that has both.

Eyal David: [19:09] So you understood that they'd be in that place when they come up for renewal, that they'd probably look for this too, or that they'd grow in maturity? Exactly, exactly, it's a matter of maturity.

Identifying a real moat and competitive advantage

Neta Coral: [19:17] So I tried to validate with existing customers and got some pushback, because they told me it's not strategic, it's not interesting right now, talk to me in a year. So it depends, it really depends on who I'm talking to. That basically steered us: our opportunity now is to bring in new business. Right, cool. So I started... what, you identified it and basically started digging in that direction? So I started digging in that direction, and basically I come and say, I now want to define my feature set, that ideal feature set, and I go feature by feature and want to analyze each one. My analysis has several parts. First, I want to understand what value each such feature gives the customer. Value: is it the main thing they care about, or is it something minimal and nice to have? Basic. The second thing is how much it costs me to build. As I said, we're talking about 0 to 1 on an existing platform. On an existing platform there are pros and cons. The pros are that there are features I get for free. I mean things like RBAC, things like reports, policies, all things that already exist in my platform, I get them for free. Their cost, from my perspective, is very low. On the other hand, there are things I want to add to the existing platform, and there are a few nuances I need to watch for. If I add it to an existing platform, can I single it out and build it just for my specific need? Or do I now have to make a cross-cutting change in the system and apply that change to everything I'm basically building anew?

Eyal David: [21:02] Exactly. You're trying to find your boundaries, to understand where you operate, in order to understand how much it's going to cost you, and from there you do the scoping. But just a second, before I go there: when you planned the full feature or the full solution, did you also go through competitors? Because you looked, of course. Actually no, no, yes, I didn't mention that.

Neta Coral: [21:22] Do you sign up for demos? No, I don't know, I'm Esti the manager, I see doing that, sometimes, sometimes, sometimes there are demos that are really public and you can watch competitors' videos, but yes, it's really important to understand what your competitors offer. It also helps me define my feature set. Yes, I want to know for each such feature whether it exists at the competitors or not. How good it is, how well it answers the need. Exactly, that's really important. And then there's also the question you and I talked about earlier, I think: whether I now want to go for a solution that's good enough, that's like the customers, like my competitors for that matter, or maybe less, maybe roughly in the area, or whether I go for something that's 10x, that's much more in the direction I want, and then afterwards I can take some clay and basically adapt it to my solution. So yes, I think there's a matter here that I need to ask myself, because if I come and copy-paste my competitors' feature set, then I'll probably always be one step behind them and I'll always have to keep running. I need to find, again, given that my goal really is something strategic I want to invest in and not just something to say I have it. Here I basically need to see how I create some competitive advantage, some moat that will also be hard for my competitors to catch up with once they come and say, okay, I see what she has and I want that too.

Eyal David: [22:47] This moat, do you create it, do you think about it, while you start seeing the system's boundaries, or before?

Neta Coral: [22:54] So it has to go together with my feature set. I mean, I come and say: which of these features can I say, here I identify a competitive advantage that others don't have. And that has to be constantly on my mind when I define that system, because again, as I said, without it I have no way to stay competitive. So I need

Eyal David: [23:17] to identify the strengths I already have in the system that I can leverage for the solution... So remember we planted that pin at the beginning, when you started describing how Apiiro, I'm doing it badly for a second, but how it creates a catalog for the security department of what they have, what it looks like, what it uses, and so on. So if you now give an example of how you took that and used that strength in a feature, maybe that would be a good example. Absolutely.

Neta Coral: [23:44] So the biggest strength... A catalog isn't bad. A catalog is excellent. So Apiiro's biggest strength really is that Deep Code Analysis we do to identify and analyze what happens inside the code. Once we use that and try to see how we basically use it, how we bring it into future things, we can take as an example our expansion, say, to the right, into runtime, by using the strength we have in code. We can identify it, and basically, I didn't say this earlier, but a very, very big problem we have is how we know, and supposedly it sounds simple, to look at the code and say, here it is, deployed in the cloud. But it's a very, very complicated problem. I mean, it's very, very not simple, neither for people working in the organization nor for technology companies, to come and say: this instance in the cloud is produced from this code. That's something that requires a lot of investment to be deep inside the customer's pipeline in order to trace that trail. Now we basically use that same Deep Code Analysis to make that connection. We did it for the code, and now we can look at that instance in the cloud, do the same analysis, then identify the common threads and understand that these two things belong to each other. Yes, do the matching. So the matching problem is a very, very big problem, and we identified that, honestly, our customers, our competitors, don't have a good solution for it. There's a lot of manual work the customer has to do to say this belongs to that. The moment we say we solve the matching problem for you, that's a significant advantage we can offer them. So here, basically. While I was doing that analysis of the future product, we went into a research process of whether we could do this matching, which proved very successful, and basically we see that we're able to replicate it and turn it into an automated process embedded in our product. I jumped a few steps ahead to the finished product here, but within this I basically used a very, very big advantage I had in order to extend it into my new world.

Eyal David: [26:18] So maybe let's connect this for a second. We talked about the problem that a lot of code is written by AI, right? And suddenly I have this capability, right? How could I use it, let's just give an example, how would I use it as a moat, for that matter? So basically part of...

The 0→1 traps to avoid

Neta Coral: [26:35] When we come and say AI does lots of things for us, AI doesn't operate in a context-free world. AI needs context so that we can do something real with it, to solve security problems that, for that matter, we want to prioritize and decide what matters more to us. So looking at that matching and seeing how this code is deployed out there lets me add another dimension of prioritization. I want my customers to focus first on something deployed out there, and not on what's now lying around as dead code that nobody does anything with. So that's basically something I can offer the customer as another capability. Or even finding all the instances, right? Without needing to tag, like you said, so everything that's out there is another dimension for prioritization, basically. Exactly. Excellent. We haven't even touched on the fact that we're talking per vertical here, right? Maybe we'll touch on it for a moment. So basically what's relatively worthwhile, I want to mention and talk about, because it's something I personally fell into, and I think it can be avoided with a bit more investment in our research phase, is that, at least in our world, but I think it's relevant to lots of domains, we deal with different technologies, we look at lots of integrations with external tools. And we need to make sure we're building a solution that isn't specific to any one tool, but that we look at it horizontally. I'll give an example: since we're talking about the runtime world, I want to make sure I'm not looking only at AWS and building a solution that fits only AWS, but that it can also be replicated and extended to GCP and Azure. Because ultimately, if I rely on certain data I saw exists in AWS but doesn't come to me from other places, I'm in trouble later, and I may even need to rewrite the whole infrastructure I built in order to support other vendors. Again, so it stays connected to our goal from the top, and you can shoot yourself in the foot.

Eyal David: [28:43] Exactly. I want to stop for a second and we'll continue. I think it's really interesting to ask you how you do research. Okay. You do very thorough research, it seems to me.

Design partners and first runs with customers

Neta Coral: [28:51] So it really depends on the field and how deep I really need to go, again from the same starting point we said: let's define our goals. My research will usually first understand what's out there. My world is the security world, so I'll try to find security experts who deal with this problem and listen to them. I'll try to find analysts I can talk to, to hear from them what they hear from customers. For example, Gartner are great, great people to collaborate with and get to know. Competitor research is usually a bit problematic in my domain because not everything is public. So exactly, what I can find from, I don't know, competitors' demos, from newsletters they send, maybe I have access to all sorts of open-source tools I can look at. When do you actually raise the white flag and say it's ready? So basically, once I've collected all my research and decided what my feature set is, there's some work here that's pretty cool, I'd say. It's a bit of curation work, coming in and starting to pick and choose, like, what's the mix. Yes. Exactly, what's the mix of features I put into my MVP. So I take, in addition, all of those. We said we need the core inside, season it with a few free features I get, and the features I need to develop, and again I look at cost versus benefit. And so I prepared this whole thing, I designed it, and here's the stage where I must validate it with that potential customer. And here, by the way, maybe I want to tell you about a process I got to do, since for that matter I'm working on a feature like this. A customer came to us who was very interested in this. I mean, it's not why they came to us, but they expressed a lot of interest in it. And I come and show them my design documents, and I had two such very, very large customers where, honestly, that's what ultimately closed the deal. They didn't come for that purpose, but because I showed them my designs, I showed them I know what I'm talking about, that I'm coming to solve a real problem that hurts them, and that I have real plans on the ground, they gave me a lot of feedback I could use to shape the solution, and I also won their trust. And today they're my design partner and I work with them on a lot of things. So that's also something worth doing and bringing into this process. Yes, and if you also have a date for roughly when this thing will go live, that's even better.

Eyal David: [31:57] Okay, cool. So what you're basically doing, so now, okay, we decided to launch the thing, we got over that hurdle of showing it to a few customers, maybe we even really won their trust.

Neta Coral: [32:10] What does a launch of something like this look like? So a launch like this is a very big, happy event. We basically want to get the word out there. We work in a process of rollout stages, working closely with design partners. First, we'll bring an initial version to our customers who we know are interested and want to give us feedback. We'll get that feedback, see that it's good, and make changes as needed. And then we basically expand the set of customers receiving the feature and release it to our early adopters, the set of customers willing to receive features at a relatively early stage. I mean, they're not the first to get it, but they know they're not getting something that's necessarily GA. And then we see that we're really able to work at scale and fit a much bigger set of customers. At this stage we'll also probably add all sorts of PR events, write blogs, put out announcements about the new feature. Usually it might be tied to some big conference happening in the field, so we'll do a very festive launch and celebrate the big event that happened here. Somehow it always happens that when we launch something big, and always while we're working on it, a huge number of customers come to us interested in exactly this thing, so very often we basically have to hold customers off for a moment and tell them, wait, wait, let's make sure we first launch it to the limited set of customers.

Iterating with marketing and sales from day one

Eyal David: [34:02] We got past that stage, GA. Tell us for a second about marketing, for that matter, because you kind of flipped through it and ran fast, but

Neta Coral: [34:10] how involved are they in your initiative, and from what point? Pretty much from the beginning. They have to be involved from the beginning, also because they know what's happening in the market, they know the buzzwords, they hear what customers want, and we want to make sure our marketing language speaks the same language as the product. So we involve them as early as possible in the process. First of all: know that it's coming, know that we're working on this thing, already adapt the marketing language at the initial stage of initiation. And then as we progress, we also want to involve them in the development stages,

Eyal David: [34:50] to make sure our product speaks the same language we defined together. What do you mean? Are you going for benefits here, or really down to microcopy in a blog post or in the product?

Neta Coral: [35:03] Both. I mean, how we describe the... I'm talking not just about a feature but about something relatively broad within the product, so we want to make sure that even the name we give this new vertical is something we coordinated with marketing.

Eyal David: [35:20] So it's a lot of close work we do together. Surely also if we ask you to stand behind the benchmarks or whatever, that they'll follow afterwards, I mean those are checks you basically need to do, right, so it isn't advisable. Cool. If you had to, before we continue, if you had to step out of Apiiro for a second and build your own product, and you had to do 0 to 1. Okay? Without all that high, dry enterprise air? How would you approach it? You now need to get into... you have some problem or some market, and you now need to get in and understand it. How would you do that research?

Neta Coral: [36:01] I assume that if it's a new market I'm entering, it's a market I don't necessarily know, and I'm not necessarily the main user. I first need to understand who my personas are, what problems they deal with, what their day-to-day looks like.

Eyal David: [36:20] Understand the domain. You'd probably start by interviewing people, understanding the jargon, like you said, right? Yes. You don't have Gartner, so how do you do that research?

Neta Coral: [36:29] Again, it's a relatively broad question, so we need to look at what exactly we're looking for. But, but yes, I'd want to understand who my potential user is, where I find them, where they hang out. What exists around them? Right, what's the solution? Even, you know, which forums they hang out in, who, how I can fish them out and hear from them what they think and so on.

Eyal David: [36:54] And here too, the work with marketing probably, or if you have marketing, also needs to be very close and understood from the start, right? Yes, depending on which organization I'm in, its size, how much of a marketing team I really have, but, but yes, I, I try. Whatever it is, you need to market this thing in the end. I'm working on this thing, and my salespeople are, honestly, hand in hand with me from the first stage too. Because they need to sell it. Yes. Exactly. So I really took the matter of circles, it's always true, even if you're building something that, in the end, you're releasing something 0 to 1, you need to pass validations.

Neta Coral: [37:28] You, you obviously open it to paying customers already, right? We open it to paying customers, although we also work like, new features, we can launch them with customers who are in a POC too. I mean, if it's a customer who says, I'll sign on this only if you absolutely have to do this. We talked about it at the start of this, that this is basically the goal and we go for it.

Eyal David: [37:51] Gorgeous. I want to switch records for a second and ask you a question we usually ask here: what, in your eyes, are the most important product skills in product people?

The most important skills for product managers

Neta Coral: [38:04] So it depends on which product. Yes, for a product that's highly tech oriented, I want someone who knows how to do this kind of research process, knows how to look at problems, knows how to ask the right questions. Relevant to every product? I don't know, probably yes. But, but someone who knows, who knows how to dig deep and can basically take a field they don't necessarily know, aren't necessarily an expert in, and can dig into it, can speak the language spoken by my customers, my developers. A lot, a lot of the product manager's role is a communication role. I need to communicate. If we talked about circles, I have tons and tons of different people I need to talk to: customers, salespeople, marketing people, developers. With each one, I need to know how to adapt myself and speak their language and earn their trust, so they know I know what I'm talking about, I trust them, and we're basically working together here to do something shared. If I want to rally them and I'm not their manager, ultimately, then I need to know how to talk to them. The second thing that's very important to me is being able to absorb change. Especially in startups, something new pops up every day, and I constantly need to know how to change my roadmap and prioritize between lots and lots of critical things at the same time. So being a person who's sensitive to change, able to do relatively many context switches, and able to separate the essential from the trivial is super, super important. I can't even tell you how significant that is in my day-to-day. I think those are more or less the central things.

Eyal David: [40:12] Let's say the things you didn't say, but kind of did say throughout the conversation: you talked a lot about impact, right, identifying the impact. You talked a lot about bringing in people in the know, or consultants, in places where you don't know, just don't know.

Neta Coral: [40:27] That's a really important point. I often find myself feeling that I'm not sure enough that I know what I'm talking about, and I need to pull in relevant people to research some specific topic. I really like consulting with experts in the field, whether it's the technology, security, or I don't know what.

Eyal David: [40:53] It's just shit, shit, right, at the end of the day. At the end of the day I know I can't be an expert in everything, I need people beside me to help me navigate this world very fast, that's basically what you're saying. Okay, cool. Just a second, we're nearing the end of the episode. Do you have anything else to add about 0 to 1 that we didn't talk about?

Neta Coral: [41:16] I think we covered most of it. Maybe one thing I didn't mention is just to make sure I'm building a solution that actually, of course this happens at the validation stage, but it's better to do it earlier, to make sure I'm building a solution a customer will be able to adopt. That I'm not inventing all sorts of things for them where, for example, I need to ask them for access to some system they can't give me access to, or I'm asking them for very broad permissions. Those are blockers. We should have talked about blockers, we didn't talk about blockers. Those are things I also ran into in the past, and we had to do an about-face and see how we redesign, doing all sorts of workarounds to make sure we don't hit walls when we come to the customer.

Eyal David: [42:04] Yes, okay, so we're really nearing the end of the episode, and I want to ask you: if you now had to refer to this episode three months from now, three months is a lot of time, but some golden tip that you'd refer a friend to and say, wow, you have to hear this because of this. Do you have a tip like that?

Neta Coral: [42:25] I'm an analytical person, I like to work in an orderly way, and I think ultimately there's a set of a few steps here that, once you go through them and do them one by one in an orderly way, can really solve problems for you. Like we said, it's not true only for the security field. I think it's true for product management no matter what domain you're in. So in my eyes, if you're entering a new, unfamiliar domain, these are simply the steps I would follow to get on the main road and see how I get there. And most importantly, always keep in mind the goal of why I'm doing this thing, so that I'm constantly aligning to that goal and not now developing monsters that aren't relevant.

Eyal David: [43:16] Excellent. And do you have another tip for product managers?

Getting into product management in cyber (including women in the field)

Neta Coral: [43:21] In general, since you mentioned women product managers, I think that specifically in cyber, as rare as it is to find women in high-tech in general, although I now see more and more women developers, which really excites me and makes me happy, I think in cyber there are even fewer women, and it can be a relatively intimidating field for women who want to enter it. So, so first of all, fear not, nothing is too big, and my door is really open, and I'd be happy to meet women, whether they're women already in the field, women considering entering the field, or anyone who's interested

Eyal David: [44:05] to reach out, and come, come let's talk. Tell me, and if you now really want to address someone who wants to get into product management, not necessarily cyber. Because I really agree, there are fewer there. How would you recommend getting into this field?

Neta Coral: [44:21] For example, you actually came from GE, right? I came from GE. I got into the cyber field really by chance. A friend-brings-a-friend kind of thing. I moved into another role. I mean, I was already in product management inside GE, I veered a bit to the side and took a role at a cyber company in project management. I simply looked around and saw what people in my company were doing, what they were working on, and I tried to do it too. I mean really hands on, to start getting into the substance of what this product is, what the product of the subject is. Specifically, I worked at a company that dealt with a proxy that looks at data moving from place to place and performs all sorts of operations on it, encrypts it, touches it, and so on. Look, at GE you did the same thing, basically, you said you went and watched a product manager. Absolutely. I locate the places I'm interested in getting to, and then I simply get my hands dirty and get wherever I get, and that's how I simply learned about this field. I added more and more and more experience until basically, you know, I felt confident enough to say: here I feel, I feel I can now come and be the product manager of this thing.

Wrap-up

Eyal David: [45:41] Excellent. So anyone who wants to can reach out to Neta on LinkedIn, we'll leave a link. Gorgeous that you came, what fun. I had a really great time, thank you very much. Thank you very much, bye for now. Bye. Hey friends, thanks for listening. If you found this podcast valuable, you can subscribe and follow us, of course, for more episodes on Spotify, Apple Podcasts, or any other app. And of course, if you couldn't find us on some app, I'd be glad if you wrote to us. We'd really appreciate five stars on every platform and for you to follow us, so more listeners can discover us and find the podcast. You can also find previous episodes in any app or on the YouTube channel, we have links in the description. So until next time, yalla, be efficient, and bye bye.