 Welcome to this webinar on Building for Builders. My name is Monika Ombo-Go. I'm a Product Manager at Microsoft, and I'm excited to be here through this session. The learning objectives for this webinar are one. We are hoping that you'll live here with an understanding of how to apply the principles of product management to deliver high-quality products for builders. We're going to define who builders are in the next few minutes. We're also hoping that you'll be able to demonstrate an increased understanding and appreciation for the unique nuances of building products for builders. Let's get started. Who are these builders and what exactly is this topic about? Typically, a Product Manager builds products for a group of users, and we're going to call that group end users for the purpose of this webinar. End users typically are diverse, and the role of the Product Manager is to really define the product vision and the strategy of the product and the roadmap. The Product Manager is also tasked with conducting my head research and also really managing the product lifecycle. The Product Manager also collaborates with people from different teams and ensures that all the product features are delivered. It's also the role of the Product Manager to really monitor the performance of the product and ensure that it is hitting all the objectives that were set. That is a typical role of a Product Manager in a typical company. What we see that happens sometimes is that the Product Manager will not just build for end users, consumer end users, if you might call it that. Sometimes the Product Manager or Product Manager might find themselves building for a group of users who are in turn building for other users. The roles of the Product Manager are still the same. They still need to define the product strategy, conduct research, and all that stuff. But today we're going to look at what are those unique things that might differ or might differ only slightly here when you compare building for an end user versus building for builders. If you want to define the term builder, builder is any professional who is involved in the design, building, or maintenance of applications, system, and tools that in turn meet the needs of the end users. We're going to give a few examples. The first very big category are software developers. Software developers are oftentimes building for other people, and so you might be a Product Manager and you might be building tools that are going to be used by software developers who are in turn building for other folks. These software developers might be internal to your organization or they could be external. We're going to look at two examples of that and see how they differ. Let's look at a hypothetical scenario here. Let's imagine a user called Anna, and Anna is an internal software developer and she works within the company that the Product Manager also works in. Anna in particular works on what we might call a low-level software component and just to make it more concrete, we're going to assume that she works in the virtualization space. She's building virtualization software. This is going to help and enable multiple operating systems to be run concurrently within a single server or a single machine and help in the utilization of resources. Let's imagine for a second that we are actually building some tools for Anna to use. The main question we're going to ask ourselves is how is building for Anna different from building for consumer end users? We're going to look at a few things. Let's first of all talk about the idea of a product market fit. Again, as a Product Manager, oftentimes you need to think about the product that you're building and whether it is meeting a real customer need, right? The one thing that here we need to really emphasize is that when you're designed for Anna, you are still designed for a user and consequently we still need to ask those questions. What is Anna's needs? What are Anna's needs? What are her pay points? So that you can be able to answer that and build a product that has features that meets those needs. We need to really offer a concrete value proposition, very, very concrete to Anna. As much as if she's not a consumer end user, she is still a user and therefore we really, really need to focus on her needs. Also very, very important to note is the need to iterate based on feedback that Anna gives, right? So just again, Anna is not a consumer, an end user, if you have to call it that, but we need to get feedback from her in terms of things like NPS, what is her customer satisfaction with the products that we built for her. And we need to do that on a regular basis as we introduce different features to her. And what are some of the things that might look different when you're looking at the product market fit in this scenario? Obviously the size, right? You might not have as many Anna's as if, for example, you're building for consumer end users, right? So the size alone is smaller and the internal, the number of internal software developers that you might be building for are not as many as if you're building for an external audience. And obviously also, you know, again, when you're talking about product market fit, oftentimes you talk about things like willingness for the customer to pay. Again, this might not really apply here, but what matters here is again, just looking at the value, right? Because a lot of times willingness to pay is also pegged on the value that the product brings to the user. Really looking at whether this product is meeting the needs of Anna and of the internal software developer. And then just to look a little more at Anna and look at, you know, again, the product lifecycle, one of the main stages of product development is actually ideation, right? Coming up with ideas on what to build. And one of the things that you might notice as a product manager building for Anna is that you might notice that a lot of great ideas will actually come from your own internal engineering team. And that is because there's a greater empathy because your engineers or the engineers who are working internally have been Anna. They have been that person who's using some virtualization software to try and make sure that there's resource optimization. So they know what to look out for. They know that things like performance, security, good documentation, all those things really, really matter. And so the empathy that you will encounter even as you are an advocate for Anna, right? Because a big role of a product manager is to be the advocate of the customer. A big chunk of what you might face is that there will be greater empathy for Anna. And so it's interesting how things like brainstorming might look like because you'll be brainstorming with internal teams, how prototyping might change and how even collection of early feedback. A lot of that might happen just within the team where this is being built. And this is, in my opinion, one of the benefits of building for builders because you don't have to go very far to even get users. You might have users right there on your own team. And it also makes your job of advocating for the customer a little easier because people get it, they have been the user, they have been the customer, and so they understand. Let's look at another example. Let's imagine a user called Andrew and Andrew is an external software developer and Andrew is actually building tools using SDKs that we have provided and using an API that we have provided. And let's assume that we have built some SDKs on top of that API to help people use the API using different programming languages. And again, the question that you're going to ask here is, is it different when we build for Andrew, is it different than if we build for somebody externally? And let's consider this idea of user journeys, for example. So a lot of times when you create a user journey, you start by creating a user persona. If you identify the user, this is the journey they go through. These are their goals, their motivations, and they're paying for it. And then you look at the goal, right? Where do they want to go? What do they want to fulfill? What is the objective? And then you list the steps between where they are and where they want to go. And oftentimes we talk about actions and touchpoints, right? And these are the two things that might vary slightly when you consider developer user journey as opposed to like an end user consumer user journey. The touchpoints might differ, right? And the actions that they take might also differ slightly but ultimately there is a user journey and there is a developer journey that Andrew is going to go through. I think important to look at, which is the same across the board whether you're looking at the user journey that Andrew and other developers go through is considering the emotional state that they're in where are they happy, where are they frustrated, where are they excited, where are they satisfied? And also identifying the pinpoints along that journey where they might encounter barriers and where they might encounter difficulties in achieving a certain objective. And all of this really helps us define the opportunities for improvement along that user journey and along that developer journey. So I think important to note here is that as much as you might have different actions and you might have different touchpoints, it is important to really define that developer journey and look at the different pinpoints and issues that Andrew and other developers might face along the journey. And also let's look at definition of success, right? A lot of times again, as we say that all of our product managers to look at their product and to really consider, is it doing what it's supposed to be doing? And when you look at code fast users, if we might call it that versus UI fast users, the metrics are very different in terms of how you define success. And that oftentimes how we define success for things like APIs, for example, is not the same way we define success for our UI, our web UI. But the point and the main thing that we might need to focus on is that we still need metrics to evaluate whether we are doing well or not doing well, right? But instead of looking at things like page views and the average time that somebody spends on a page, we might be looking at how many calls are being made to a certain endpoint and such metrics. So it's important to do that. And additionally, it's also important to look at other metrics that are not as quantitative, things like surveys and things like interviews that still matter and still cut across the board, both for UI fast users and code fast users. And maybe to summarize and the key takeaway that I want us to leave this very short webinar with is that across all the development stages of a product, such as ideation, defining the product itself, prototyping, designing the initial prototype, et cetera, there are differences. There might be slight differences when you're building for end users and when you're building for builders, if you had to call them that. But ultimately the fundamental roles of a product manager still applies. And so if you're a product manager and you've been building products for consumer markets and for end users, I think the transition to building products for internal folks and for builders is not that difficult and it's not that complicated really. It really is just a slight modification. You just modify a few things here and there and some things will actually be easier. So thank you very much. Thank you.