 Hi, everyone. Welcome to this talk by myself, Aisha Ghaffar from the Product School on how to make the leap from being a data scientist to a PM. I'm really excited to show you the content today. So let's get started. So this is what we're going to cover in our talk today. I'm going to give you a quick introduction on myself. Then we're going to talk about how you can pivot your analytic skills to transition into becoming a PM. And then we're going to go over one of the data-driven frameworks that you can apply that leverage your analytic skills and your data science skills as a product manager. So who am I? My name is Aisha Ghaffar and I'm a technical product manager on the Azure portal. The Azure portal is the front end of our cloud services from Microsoft Azure. I work on the framework that is essentially used by our internal developers to put all of their front end experiences for their cloud services, like virtual machines, app services, storage in the Azure portal. I also work on a lot of experiences that new users see like a quick start center as well as our product catalog. So it's a great opportunity for me to have experience being both a feature PM and a platform PM. If those terms don't really make sense to you right now, don't worry, we're going to get into it. But I wasn't always a product manager at Microsoft. And so I want to tell you a little bit about my career journey because that's kind of how I, that's what's inspired this talk as well as giving me a lot of lessons on how to transition from what I used to do to what I do now. So I started at Belmont University, which is a small liberal arts school in Nashville, Tennessee. I studied journalism, but I hated it and I quit and then said I decided to switch my major to finance and accounting. And so throughout my college experience, I interned at a lot of financial institutions from private equity to investment banking to a hedge fund. I also added a minor in math to help me with my thesis at the time, which was around finance. So at that time, I was completely set on like going and working on Wall Street. I wasn't even thinking about tech at the time, but in my senior year of college, I had an opportunity to do a presentation with one of the clubs that I was in that gave that essentially was a club that helped students to create their own social enterprises. So our business was a mattress recycling business, where we used to take mattresses that would normally end up in landfills, and we would and we would recycle them working with people that were coming out of incarceration. And so it would both give people employment opportunities as well as being able for us to help recycle something that would normally end up just causing waste. And we were able to sell those recycled parts. That was one of the businesses I helped came up with with my colleagues in school and my professor. And because of that, we were able to present this at a competition. And Microsoft ended up sponsoring the competition. I was talking from the finance perspective, and long story short, one of the judges at the competition, one of the judges at the competition was a CDP at Microsoft. And so they basically reached out to me through LinkedIn and asked me to come and interview, which was such a surprise because one, I thought I was going to be working at an investment bank in Nashville, but I ended up getting an opportunity to fly out to Seattle to interview. But the thing is, I wasn't interviewing for what I thought was a fancy tech job. It was actually a very esoteric role at the time, which is called sales incentive compensation. And that is essentially where you design sales plans for people in the company that are selling things. So it was a complicated role. I was learning a lot, first job out of college. But from that, I got exposure to Microsoft Azure, because at the time, all of our salespeople were selling Azure based off of a revenue, based off of both size of the contract, not off of how much people were using Azure, how much our companies were using Azure. And so I helped change the incentive structure based off of Azure consumption, which was really important for how we sold Azure to our customers and how we got our salespeople to think about how to help their customers use Azure. From that, I started to love the enterprise cloud. I then transitioned into a data scientist role. So I was this data analyst, business analyst in the sales and marketing organization working on sales plans. And then I transitioned into a data science role in an engineering group. And essentially it was called growth hacking, which was kind of like marketing, kind of like analytics, kind of like data science, in that we helped teams run experiments to help optimize their funnels. So I worked on customer acquisition, optimizing the funnel from people that are trying out Azure as trial customers and converting to paid customers. From this, I learned a lot about how we can apply data science models to these types of problems, as well as how to run robust experiments and really think about how to use, how to leverage analytics essentially in order to to grow the business. And then this was basically my pivot point into becoming a product manager. One of the ideas that one of the problems that I saw that was going on with Azure at the time was that we were having a hard time onboarding customers. And I thought that a solution to that problem would be to create an onboarding platform in the portal itself. And so as a hackathon project, I didn't have any engineering skills on my own. So as a hackathon project, I sent an email to the entire company asking, telling them about this problem, telling them about my idea for the solution, and got 12 people to sign up to join my hackathon project, because Microsoft does this yearly hackathon where people can participate in working on something that's outside of the scope of their job. And so what we all worked on, the 12 of us, was the Azure Quick Start Center. You can see the logo for this here, which was the time it was called Azure Launchpad. But then it was essentially an onboarding platform within the Azure portal. And we were able to convince the leader of the portal team to actually build it. And I got to Moonlight as a PM working on the Azure Quick Start Center. And then I eventually joined that team full-time, and then was able to take this product to GA. So that's kind of how I was able to transition from being a data scientist to a PM. That was very quick, and I'm going to go into more of the specifics of what actually worked in there. But from there, I've been on the portal team, and I have since gotten my master's in applied mathematics. And yeah, and I've been working on various different products since. I actually now work on the experimentation platform for the Azure portal, which has been a great opportunity to leverage the work that I used to do when I was a data scientist on the growth hacking team. And so that was just a little overview of me. Now I'm going to talk about how you can pivot your skills to being on PM and the lessons that I learned from that transition. So let's take a quick look and understand what is a data scientist, because I think that's going to fundamentally help us to think about how can we take what the skills of a data scientist are and then transition it into what a PM would do. So fundamentally, a data scientist's job is to extract meaning from data to better understand their business and their customers to make better decisions. So really, like data scientists, typically, they need to lay a solid data foundation, which could mean anything from making sure that the data is clean, it's concise, a lot of data wranglers, as they would be called, in order to then perform the analytics on top of that. Then data scientists use analytics experimentation and machine learning to then extract meaning from data. And then they also build data products, such as those machine learning models, personalization tools, enhance the customer experiences. So there's two areas there, or three or rather, is really making sure that you have a solid grasp of like, how can we make sure that the data that we have is accurate, reliable, usable, reproducible in a sense that I can easily get the data again to be able to run or whatever I want to do on it. Then the second aspect is being able to then use the tools that a data scientist would have in their tool belt, which is like statistics, experimentation, machine learning models, more data science, more and more it's machine learning models, but there's different tools that people can use to extract meaning from the data. One of the areas where I work with data scientists a lot, and that's what I used to do, is extract meaning from data, and then also to building data products on top of that, which are ML models. But if we think about all of that, it really boils down to creating meaning from chaos and generating actionable outcomes. I want you to remember that, that creating meaning from chaos and generating actionable outcomes, because that's going to be key into what a PM does. So now we're switching to what is a product manager. So fundamentally, a product manager's job is to make decisions and execute. So before we're talking about creating meaning from chaos and creating actionable outcomes, the similar thing here is being able to then make decisions and execute. So a product manager's job is they're responsible for understanding customers' desires, needs, and problems, and working with the different disciplines to turn an idea for a solution into a reality. The ones that are the best are the ones that can make the best decisions and execute. How do you make the best decisions? You make the best decisions with having a clear understanding of all these things, customer desires, needs, problems, what's going on in the market. A data scientist is the one that extracts the meaning from data. A lot of times, it's customer data. So you can see how both of these roles very much complement each other, and that usually a product manager, they're not able to do all of the analysts on their own. They usually work on data scientists in order to figure out what is the meaning there. And so together, they can work on making the best decisions and executing and having the actionable outcomes. So you can see it's really about empowering the product management team to make those best decisions and executing on an idea that is going to have an impact on the customers, on the business, and on the ecosystem. Usually a product manager is called the CEO of the product. A lot of leadership without authority because unless you get to a really high level, you're an individual contributor. And so you're working with all of these different disciplines, UX, engineering, design, research, marketing, data science, without any authority over them. And that's why you have to use impact or influence, influencing people that you know what you're talking about or that you can make good decisions. And then people say that PMs are problem solvers. Everyone in the product management team, everyone in the tech company are problem solvers. Everyone solves problems. PMs are just responsible for this problem end to end. This is one of the distinct things about a product manager is that they are responsible end to end for the delivery and execution and success of the product. So we talked about it in high levels about what is a data scientist, what is a PM? Let's look at the similarities between the two goals. So data scientists usually works with data engineers to ship data. Basically, they need to make sure that there's a solid reliable data foundation and that there's dependable, reliable, scalable data systems. A PM slightly different works with engineers to ship features to ship software features, essentially. A data scientist has end to end ownership of model development, where a PM has end to end ownership of product development, so the entire product versus perhaps an machine learning model. A data scientist needs technical skills to be able to design reliable, scalable, understandable data science models, machine learning models. A PM needs technical skills to be able to design reliable systems. A system could be anything from like the Uber application or the experimentation platform that I work on. These are all systems and a PM needs technical skills in order to be able to work with the engineers to develop the appropriate solutions that are not going to be having too much technical overhead or not infeasible to be able to design. A data scientist has general knowledge of statistics, experimentation, machine learning models, but they can also be specialized in certain topics. For instance, lots of companies are hiring for specific skills in something with natural language processing. A PM is also a generalist, but of a much broader skill set. They are a generalist of statistics, experimentation, machine learning models, and UX principles, technology stacks, go-to-market strategy, pricing, marketing. They need to know a little bit about everything, and they need to be the person in the team that can use that, what they know, to empower other people to make, to do their best as well, so the whole product development team is successful. A lot of the field in data science, you can be called different things based off of your education. For instance, if you're a PhD, you might be a machine learning scientist or a machine learning research scientist. If you have your master's or maybe your undergrad, you'd be a data scientist. If you do not have a lot of that experience in machine learning models or statistics, perhaps you start out as a data analyst, or if you have more experience with data systems, such as Spark, Hadoop, even SQL, maybe it'd be a data or BI engineer. As a PM, there's also different flavors. This can get a little confusing, and we will talk about it a little bit, but there's regular product manager, technical product manager, platform product manager, product manager, and then a data scientist makes trade-offs between the performance and precision of their models. A PM makes trade-offs in general between the feasibility of their solution and the ideal solution. For instance, what is the ideal solution that a customer would want, but what is feasible with the engineering budget that we have and the time we have and the number of engineers we have. The commonalities between the two are commonalities between probably most disciplines in tech, but in particular, both have to manage stakeholders. We work with people all the time, and the people that can work the best with all their stakeholders usually do pretty well. Being able to communicate clearly and concisely, this is really important because each of these disciplines is important for being able to generate actionable outcomes and execute. You cannot do that if you're not able to communicate your ideas clearly. Working well with ambiguity, data can be super ambiguous, people and customers can be super ambiguous, and the problems that we're solving are ambiguous. Working well with ambiguity, this is something that both disciplines have in common. You also need project management skills because you're working with people, and you're also managing yourself, and you need to be able to manage projects really well. Then this is something that's very important, and this is something that is going to be critical in being able to pivot from being a data scientist to being MPM, is understanding customer needs and behaviors using analytics. This is something that both disciplines do. Data scientists do it to a higher degree, but PMs also need to be able to do it too. This is going to be critical to differentiate you as a data scientist into becoming a product manager. Then the other part is understanding the needs of the business. It's not just about understanding customers, you also have to understand how it is a business operating, what our competitor is doing, how do we want to differentiate ourselves, how do we make money? Then very small, but very critical is knowing how to run queries. This can be something, this is something that I actually was able to do before my transition into being MPM, and that's essentially what gave me a bit of an advantage. On my team, everyone is very excellent at running queries, so that is something that is kind of expected in our organization in Azure. Which role maps to which type of work? You saw on the Venn diagram that I highlighted growth PM, that's just because I'm going to dive deeper into that, but there's four different types of product work in general. There's feature work, which is generally what most PMs do, I'm developing a software feature, this is a person that creates and captures value by extending a product functionality. So I'm sending a product functionality to add incremental, to incrementally capture a new market or new set of customers. Growth work is essentially, it says creates and captures value by capturing more of the existing market, but growth PM is essentially someone that is thinking about how to optimize certain funnels. So like customer acquisition, retention, making sure that I'm reducing churn, making sure that I'm able to, with the current customers I have, I'm able to increase their usage of the product. And so in Azure's example, it's all about usage. And so what we want to do is get our customers that are using virtual machines use more virtual machines or use them for a longer period of time, because virtual machines are built on hour. The third one is scaling the work. This is mostly aligned to feature PM, core PM, growth PM, growth PM. And then this is platform PM. This is the work that I said I did. I was a feature PM and a platform PM on the Azure portal. Think about these teams as the ones that are creating platforms for other people to build on. So for instance, the Azure portal, we actually release an SDK, an SDK that different teams within Azure can then use in order to create their experiences. Similarly, Azure itself is a platform. It's a platform that people use to build their products and they use as their technology stack in order to create their products that they sell to their end customers. And so a platform PM really needs to make sure that the product is able to grow across new features and that it makes sense in terms of the platform strategy. And so this is a little bit more nuanced than just releasing a new feature. It's releasing a new feature and making sure that it makes sense for the ecosystem, making sure that it's sustainable, making sure that it's not going to have any adverse consequences. And so it's very much, it's very much, and it's a lot more technical too. And there's product market fit expansion. This one, I haven't encountered as much, but what most people call this an innovation PM. So it's someone that works on more like rune shop projects or projects that like there hasn't been like more what I don't want to use buzzwords, but green field opportunities. So this is someone that would work on something where there's not as much proven, there's not as much proven in the space. And the company is making like a big bet on innovation in this space. And maybe there is not necessarily a market for this right now, but we're creating a market for it and we're seeing a market for it. This is still a core PM, but it's a core PM that has that leans more into ambiguity, leans more into customer discovery, leans more into understanding what the customer needs without them even saying that they need it. So that's similar skills, but much more risk, much more ambiguity. I'm going to run through a typical PM workday very quickly because I want to focus on one of the aspects that is common with data science about you think that's which one. So a PM, you know, you have to communicate ideas, they gather information. Here, there it is. One of the ways that they gather information is through data analytics, as well as technical understanding, technical limitations, they brainstorm ideas with UX researchers and designers with their engineers and architects and with their go-to market team and leadership and sales and in marketing, they plan strategies and they execute and they plan managing through scrums and meetings. But as you can see, this is not, this would not be a typical day for a data scientist at all. They would do something really different. If you're a data scientist, you probably know that. But the common thing is data analytics. So I wanted to, so previously we said, you know, data scientists and the PM, they do have quite a bit in common through that Venn diagram. But when you look at the day-to-day, it can differ quite a bit. I want to point that out because you can leverage your data science skills into being a PM, but you'll have to like really learn all these other skills as well. The good news is that these are fairly, as you build a product, these are fairly easy to learn or reasonable to learn. A quick run through of like the different types of PMs that there are, the product manager, technical program manager, platform PM and growth PM. I want to focus more on the growth PM because that's what I was. And I think that's probably the easiest way to transition from a data scientist role into a type of PM role. I've obviously people have transitioned from being a data scientist or even a data analyst into four product management roles, technical program management roles or platform roles. But I think the growth PM is a lot easier because this is the role that aligns the closest with data analytics, science and marketing, growth marketing. Because they're focused on driving business outcomes. Remember what we said about data science? They drive actionable outcomes by creating meaning out of chaos and meaning out of data. Similarly, the growth PM is focusing on driving new business outcomes, such as acquisition, retention, usage, and revenue. And they usually work with additional core product managers to drive these outcomes via growth hacks, like experimentation or product optimizations. So they are using the growth of business. So this is a great role that leverages both the great skills of a data scientist as well as PMs and understanding the customers and creating actionable outcomes and delivering in order to be able to move the business. This is how I transitioned from being a pure data scientist into being a PM because I was also working in my role as a data scientist also as a growth PM. And so I was able to leverage those skills that I had learned, but also get more of those PM skills that we talked about are important to learn here that you do in your everyday activity. Really quickly, for those of you that may not know, a traditional product manager focuses on the what and the why. They're usually customer facing. They set the product and go to market strategy. They're most often technical, but they can also work with non-technical teams. Sometimes you'll see someone say, this is product manager, technical, it's just product manager. The key difference is how technical are they, and if the product that they're working on is a technical product like AWS or Azure or a non-technical product. A technical program manager is more execution oriented. They are responsible for the planning and development of a solution. They usually work on when and how. We have a strong technical background because they work with engineers more closely. Many companies combine one and two, like Microsoft, product managers, and TPMs are the same role. And then we talked about platform PM, so I'm not going to get into it too much, but they are responsible for toolings or platforms like just APIs, operating system SDKs. They need to consider developers who are usually their primary audience because they're usually working building for developers as well as their developer's customers. So they're customers' customers. And they need to balance the short-term trade-offs for long-term platform success. So this is kind of where I was saying, it's like a feature of PM, but it's a lot more nuanced because you have to make types of trade-offs. Okay, so the core question is, how can I demonstrate these products built? How can I get someone to hire me as a product manager as a data scientist? And it's going to sound a little bit trite, but it's quite simple. You build a product. That's what I did when I was working on the Quick Start Center is I saw a problem, and I came up with a solution that I thought would meet the need, and that proved to be successful. So that is essentially the core of it. And because a product manager needs to demonstrate that they can see a problem, they see a customer need, they can understand and make a good decision on what to build for that customer based off of their judgment. It's very important to have good judgment as a product manager, and then they can execute and make it a reality. This is something that not everyone will be able to do in their current role as a data scientist. Maybe your team won't allow you to stretch into that. Maybe there is not really a scenario where you can build a product. That's okay. This is something where you could do even in your time away from work. Moonlighting as a volunteer in a particular area where you can, or for an on-profit, where you can build a product using your data science skills. You can understand how I can use my skills as a data scientist to understand what the customer needs. Maybe I can't and then essentially use that to build something. Basically, you need to build something and demonstrate that. But remember your competitive advantage. Remember the things that you can do that perhaps other roles that are transitioning into product management can't do. You have excellent skills in terms of extracting meaning from data. That's what's going to enable you to make better decisions. The difference is you've got to take that and you've got to drive it end-to-end. I think that's one of the joys of being a product manager. That's what I wanted to switch from being a data scientist into a product manager is I get to drive the end-to-end outcomes working with a ton of people that are amazing, but I get to drive the end-to-end. I think that gives so much satisfaction and so much opportunity to make an impact on customers. I'm going to run through the data-driven frameworks for product management that I think there's lots of frameworks that people use or they don't use frameworks and they just build something. I'm going to talk about this because I think this is super relevant to you as a data scientist and it's based off of the scientific method. As scientists, we know that what would we do for us in the scientific method is we observe and we ask a question. We make an observation and we ask a question. Oh, I noticed that this customer is doing something like this. I wonder what would happen if they did this instead. We would research the topic area. We would search for existing solutions or answers. This is just basically doing your homework. Once we've done our homework, we would hypothesize. We would form a hypothesis. This is very clear how we would think about something. If I did this for this customer, then this would happen as a result. I'm saying it in customer terms, but obviously the scientific method is used for scientific problems, but we're going to apply it broadly. They form a hypothesis based off of their observations and their research, and then they design an experiment. They design an experiment to test their hypothesis. After they run that experiment, they analyze data and they draw conclusions. It's very simple. People have been using the scientific method for hundreds and hundreds of years. Now we're going to take this and we're going to turn it into our product development framework. Remember, I said a product manager owns the end-to-end product development process, but it's a virtualist cycle. It's a flywheel. What we start out with is building a problem hypothesis. This is inspired from the first three phases of the scientific method, where we understand what is a problem that we notice something. We notice someone doing something, but then we say, ask ourselves, what is a problem we're trying to solve? Who are we solving it for? Is there a large market for the problem? What are the characteristics of this problem and what are competitors doing? From then, we come up with a hypothesis. We say, hey, we believe that if we do this, then this is going to happen. What do we build to meet customers' needs? How will we know we're successful? How will we measure that we're successful? Then we design an experiment to validate and execute, to validate the solution hypothesis, and then execute it if we're trying to help. Here, we ask ourselves questions like, did we successfully deliver the ideal customer experience? Did we solve the customer problem, both short-term and long-term? As you can see, I'm showing you what are the types of activities we would do at each stage. Notice that in the first stage, we're usually working with data science and analytics and user research, as well as business strategy, compete analysis, and telemetry analysis. Here, we're really doing our homework. We're really trying to understand what is the customer need. We're also extracting meaning from data. Usually, we do that with working with a data scientist. This is really where, for me, when I was a data scientist transitioning into a PM, I realized that there was a problem. I knew that there was because I had done my homework. I had done the analysis on customers. I understood where were they dropping off. What was the gap? They came up with a solution, a solution hypothesis. This is where, in order to actually run an experiment, we have to build something to test. This is where the PM would work with the designers to design the UX, the UX product, and engineers to develop a roadmap of features to build. It also defines success metrics. This is very important for all PMs to be able to do well. This is something that a data scientist, as a PM, can do really well, because it's about understanding the different metrics that make sense. It is an art and science in itself. We don't have time to get into it today, but this is something that where data scientists can really shine. Then also testing the designs in user research studies. User research studies are essentially where you bring mock-ups, usually, or a lightweight prototype. You see how they use it. Basically, there's more to it than that, but you see how they use it. Before you go into code development. Then once you ship the product, you make sure that the feature ships on time. There's an asterisk there as software. You think it would be easy, but almost nothing's on time unless you're having your people work overtime, which you can do, but not recommended, unless you really have to. Then you run the feature through an experiment. This is where designing an experiment, designing who you're going to expose the feature to, what are you going to manage, what's the rollout schedule. This is really important. This is the experiment design execution phase that a PM would need to do. Sometimes when we're thinking about those broken up rolls, this might be something that a TPM does, a technical program manager, but usually it's TPM slash PM that would be responsible for this. We analyze the long-term impacts of the feature. Is it going to have the impact that we want long-term, or is it just going to be a temporary flip? These are the types of things that a product manager would think about when they're using this type of framework, and it's really a hypothesis-driven framework. We're thinking about, is this the right problem? Okay, we've done our homework, and then is this the right solution? Okay, we'll validate an experiment. If it's successful, we'll ship it, and then we'll continually iterate and we'll learn. I believe that is the end of my content today. I want to thank you all for your time and listening to me talking about how to make the leap from being a data scientist to a PM. If you would like to reach out to me, you can find me, please go to the first slide. My name again is, oh my gosh, I have to do this. Okay, one second. My name again is Isha Ghafar, and you can find me on LinkedIn. You can also find me on Twitter. Thank you so much for joining again, and I hope that you are successful as you make your transition from being a data scientist to a product manager. Thank you so much, and have a great rest of your day.