[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron. And today, we’re talking product management with Shruti Anand, Product Manager at Lacework.

[00:00:18] SA: So before coordination of breaking the requirement, negotiating the timelines and executing on it becomes a lot more simpler because of having this technical background.

[00:00:28] SY: Shruti talks about getting a bachelor’s in computer science and master’s in architecture and software engineering, then pivoting to product management and how her technical background has given her an edge in her product management career after this.

[MUSIC BREAK]

[00:00:53] SY: Thanks so much for being here.

[00:00:55] SA: Thank you so much.

[00:00:56] SY: So tell us about your technical background.

[00:00:58] SA: Sure. So I actually entered computer science when I was doing my bachelor’s. That was the course that I picked up. I mean, I came to the world of computers at an age of 10 and 12. That’s when I got my first computer, but that was mostly playing games, how we are at that age. But the first coding challenge that I took was, well, in the college, first year, that’s when I decided that I wanted to do something in the world of computer science. And that’s where my technical journey started. And then I did a couple of years of Java as a software engineer, came to do my master’s, and then finally landed a job as a product manager at Hitachi. That’s where my true journey started as a product manager.

[00:01:41] SY: And when did you first start dabbling with code? What kinds of things did you do?

[00:01:45] SA: I guess it was my first year at college where I was expected to write a code using linked list. That was my first interaction. I was not sure if I would be able to finish that assignment, but towards the end, there was light at the end of the tunnel. I figured it out. I understood why some of these concepts actually made sense. And especially to the whole tenure as I went through it, like every technical discussion that I had, whether it was around cloud computing, machine learning, data analytics, I knew how it’s actually being used in a real role and that gave me a sense of this technical journey that I took.

[00:02:22] SY: So what did you like about coding? What spoke to you about it?

[00:02:25] SA: It was just solving challenges. Right? I would pick up Math’s problem in school and you did it for, like, let’s say you could add two numbers and that’s about it. You could use calculator to, let’s say, add 10 numbers, you still had to fill it in, but coding just made it so simple. You can just have a loop iterate over like I don’t know how many numbers and then solve the problem within seconds. So that was something that just spoke to me that, “Hey, you’re addressing these challenges,” simple world challenges, but at a scale of nine billion population. You look at Facebook. You look at Twitter. The amount of data that they’re churning is just so huge while they’re solving day-to-day challenges of keeping people connected and entertained. So I think that’s what made it very interesting for me.

[00:03:14] SY: So you got your bachelor’s in computer science and then a master’s in architecture and software engineering. Did you have a specific career in mind when you were doing your studies?

[00:03:23] SA: Well, when I started bachelor’s, I was more like I needed to be in computer science domain. That was the new concept, at least in developing nations, like India, where people were tending to move away from mechanical and chemical engineering and actually land a job in coding. But once I had done my bachelor’s, I moved to a company called Deloitte. And once I started working as a software developer and interacting with product managers, I figured out that’s the place where I wanted to be. And that’s what led me to do my master’s and basically search for a job which opened the world of product management domain.

[00:04:02] SY: So we talked quite a bit about different people’s experiences, getting their bachelor’s in computer science. But tell us more about what getting your master’s in architecture and software engineering looks like.

[00:04:14] SA: Sure. So it was very different, I think because of a couple of reasons, like how the whole learning system changes when you are in a developing nation versus a developed nation. So when I was in India, it was very theoretical. There were only so many real life applications that you were aware of or till the time you actually landed a job. But when I came here for my master’s, the whole perspective changed. The diversity of the class that I was sitting in was so huge that I got to learn a lot of things from different people. So A, that was there. And B, the whole coursework was framed on solving real life problems. It was not just a coding assignment that I was doing. I was actually working on a side-by-side plan project too. So what it actually means in a real world when you actually join a company after attaining a degree, I could see it through my master’s degree itself. So gathering requirements from customers, working with customers to set the customer expectation, if there was a bug info. Right? If things didn’t work as expected, all of that was actually covered through my course. We had coursework which actually made us understand what are different software development life cycles, like when do you actually pick up Agile, and even within Agile, when do you go this Scrum model versus Kanban model, or in terms of architecture, how do you make scalable system, what does new distributed architecture trends look like, and then in terms of requirement gathering, like working with UX researchers to figure out how can you map customer’s journey, and based on personas, how can you actually create user experiences that worked for your targeted audience. So my whole master’s had bits and pieces of everything that I do right now.

[00:06:01] SY: So when you graduated, what was your career trajectory like?

[00:06:05] SA: So I started as an associate product manager at a storage company that time, that was my first window into product management. And thank God, I landed the job because I am so glad that I am in the world of product management. After that, I joined another startup within two years, doing the senior product manager there, joined Splunk immediately and worked there for three years and my whole area always was platform and monitoring. So the challenges that I was solving was you build a platform, whether it’s Lacework, whether it’s Splunk. How do you make sure that customer knows everything about platforms? So it’s like building tools that make you analyze if your car is running properly or you need gas or if there is an engine oil problem. So similarly for platform, you need to have the right observability metrics to make sure that are you going to run out of license, are there injection issues, are there integration issues that we need to resolve, or as a customer, you can take care of. So that has been my whole career till now and this is something that I’m actually working at Lacework as well.

[00:07:11] SY: Tell me a little bit more about Lacework. You’re a product manager there now. What is Lacework and what do guys do?

[00:07:18] SA: Lacework is a cybersecurity new age company. So if you look at cybersecurity market, it’s a huge market right now. There are more than 100 to 200 plus in that part, beside the cybersecurity market is also growing at a very rapid rate. I think the time is going to go anywhere in like 300 to 400 billion in the coming years. So it is a very huge market. Now what we do is we are a very new age company and our goal as a software is to make sure that customers who are migrating to cloud have the right platform to make sure that they are secure and that they are not vulnerable to any attacks. So as a platform, you can think of as ML needs cloud security. We have technologies like Polygraph, which basically help customers analyze their entire cloud environment and basically figure out if they are open to any security breach or if there are any potential vulnerabilities that would happen. Pretty much when you look at that graph, you can see if there was a new user who was trying to access your system or there was a new service that was calling your system and it’s built on an hourly basis. So we are continuously learning from your behavior to make sure that, hey, if this is something you don’t care about, we wouldn’t alert you on it again. So one of the other issues that you see with security is getting too much noise, right? So you want to cut the noise and you want to focus on what’s actually relevant for you. And Lacework, through its machine learning and other capabilities, make sure that we keep you focused on what is relevant for you.

[00:08:52] SY: So now I want to dig into product management a little bit deeper. Tell us what exactly is it and what does it entail?

[00:09:01] SA: Sure. So that’s one of the toughest questions about product management is that there is no perfect job description about product management. Some call it a CEO of a product, some call it as someone who needs to do every like a single light work. But typically I would define product manager as someone who makes sure that engineering knows what to deliver and why are they supposed to be delivering it. And then from customer perspective, customer knows that what is being delivered. So they are pretty much a liaison between the technical teams and the customers. So my role starts, as soon as I have an idea, I know that this is a trend going on, I reach out to customers. I started understanding the customer base. I worked with the user experience team to come up with mock-ups, write down a requirement document. And once I have all of this, I start evangelizing it with the engineering team. Once the entering team understands what they need to build and I’m involved in all the architectural decisions. So for example, they’ll have question, “Hey, how many customers do you think you need to build for? How many alerts do you think our platform needs to support first?” All of these negotiations have to happen between a product manager and an engineer. But the knowledge that I’m guiding is through continuous research about other products, trying to understand the recent trends of technology, and also talking to customers. And once the solution is built, the role of product manager is to also work with the product marketing manager. So basically making sure that our customer knows what are all the beneficial features that are available in market to our product. So I work on creating blogs. I work on creating videos to make sure that our customer knows that, “Hey, we have all this cool stuff available for you.” I also work on enabling our internal teams, like customer success, sales team, so that when they are actually pitching it either to an existing customer or to a prospect, they know how they can leverage some of these features to either renew a contract or upsell a contract and whatnot. So pretty much like a centerpiece who works with each team in the organization to make sure that things get done end to end.

[00:11:17] SY: How much does this role change or vary from company to company? Is it mostly the same thing that product managers do? Or is there a lot of differentiation depending on where you go?

[00:11:27] SA: I would say it varies from company to company to a certain extent. It also depends on, I guess, how big or small the organization is. So in my previous organizations, there were a couple of instances where I was just asked to write the requirement, document, collect the requirements and hand it over to engineering, and then only get involved when the feature gets shipped. But I feel that you miss actually the learning pieces of it, because if you don’t ever have that negotiation or architecture discussions with the engineering, you’re missing the decisions that they are going to take, which in fact is going to impact the product that you build and hand it over to your customer. So to answer your question in short, it differs, but I like the process that we have discovered here as part of Lacework.

[MUSIC BREAK]

[00:12:32] SY: So what is your role look like at Lacework? What would a day in the life, a week in the life of Shruti look like?

[00:12:40] SA: I wouldn’t go to a day granularity level because every day is like new to me. But like on a weekly basis, I can say most of my time, at least 30 to 40 percent time goes in conducting customer interviews because either I’m in the inception phase of an idea where I’m trying to understand if the directional thinking that I have is correct or not. Right? So I’ll be doing these research interviews with customers, getting their feedback on the requirement. Like 10 to 20 percent of the time after this would be spent working with UX designers, trying to convert whatever feedback I have gotten into an experience that we can use to validate with customer at a later point or into an experience that actually guides the engineering to think. Right? When you show things visually, it’s much more clear. So that’s like 50 to 60 percent time is gone there. Then 10 to 20 percent time actually working with engineering, answering their questions, if any about features that are in progress or things that are about to come. And then the rest of it goes around forward thinking. So a part of a product manager’s life is to think about what is beyond horizon, right? Like what as a product we need to do beyond a year timeframe so that we always stay at top of the notch. We are always a foot ahead of what our competitors could do or anyone in our cybersecurity domain could do. So roughly 30 percent time is spent doing strategy planning, whether it’s via executed review, whether it’s just an internal conception where I’m just looking at computation, just trying to understand things from Gartner’s research studies. So like different kinds of pointers taken into account from the strategy planning perspective.

[00:14:22] SY: So it’s interesting because you spent your school studying computer science and architecture, but then your career, at least most of your career was in product management. What created that shift? What caused that shift away from computer programming and into product management?

[00:14:38] SA: I think it’s more than a shift. The computer science knowledge created a baseline for me because now when engineers bring about the problem, like when I give them a requirement and they say that, “Hey, Shruti, this is not how you should be approaching this problem,” or, “We need to think about these more knobs before we actually say that the solution is done.” I have that technical mindset to empathize with them and understand them as well. So I moved into product management because while I was working as a software developer, I always wanted to understand the impact of things that I was doing. When I check in a code, I want to understand from customer point of view what problem in your life is it solving. So I wanted to understand that. Obviously, not all the product managers would explain it to you. So when I was doing this customer project, as part of my master’s, actually when I was dealing with the customer, I felt much more knowledgeable and in control of things, rather than just being handed to write a coding project. So I felt that I was more meant to be outbound as well as inbound focused. And this was the career path which offered me best of both worlds. And that’s why I landed into product manager.

[00:15:54] SY: And what was that transition like going from software to product management? What was that like for you?

[00:15:58] SA: It was tough because when you are a software engineer, so at least till 2014 or ’15 when I landed my first job as a product manager, not a lot of companies had this associate product manager level. So anytime you wanted to interview as product management, there was an expectation that you have at least five to ten years of product management experience before that. So it became like a chicken and egg problem, right? Like how do I have an experience without being a product manager? So most of the PMs that you see in industry had transitioned either from a software engineer role or a sales or marketing role. That was the only option. But I was headstrong that the first job that I wanted to get was a product manager. So fortunately, when I started applying to couple of companies, I got to one of them. And when I landed there, obviously, there were a lot of issues, a lot of breakthroughs that I had to go through, but my manager was very supportive. And he literally made me understand the technical challenges. I landed into a software company and software domain was very new for me, but the concepts that they were trying to solve were very normal. So if you start to go and research, you start to understand AWS as any cloud vendor out there or like literally any infrastructure, the challenges are very common. It’s just the approach that you take will make you or break you as a company. So that brainstorming exercise, that guidance that came in from my first manager helped me smooth out the transition from a software engineer background to a product management background.

[00:17:33] SY: And I know you mentioned a little bit earlier that having that coding background really helped you empathize with your engineers and really work with them better. Can you talk a little bit more about that? What are some other ways that having that coding background helped you as a product manager?

[00:17:48] SA: So I think at least the products that I have been a product manager for are very technical in nature. So most of the times, if I’m talking to a customer, they are very technically sound. They are the people responsible, for example, here at Lacework to roll out Lacework as a platform in their company. And probably they are taking care of other products as well. Like for example, they might have AWS in their account. They might have Google Cloud in their account. So they’re technically sound people. So when you’re talking to them, for example, if I’m trying to create a use case around better access control mechanism, once they start giving me the requirements, I understand where they are going, like what are the challenges that they are trying to solve for, and how technically feasible it is. So it’s a coordination, mental coordination that I can establish with them based on the coding or the technical background that I could gather to bachelor of computer science. So it gives me a sense of whether the things that they’re asking for is small, medium, or large in size. And then when I take it to engineering, I know how granular do I need to break it down in my requirement documentation, so that it’s easily consumable for them. And when I negotiate with engineering, in terms of roadmap, planning and timeline, they come back to me and say that, “Hey, Shruti, we need more details around it.” Or for example, our platform needs to scale enough to support all of these. I could empathize with them. I can negotiate with them in terms of timeline. So before coordination of breaking the requirement, negotiating the timelines and executing on it becomes a lot more simpler because of having this technical background.

[00:19:25] SY: Do you feel like it gives you an edge compared to other product managers, those who don’t have that same background you do?

[00:19:32] SA: I mean, I have seen product managers who do not have technical background and come from, let’s say they have done MBAs that they have an edge because they know finance or maybe they know pricing. I do feel like having a technical background at least gives me an edge from the product perspective that I’m working on, especially from the platform core infrastructure layer perspective. But there are product managers who just do licensing, who do billing. If they don’t have a technical degree, they survive quite well as well.

[00:20:03] SY: So now that you have been doing this for a number of years, do you recommend or do you feel that product managers at software companies, especially those leading software projects that are working directly with engineers, do you feel that they should have some coding background?

[00:20:20] SA: I think I will say maybe because I’ve seen some excellent product managers who do not have a coding background. So the first layer that you should possess as a product manager is empathy. And the second layer that you should possess is the ability to learn. So even though you do not have a coding background, you can learn about technology. You have that rigor to continuously research about product because technology is ever evolving, right? So if you have that rigor, you can survive this.

[00:20:50] SY: What would you say makes a good product manager and what makes maybe a bad product manager?

[00:20:56] SA: I think the key aspect at least that has made me grow in my career as a product manager is to be people driven. And that means possessing this empathy layer. When you’re talking to people, you have the right respect, but you also understand the problem from their point of view, right? You can step in their shoes, whether you’re talking to a customer or whether you’re talking to engineering. If you can really empathize, you can grow into product manager. What, as a product manager, I think one should avoid doing is the ideology of like perfection, of creating perfection Day 1. So you need to be perfect in 10 or Day 11, but the idea is to get started somewhere. So start early and fail fast is the module that you should always have. And as a product manager, we always discuss it within organizations, we tend to have a lot of PTSD. So things will fail for sure and go down the route, which you do not expect. The idea is always to retrospect and get out of it and revamp and redeliver again.

[00:22:10] SY: Coming up next, Shruti talks about some of the most important things she’s learned from her product management career that might help others in their own product management work after this.

[MUSIC BREAK]

[00:22:33] SY: I feel like there are so many more product manager positions now than there used to be. It feels like this area is growing. Why do you think there’ve been a rise in the need for this position?

[00:22:45] SA: I completely agree with you. In fact, when I came for my master’s this year, there was not a single product management role that was offered as part of any college. And now, in fact, my alma mater, CMU, has a dedicated product management course, and I get requests like LinkedIn requests or at least like on a day-to-day basis from five to six product managers. So there’s been like recent transitions of people. I think it’s driven by two factors. One that people like who were internally growing into product management now know that you don’t need to actually take a step to become an engineer in order to get a job as a product manager. You can go directly into that chain using the APM route. And the second thing is the different growth factors, like earlier software engineering was one of the growth routes that you knew that you had to take in order to possibly become a CTO and then a CEO. Now there are other growth routes that you can take as value. You can become a chief marketing officer. You can become a chief product officer. So this industry trend where people are introducing more leadership levels, I would say, which has led the increase in product management positions as well. So when I was working in my previous company, we introduced the notion of chief product officer. Now maybe soon down the route, Lacework would also have that. So it’s a growing trend and that’s why you see increase in product management.

[00:24:11] SY: Tell me a bit more about how your team is organized. I know that usually in a team there are maybe some junior software developers, there are some mid-level people, some senior people, but I also know that there’s a lead engineer. That’s usually a role. There’s the PM, which is you. How is your team structured? What are the different roles that are needed to make a product work?

[00:24:35] SA: So PM organization at least within Lacework is different from the engineering organization. And the way a PM works with I guess engineering team differs from the role that they have as well. So for example, if you take in Lacework, if you’re a compliance PM, you might be working with a set of engineers that are dedicated and you’ll be going back to them again and again. But being a platform PM, I have to work with different PMs as well. So I might be working with an agent PM. I might be working with the compliance PM. I might be working with the vulnerability PM. And on the inbound side, I’ll also work with engineering teams, like not just one engineer engineering team, but multiple engineering team as well. So for example, I might be working with an ingestion engineer, at the same time I might be working with someone who is creating polygraphs, so machine learning engineers. So it really depends what feature I’m working on. And even for a feature, it might have dependency on an ingestion pipeline, on a UI team, on a modeling team, all of it altogether. And in terms of leveling, I don’t think it matters, but usually I’m working with anyone who is a junior engineer to a senior engineer, depending on how complex is the problem that I’m trying to solve.

[00:25:56] SY: So what are some of the tools that you and other product managers use on an everyday basis? If you ask a coder that, there’s their IDE, there’s GitHub. There are certain tools that are just part of the job. What are the tools that are part of your job?

[00:26:12] SA: Sure. So if I’m doing, let’s say a customer presentation, I will obviously be using slides. Google Slides is my go-to. If I’m doing like a roadmap planning, we use internally AHA. It’s like somewhat like Jira, but only meant for product managers. It’s also useful because it is a tool through which we get ideas. So for example, sales is pitching our product to someone and the customer asks them. It’s a great idea that they want to incorporate in the product. They’ll route it by AHA and then we prioritize it on their own. Now we’ll reach out to the customer to get more feedback. I also use a Google Doc quite a bit because there are these landing PRDs that we need to create. We need to milestone it. We need to make sure that it gets handed over to the engineering in the way that they can consume. And then finally, I use Miro for brainstorming.

[00:27:01] SY: I love Miro.

[00:27:03] SA: Yeah, me too.

[00:27:03] SY: Yeah, great tool. Great tool.

[00:27:05] SA: I was just using it an hour ago for one of our projects. So we collaborate through Miro, either it’s an engineer or me collaborating or it could be a bunch of product managers collaborating. So a bunch of different tools. Then we use Jira to track if an engineering is working on a particular Jira ticket, when is it going to go out as part of it, when is it going to go out. Yeah, that’s about it.

[00:27:27] SY: What are some of the most important things you’ve learned in your career as a product manager that might help others in their own product management careers?

[00:27:36] SA: The best advice that I could give at least from my learning is that retrospect, right? We deliver a feature, whether it’s successful, whether it’s a failure. The key part about it is to retrospect what you could do better the next time. Even though it’s successful, there are always opportunities to improve. And even though it’s failure, there are things that you have done, which are better than the previous time. So retrospective not only helps you improve as a product manager, but also helps you build a great relationship with your team because you’re sitting there in a safe environment, asking everyone for their feedback. When you’re actually creating a feature, no one gets the mental bandwidth to discuss how they could improve the existing process. But this is your opportunity where you could actually work on making things better overall as a processing. And I feel that as a product manager the best thing you could do is to create great relationships in an organization because that’s how you grow. You’re not a manager of people. You are a manager of a product and how you get things done is all dependent on the relationships that you have in the organization. And the second piece of advice is the data. So always backup your commitments, your PRD, your requirements with data, because there are going to be opinions, but the only thing that you can use as a crutch is the data.

[00:29:02] SY: So what are your favorite resources that helped you become a product manager at the beginning and also just leveling up your career as you go?

[00:29:10] SA: Sure. So I think the best resources is to look at the products out there. Right? So for example, anytime I’m actually looking at least three to four products that I think stand out either in terms of user experience or any feature that I’m driving. So one of the best resources is to look at a competitor or a non-competitive product, but just keeping yourself up to date in terms of industry trends. There are a lot of white papers out there, which you can look at, whether it’s a Gartner study. There are a bunch of other research studies as well that you can use. Keep an eye on the overall company strategy too. I think that should always tie back to the features that you’re trying to drive. And fourth, I guess, but not the least is talk to your customers. They are the best resources that you can use for brainstorming. They are available and they want to actually partner with you in order to make great products.

[00:30:10] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Shruti, are you ready to fill in the blanks?

[00:30:18] SA: Sure.

[00:30:18] SY: Number one, worst advice I’ve ever received is?

[00:30:22] SA: First advice I ever received was to be perfect. At the time, I only realized like the least thing and makes you an over-thinker. So the ideology is to start early and fail fast.

[00:30:33] SY: Number two, best advice I’ve ever received is?

[00:30:36] SA: Best advice I’ve ever received is to retrospect, as I said earlier. It makes you a people’s person. It makes you a process person and it makes you a better person.

[00:30:47] SY: Yeah. I love that. Love retrospecting. Number three, my first coding project was about?

[00:30:53] SA: My first coding project was 10 years ago and it was about building a monitoring tool for the light web services. So it lets you monitor whether your UI and performance time was accurate like as per expectation or not, and certain other parameters around a UI and back end as well.

[00:31:11] SY: Very cool! Number four, one thing I wish I knew when I first started to code is?

[00:31:17] SA: What kind of complex situations you could land into while coding and just how many peer reviews you have to go through to get it to learn.

[00:31:28] SY: What is the most PR reviews you had to go through for a single feature or a single release?

[00:31:34] SA: Look, I remember that was like 25 or 26.

[00:31:38] SY: Yeah. Yeah, absolutely. Well, thank you again so much for joining us, Shruti.

[00:31:43] SA: It was great talking to you.

[00:31:50] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.