 Hello everyone. Thanks for joining in for today's webinar. I'm so glad you could make it. I'm a poor worker and I'm a product manager at WhatsApp and today I want to talk about succeeding as a non-tech product manager. Before we get started, let me share a little bit about my journey. I'm an electrical engineer by education and my career kicked off at National Instruments as an application engineer. This job took me to Bangalore, often called the Silicon Valley of India. And it took me at a time when messaging was picking up, apps like WhatsApp were gaining traction. And as someone who did not like speaking on calls, I was so drawn toward the possibility of what instant messaging had to offer. During this period, I stumbled upon an early state startup called Haptic, which was pioneering the transition from traditional customer support calls to chat. This young company had just secured seed funding and was making waves all over the news. I took a leap of faith and applied for an operations role, which was finally the only non-tech position amidst all the openings that they had. Little did I know that I was now taking the first step towards being a product manager. At Haptic, I did many random things, like setting up 100% operations for replying back to our users, being proxy for a CTO who was based in US, reporting what was done today, not done today, what we could work on next, talking to our users while distributing flyers, asking them to download ads. And somewhere between all of this chaos, I became responsible for figuring out roadmap for our backend tools that interface with our operation tools, and that marked the transition into product role. Eventually, at the company, I led all of product through a $100 million acquisition. During the acquisition, I was interested with the task of identifying new products for the company to invest in. The opportunity led me to create and scale, interact, a CRM solution that empowered small businesses to operate efficiently on WhatsApp. The product gained rapid traction and witnessing the value WhatsApp brought to small business ecosystem in India was truly an eye-opening. With this newfound perspective, I could resist the opportunity to join WhatsApp, where I'm currently engaged in crafting products that connect over 2 billion people with businesses around them. So, if you're wondering why someone did that engineering degree by education, talking about being a successful non-tech product manager. There are two reasons why I want to discuss this. One, a personal one. I was and still am terrible at coding. The two mandatory programming courses I had to take in college still give me nightmares. And the second reason is a selfish one. Many of the best PMs I've had the privilege to work with didn't come from technical backgrounds. The diverse backgrounds ranging from Spanish major to being a ski instructor or being in marketing and sales has made me learn so much about different perspectives and ship better products that if I could encourage even one person today to give product management a shot, I know the community would benefit at large. If you don't believe me, that's totally all right. Here from some of the amazing leaders out there who are masters of the craft, and they often talk about how their non-tech background is what gave them the edge. Now, if you're someone who feels like they should learn code by all means, go for it. Whether you want to be a PM or not, it's a valuable skill set. But if you're someone who doesn't want to, I'm going to spend the rest of our time together today to share what I learned about excelling as a PM and what you could do to master working with engineers who are very important partners when you don't like or don't know how to code. There are so many different definitions of who a product manager is and what they do. Honestly, the role varies so much by the team, you might be on the stage of the company, and then as an outsider, it might be difficult to understand what PMs actually do. And more importantly, what skills you need to build to break into and thrive as a product manager. One analogy that really brought this home for me was thinking about a PM as a conductor of an orchestra. Imagine that the company is a great concert hall and your team is a talented orchestra. Much like the orchestra has different sections, the woodwinds, the string, the keyboards, your team is composed of different functions. From engineering to data, to design, to marketing, to legal policy, a well-performing team often feels like an orchestra playing beautiful music for your users. Like a conductor, a killer PM is responsible for controlling the cadence of the project, ensuring each section is playing correctly and overall working to unify the many musicians that make up the orchestra. And the PM, quite like the conductor of the orchestra, is not the star of the show. The spotlight belongs to the orchestra. I love this analogy because it's very versatile. It has helped me redefine and understand my role as I move from working on different kinds of products and things. I can build great products by enabling people to do their best work and be able to work well with each other. Some of the skills that are valuable in enabling this are having immense empathy. Empathy for your users, your team goes a very long way. Communication, when you're working with so many different people, communication that drives clarity simplifies things for everyone is a game changer. It enables everyone to make progress and not to often revisit decision because they understood a different version. Mastering the problem's space. As a PM, we have the opportunity to see all sides of the problem. What users want, what can be built, what enables business objective, being able to piece all of it together, share our perspective and have opinion is empowering for the entire team. Being technologically curious. I would think this is an easy one for most of us here. If you're here and looking to be a PM for a software product, you're probably already technologically curious and the possibilities of what technology can do is why being a PM is exciting. Tech is fast moving each year. It pushes the possibilities of what can be done. Being technologically curious enables us to stay on top of what wasn't possible earlier but might be now. The interesting thing about each of these skills is that anyone can invest in them, get better at them and hopefully you're now feeling like these are doable. You already have some of these and can possibly build for others. Let's now get a step closer and deeper to see how this translates into working for engineers. As you look to work with engineers, remember our goal is to figure out how something needs to be done but to enable them to understand why it needs to be done. We're looking to help them to understand what needs to be built. You can get better at this by understanding tech lingo a little bit more and look to make decisions together with engineers. The art to master is that of asking right questions. There are a few playbooks and techniques to master asking the right question I'm sharing a link to a video by a fellow PM Anjumani Rudra who's a senior leader at Google and has great resource on how to ask right questions. All of these four techniques that are just listed out here can be applied when you're looking to figure out how to work better with any particular talent group on your team. Example, if you're wondering how to work better with designers, you start by empowering them by sharing what and why users need and not the how to build the product. You enable them to work better with researchers, analysts and engineers. You get comfortable with the design lingo and master the art of asking right questions to reach better decision making. I've compiled a list of common tech lingo that can help you get started. There's a lot of content explaining each of these out there. If you could pick YouTube videos or read them on the Wiki or read some blogs, you could pick the approach that works best for you and take just one as an example. Let's take API, for example. A simple Google search tells me that API stands for application programming interfaces. They like set of rules and protocol that allow different software programs to talk to each other and share data or functionality. For example, if you want to use a weather app on your phone, which let's say software one in our example, it's probably using an API to get current weather data from another service, let's say from the Met department, which is software two in our case. There would be an API that defines rules like if the weather app sends latitude and longitude of a place. The Met department would return back the current weather of that place and let's say degree Celsius. This helps the weather app developer to figure out the possibilities of the product they're building. For example, they probably need a way to convert users' location to latitude and longitude information. If they want to display results in Fahrenheit, they probably need to multiply it by 9 by 5 and add 32 to the temperature sent by the Met department. If you're someone who's looking to learn the tech lingo, a great place to start is this list. You could keep going down the list as and when you get comfortable with the terms above it. And when you feel like you're ready to go a step further, one skill that can help, it's often not necessary is being able to read tech documentation and try out APIs for yourself. This can be particularly helpful if you're looking to use other services within your products and looking to understand possibilities. You can always sit with engineers and ask them to explain the possibilities to you. And if you master the art of asking that question, this should be sufficient. But if you're someone who likes to check for yourself, being able to read documentation, mastering a tool like Postman that allows you to work with these APIs without writing the single line of code could be your next step. Remember, we are investing in tech lingo to be able to communicate better. Being able to communicate better can have many flavors. And if you feel like taking everything up a notch and going visual, the possibilities with no code and UI-based tools is limitless. From design tools like Figma, Balsamic, that help you sketch visuals quickly to no or no code tools, prototype pink today as a non-tech person, very possible. Learning is a continuous process. And you could invest in a bunch of things to keep reinforcing your learning. If you already know engineers, ask them for help. Take them for coffee. As in what they do, ask them questions about something you learned. You may be surprised how feeling most of them are to explain their work. Hackathons, these are my favorite way to learn anything new. A great real-world setting to get to know what working with a real team feels like. What would your role as a PM look like if you were to work with a set of engineers? If you're someone who doesn't know any engineers, can't go to Hackathon, there's so many engineers who break down different products and their constituents on YouTube. Follow them, listen to them, build your own understanding. There's so many possibilities out there to get started. Just set your goal to build your roadmap and milestone to figure out what your journey looks like. Here is a sample milestone chart when I did not know how to get started with engineering. This is the path I took to there's so many different parts you could take. I hope everything that I shared today gives you a little bit more confidence in your abilities and gives you more ideas on what strengths you could bring to your team as a product manager if coding is not one of those. Sharing some of these things I did to get more comfortable working with engineers can give you ideas to create your own journey. All I want to say before closing today is that always remember that your unique perspectives and skills as a non-tech PM can be a tremendous asset. Please go embrace this journey and the learning process. It's a rewarding path to success in product management. Thank you for your time and if you would like to discuss anything more specifically with me, I am very reachable on LinkedIn. Do drop me a DM. Thank you so much for your time today.