 Hello, everyone. My name is Sid Nosnodukar. I am a PM with Amazon and I'm here to speak about consumer versus enterprise product management. But before we start, a big thanks to the product school for having me here. I really appreciate this opportunity. It is a great way for me to connect with the rest of the PM community and share some of my learnings from my experience. So, let's quickly go over our agenda for today. I will start off with a brief introduction on myself. Then we will go into the topic and basically understand the different type of consumer and enterprise products, who are the users, who are all the stakeholders within these products. Then we will basically take a look at how the user needs very based on the type of the product. Finally, we will get into understanding how we manage the stakeholders, what is the complexity that we have to deal with as our stakeholders change and how does it impact our overall build velocity. So, to start with an intro on myself. I describe myself as a product management generalist. I have about 13 plus years of experience in product management space. I have worked on a variety of products from consumers to enterprise. Right now I am with Amazon. I work on Alexa. I previously also spent some time here on the retail side, you know, bringing to life some of the products for pets. I also spent some time at Meta where I was leading this PM role for bringing real-time communications, which is audio, video, AR, we are calling to a variety of Meta's apps and devices. And prior to that, I've also spent time in the satellite telecom industry, university software industry, also founded a startup that built automation solutions for tracking of or for mining industry. I do have a technical background and somewhere down the line, I've got an MBA that kind of helped me transition more into a formal PM role. I love PMing. I really think it's a great way for me to feel more connected with the users and eventually understand what the customers want and work backwards from there to build great products. So to start in our topic of consumer versus enterprise product management, let's start thinking about what are we building and whom do we build for. So we have, we broadly categorize most of our products as consumer and enterprise. That's the most common perception out there. We think that there might be only two types of products. Now, that's a great place to start. And that ideally, basically, it is the way to think about whom we are selling the products to. In this case, we are mainly thinking about whether we are selling the product to a business or an organization, in which case it's an enterprise, or are we selling it directly to the end user as a consumer. However, in reality, there might actually be more than just those two flavors. There are buyers, there are builders, and there are users. Take this, for instance, you create a product and you put it out there. In many cases, the person who buys the product will not necessarily use the product. So we can define these three roles very, very broadly as buyers are the customers who want to buy your product because they see value in it, whether it's for their personal use or whether it's for their enterprise or whether they want to just gift it to someone. Builders are the customers who build other products using your products. For instance, if I were to go and purchase in a bricks to build my home and I'm a builder, I'm building homes for someone else. That's the role that the builder plays in the ecosystem. And finally, the users are the end customers who interact with the final end product or the final output or whatever we call it, who are the ones who would be most closely connected with whatever gets built. So in a typical world, we can think of the buyers, users, and builders as having some kind of a correlation. So whenever we have a product, it is almost certainly purchased or taken over by a buyer. When a buyer has a product, it can be put to use directly to a user or it can be put to use through a builder where the builder takes that particular product and builds something more. When a builder has a product, the builder can put it in the hands of a buyer or can put it in the hands of the user to use it. Again, that depends on the type of the product. So basically, this is a relationship between these three entities on how they interact in a typical ecosystem. Let's go into what exactly might happen and how many hands might the product go into before even ending up with the final user. So users can, in many cases, be multiple degrees away from the product. And the more the degrees away a user is from a particular product, there are more stakeholders involved. There is more complexity involved. And in most cases, based on what we want to get to, will require us to think through more thorough requirements. So in simple words, we can define a degree as the number of entities between the product and a user. For instance, if a product is a consumer product, a consumer buyer purchases it, and a consumer user uses it. In that case, between the product and the consumer user, there is just one entity which is the consumer buyer, which makes it a first degree. Of between product and the user. So in many cases, the buyer and user might be the same entity, but in many cases, it might be different. As we go more into the enterprise space, we can expect, given the number of stakeholders, given the number of varying complex requirements, we can expect the products to be much further away from the end user. So there might be like third degree users who are four degree users, in some cases, who are actually going to use this product and whatever you build might essentially go through the hands of multiple other stakeholders. And that's not all. It can also be a combination of these. So your product might have a third degree user, a second degree user, and a first degree user. In that case, you have to deal with multiple degrees of users. Further, your buyer, builder, and user can either be internal to your company or external, in which case the stakeholder management models that you use might be very, very different. So in this case, what should we do? What mental models should we apply to thinking about how we build these products? So just as I was putting together these slides, in fact, Carlos just made a post, which I really wanted to talk about, that your users are the only reason why your product exists. So what I want to say here is, essentially, we have to focus on our users first, because as we start thinking about where our product is going to end up, it's always the users. And unless we are creating value for the end users, everything in between, like the builders or the buyers, would essentially have no value in your product, if a product exists, because the user exists. In that case, if you build great products, which can tailor the needs of all of the users, the builders and buyers would find a lot of value in even doing so. Second is, as we put more focus on the users, what are we doing with the builders? The builders are essentially also building for the users. So it's our job to make it easy for the builders to focus on the users. And that's how we are actually creating value for the whole ecosystem of buyer, builder and users, whether they're enterprise or whether they're consumer. And finally, when we think of buyers, we have to create the right marketing message for them. We have to let them know that their users are getting the right value out of our products. And so the product makes a lot of sense for them to go and buy. So let's quickly take a look at a couple of examples, they're very simple examples on who might be the buyers, who might be the users and who might be the builders. So the first one you have here is a simple product, which is a toy. In most cases, the buyer and the user is almost certainly going to be different, because the buyer is mainly going to be an adult who gives the toy to their child or somebody else's child they gifted to. So basically, what goes on here is the product that is being designed has to be designed in a way that it takes into account all the needs and requirements for the end user. But at the same time, we have to market it to the buyer who makes the decisions for the end user. Thinking a bit more along the lines of higher degree of users. Let's take a look at the second example here. The second example is mainly about a website builder. Now a website builder can be think of it as a wizard that lets designers or anyone who wants to create a website allows them to create a website. There might be a primary enterprise buyer for this type of a product. And the enterprise buys this product so that they can start creating websites for their customers. So here in this case, in the example you might see an enterprise buyer purchases it. A web designer within the same enterprise buyer is actually able to use that product to create websites for another enterprise which here is some travel company called XYZ Travel. And the end product is the website that you have created out of this particular website builder. It gets used by a consumer who is a traveler. So at a high level, what we actually built was an end product for the end user. So basically, if this website builder, only if this website builder is able to create an awesome experience that takes care of all the needs of the final user, then there is value for everyone else, which is the primary enterprise buyer, the primary enterprise builder as well as the secondary enterprise buyer. At the same time, we also have to think about what are we doing to facilitate the builder to bring this particular website to life. And that's exactly what this website builder is designed to do. It allows the web designer to bring great products for the end user to life. So basically, we are thinking through multiple layers of stakeholders to make sure that we have great satisfied users and we are tackling, we are bringing great experiences to them. So as we understand the flavors of who are the users, who are the builders, who are the buyers, it is important to understand that in most cases, although not almost always, the higher the degree of users, the further away they are from the product, the more product complexity is going to increase, which means there are going to be more requirements, we'll have to do more trade-offs because we will have to start thinking about which entity to optimize for. So that's when we have to start thinking through who are the, what are the needs of each type of our users. So if you look at this particular table here, we'll mainly think about the users first, we'll come to the builders later. But in most cases, a consumer user is the one that's out there. Now, those are the individuals all over the world who have a lot of needs. But again, it's very easy for us to do research on them through a variety of methods that are available, versus an enterprise user, it's a business, and they have very, very specific needs to make sure that their business functions in a healthy fashion. So looking at the dimension of user research, if you were to think about a consumer user, it's very feasible to go after very, very data-driven user requirement collection process. The most simple one we always talk about is creating a survey. If you were to send out a survey to millions of people and still get hundreds of thousands of responses, it still gives us a significant volume of data to make informed decisions on what matters to the population or even segments within the population. But that's not the case for an enterprise. We have basically, in most cases, had to do a very thorough depth plus breadth driven qualitative requirement collection. So this can, in most cases, happen through one-on-one interviews with all the stakeholders with the enterprises we are working with. For instance, if you are building a CRM solution, for instance, it will be very important to understand what the enterprises are looking for, what type of customers they have, what type of data they want to extract, and every company might have very, very different requirements. So at a high level, it's going to be a much more qualitative process. Secondly, the fact that intuitively there are a lot more consumers out there as compared to enterprises out there. And enterprises are probably a lot more higher paying than consumers. So each enterprise user has a lot more value, is a lot more important. So it is possible for us to tailor to them individually versus going after the large scales of consumer users where we are mainly looking for signals that speak of the key pain points that they have. In terms of regulatory requirements, most consumer products can be researched through standard regulatory requirement processes versus enterprise products, in many case, might likely have very, very high bar, might require very highly specialized, highly complex regulatory requirements that we might need to take care of. That is because in most cases, enterprises are also dealing with their own particular users, their own customers, which requires them to comply with certain regulations and which is something that we have to make into the products that we are building. In terms of privacy requirements, so over here the caveat is that we are mainly talking of the privacy of the requirement collection process and not the privacy of the product. Privacy of the product is always important whether it is a consumer user or an enterprise user. But the requirement collection process for consumer users is a lot less data sensitive. Example, when we do anonymous service, most customers are not going to enter any sensitive data into the survey inputs. But if we think about the enterprise users, when we interview them, when we are building products for them, there is a fairly high chance that they might be talking to us about something about their business process which is confidential, something about a product that they are working on which is not yet launched, which is also confidential. So the requirement collection process is also going to be very, very privacy driven. In terms of pricing behavior, as we spoke of, most consumer users will be price sensitive versus enterprise users will be quality sensitive, given the very complex requirements that they have and which we have to meet. In terms of the need flexibility, one might expect the consumer user to be a lot more flexible versus the enterprise user. Take the simple example of a phone. If a phone does not have a certain feature, customers are looking for 20 megapixel camera, but they find a great phone with 15 megapixel camera that might still satisfy their need. But when we are thinking about enterprise, most of those needs are going to be super rigid because it kind of impacts the business decisions that they take. Going into understanding the requirements of the builders and developers. So at a high level, we know that builders and developers are essentially building for the end users. Now, whether they are an enterprise user or a consumer user is less important for the builder. But what is important here is how are we enabling them to move faster? There are actually the seven different dimensions that I could come up with. I'm pretty sure there might be more. These have been fairly valuable for me across some of my previous roles. And those were basically as we build some of these tools to enable developers to do something for the end users. All these questions always came up. How easy is it to use the tool? Does it help us intuitively build products for the end users? Second is speed of development. Does using the tools or the product that we are supplying to the builders, does it significantly speed them up in getting to the end goal of catering to the users? Feature extensiveness. Does this tool actually support all the features that might be required by the end customers? Interoperability can be actually built across all the platforms and the stuff that we build work with our product variant on some other platform. Versioning, how are we looking at releasing new versions? Do we have backward compatibility and so on so that the builders always have access to some of the latest stuff? Troubleshooting, logging, and telemetry. Do we even provide visibility into the product health just in case the builders have to troubleshoot something, should something go wrong with the product or just get some analytics on what is going on with the health of the product so that they are able to dodge any upcoming issues, etc. And maintenance and support. Obviously, as we supply products to builders, they will always be required to have all the maintenance and support so that they can still cater to the end users. So basically, given that there might be very different needs for an enterprise user, a consumer user, and a builder, we know that the needs of whoever we are building for can be very, very different. So the first takeaway was we always have to, not always, but in most cases, it's helpful to rely on data for consumers, specifically because it's available and it is possible to get that when it's not available. So if you make data-driven decisions, we are always doing our best to make sure that we're mitigating any risks of our product failing and we are still catering to the best in the best possible way to what we know about the customers. For enterprise users, it is really important to pay attention to detail, understand them well, interview them, and build expertise around their processes so that we know what exactly we want to tailor to. For builders, one of the key takeaways is we have to leverage SMEs. For instance, if I were to build, going back to my previous example of the website builder, if I know what web designers want, I'm able to cater to them in a much better fashion. But if I'm a product manager and I do not have web design experience, it would be really important for me to leverage some of the subject matter experts within my company or even in the buyers company to make sure that I am able to identify the needs very effectively. So finally, once we know what are our needs, what are the user needs, we know more about the product complexity. I will not go much deeper into how we prioritize. There are a lot of great videos out there from product school and some PMing models and how we should be prioritizing SPMs. I will speak a bit more about how we build by the type of stakeholder management processes that we need to get into and how they might be different for either enterprise or consumer. So if you look at this table, one of the things I've written here specifically is stakeholder complexity can be very different from product complexity. And the reason I say that is for there might be more stakeholders in a particular situation. However, they might not have a lot of influence on your roadmap versus in another situation, you might have very few stakeholders, but they might have a lot of influence on your roadmap. One example is if you're building internal products. For example, I worked previously with Meta and some of the stuff I built was essentially tailored to some of the internal teams. Now what that means is as we cater to internal teams, we are all within the same organization. We have all very, very, very easy access to each other. So as I build out this roadmap, all the internal teams or stakeholders that I'm catering to at some point of time or the other, I'm going to run into a prioritization issue. I will have to decide I'm building for XYZ, which is required by some teams, but I'm not building for some other features which are required by some other teams. And what I mean by stakeholder complexity is all of these teams out there within my org or within my company will always have some safe or they will have access to me in determining what exactly I build. Now that is not the case if my stakeholders are external. Even if I were to build for an enterprise and my stakeholders are external, if I'm tailoring to five different customers and I'm able to think that, okay, I have the resources to build for three of them, I can still only build for three of them. The external customers, they are more than happy to whom I'm not building for, they might be more than happy to go sign up for some other product. So at a very high level, no one might expect that the complexity of stakeholders and stakeholder management that we deal with is going to be a lot more complex internally versus externally. And again, there might be certain products which are actually catering to both internal and external customers. In those cases, again, mostly depend on the maturity of the product and how complex the stakeholder management processes. For very, very mature product, you're going to be mainly dealing with external stakeholders because you would have already met the requirements of the internal ones. But for products who are just made it to market externally but have been working internally, those are going to be some of the most complex ones because you have to cater to all of the internal stakeholders and at the same time, you're getting into the external market where you are thinking about some external stakeholders. Also, the other part you might notice here is now consumers might be the consumer user, whenever you're building products for consumer users, the stakeholder complexity might be fairly low versus as you get into more of enterprise and builder space or complexity increases because you are dealing with stakeholders whom you are working more closely with. So how does this actually impact the velocity of delivery? Now, velocity of delivery might essentially be two things. So how fast can we move as we are building the product? So the more complex the product is, one might expect the longer it takes to build it. And at the same time, the more stakeholders we have to manage are not necessarily more but more complex relationships we have to manage. It might still take more time to arrive at a particular outcome. So at a very high level, this is going to be mainly a function of product complexity and stakeholder complexity. Now, as we might know, for consumer products, we can build very iteratively. We can start rolling out features or products in increments. We might not necessarily need to tailor to every particular need but we can start slow, test out the market through a beta and then decide how to keep building on top of it. So one might expect to be much faster in a consumer space versus enterprise or when we're building for other builders. Also, one might notice that as we are building internal products versus external products, we do have some flexibility on moving faster for our internal users versus external users. And that is mainly because as even as we start thinking through the requirements of our internal teams, in most cases, we are able to find workarounds for a lot of things that we might not necessarily be able to deliver. For instance, we build a great product which requires dashboarding. The dashboards that might be available internally might be a simple pull of data from the data warehouse. So there is a hacky way to get around it. But when we're thinking of building a full-fledged product externally, we have to actually start thinking through what does it take for us to build a data lake and get all the data that we need into that. How do we build on top of it to create analytics, etc. So the long tail of requirements will actually make it a lot more complex, making our velocity of delivery a lot slower when we're thinking externally. And that also changes as we start thinking about whether we're building a hardware product or a software product. As we know, hardware is a lot more expensive, development takes a lot of time. So it's always going to be a lot slower. So whatever key takeaways. So those were the key areas I wanted to talk about. But what can we actually get out of all of this? Number one was end users. Whether we are thinking about an enterprise product or a consumer product or maybe enterprise buyers or consumer buyers, it's really important for us to think about the end users. And basically enabling everyone else along the way, whether they're buyers or builders, to cater to these end users. So once we do that, we're actually creating value not only for us, but to the other stakeholders as well. User types. Basically, the second takeaway is that most customers or consumers are price sensitive. Enterprises are quality sensitive and will have more complex requirements. And finally, the builders who are some of the developers or other entities we work with might essentially require us to work closely with subject matter experts. Third takeaway is stakeholder complexity. In this case, internal stakeholders are a lot more complex. They do have a lot of influence on your roadmaps versus external ones. So that is something that we have to essentially take into account as we build products. External facing products will have a higher product complexity. That's because we have to go through all the requirements without thinking through a lot of hacky ways to get there, which we can potentially do for more of our internal customers. We have to meet a certain quality bar for our external customers, which makes it very, very complex. And finally, the velocity of delivery, which we know that how fast we can move will depend on how complex our product is and how effectively can we manage all the stakeholders in the process. So there are a few things I've not actually not spoken of in the velocity of delivery, which will be important such as, which is mainly going to be all related and whether you have all the resources, et cetera. But again, putting that aside as a denominator, that is kind of a derivative of the product complexity. So it is kind of implied in that. So that is all I have for today. I hope this was helpful. Please let me know if you have any questions. If you post a comment, I will be certain to respond to you. Again, I would also love your inputs. A lot of this stuff is mainly derived out of my experience, but I'm pretty sure your experience might also add a lot of value and have a lot of other inputs as well, which I would love to understand from you. So please add some comments. And thank you very much for signing in and listening to me. I hope you have a great rest of your day and thanks to Product School as well.