Transcript: Nardit Hikry | Upwind Security | How Do You Design UX for a Cloud Security Product?

Eyal David: [00:00] Hi friends, it's Eyal. You've reached Product Builder, where you can listen to the most interesting product conversations. My journey began in 2012, when I learned what product is at my own startup. Since then I've worked in the industry, and since 2017 my company has been advising a wide range of companies. My drive is to help all of us get better as product people. And before we start, if you enjoy listening to Product Builder, please rate us five stars on Spotify. It gives me great feedback that the podcast is giving you value, and it would make me very happy, so yalla, let's start. Hi Nardit, how's it going? All good, how are you? All good, a rainy day. Gloomy, but it isn't actually raining yet. Right, so you walked here from the Upwind offices, right? Right. So you describe yourself, in a word, as head of product at Upwind. Tell us a bit about the company, what it does.

What Upwind does: cloud security from runtime to code

Nardit Hikry: [00:56] So Upwind is a cybersecurity company, a startup that's two years old now. It deals with protecting the resources that live in the cloud. It started as a runtime detection company that responds in real time to attacks in the cloud, and recently it has evolved into a full platform that provides an end-to-end answer across all the stages of running in the cloud: from configuration, through writing the code, and of course in real time. What it brings to the table is the ability to bring in context from real time, to analyze communications, analyze processes, and add that on top of the configuration that other companies provide.

Eyal David: [01:41] Okay, so let's take it back a little and break it down for me. Who is your ideal customer? So our classic customer is the CISO, the...

Bridging security people and DevOps

Nardit Hikry: [01:52] and the security engineer, the cloud security people. But we're actually doing something a bit unique here, because our founders came from the DevOps world; they previously founded Spot, for those who know it. So in practice we bridge here, we don't answer only the CISO, we bridge the gap between DevOps and the security person and give a much broader, more holistic answer that also bridges the gap between them, which is often really tough, because DevOps has visibility into the cloud assets and the ability to configure them, while the security person basically only has visualization and needs to get DevOps to act. So we want to help the security person give DevOps, who can operate things, a lot more detail, and often to actually act on their own. Interesting, so the companies working with you probably need to be big enough to have both of those roles. Not necessarily, not necessarily. In many small companies it's really one persona; there's probably no gap to bridge there, and the DevOps person probably has better visualization, but we can definitely help them reach solutions much faster than they do today. And what's the most common use case that makes people use your product? So we have different companies that buy us and also evaluate us on several use cases, because for each use case there can also be a dedicated company providing the solution, and we come to give a more holistic solution. So there's the threat detection use case, which means real-time response to an attack; that's where we started, it's the classic use case we really answer, and we keep expanding it day by day. And there's a use case that's no less important, the configuration and code-writing stage, where we actually scan the system and check where the assets may be exposed to attacks

Eyal David: [03:57] and how you can actually prevent them. Wow, that sounds amazing and unique. So let's talk for a second about the industry.

The competitors in the market

Nardit Hikry: [04:05] What other companies compete with you today? You mentioned various competitors earlier. We have pretty big competitors in the market. We have Wiz, we have Orca Security, Prisma Cloud, a lot of Israeli companies too, but each one takes it in a slightly different direction and offers its own uniqueness.

Eyal David: [04:23] Cool. I think what's also interesting is that you took, we talked about it before, the communication between the DevOps person and the security person, the CISO; that's a really interesting take on it. Yes, it's really something inseparable from us, because I also worked at Spot.

Nardit Hikry: [04:36] We simply live it, the feeling is that we live it, you can't not. We also have developers who came with us from Spot, and the founders of course, so our angle is a bit more sophisticated and deeper, in my view, than someone who comes only from the security world. It's a different language.

Eyal David: [04:56] So you came to this podcast, and I told you this downstairs too, I'm kind of glad that specifically you came to represent the company. Because in the prep call we did, you had a very broad view, much broader than design in a big company. I felt we were talking product and talking business, and we jumped between many worlds, and that's the conversation

The day-to-day and the weekly product offsite

Nardit Hikry: [05:17] that's very interesting. I'd like you to tell us for a second what your day-to-day looks like. So really, my role did start as classic product design; I came from Spot and that was my position. But very quickly, because of the stage at which I joined the company, and because the founders understand that the user experience of the product isn't something to take for granted, it has to be one of the most prominent and best things for the product to succeed. So really my day-to-day is a bit different from a regular product designer's. For example, once a week we have a meeting called the product offsite, which brings together all the stakeholders in the company: the VP Engineering, the VP Product, the founders themselves. We all go over mocks together. I hear the requirements from the salespeople and from the founders directly; I don't need the filter of the product managers. And then, in very, very close collaboration, we research the business together; the research people help too, of course. And basically everything passes through everyone's eyes in order to reach the most precise solution for the user.

Eyal David: [06:29] Okay, that happens once a week, and that was actually really interesting, so let's crack it open. How long does a meeting like that last, what are its outputs? It's a three-hour meeting. There were also weeks when it was longer

Nardit Hikry: [06:41] and now it's slowly getting a bit shorter because it's tighter. And really, it's funny, but they're proud that since the company's second month we haven't missed a single week of holding the meeting, even if one person or another was missing here and there. It's something that, the customer, really customer obsession, which is an Upwind value, stands out a lot. It's my luck, actually, as a product designer, to join a company like this; it's not a given. And I usually pretty much lead it. We go over, sometimes there are product documents, but the heart of it is really going over the experience and getting everyone's feedback, and also getting a can-do approach from R&D so there are no surprises, and then

Eyal David: [07:29] it really gets executed. I connect with your approach. Tell me, and I still want to push on this for another moment: you said UX is a very, very important thing in this product and that it was clear to everyone. Could you expand on that? First of all, when I came to Upwind, the founders were already ready with a set of values.

Company values that put UX at the center

Nardit Hikry: [07:51] The set of values included customer obsession, included fail fast, meaning even if we don't succeed at something we'll fix it, speed, not getting held up on anything. Really a set of values that put UX at the center and gave me a free hand.

Eyal David: [08:12] I'm with you, I'm trying to understand, but why exactly did they define UX as the engine behind the company?

Nardit Hikry: [08:19] I think we understand that's where the world is going. Today, products without a good experience simply don't survive in the market. That's the fact, and we look at competing products, examine their experience and see where they fall short so we can learn from their mistakes. Because people who come into very complex security systems can sometimes get overwhelmed and leave the system if they don't feel... In systems like this you need to create a lot of trust with the user, so they really believe that the data we bring is really what's right, to work with a lot of evidence, to bring them the information in the most accessible and most truthful way. But, but not everything; to condense it for them, to bring the most precise information and the most precise message, so they know how to act as fast as possible and fix as many things as possible in the shortest time.

Eyal David: [09:15] I'm really glad you brought that up, because it's the main topic we'll talk about today, and I'm curious to know how it fits together with speed. Because one of the things they defined for you is that speed is the most important thing, and, as mentioned, doing very good UX, especially for several personas, is something you need to go deep on, right?

Speed vs. quality: fail fast and design partners

Nardit Hikry: [09:30] That's my biggest challenge. There's no doubt about it. Sometimes I also need to raise the red flag here and say, wait, wait, wait, I'm giving you the solution now, but it's not certain it's the best solution. But there's also the value of fail fast; it's really important to us to get a lot of feedback from customers. So even if we deliver something fast, we communicate it to them. It's very important: the salespeople, the SAs and the account executives actually sit with the customers. We have customers who are design partners too, and we communicate to them that right now we shipped something because it was important to us to get their feedback; it may not be perfect, we'll keep fixing, but we shipped it anyway. It's better to deliver something, get the feedback, and then, also, there's no such thing as perfect for anyone. There's no such thing; you can always improve, and we really believe you can always refine and refine and refine, and that's UX too. That's its whole thing, refining. So sometimes it may be hard for me when something ships half-baked, but in the end it proves itself. Yes, so is this something you're encountering for the first time at this company, or before? Honestly, I got to Spot after it had already been acquired; Spot was already Spot by NetApp, the pace was different. And before that I worked at Amdocs, which is also a corporate company, like, like NetApp, so I didn't work at these speeds. Actually, you could say there were stages where I felt bored there, because until I got something out the door it could take months and years. So it has its downsides, but it also has the fun and the adrenaline this creates. And now your team also works this way, it's something that's been ingrained. Yes, there's no, no, no, I need them available. I have two designers and I need them available and attentive, and they also had to go through, you know, when you study UX in college you learn there are processes, there's design thinking and empathy and all that. So we keep the fundamentals; it's not that we don't. We know who our personas are, and on big features we make sure to take time, and yes, we do interviews and user testing and all those things. But we also know when to let go and just let it run, get the feedback and fix. It's very delicate, but it's a process you probably go through in a startup. Probably in a startup of this kind. And empathy, I hope you meant empathy for the user. Yes, empathy for the user. You also need it for the people working at the company. So okay, are you hiring now? Yes, we're very, we're constantly growing, and we mainly need backend developers and

Eyal David: [12:19] frontend developers to help us run at our fast pace. A question we usually ask here, and I'm really curious to know: what product skills are most important in your view?

Product skill: fit the solution to the company's stage

Nardit Hikry: [12:32] So really something I learned firsthand is that one of the important things in a product manager is that they fit the solution to the stage the company is at, both the business stage and the stage of R&D's capabilities. Because many times we thought about and planned to do things that were too grandiose, and in the end it shrank and was really lean. You need to think that once a product manager builds a solution, with or without a designer, they need to take into account a whole set of parameters: what the company's technical capabilities are right now, what the business situation is, which customer they're targeting, whether this feature is meant

Eyal David: [13:12] more for the sales stage right now or for daily usage. You need some skill to understand the situation. It's always a thing where you, from one side, I don't think, in a product mindset: on one hand you need to communicate the vision to the customer, maybe even create some screen that demonstrates very well where you're going, but at the same time create drop one of the thing, right, so it communicates. So first of all, we do that, we create

Nardit Hikry: [13:41] it doesn't matter, not, not at the level of spaceships, but we also create prototypes to show the customer where we want to get to. But we also try very hard that what we deliver is good enough. It has to be. And we don't compromise on that stage, and honestly our developers are at a level, I'm really happy to say, they're dream-makers.

Eyal David: [14:03] Amazing. Sometimes it doesn't depend on the developers at all; it's data you need to collect over time, or things that need to happen. Yes, but also, when I talk about experience I'm talking

Nardit Hikry: [14:11] a lot about the UI too, and that's not a given. Dream-makers, what times we live in; it used to be so much more complicated.

Eyal David: [14:19] You started talking about your challenges, you listed one; do you have more challenges? So we said the first challenge is really speed.

One feature, several personas

Nardit Hikry: [14:27] The second challenge is really that I need, that we're at a stage of the startup where it needs to serve several goals. So every time I open, now they give me a certain requirement, I need to think about where this requirement comes from and which goals it needs to answer, business-wise, right now. Is it now meant to be a dashboard for our buyer, which is the CISO, or do I now need to work on a dashboard that really prioritizes for the security engineer, or do I already need to give the details in the dashboard to DevOps so they can solve the problem? So I have a whole set of personas that one feature is supposed to serve, and it needs to be done in a very smart and elegant way so that it delivers the answer.

Eyal David: [15:18] But there are solutions. So how do you approach that distilling? Do you do it with team members? Do you do it as part of the offsite? Do you do it alone? What does it look like?

Nardit Hikry: [15:29] So it depends on the feature, but broadly, one of the very first things we do is understand how it works in the cloud. Understand where our users, how they work in the tools they have. Because even if we think up some vision, imagine what the user will do, as long as we don't... In the end they work with a million tools they already know, and you need to connect to the tools they work with. So that brainstorming is worthless if we don't see how it works in the real tools, if we don't talk to the users. So first of all we try to get as much information as possible from users. Really see how it works in the different clouds, what the assets look like there, what information there is on each asset. Whether there are equivalent products in the cloud, and there are, like, there's an answer for threat detection in AWS and also for vulnerabilities separately; our features already have different answers inside the different clouds. So first you need to understand what the user knows. And only then move on to how we improve it. There's a line that Amiram, the founder, likes to say: we don't invent anything, we only improve.

Eyal David: [16:42] That's very true. So tell us for a minute how you do discovery, because that seems really interesting to me; I'll even sharpen it. Most of the products you deal with, or as competitors, sit behind some wall of login or payment or a demo; they're not open. Right. So you can talk to your customers or to various bodies to get information about them, you can look at demos; what else can you do, like, what else does your discovery look like? It's mainly, it's mainly hearing from the customers, also hearing what they like more.

Discovery when products are locked behind demos

Nardit Hikry: [17:15] Many customers we work with already have products, even if they don't give a full answer; sometimes they have several products that we can replace. So they can really give us some starting point to understand where their pains are. We also really watch a lot of competitors' demos, and also the clouds themselves. Besides that, we have a research team that brings us a lot of data. It's very important to bring in, of course, I didn't talk about this at all, but you can't work without data: understand the volumes, understand the pains in numbers, understand what order of magnitude of things we're even dealing with. Those are the tools, and our salespeople also do the work.

Eyal David: [18:06] Yes, I think discovery in these worlds is really interesting because it's really very limited. Okay, so when we talked about challenges, another challenge came up that I remember you mentioned: you talked about needing to deliver things really fast, and on the other hand you also want to get feedback very fast. So what does that look like? Do you actually create mocks, as you said, and send the salesperson with them to a customer call, do you join?

Fast track and the saved-views example

Nardit Hikry: [18:28] What does it look like? Yes, so the intervals, as I said, are very, very short. Many times the founder, we have a core group, a core design group, on Telegram, and there there's really a fast lane, as it's called. There are the more orderly features that really go through the more regular product process, where we know we now need to work on something big, the product manager writes a document and then it comes to design. But there are also the fast-track processes, as I call them, where a customer needs something, we're in a POC, we want to close a deal, and now how can we do it in a smart and fast way and deliver value quickly. So usually it comes into that group, which is really me, the founders, the VP Product and the VP R&D. We get the requirement, we create an initial mock relatively quickly. We get feedback in a fast cycle; many times we already bring in someone strong from engineering to give quick feedback too, to see some validation, yes. Many times we actually go to the customer who asked and ask, what do you think, does this really answer the solution? It's very important for me to say that many times these things do come as a very fast, very specific requirement, but I insist; I'll always ask the question of what's really needed here. I won't blindly go with the customer's, now add me a bunch to the URL, add me this row of all the filters I filtered. I'll always think, okay, what need am I trying to solve here? There's a real story here, a small example we had: a user asked, on one of the dashboards we built, that once he filters something, things get saved in the URL so he can share that URL with another persona in the company, and then they'd get the same view of the dashboard. Okay, that could be one solution, but before you give him what he wants you need to ask yourself, what's his need? What the user actually wanted was to create some view in the dashboard that could be reusable, that he could open again to see if something changed, to see if there's a trend around exactly that particular filtering, and to share that view with other people in the company so they could do the same. So we chose to solve it by saving a view of filters, including generating a link that can be sent,

Eyal David: [21:11] rather than saving it in the URL in a patchy way to give a very specific answer to the customer. Intriguing, so let's dig in here for a minute. How did you approach it? Because you got this request, and on one hand you can map it to other needs that came up, maybe from different systems, things you know as best practices. How did you actually know to say, okay, he needs filtered views here and not...

Nardit Hikry: [21:37] So first of all, I don't skimp on questions. What's needed, why it's needed, who asked, which customer, what was their need, what was the need. Many times you can even read it in the words of the SA who passed on the requirement, that he simply doesn't know how to translate the need. But I always take it to the further place of sharpening the user's problem. Of course I validate before we run to solve it, especially in development; maybe in mocks, I do make initial mocks, but it's important to take it to the user and ask, would this solve your problem? And then suddenly, yes, of course it would solve it, oh, it's better than I thought, many times. And applause. Yes, yes, and then there's, especially the SAs, whom I really love, but the SAs also come back with feedback, which is no less important. It's important for the whole group, especially for the developers too, that they always come back with the feedback: the customer loved it, the customer was happy, thank you very much. That's also something we really try to instill in the company, because working without feedback, nobody...

Eyal David: [22:40] That's also lovely, because you're kind of training the salespeople to already think about these questions themselves, right, to come to you with input.

Career: from Amdocs to Spot to Upwind

Nardit Hikry: [22:47] I had exactly such a case today, an amusing one honestly, at the company. We made a feature to give a name to an object, to one of the assets in the system that doesn't come with a name. There are assets in the system that are stored only as an ID and had no name. And then I posted in the group, here, we added a name, and automatically the salesperson came to me, I need a name here too. Now, it was a bit, and then we looked and saw the object has a name. It's just that the name we gave it is gibberish, an anti-key, yes. So he, but like, they, they, I do see a process where they do notice our solutions in UX and UI; they suddenly see, they manage to get to thinking about those same solutions of ours on their own sometimes, rather than being fixated on... In the end he lives the product, he runs all the demos, he prepares the demos, so he also runs into questions. Very cool. Okay, so let's dive a bit into your story to understand who we're talking to. Can you tell us a bit about your path, where you started, how you got into tech at all? Yes, I started as a marketing designer at Amdocs. I dealt with everything related to presentations, but already there I was very business-oriented. I wasn't classic marketing; I did the... I was in a group that was actually an R&D group, where the VP R&D there decided he needed a designer to convey the messages. The messages to whom? To customers. To customers. It was a special group, an innovation R&D group at Amdocs that created very innovative products, and they needed someone to help them deliver the messages. I think that was the first time I understood I need to understand the business in order to convey messages, and that's something that has stayed with me to this day. After a year I moved to the product design group at Amdocs. It was a group that had UX, pure UX, and pure UI too, and I worked on one of Amdocs' core products, which was a back-office product, but it was really innovative, because it was the first time that Amdocs, which at the time was a bit archaic and didn't believe in experience, decided, understood, that what would change sales was experience, and it brought in a group of front-end UI developers from outside. I worked with them and learned a lot from working with them about how to build a design system. I got to build the first design system at Amdocs, and I'm talking to you about 6-7 years ago, when it was just buzzwords and didn't really exist yet; today everyone has a design system. It wasn't like that back then. And really working with tools like Storybook and building components, and really for the first time defining the UX behind the components and thinking through all the edge cases, while again understanding that you need to understand the business, you need to dig into the existing products, you need to get dirty, get your hands dirty. Even as a designer you can't just wait for product to do it and tell you do this, do this, do this. And then, after, I was 12 years at Amdocs, only five of them in product design, but during Covid, after it had already started... I live in Hadera, I didn't mention that, which is a bit far from the Tel Aviv world; I was a homebody. Too bad, the north, what do you mean far? But no, yes. So only during Covid did I start glancing outside the golden cage I was in, because I really had a leadership role there. And working on a product that was really unique in the Amdocs landscape; today I assume they've aligned a bit and experience gets buzz there too, so I learned a lot there, I have to say. And then I moved to Spot, which was already Spot by NetApp, and entered the whole DevOps world. There I was also the leader of the designers' guild, and I instilled processes, I started instilling, I wasn't there a very long time, but research processes. What didn't exist there: working with data and FullStory, asking questions about how you actually measure success, what the criteria are, how we can check it inside the interface. I don't know if you know FullStory, but it's a platform that measures, that looks at sessions and can bring metrics on the sessions. So anyone who doesn't have a data analyst can do it themselves; if I'm not for myself, who will be? We really analyzed flows there to improve the experience. And I also got to work on several flagship features, like the dashboard, which Spot didn't have until then, and also a new onboarding.

Eyal David: [27:42] And after a year and a half there I moved with the founders, as I said, to Upwind, to build something new. A dream-maker. So I have to ask a few questions. First, I love this story, like Steve Jobs: okay, building presentations accompanied you throughout your career, and later it probably also made you distill and get closer to the business. And how was that transition from Amdocs to Spot? Because it's completely different, right, you kind of said it between the lines. The field is different, but in the end I came to a company that was

Nardit Hikry: [28:21] already corporate, it was already designed. Yes, I had, it came, at Spot there were no processes, because the stage at which I joined was, okay, they were bought, we're now integrating with NetApp, and what now? So I came in at a very interesting time where I had the opportunity to say what now and bring in all the processes. Also there was, like, a designer for each product, and they didn't collaborate. And I really did the work of connecting there, and seeing how we push it toward a design system there too. So really, but still, there was something, by contrast, the big leap was like, okay, where do you start, we're now in a new startup, what...

Eyal David: [29:02] what do they want from me. So okay, you took the plunge. So how long did it take you to get going?

Nardit Hikry: [29:10] At Upwind, they started, they waited for me a bit, they started with some agency. I got a very rough start to look at, and I had to learn the business a lot.

Eyal David: [29:23] I had no choice. How long did it take you, how long did they give you? They don't give, they don't give, but you need to learn; how long until you'd absorbed it?

Nardit Hikry: [29:30] Within a week I was already running. I really learned what I needed to solve the problem. You know, I think UX is really a field where you can start delivering without, while you're learning, actually, because yes, but when you're, when you're 14 people in a startup, it's not like there's someone doing the work in your place; everyone has to be sharp on everything.

Eyal David: [29:51] That's also one of the values you take with you in the company, right? Hmm, we're no longer 14, but yes, we like, it's, it's

Nardit Hikry: [29:58] the efficiency and the profile, the professionalism, it's, it's, you can't wing it, you said it. Of course sales needs it completely. Okay, cool, so let's talk for a minute about distilling a problem.

Eyal David: [30:12] How do we approach a problem, how do we distill the solution? I'm sure you came with a few stories you want to share. Yes, really, like, I'd be happy to share various ones, to maybe also give value with various, actually

Distilling a problem: the dashboard with thousands of assets

Nardit Hikry: [30:27] many times we get a requirement that, like, solves the problem. They tell you, okay, now you need to do it like this, and then supposedly you could just accept what, as a designer, no, you, I believe you can't accept what you're told as a given; you can start digging a bit more to distill the problem. So when you say they ask for something, is it a feature request coming from a customer? It doesn't have to be; it can even be at the level of a bug fix. Or it can be a feature request; it can be at all kinds of levels. I can give examples. For instance, we worked on a dashboard. In the dashboard we need to show numbers saying how many problematic assets we have, not problematic, assets exposed to the internet, by different categories.

Eyal David: [31:17] that we have in the system. So let's get into the head of whoever sits in front of this; it's probably the security person, right? They want a status picture, some sitemap of what's going on. One second.

Nardit Hikry: [31:26] It's even the CISO, someone more senior in the security world, who now wants to understand where I stand, how many, how many of my assets are exposed to the internet, how much I'm at some risk. That's the degree of risk, right? Yes, yes. Okay, yes. And then we built a component, intuitively you say, okay, I have, I have categories, I'll put the number of resources per category. We come and start developing, because, like, we answered the problem, okay, right, that's what we wanted, we answered the problem. We start developing and we see that the numbers coming back are thousands and thousands of resources in large environments. We see we have a thousand assets exposed in this category and another two thousand, which really deters the user, the CISO. He says, okay, even if I have these numbers, how do I solve this, what am I supposed to do with all this information, what am I supposed to do with it, what are these numbers? So we understood that the quick solution we gave here probably wasn't precise. It didn't give our user a precise answer. And then we understood we could go up one level, and instead of showing the number of specific assets, give, as we call it, for every asset that comes up we call it an issue. So basically give the number of issues at the headline level. Say we have some asset that failed its compliance, so say 83 assets, yes, do grouping, see the grouping, and then if someone now does want to see the details, let them start drilling down from top to bottom to examine the details. But this way the numbers will be a bit more reassuring, it will serve our user, and it will give an answer both to the CISO now and to whoever later needs to start solving the problem and see the details.

Eyal David: [33:17] Gorgeous. So you also handled several personas here, yes. And you keep saying we discovered, we did; what does a process like that look like?

Nardit Hikry: [33:26] First of all, I always speak in the plural. I remember that, for me, we're one whole team, including engineering. One of the things is that I really always work in collaboration with everyone around me, so I don't take, maybe it's a mistake, but I don't take from them. Yes, so we discovered; in this case specifically, the numbers, we already saw, the developer saw and said, is this what you expected? What I instill as UX, which is the most fun thing in the world for me, is that the developers themselves, the front-end developers, are like my gatekeepers; they raise flags like crazy. The next stage is that they also come with the solution: maybe let's do it like this. So they come. Say I had a developer who worked very, very intensively on a module called identities. And now we're working in threat detection to add identities, so she already knows; she's already telling me, but I want this to be clickable and open the persona for me. Wait, wait, wait, wait, wait. We have that option? Like, she already knows, she already sees the solution, and to me that's the secret of success too: that we manage to make this seep through to everyone. Yes, right. And how fun it is to come in the morning to this company, honestly.

Eyal David: [34:40] How fun. If you want to get sharper, talk to Nardit. Tell me, in this case, did you do a retro on it, think about how next time you could avoid a situation like that? So I take it mainly with my team, the

The design team's checklist and brief

Nardit Hikry: [34:53] retros. First of all we set up a checklist that's not about technical things but more at the conceptual level, of what things you need to think about before we even show the mock: how, which things, whether all the personas are addressed. They need, every feature they work on. So one of the things I told them: even if it takes you, you don't need to go crazy now. But do distill the problem and write down which personas we're solving for and what the solution is for each persona. Like, this checklist is also part of their growth path, of course, to see that we're really progressing, but

Eyal David: [35:34] it sits mainly with us in the design team, but that's the process. Maybe you could, I'm thinking out loud with you, bring in some brief template that you require to be filled in, and then you get in advance the information you might need, or the answers, and you can. Yes, it's just important to me that before we start working

Nardit Hikry: [35:58] they ask the questions. It'll also be the customer you're now opening the problem for. There's always someone behind it; even if it's a big feature, it might be four customers, but in the end there's always a customer, a persona, a human being behind it, and if we know that, we can refine the solution. Right, at our company we really have a brief for designers

Eyal David: [36:20] that was written in blood. It works, it works great. In terms of efficiency, we work that way, so yes. So I don't know, for us it works. What other things did you run into where you really had to distill another problem and dove in?

The standards list and the special filter

Nardit Hikry: [36:33] So I'm actually not talking about the big features, because of course everyone knows the solutions for big features, where you have to come with, like, there's an established process and you ask the questions. I'm talking specifically about things that happen along the way. I think that's a bit more... You're right, I think so too. A bit more intriguing. So I can give an example we just had: we released a new feature, a new design for an existing feature actually, which is about compliance with standards for cloud resources. These standards are very formal documents with numbering and hierarchy; every standard really has a category, 2.1, 2.11, and it's something that people who live it know, sometimes even by heart, that numbering. And each such standard can be an automatic check we run for our user, or there are things they need to do manually, or we're missing information. And then we released it. Let me just ask: you're building the tool that's, like, the visibility of managing this thing? Yes, okay, meaning we, you connect your environment, we scan it for you and tell you how many assets failed, how many assets passed, and which assets failed, of course, not only that but also over time, and we give you all the information around it. In the end it's a list where you see all the standards and you see where there are problems. And then they came to me and said, listen, the list looks great, but let's move to the bottom all the assets, all the standards that aren't relevant at all, that have no assets to check, that are checked manually; they're just making noise, just making noise. And right away I say, if we move them down... Okay, what's the problem? First of all, if we did, first of all you're in the mindset of, no, why not? There's nothing to do, it's everyone's intuition; everyone says why not, why not. Because if I move it down, the whole order of the numbers will be jumbled, and then for the users it'll be, okay, why is the order of the numbers like this, it'll start raising questions. Say, even if there are some aggregations above some numbers that sum it up, it, like, doesn't speak that language. Yes, everything started getting kind of messy there, it's not... So it's like, and then someone suggested, okay, maybe we make all of them, all the ones that aren't relevant, gray. And then I'd have a zebra here that would also start raising questions for the user: why is this gray? Why is that black? And we don't like our users asking questions; the goal is to make things accessible to them as fast as possible, what they need to handle, and not make them ask more questions, because the system is loaded as it is and there are a lot of riddles around the security world. And then I asked myself, okay, so what are we trying to achieve? We're trying to achieve, I didn't just ask myself, I even asked my colleagues, what's the goal? Let's go back to the plural, right? Yes, we're actually trying to distill the problems. Understand what needs to be handled, and cut the noise, simply cut the noise, because there are a lot of things to handle in a feature like this. And the solution I came with was a special filter, not a regular filter either, a very prominent filter above the filter, what we call a special filter, that would quickly give me all the standards that failed. As a result, it would clear out not only the controls that are checked manually or have no resources, it would also clear out the ones that passed and are all fine. So that's how I decided to propose a filter for that state, a filter for the state of everything that passes, and the user can choose which view is more right for them to see right now, plus everything, of course, for whoever's interested.

Eyal David: [40:19] Okay, so you're actually describing a much broader feature than what was asked for. I have all kinds of questions. One, it's good that you took it, you concluded I probably need to adopt this, also that it's really what they want, right, yes. After that it's interesting to know, relatively, after that you want to know, I assume, or you don't deal with this very much business-wise, so I think you do: how much this thing will cost compared to the original thing they asked for, right?

Nardit Hikry: [40:45] Yes, in this case we do that, but here it was clear the original thing wasn't good, it was much less good, so not even. We didn't ask the cost question in this specific small case. Because the value the customer would get, it would simply be a few days of development; making a filter costs, and it's a backend filter that takes three days, they're working on it now, but still, the feeling is it will give much more value.

Eyal David: [41:16] So let's say that most of the time, if it's not such a tiny feature, we'd ask that too. What other questions do you ask?

Nardit Hikry: [41:25] At this stage, like, it's not enough that it just looks nice and gives value; we want to know whether it answers other feature requests too, right, from others. Whether it can also be reused in other features. Right. Like, the same solution; our goal is for the system to be a system. That's also why that saved view I talked about, we took it and implemented it in other features; we didn't keep it only in the feature, ahh.

Eyal David: [41:45] Suddenly there's a much broader view you can take within that time frame. You know, Yael from Fiverr was here, and she presented, do you know the six Qs they use there? No. So we talked about a brief, but they do something a bit different. It's a document born to improve communication between R&D and product. Okay. And basically you come and answer a few questions around who my audience is, what I'm trying to solve, the hypothesis; there's a set of six questions there: what the solution could be, who we're testing against, which data points. I think that's actually cool and really helps distill the initial stage. I'd love to learn something new. I'll send you a link. Cool. Tell me, you mentioned earlier runtime, and we ran through it quickly; can you explain a bit more about it?

Runtime context and prioritization

Nardit Hikry: [42:28] Yes, so really one of the things, Upwind's starting point, where it began, is actually the runtime world. It's something unique Upwind brings over its competitors: the ability to monitor attacks in real time. It's not just monitoring the attacks, but also bringing lots and lots of additional context that you can't really find in the market, certainly not the security people; the DevOps people maybe are more exposed to it. But it really takes effort to understand who my assets communicate with in the environment, which processes are running. It's something no tool today brings you like, okay, here's all of this. So we bring that as context, additional context on top of the other modules. For example, if we're now scanning code and saying there's a vulnerability there, we can add that this asset is exposed to the internet and communicates with sensitive resources, so you should start handling this resource. Meaning, all the runtime context really helps prioritize what to handle first. On top of that, of course, we have the classic threat detection, the module Upwind started from and keeps strengthening all the time, which tells you in real time if there's an attack and gives the security person a real tool to do prevention and response and react in real time, where elsewhere they'd need DevOps to provide that answer. Well, that was so interesting, and I want to ask you before we part

Eyal David: [44:04] what do you wish for Nardit in 10 years?

Nardit Hikry: [44:08] First of all, that the startup succeeds and I get to enjoy its fruits. I think right now the biggest challenge is also combining family with work. I don't think I'll be able to stop and shift down a gear completely. Again, it's not something I want, but I really wish to keep working and combine it better with, you know, with the kids and those things, but to leave value in everything I do.

Eyal David: [44:46] Wow, that sounds good. Gorgeous, good luck with that. And do you have any, I'm sure you do, do you have any recommendations for someone who wants to learn how to solve a problem?

Advice: ask questions and understand the technology

Nardit Hikry: [44:56] I think simply, you need to learn to ask questions and not be afraid to ask questions; that's my recommendation. Don't take things for granted. You don't need to start nitpicking everything either; come with an open mind, know how to listen, take feedback, but also always, at least with yourself, challenge the feedback.

Eyal David: [45:17] I'm thinking of another thing I notice with you: you went and really learned the business very well, and then you have ground, like you have some base to lean on, so you know, right, many times I also knew, I also know how to challenge, I'll say okay, but that's not right.

Nardit Hikry: [45:32] That's not right, because that's how it works in the cloud, and we don't have a status on this object at all, what are you... But that's exactly the point: you need to understand very well, or understand well enough, the technical side, right, to ask a question like that. Yes, so if you, if I go back to my recommendation, then also, like, doing the grunt work, getting into the guts of things, really helps sharpen the message. So probably before coming to interview with you it's worth really reading a lot of user reviews, worth diving maybe a bit into the architecture or things you release. Yes, no doubt that... even if I come to the office... Not technical knowledge, it's, it's, it's something that for us is key. Because our users are technical users; it's not like a B2C product that anyone can touch, that everyone knows. So here, to create a good experience, to be a good product manager, even to be a good developer... they also came from the Kubernetes world, they also live the assets. And many times I talk with developers, even a backend developer, and they tell me, wow, I don't know anything, let's go over it, help me, walk me through it, tell me how it works so I can do it. And it also creates the drive: when you understand how you're helping them use it, the drive is much bigger.

Eyal David: [46:55] Gorgeous. Okay, where can people reach you if someone wants to get in touch? On LinkedIn. On LinkedIn? Yes. So we'll do it there. Yalla, yalla, so much fun, Nardit. Thank you very much. Me too. Yalla, bye for now, bye 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 didn't find us on some app, I'd be glad if you wrote to us. We'd really love 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 on any app or on the YouTube channel; we have links in the description. So until next time, yalla, be effective, and bye bye.