Dev Interrupted

Scaling Smart: Strategies for Product Development | Semgrep’s Adam Berman

• Season 4 • Episode 30

Share episode

Scaling new product lines within a growing company can be both an opportunity and quite challenging. Semgrep's Head of Engineering Adam Berman joined us this week to share his own experience developing Semgrep's second product line.

Adam was instrumental in developing Semgrep's second product line, and he shares practical strategies for moving from a single-product to a multi-product organization. He unpacks the challenges of organizational design, the importance of fast iteration and feedback loops, and how to build a cohesive company identity with so many moving parts.

If you want to learn how to effectively scale products and how to drive product growth, this episode is a must-listen.

Episode Highlights: 

  • 1:10 The challenges of new product lines 
  • 4:25 Scaling teams for success and strategies for growth
  • 7:30 Finding the right balance between practicality and innovation
  • 12:15 A startup within a startup mentality 
  • 18:40 Learning through experimentation
  • 23:55 Key considerations when navigating product market fit
  • 28:20 Driving growth in engineering teams

Show Notes: 

Support the show:

Offers:

Adam Berman:

product development is so much fun. and I think it makes Like every engineer better to have an opportunity to work on a product team or to think of themselves as building products. I talked to a lot to our infrastructure team too, that like the reason our infrastructure team has been so successful is they also think about building themselves as building products, but for the other engineers at the company that everyone, if you put on your PM hat, if you think about who are my users. How is what I'm building going to bring them value? It's so much fun to build something, get it into someone's hands, see them use it, and then get, keep on iterating, see if you can like really stretch that value, make things easier, make things better. Are you looking to improve your engineering processes and align your efforts with business goals? Linear B has released the essential guide to software engineering intelligence platforms. And this comprehensive guide will walk you through how SEI platforms provide visibility into your engineering operations. Improve productivity and forecast more accurately. Whether you're looking to adopt a new STI platform or just want to enhance your current data practices. This guide covers everything you need from evaluating platform capabilities to implementing solutions that drive continuous improvement. Head to the show notes to get your free copy of the essential guide to software engineering intelligence platform is today. And take the first steps towards smarter data-driven engineering.

Conor Bronsdon:

Everyone, we're back on Dev Interrupted. I'm your co host, Conor Bronsdon, and today I'm joined by Adam Berman. He is the director of product engineering at Semgrep. Adam, welcome to the show.

Adam Berman:

Yeah, great to be here. Thanks for having me.

Conor Bronsdon:

And obviously great to have you on the show because we have a producer named Adam. So, you know, like clearly there's some synergy happening here, but So, I think the real reason we're bringing you on is that over the last 18 months, you've had the opportunity to build the second product line at Semgrep. And this is a unique opportunity that happens at a lot of startups, a lot of new organizations where they're saying, hey, we're going to start this new line. And throughout that process, you had to decide the shape of how the product development organization at Semgrep functions. And so through research, conversations with our managers, lots of trial and error, I'm sure, you helped evolve this organization. And I think it's a really interesting perspective because usually we talk to leaders who are maybe farther along. They're like, oh, I've built, you know, six product lines now. I've done this thing, or I came into an established organization. Or we talk to leaders who are just starting, who are saying, Now we're doing this first product. So you're at this interesting transition point. Let's start there. what's the process you took to build and launch this new product?

Adam Berman:

Yeah. When a company goes from a one product company to a two product company, it's this like huge change in what the organization has to be responsible for. When there's one product, every engineer at the company is like singularly focused on the one product, on the one mission, on the one goal. As soon as you move to a two product organization, you start to see the organization needing to function a little bit differently. You start to think about platforms, you start to think about systems and services that can serve multiple, uh, products, and you also start to think about, like, okay, who is actually serving the products, uh, themselves, how can we make sure that there's, like, singular ownership, uh, make sure that there's, like, really core direction for each of the Uh, and then eventually you start having to start to think about like, okay, how do we make sure these products aren't too siloed as we start to keep focus? You know, you're trying to like do this thing really scrappy at the beginning and then think long term about the, if this takes off, what does this look like when it's successful? How do we make sure that like, you know, we don't end up with some product that's totally different, has totally different primitives. We don't want a totally different sales and marketing organization for a second product because it's so different from the first.

Conor Bronsdon:

So that brings up a few interesting questions. The second product line, is it the same ideal customer profile? Is it a related customer profile? How have you approached that?

Adam Berman:

Yeah. And I talked to a lot of other engineering leaders as we were starting to build the second product, uh, to think through like, Hey, how do you decide what do you decide to split out into, uh, something that is really like cross functional and singularly focused, where do you draw like the platform approach? So the ideal. We're still, we're a security company, we're focused on static analysis, uh, of code. So, we're trying to take static analysis and apply it to a second domain. So, our initial product, uh, looks at the security of your first party code, the code that your developers are writing themselves. This second product, SemGrup Supply Chain, focused on the supply, your supply chain, the packages that you're pulling in. Software supply chain is a huge security concern. Exactly. There's so many, like, deprecated things you can bring in. There's so many, like, look for Log4J. There's still people downloading, like, These are like issues with logj into their systems today. Exactly, and a lot of the tools, especially tools from 5 or 10 years ago, are really focused at visibility, trying to help you see all of the possible vulnerabilities you could be bringing in, but people are bringing in so many vulnerabilities, and then using only just a tiny slice of them, that we try to help people understand, okay, which packages you're bringing in that have vulnerabilities, but then we use static analysis of your first party code to see, okay, in which of these packages are you using The Dangerous Functionality, the Vulnerable Functionality, we call that Reachability Analysis. And, and so, we, we see that we're, the user persona is really similar. It's often the same person, or maybe, uh, the two different people on the same team, the AppSec team, who are using both products. We're, so, it's the same economic buyer. Um, it's often the same kind of persona you want to target with marketing. We don't need to think about different sales, we don't need to think about different marketing. And we often even don't need to think about totally separate workflows for onboarding, for, access control, for things like that. But, that we're, we're talking about like two different parts of the AppSec problem. And so we're thinking about, okay, how do we make sure That we don't just like think about this as an add on to the initial product. How do we make sure we really serve the needs and solve this different problem really completely?

Conor Bronsdon:

So do you treat it as a single AppSec platform or as two distinct products that can be used in tandem?

Adam Berman:

Yeah. And that's, I think that was when we decided, Hey, we're gonna go build a second, product. That was the question was like, do we try to build like two point solutions that people can like deploy separately? Or do you try to think about this as a platform? What we realized is there is this kind of like better together approach. Uh, when you're trying to. Uh, provide a product for the same user or like the same team, uh, that you can, uh, make it a lot easier for someone to do their job if they don't have to be like really context switching when they're using the tool. And then eventually you can start building insights from one tool into the other. Try to make it so that like, okay, you're not just prioritizing two separate streams at work. You're really prioritizing the most valuable thing you could do with your time at any given point. Um, so we tried to like really stay focused on, you know, when you're starting building the product from the beginning, you try to stay focused on it. A single mission, um, making sure you understand the problem really deeply. What is the pain that AppSec people are feeling? They're feeling the pain of a ton of noise. Okay, now we're going to help you focus on the highest priority thing you could focus on. But then as you start to build a product, see success. Now the question is, and we're, you know, 18 months in, it's like, okay, how do we build these things back together? They're deployed in the same platform. Now, how do we make sure that they can be more useful together?

Conor Bronsdon:

So, how did these decisions inform how you then constructed the product organization and belted out to support these two lines?

Adam Berman:

Right, I think that, one of the traps you can fall into is kind of over optimizing for the long term future. At my previous company, Meraki, would often say to ourselves, like, Hey, scale problems are good problems to have. You get the fortune of having scale problems.

Conor Bronsdon:

Yeah, champagne problems.

Adam Berman:

Exactly. If your product doesn't take off You don't get scale problems. If you don't have large users who are going to like really utilize the full breadth of the product, you don't get scale problems. So scale problems exactly are champagne problems. So we want to not over optimize. We want to so we wanted to focus in the beginning on learning, and we'd frequently use the phrase, build to learn. So we talk about, and I'll talk about in my talk later today, that there's, like some trade offs you're going to make. It's like, do you think about optimizing for the cognitive load of technology? Or do you think about optimizing for the cognitive load of, like, business domain? And we decided at the beginning, we don't have to care as much about scale. We don't have to care as much about like building robust systems because if a product never takes off, no one gets to use our robust system. The system doesn't need to be robust. And so at the beginning we thought about, okay, we're going to pull the minimum set of people from like a variety of domains or a variety of technical expertise, give us like the, uh, breadth within the team to solve problems like okay enough. But really deep dive and say to ourselves over and over we're going to build to learn, we're going to build to learn, we're going to build to learn, and knowing eyes wide open to the technical debt we're going to accrue, we're going to accept that trade off, we're not going to say, oh, and these systems are going to scale forever, because we know that they're not, but we know, hey, if this thing takes off, We're going to take a pause, we're going to understand the directions that things are going to take off, because who knows, one of these systems is going to need to scale, another might not. We're going to take a step back and say, okay, to achieve the next 18 months of our roadmap, to get the product to where it needs to be to support the next scale of users. What do we need to rebuild? What do we need to develop back into the platform? How do we like reintegrate? So it's kind of, you're thinking of this as like a little, people say this a lot, a little startup within a startup, but there's this aspect to it. It's not a startup forever within a startup. At some point you kind of try to reintegrate some of the systems back into the main platform.

Conor Bronsdon:

So did you take an approach with user feedback where you talk to your current customers to start with and said, Hey, we think this is an extension. This is what we're kind of hearing from you that can help you. Uh, let's get some of you on it and kind of start getting that, that feedback and seeing how it works. Or how did you get the initial user feedback you needed to make product decisions?

Adam Berman:

Totally. One of the most fun parts about working in product engineering, it's the thing I love so much is this zero to one helping go from this like kernel of an idea to something that is valuable. But the kernel of the idea isn't really like I have some game changing thing that's going to really change the world. It's like I have an idea that a problem was not well solved. And I, in order to be able to solve that problem, you need to really have a depth of understanding of the problem. So the first month or two was just, yeah, talking to whatever customers would talk to us, talking to people who had a lot of breadth and depth in the space, people who we expected never to be customers, people who are like, uh, you know, just other people who are thinking and have been in this space for 20 or 30 years, who would tell us, hey, this is the pain that we see, these are the problems that are unsolved, trying to get an understanding of like, okay, where is a place you can like Um, and from there, uh, we tried to develop like a core group of four or five, uh, early partners. And the benefit here is that Semgrep is open source. Um, we're really able to lean on that open source community. Our customers are really willing to give us feedback. Some of them even contribute back to the open source tool, which is great, really cool. And it means we also have a community slack. With now I think 3, 000 people in it who are like constantly talking and it means that we have access to our customers on like a daily, hourly basis. Um, there's this really fun, a lot of people will talk about like trying to shrink the iteration and feedback loop as, as, as quick as possible, make that iteration loop as quick as possible. With, when you, when you have a Slack thread going with a customer, that feedback loop can be minutes. Uh, we would sometimes come up with an idea, we'd, build something really quick in an hour or two. We'd slack a couple of our partners and say, Hey, what do you think? We'd post a screenshot. Maybe we'd want to screen share. They'd say like, Hey, I'll hop on in 20 minutes. Uh, they'd give us some quick feedback and then in the same day we'd be able to take their feedback, make an iteration, put something else up and get another round of feedback. So we're able to move really fast and that doesn't mean that we were like. Coming up with brilliant ideas every day, what it means is we were failing really quickly. We were understanding, like, the edges. We iteration on it. Exactly. And so what looked like really fast progress on an idea that, like, from the outside you could have just said, like, oh, this idea worked really well the first time. It's like, no, no, no, no, no. Let me tell you, we had 30, 40 ideas that were not useful. But the fast iteration loop and customers and partners are really willing to be honest with us, give us feedback because they knew they'd benefit one day from them getting a product that was really useful to them. that made it so that we could use that fast feedback to really shape the direction of the product, find that early landing point pretty quickly.

Conor Bronsdon:

So for other leaders who are listening to this or maybe about to hit this stage of, Hey, I need to go build a second product or I need to build a team to build a second product. What would be the advice you would give them based on your trial and error?

Adam Berman:

So, I think first of all from an organization perspective, if you're going to go build a second product, you're going to take resources away from the first product. So you want to have an open and honest conversation with the other leaders of your organization, with your boss, with the CEO, whoever, about what kind of pain you're going to put on the rest of the organization. If people aren't engaging there, people are like, it'll be fine. I think you really haven't started the conversation. You want people to sort of agree that things else we're going to slow down. I think one of the other things to be careful of is to make sure that your experimentation doesn't put the existing products like stability, reliability, brand at risk. So you're looking to find ways to really mitigate that. For us, it was making sure that we had developer partners and they were the only ones who were seeing our early versions that were. Uh, totally okay with something very low quality. And it also meant early on making sure that like the stack that we were developing on was totally isolated from the initial one. And that meant at the end of the day, we threw away all of that code and we had to go into the mindset of like, Hey, all of the stuff we wrote early, it. Not only shouldn't it be in the product, it cannot be in the product. There's a point where you transition from build to learn to like build to build and like go make a product exist. And at that point you have to, then you can take a step back and say, great, there are some things we need to make sure are true for stability reasons. And then you can think more deeply about like what system to build, how to build them effectively, how to build them robustly. But if you try to do that from the beginning, your iteration time, you're like, you're gonna, you are gonna throw your initial product in jeopardy in terms of reliability and are gonna go more slowly. So finding ways to. Uh, separate out your, like, development stack early, uh, can really be useful. it also means, as you're trying to find that early feedback, it means, like, really limiting the scope of who you're trialing with. We made the mistake early on of trying to say, like, hey, let's see if we can get 10, 20, 30 people interested. And they were, but there's different degrees of how interested they are.

Conor Bronsdon:

Right, can I get a hold of them the same day to get that quick feedback like you mentioned so we can improve the The product very rapidly, or is it going to be, oh yeah, I'll get back to you later this week or next week, and it'll slow you down, maybe.

Adam Berman:

Exactly, and we can't manage 20 or 30 relationships, even if they all wanted to give us feedback really quickly. Um, and so, true, not all of them did, and we were able to, instead, like, we gauged, okay, there's a lot of excitement in this area. We were able to tell them, like, hey, great, we'll come back to you when we have an alpha version ready. Um, but we were able to narrow the pool to four or five folks who could be really good partners. Who were really willing to be honest with us, who we could, go into something with something kind of scrappy. Um, and that made the relationship really strong. Eventually these folks ended up being like the strongest partners for us when we went to market. There are like most committed users today. And I think they feel a lot of skin in the game. They feel like we built a product for them. And that's helped us like, you know, they sometimes will advocate for us. They'll go talk to some of their friends, their partners, other, other companies that they think, think similarly to them and say like, Hey, this is, this is like they built a product for us. And I think they built a built a product for you and that's helped us get a little bit more traction and a foothold.

Conor Bronsdon:

Are there other insights that you drew from this build to learn phase?

Adam Berman:

When you talk about build to learn, it's something that can be a little trite. People will talk about, like, the MVP.

Conor Bronsdon:

Yeah, um, I've probably overused that phrase.

Adam Berman:

Right, and MVP means, like, a lot of things and kind of nothing. It can be a word that people throw around to just mean, like, let's get something out there. And, you know, we'll come back to it later. It can also kind of be weaponized to say, like, let's cut corners. Um, and like, cutting corners is good at certain stages, but you also want to cut corners sort of tactfully. I think one of the things we benefited from a lot was People on the initial team were pretty experienced as they knew the kinds of corners that you could cut and not pay for too dearly in the future and the kind of like corners that like maybe are just totally worth avoiding whatsoever, let's not even dig into this, we'll find a solution for it later.

Conor Bronsdon:

How big was the team that was engineering the second product when you got started?

Adam Berman:

At the very beginning, it was just me. Uh, and that was like the phase of we were just talking to, I was like, had. Uh, 10 or 15 meetings a day with, with like, uh, external people who could give me feedback and, I was building something with like a Lambda that was totally separated out and like everything looked awful. Uh, I'm so glad that doesn't exist today.

Conor Bronsdon:

No, this is really interesting because it is, you really took the approach of we're going to be a startup within a startup. Like you said, like it was almost like, Hey, I'm founding this new thing that is building off this open source framework. Totally. And it's going to be new and helpful, but it's So it's, I mean, it was you and then I'm assuming you had to bring in some resources from within the company and also probably hire net new devs to help out.

Adam Berman:

Totally. And so we benefited from, there'd been a Hack Week project that had some technology that I was able to leverage. There were some other people who were willing to, I was like, you know, beg, borrow and steal people who like chipped in. And they were like 10 or 20 percent time to help unblock and that's awesome. So I don't, I don't want in any way to say that I'm like, want to take credit for this. This is an idea, also, we look back like, this is an idea the founders had like. They had this conversation at some point five or six years beforehand, they're like hey, this would be really cool to do. Right, but there wasn't traction at the time, so they sunset it, which was like, ok, what if we dig this up again. and, you said like, think about it as an investment in a startup, within a startup. It's something we literally explicitly did. I talked to the founders and they said, Think of us as like your investors. Think of us as your VC. We're going to think about like, okay, your salary is what we're investing in it for a few months to begin with. And one of the possibly good outcomes is that you decide after two months of full time investigation, that this is not worth exploring. And that's, we've limited our investment. And we'll move on to something that could be more valuable.

Conor Bronsdon:

We didn't have to raise that, you know, Series A round for you and really, like, burn some cash through.

Adam Berman:

Exactly. But the other opportunity is like, you decide that there is something here. That there's a market for it, that there's a technology that we have that can make this really useful, and then they can increase their investment and think of it as another capital investment in this product.

Conor Bronsdon:

This is a really cool idea, because I mean, you can really draw these lines, right? Of like, so your investigation phase is your, like, families and friends round, right? And then it's like, okay, our seed round now is when we're going into this build to learn phase. Yeah. And then maybe the build to build phase is your series A round. It's like, hey, we're actually, we're going for this now. So I like this framing because it helps explain it in a way that I think is very common for anyone who's been involved in the startup space.

Adam Berman:

Totally. And it lets us also like kind of view the founders as your board of directors. They're not the people who are saying, Like, literally, here's what to do, but they're the people who are kind of steering you. They have also built startups before, uh, in this case, they have literally built the startup you're a part of. So they really know the context really well. And so they were able to guide, give advice, uh, help me like see around corners they'd already seen before. Um, and then as the scope expanded, so the team would have expanded from like a one person investment to like 50 percent of a security researcher, 50 percent of a program analysis engineer to really dig into some of the tech. Yeah. Yeah. Yeah. We expanded by the time we were three months away from launch. That was like July of 2022. We launched it in October. Uh, we had added two more cloud engineers to the team. Uh, and the security researcher and the program analysis engineer had gone full time. So we had a four plus me person team, a five person team, uh, bringing this to market for the last couple of months.

Conor Bronsdon:

That's that build to build phase.

Adam Berman:

That's that build to build phase, exactly. And by that time, I had to be able to pitch the other engineers and say like, hey, you're tying some of your career to this too. This isn't just a this isn't something where if five of us tried to all coordinate building to learn at the same time, we're probably not going to do that very effectively. This is something that we feel like there is a lot of, uh, conviction that if we build well and we build the right thing, there will be success. And, I mean, like, you know, engineers are gonna only come join a team if they feel personally bought in to the mission. Personally bought in and excited. You never want to be the engineer that's like kind of pushed to the same project. Um, and so getting them bought in was kind of a signal to me too. It was like, okay, if I can get other people on the team really bought in that they could spend a couple months on this and make a big impact, that probably means that we're moving in the right direction and that it's also like the right time to do this. And we thought about this as like, great, this is our series A. It also meant that we started like the board of directors also, got a little bit wider. It wasn't just the founders. It was now like the other kind of executives at the company were bringing in sales or right marketing. We're building in HR and recruiting in the sense of

Conor Bronsdon:

that other VC got to bring another board member. Yeah,

Adam Berman:

exactly. And we're starting to think about this is no longer a short lived experimental team. This is a long lived team. We got to think about the health of the team. There's a long lived product. We got to think about how we're going to market it, how we're going to sell it. Um, and your job as the engineering leader is a little bit like a, you know, Uh, CEO or CTO is to think about like, okay, where does the business and the technology, how do those things intersect? How can you make sure you're optimizing your organization for the next phase of growth?

Conor Bronsdon:

So fast forward a year, we're having this conversation at LeadDev West Coast, you know, it's October 2023, the product's been live for about a year. Yeah. How big's the team working on it now?

Adam Berman:

So it's now two teams. What we've done is we've, uh, built like a five, a six person, like full stack team, uh, that's like senior and understands the domain and has a lot more like of the technical expertise to, to be able to build some of those systems more effectively. We also realized that there was like one key, like deep technical piece that was very different from the rest, that its own workflows needed staffing, uh, because like the work streams were pretty continuous and that was security research. We needed folks who could be full time paying attention to CVEs, diving deep into them, understanding. What makes them dangerous? Writing semgrep rules for them. And that workflow was like, just very different from how the rest of the engineering team, like product engineering team was working. We tried, I think as much as possible, I try to like keep teams together. The more you like artificially segment teams, the more communication overhead there is. Um, and folks want that context because as much as possible, if two people are working on the same kind of problem, they're on the same team, they Know how to work together that a problem that project is gonna be more successful, right? But we kind of got to the point where it felt like we were Artificially keeping these teams together and there was pain in the other direction of like everybody trying to keep context on this other stuff you'd find that like people were kind of tuning out when one set of the group was talking about their work not because They didn't care because there was just too much to pay attention to and so it became like this kind of natural mitosis of like, okay, we should, uh, break these two teams apart and break this team apart into two teams, uh, a team that was still full stack and focused on product development, uh, and a team that's focused on the security research, the incoming feed of vulnerabilities, and then also their tooling. And so that meant it's okay. It's not just like a task oriented team. It's also a team. That is doing engineering and building the tooling that supports them, but still very different tooling and very different set of engineering problems than what the engineering team is working on. Those two teams, they still work together. There's another trade off here, right? You're trading the ability to have like deeper technical expertise and singularly focus in the two different areas for overhead and communication and like coordination when those two teams need to work together. It just so happens that. That doesn't happen quite that frequently. It happens when we try to go to market with a new language. It happens when we're trying to make sure, like, the two teams give each other feedback a lot. The researchers are, have also been our users before, so they can give feedback on the product. But it, so we, we want to make sure there's still that line of communication open. We do a lot of social events to make sure the two teams feel connected. We still do a lot of planning together, but the two teams should feel comfortable operating independently and autonomously, knowing that they can really, like, work in their areas and stay focused.

Conor Bronsdon:

So, would you think about this kind of, I'll say, first year of go to market with the product as a new phase where, like, we have a compressed build to build phase? That's seed round, you're getting things out and now it's, you know, a scale phase or, or where does that transition change for you as you talk about, like, the needs of the team changing?

Adam Berman:

Totally. Okay, so I think the, there's that early phase, the, the build to learn. Build to learn, yeah. Then there's the next phase which is like build to build and it's kind of a, I mean, it's kind of like a, a gray area phase of like, okay, we're not investing too heavily because we could go to market and find that, we still kind of miss the mark. I found in my career that feedback given freely is very different than feedback when people have to put their money where their mouth is. Um, and so there just comes a moment when the quality of feedback gets much higher because someone could say, yeah, this is useful, this is useful, this is useful, but it's not useful enough.

Conor Bronsdon:

And the stakes of the feedback get higher too.

Adam Berman:

Exactly. and so we would start to frame things as like, okay, it's not just like, oh, what does it need to be useful? How much more useful does this need to get before it's useful enough for you to buy? And then there's a lot of questions like, at what cost? It's like, great, if it's a dollar, would you buy it? It was like, well, yeah, probably it's like, okay, but like, what about at the price in which it's at list price? It's like, okay, now we're getting a sense of here is the edit distance from where we are, from where we want to be. And that meant that we kind of enter this second phase of. Like, we're building to, we're building to build, we're like learning again very quickly.

Conor Bronsdon:

So the iteration phase again, but like a separate one.

Adam Berman:

Right, and one in which we're like keeping a lot of buffer, because we realize that, like, we're gonna get feedback really quickly, and we, now that we are public, we can't build quite as scrappily anymore. When we make a commitment to a customer and say, Hey, we're going to be able to build this thing to be able to enable this workflow, which we believe is really important. The workflow needs to work. People start to have expectations. There's a contractual obligation. Even from like a, from like a values perspective, like. People are now investing their time. They're expecting you to like help make their lives easier. And if it's ends up just kind of being fluff and they spend all their time, just like waiting for your product to fix because it's constantly broken, like that doesn't give them any value. Like the reliability must be there. The performance must be there to make it usable. And so the next phase is like. Still trying to keep iteration high, but trying to focus on a narrower set of things that really provide value to the customer and making those things more important. We went to market with like a, kind of like a broader set of ideas, uh, than we thought we would, uh, like really double down on. And that, that ended up being true. We like. Ended up sunsetting some features that weren't as useful and instead doubling down on the things that were useful. And then we ended up realizing, great, now there's these other domains we want to explore because we realized like, Hey, we can really unlock something if we can do this and the other thing. We realized like, Hey, we can get into license compliance. Like a key stakeholder in supply chain security is the legal team saying you can't use a dependency that has a really restrictive license. Um, so we said like, you know, a lot of companies were like, we want reachability analysis. We want this product. But if it can't do this other thing, we can't have the product we want. So being able to offer an investment there allowed people to unlock and be able to use the tool they really cared about.

Conor Bronsdon:

So is the next phase or the current phase now this, platform realignment where you bring the two products together.

Adam Berman:

Exactly. And it's funny, we're doing this as sort of acrobatics, we're doing this well also launching a third product. So we released , we released the Beta of secrets, subgroup Secrets a few weeks ago, which is, uh, secrets, uh, scanning product that also does secrets validation. So it all scan secrets and find, uh, like go query, the API the secret is supposed to belong to, to see like, hey, is the secret still live again? Trying to cut down on the noise. Help you prioritize the secrets that are. So we're trying to do this kind of acrobatic thing where, uh, we're going to market with a new product, we really want to encourage them in their build to learn phase, and now sort of the build to build phase, but not over investing and trying to figure out, okay, what are the parts of the product that will survive, first contact, what are the parts of the product you don't even know are useful until you get that, uh, that feedback, what are the parts we're going to sunset, and we're also taking the supply chain product and saying, okay, what I think for an example, we, we built like a totally separate findings workflow for supply chain from the semgrep code. We thought to ourselves, um, like first of all, we don't want to cause any outages on the existing findings pages where most of our, like, AppSec people spend their time going through the list of findings. But we also thought like a supply chain finding is just a very different beast than a code finding. We're now realizing they are, but there are ways in which we can support this in a single workflow where customers will get a lot of value not having to like, Change between pages where we can do prioritization across multiple product lines by just having those workflows tied together. Um, and so we're trying to figure out a way to like, how can we support the, this like new iteration while also making the product just more usable. People get more value out of it and then figuring out ways to like also narrow the scope of the team so that there can be a platform team that can like build out, uh, like provide these APIs, uh, so that the, each of the product teams can focus on like what is their core differentiator.

Conor Bronsdon:

Adam, I love how passionate you are about this. I can hear your affinity for organizational design and psychology kind of coming through here. And, uh, I love that you're thinking about this in a phased approach because it's very clear you really care about this. What has the process of this last 18 months, two years almost, taught you about the org design that you need to do to successfully take this approach?

Adam Berman:

Yeah, you said I'm really passionate about this. I think I really am. It stems back from my undergrad degrees in philosophy. I love taking But, you know, it's just really great to be able to dive into the theory, taking like a principled approach to some of these problems. But I also have had a lot of practical experience here and failed as we said in the beginning, failed a lot.

Conor Bronsdon:

Failure is an amazing learning experience.

Adam Berman:

Exactly. And like failing quickly, I feel like again, whether it's in product development or in leadership, failing quickly ends up being really important. As we're thinking about evolving to this next phase, I think when you're in this early stage of a startup, you're able to trust your gut so much. and I think one of the pieces of development for me is like, I could trust my gut because I would deep dive into every piece of context. I feel like I really knew what was going on and could then like, allow like the synthesis to happen in my own brain and then help other people understand that synthesis. this next phase, which is interesting, is like, hey, we're gonna try to tackle a lot, a lot more big, hard problems. and I think the evolution for us in this organization is helping other people learn how to trust their guts to. It's like, it's not my, it's not my job, it can't be my job as the product director to help, to like, be in every single piece of context to make these decisions. instead I feel like my job, and this is something I get really excited about, is helping other people build these frameworks, helping other people fail fast so that they can build up their, uh, context, they can build up their gut, they can, uh, really try to find the right balance as they move through these different cycles too.

Conor Bronsdon:

How do you help other people fail fast, to your point?

Adam Berman:

Yeah, I think part of this is, I feel like I got really lucky and I had leaders who like Pushed me to move faster, uh, than, than I felt comfortable with. And then realize that like, hey, this is good. Moving fast is good.

Conor Bronsdon:

Speed in is quality.

Adam Berman:

Exactly. and so one of the key frameworks I get, like I just find myself like repeating myself over and over and over, uh, because like it's not, there is no like key technique. There is no like silver bullet that solves this problem. It's just about like taking a step back. And like questioning your assumptions. So I think about this like grid constantly, which is like the, on one axis is how likely you are to be wrong. And on the other axis is how bad it would be if you were wrong and where the dots are is like, like the scale of risk that each assumption brings. And so people will often say like, well, you know, you want to figure out an experiment to validate your riskiest assumption, but like quantifying what, how riskiest is kind of hard. So I think I often help people. Okay. Tell me your assumptions. How likely do you think you're wrong about these? How bad would it be if you're wrong about this? How can you build something in a week, a day, an hour? How can you not build something to go decrease the risk that you'd be wrong or decrease how bad it would be that you're wrong or prove that you are and be able to like pivot as quickly as you possibly can? these kinds of frameworks help people like kind of They help people like, uh, question their own assumptions, then they can like, okay, you know, my first, a lot of people's first instinct is great, I'm gonna go spend a week building something. It's like, okay, how can we decrease the risk? Cause if you're wrong and you just spent a week building something, that's a lot of time. What can we do in an hour to give you a little more confidence that you're right to make investing in that week a little bit more worthwhile?

Conor Bronsdon:

So that fast feedback and iteration cycle is obviously something that's like an important concept in Agile development, software engineering in general, and it's very clear that it's an important concept in product design and product iteration. What are the other key insights that you would draw from this experience or your past experiences that you would say, Hey, engineering leader listening, product leader listening, this is how you should think about this.

Adam Berman:

Yeah, I think the other thing I talk about this, this talk to is, everything is a trade off. There is this feeling that I have, sometimes people have sometimes that like, okay, we're gonna be able to do the right thing and it's gonna satisfy us today. It's gonna satisfy us tomorrow. It's gonna satisfy us a year from now. I think the important thing is to be eyes wide open to the idea that you are making trade-offs in real time. Mm. And to be intentional about the trade-offs that you make. Um, in the early phase, we've talked, I talked about this earlier, like, you know, if you don't get a product that can get to market, if you don't get a product that gets traction, you don't get to have scale, but. If you, uh, don't make those, but if you make those decisions to get you to market quickly, you are going to run into those scale problems later. So don't bury your head in the sand and say like, we're going to build a product. It's going to be, get us to mark quickly and then it's going to be perfect.

Conor Bronsdon:

That's how we never put your MVP out.

Adam Berman:

Right. It was like, uh, you know, if you just decide we're going to build this and then we're going to walk away from it and expect everything to be fine, that's not going to work. So one of the things I talk about with people is I don't mean exit strategy as in like how to walk away. I mean like think about your exit strategy as in how to. Exit from your current set of assumptions, how to make that transition to the next set of things. And sometimes it means like, Hey, you are not the right leader to take this, the next phase because you love going zero to one and this now needs to go one to a thousand or a thousand to a million. Yeah. It's like, okay, how do you then, you know, elevate someone else or bring in someone else who can help with that next phase and then you can go do what you love to do. But I also think about like, okay, how do you prepare yourself for that transition? How do you help the team shift its mindset to go from, Hey, we're no longer just building to learn. We accumulated tech debt. We are now like excited. We get to solve these different set of problems. People are using the product. People are loving the product. Let's like help people use and continue to love the product.

Conor Bronsdon:

Yeah, you brought up this idea of looking around corners earlier, and I think it's a really important leadership trait, particularly when you're starting something new, and the help that you clearly got from your leadership around, hey, here are things that we've seen, uh, I can, I can tell you've spent time thinking about that. Are there pitfalls that you would say, hey, be aware of this, or we had to avoid this, that you would maybe highlight as well?

Adam Berman:

Yeah, I think that's an interesting one. I think the The pitfalls that we've run into I think have been really about being too singularly focused. I think like and there are times where we didn't adjust as well back to the platform. I think if we could have made some key investments and like started to set ourselves up for that transition back, Earlier that would've been useful. But I also think like, hey, it's easy to say that in retrospect. Yeah. Um, it's really hard to know, you know, it's like when you know, if you're gonna try to time stocks, like how do you know what's gonna happen? It's really hard to know whether you're at the peak of the time where it's like the best time possible to start transitioning to a platform versus not. I think the, the other thing to think about is like, when you go from a one product company to a two product company. There's a real question of like identity of the company at stake. For a really long time the company has really thought of itself as this one key core product. This was true at Semgrep where like the product was Semgrep for a really long time and people identified as Semgrep. When we, uh, transitioned the team, when we transitioned the company to a two product company, I think a lot of folks felt like, okay, 90 percent of the company is focusing on Semgrep code. And then there's also this team that's focusing on supply chain and we really had to work hard to shift the identity of the company to say, Hey, we are a platform company. We have multiple products. We should all identify with all of these products. We should feel an affinity towards everything. And, and it seems like semantic, but it matters so much in like every little decision that is made, whether it's like how we choose to market the brand or the company, what we do in our, like, you know, in our, in our go to market, how our sales team pitches the different products, what they lead with. Um, you know, being willing to lead with either product. Um, and then also, like, in the technical decision making, when your platform team is thinking about what are they gonna support, uh, what are the, like, use cases that they wanna make sure that, like, the golden path that's, like, you know, gonna be reliable, gonna be stable, like, are they getting inputs from Both products, and it makes sense at the beginning, like, okay, if the new product is much smaller in terms of revenue, obviously you want to focus on, uh, the product that's bringing in all the revenue. We quickly got to a point where we were kind of like co equal products in terms of go to market and revenue. And so it took us a little bit of time to, like, make that transition happen. I think we're still making that transition happen. Where the, the teams really take both products into account. I think now that we're moving actually into a third product as well, I think this is getting a little bit easier. Where people really recognize, Hey, SemGrup is a place where we build products. Like with an S, the plural. and now we really think about, Hey, if we're gonna build Underlying infrastructure. If we're gonna build a marketing pitch, if we're gonna, uh, figure out like how our sales team talks about our products, we're gonna talk about the platform, we're gonna talk about all the products. is a tool that is multifaceted and can do many, many things.

Conor Bronsdon:

What was the approach you took to build that identity with a platform across the entire organization?

Adam Berman:

I think like, partly I did a little bit of a disservice to the, to like myself here, which is when we were building the product, we were pretty insular. There's that like, uh, meme basically like, hey, PMs, just, uh, and engineers will just like lock themselves in a room and be singularly focused and that's basically what we did. We like, even in our office, we had like a little meeting room and we just like took over the meeting room and for a couple of months just like built as fast as we could, made communication really fast. We did try to make sure the whole company felt the launch. I think that was like the first, uh, stage of that is like helping to make sure while we were building a little bit isolated that the whole company felt our successes. And when we, when customers would tell us, hey, this is, this is really cool, we try to make sure it's like, it's not supply chain, the team that's feeling like, hey, this thing's been really cool. The company built something really cool. When we launched, we made sure the whole company was involved. Uh, we made, when we made swag for the product, we made sure it's, it's not just for the team that made the product, it's for the whole company to make sure that it becomes a core part of the identity. I think we're still in that process now. We're still uncovering times where like, Hey, the marketing message still feels really tailored towards static analysis of first party code. How do we make sure that we're talking about ourselves as a platform? We're talking about ourselves as a multi product company and maybe like diversifying the messaging that sometimes we're talking about. FirstPartyCode, sometimes we're talking about supply chains, sometimes we're talking about secrets, um, but I think more and more we're starting to see that identity shift, um, and that's I think partly like we want to make sure that people feel like the wins that the com that the new products bring are shared wins that everybody can like celebrate.

Conor Bronsdon:

I love that insight of shared wins because, uh, having everyone buy in, it really does require everyone feeling like that success is shared, so I think that's a, a lovely insight to kind of close us out on. Do you have any closing thoughts that you'd want to share with our audience around this process and what you learned from it?

Adam Berman:

I think like product development, you can tell from my passion you said earlier, product development is so much fun. Um, and I think it makes Like every engineer better to have an opportunity to work on a product team or to think of themselves as building products. I talked to a lot to our infrastructure team too, that like the reason our infrastructure team has been so successful is they also think about building themselves as building products, but for the other engineers at the company that everyone, if you put on your PM hat, if you think about who are my users. How is what I'm building going to bring them value? It's so much fun to build something, get it into someone's hands, see them use it, and then get, keep on iterating, see if you can like really stretch that value, make things easier, make things better. I love it.

Conor Bronsdon:

Thank you so much for bringing your passion onto Dev Interrupted, Adam. I, I will say if you're watching this on YouTube, you can really see how animated Adam is and how excited he is and, uh, it's a ton of fun to be able to have this conversation in person with you. For folks who want to follow your work and your approach, uh, how can they do that?

Adam Berman:

Um, I'm on LinkedIn, Adam Berman, I work at Semgrep. Um, if you want to see our product at all, we're semgrep. com. Um, come, uh, come check us out. Uh, we're open source, uh, you can use our open source tool, contribute, join our community, Slack. We love external contributors, we love people who write rules, uh, about how to make the different frameworks we use more successful. We have a registry of rules. Uh, so come contribute, come hang out,

Conor Bronsdon:

Amazing. Adam, thank you so much for joining us on Dev Interrupted. And big shout out to LeadDev for having us here and uh, letting us have this great conversation right on the floor of the convention.

Adam Berman:

Yeah, this is a great conference, come join LeadDev next year, uh, this is a really awesome opportunity to meet a bunch of different uh, engineering leaders, hear a bunch of different perspectives, I've loved the talk so far, there's like, all these different lenses where like we, we're tracked by like our own networks of people that we know and the lenses that they bring, there's this awesome opportunity to expand your network.

Conor Bronsdon:

Get the exposure. Yeah. Awesome. Uh, thanks again Adam.

Adam Berman:

Yeah, thanks so much.

People on this episode

Head Shot

Dan Lines

Host
Head Shot

Conor Bronsdon

Co-host