 Hi everyone, I'm Devika Vishani. Welcome to this webinar. I'm really happy to be here connecting with you all and discussing product management with you all. So let's get right to it. The topic on hand today is do you have to be an engineer to be a good product manager? Before we start answering that question, let me tell you a little bit more about me. I started my professional life as an entrepreneur. I built a retail startup called Sanskrit Lifestyle. Following that, I worked at T-Mobile, then Amazon, and presently I'm at Zulele, where I head the discovery product team. A few disclaimers, the views in this presentation are mine. They don't reflect the views of my previous companies or my current company. Next I want to cover why I picked this topic. And really I picked it because it's so personal to me. I am not an engineer. I am actually a master's, I have a master's in French literature. So I really made that switch from being non-technical to technical. And that happened because of the network I'm in, my curiosity for the technical space. And that's why I could relate to this topic. What we will cover is, of course we'll answer the question, do PMs need to be engineers? If not, what skills do they need? Why do they need these skills? And lastly, how can someone get about getting these skills? Alright then, the question, do you have to be an engineer to be a good product manager? This question has been well debated. There are opinions on both sides of the fence. My answer is obviously fuelled by my experiences and to me the short answer is no, you don't need to be an engineer. But there is a long answer and that is that when you understand technology, it makes you more effective at the PM. A lot of our UXs that we develop, especially in the tech space, at the end of the day they are software, they're web applications. So just being able to understand the fundamentals of the space helps make us more effective. I also want to say that some PM roles are just better served by engineers. They're just so technical that it makes sense that somebody who has a very robust experience in understanding that technical space more than just someone who's learned it out of interest, the engineer is going to be in a better position to drive the direction of that product. Additionally, I want to say that some companies and hiring managers prefer engineers. This is just a personal preference. All right, so let's take a step back and say what do PMs do? I'm coming at it from the tech space where typically product managers would be right at the intersection of the customer, the business and technology. So the PM would start by saying what is the customer needs and then try and determine a vision for that customer needs. The PM would also work with business to understand where the business's goals are and what the business's objectives are. And lastly, the PM would work with the engineering team in technology to understand the technical capabilities in the tech stack. So the role really is to synthesize inputs from customers, the business and engineers to be able to solve customer problems efficiently, fast, and solving the best, the most impactful problems first. So then why do PMs need to be technical if that's the case? From my experience, I feel there are three key reasons why PMs need to be technical. I'll dive a little bit into each of these, but at a high level, the number one reason is to earn trust with stakeholders. This is so true for every one of my roles, which is why I give it the most importance. The second one is to be able to give product direction. And the last one is to make data driven product decisions. So let's look at the very first one, which is PMs need to be technical to be able to earn trust with stakeholders. These stakeholders are primarily engineering and then of course there's also the business, marketing, legal or the leadership team. But let's consider engineering for the most part. PMs spend a lot of time with this stakeholder. And to be able to communicate with them clearly to understand the implication of what the engineering team is recommended is recommending and to be able to move that conversation forward fosters better communication and fosters a sense of trust. And that leads discussions up when both the PM team and the engineering team know the implication of a recommended course of action. And then lastly, when the game is working with the stakeholders like business marketing or other stakeholders were not so close to the technical issues. It helps that the PM is in a position to understand and look under the hood of the technical issues and translate that into plain speak and communicate that to the stakeholders without having to pull in engineering as a translator. So it's just overall in general it just fosters better communication and trust. The next reason then is to be able to make good trade offs and to able to able to have those discussions to make good trade offs. If you've been in the PM capacity for any length of time, you know that making technical trade off is a key aspect of being a PM. Again, once you're able to have that conversation with your engineering stakeholders and understand the limitations or the capabilities, understand what the broader roadmap for the engineering team is and how that impacts future features. I think it just helps to be able to come up with a roadmap that accounts for the tech stack and where the tech stack is heading. And lastly, PMs need to be technical so that they can self serve when it comes to getting data and getting data and making data driven decisions resides throughout the lifecycle of launching a product. Right from the beginning where a PM may want to decide what features to launch. They want to look at data about customer behavior or the size of a customer segment. The best way to do this is to run the SQL query. If you know where the data is stored, you can access it quickly. The second one would be to determine, say you're in execution mode, and you run into a defect, you want to determine the impact of that defect again, you'd want to get data to make any determination on what to do, whether you just let the stakeholders know that you're going to have a delay because the defect is impacting too big a customer segment or if it is inconsequential. And then lastly, when you're, you have a hypothesis about a feature and so you launch a test to say, okay, I'm going to test to see if my hypothesis is correct. But in the real world, often you don't get statistical significance or your test is flat. And so then you want to pull data from some other source that signifies what customers are doing when they see your feature. And that additional data layer can help you make a more informed decision about whether your hypothesis is right or wrong and whether to have a go-no-go with the feature that you're testing. All right, so that said, then I want to talk a little bit more about what these useful technical skills are and where in the product development process do they fit in. But really in the real world, there isn't a clear distinction between when you would use one skill versus the other. But for the purpose of this talk, I thought it would be helpful to illustrate where these skills may be useful. I'm going to talk a little bit more in detail about these four groupings of product development. But at a high level, I want to say that for product discovery, skills like SQL or Python or being able to code, they're helpful because you can pull data and make data driven decisions. For feasibility and for execution, a higher level understanding of the architecture of the company, how the systems are architected. Also, the fundamentals of web applications, how to code. Those things come in handy. I'll illustrate this a little bit more with examples as we talk about these few phases. And then lastly in the test and launch, again, you're going to rely heavily on your understanding of how test environments are set up. And also sometimes you need to get additional data to be able to make a decision. Now, these are the fundamentals. There's of course a whole lot more that you can do to enhance your technical skills. Those are the ones that I put in the blue rectangle out there, which is maybe you want to learn a little bit more about data structures and algorithms or about how search works or machine learning works. I'm really not going to touch upon those areas because I feel like those can be a little more rule specific. Alright, so having said that, let's look at how in the part of the discovery stage, a PM can be effective if they're technical. And really this is all about being able to self serve, being able to reduce dependency on engineers and on analysts when you want to understand how many customers are impacted or what your customers click actions are on your website. It also helps shorten decision time. Usually product management is a fast space. So, if you're going to have to submit tickets to get data that somebody else is going to help you with is just London in your reaction time, as opposed to just going into your database querying it and getting the data within a matter of minutes. Lastly, it, it drives home that that data driven decision, which is think about a scenario when there is no analyst no engineer to pull that data. You never want to be in that situation where you are incapable of getting the data and so you're taking a chance and saying, Okay, I think this impacts customers. Eliminate that that's a scenario where you're not using data to make decisions. The second step then would be feasibility, which is when you've looked at what your customers pain points are and that has told you some story and you've come up with a product vision and translated that vision into a roadmap. You're going to work very closely with the engineering team to understand feasibility of those features. And here again, it really helps to be well worth with web applications with the existing system and text stack of your space so that you're able to participate in high level design discussions. And the engineering team owns that for sure. But as a PM you're going to have to participate. Maybe pose more questions based on recommendations that the engineering team comes up with and really understand the impact of any technical direction that the engineering team comes up with. To say the technical team, the engineering team says for creating this UX, let's create a new application versus having it be part of the existing code or the existing application. You'd want to know that that has impacts on the UX for example perhaps it causes a flicker when the customer moves from one screen to the other. And so you're going to want to preempt any of these experiences and then say okay well how can we, how can we counter that or how can we improve upon that. So to be able to have that discussion that back and forth that leads to the best product experience possible. And then lastly, in feasibility also sometimes the rules and the business logic is lost. It's documented somewhere, nobody knows where and share point or a constant it's kept. And a faster way would just be to take a peek in the code and see what the rules are. Here's to give you an example, say you're a global company, you're sending notifications to several to come to customers in several countries. And then you find that you need to change the language on a notification for France, let's say. But you don't know which notification goes to France, really helps to go into the template for that notification which is basically the code. And look at the logic and see if that notification only goes to France or it goes to France and Germany and India then you know that the ask your ask for the team is going to be dependent on the logic in that particular code. That would be execution and then, like I said, it's similar to feasibility which is sometimes you're already you're in the sprint your death teams are coding. And they run into some curve balls, which is maybe there's a delay, you have a dependency on a different team for API or the API comes and it doesn't behave quite exactly quite as it as it was expected to. So having a discussion with the engineering team on how to cause correct here again it helps to be able to drive that discussion and you can only do that if you understand how these applications work. So to be able to grok what's going on the underpinnings of that technical issue and then communicated simply with your business stakeholders so probably for maybe not technical. That's another function that you can effectively do your technical without having to waste your engineering resources take them to the discussion and have them explain what's going on. So the last phase of the development process would be the QA the uat and then if you have an experiment running to see whether what that experiment is telling you, finally based on that you will make a launch decision. For QA and uat often teams don't have a dedicated QA team. And so it's good to understand what would be required from the from whoever's testing if there is no QA team the PMs are testing, but really understanding what that would mean. If there is a QA team then what, what are the fundamentals of standing up a test environment and being able to estimate the launch, the time needed from code complete to launch is also helpful. I think you've discussed this last one which is when you're looking at your test results and they're not statistically significant, then you're going to want to pull data that helps you arrive at that conclusion that your hypothesis is actually right, even though you don't have a clean read on the test itself. So that's, that's really it. And the objective here. I wanted to illustrate that no matter which phase of product development you're in. It really does help to have that overview that understanding of how web applications work, and of being technical enough to drive those conversations. If you want to make that transition from being non technical to technical, what do you need to do. And really, I think, I think you need to drive that journey. You need to own it and you need to drive it. And all you need is a mindset to learn technical curiosity and access to those resources which could be Coursera or Udemy or any of these online courses and some technical books with the caveat that it does take time to be able to say learn a new skill like coding. So you do want to account for that. I've put together some resources that I found very helpful. Obviously, there are so many more. You're, you may want to go and explore and see what really works for you. Each person's teaching style is different. Find the teacher who appeals to you. I think why these. The ones that I've listed here why I found them so effective is because I found the teaching style of each of these people really helpful. So let's start with the first one. That's the one I began with which is web applications for everyone. It's a Coursera course by the University of Massachusetts, if I remember correctly, but really engaging course you can take test. So you learn to code and then you have some exams and if your code is right, then you have the right answer. So it's reassuring if you feel like, yes, you're dropping it, you're getting it. Very engaging. I thoroughly enjoyed this. It really is the, like I said, the first course that I tried and it gave me that confidence that I could go learn more in the technical space. The second one I did was a series of videos by a Microsoft employee. I cannot recall his name, but it's architect, it's called architecting distributed cloud application. So relevant today because companies are just moving from on-prem to the cloud. And so this series of videos does a beautiful job capturing that entire journey and explaining what each of those components are, found that extremely useful. The third one is a YouTube subscription to God of 10. And this is really a fun way of looking at what happens under the hood at companies like Netflix or Uber or WhatsApp. And God of does a great job. He's fun and he keeps it light and he explains each of these processes. So really light and a good way of understanding technology. The fourth one is a book. Again, it's about algorithms and the author I think does a great job explaining it very simply to somebody who's non-technical. It's really very logical and you just go from step one to step two. I liked it a lot. The third one I googled for the stock and I found that it was very helpful in collating a lot of various sources and laying out a timeline for going from non-technical to technical, which is why I've thrown it in there. And you may want to go and look at that one to get a bigger list of resources. All right, so that's pretty much it from my side. I do have my LinkedIn details in the first slide. I'd be very happy to connect if you have any more questions. I hope you found this talk helpful and I'd love to stay in touch. Thank you so much.