 Hi everyone, welcome to the Product School webinar today. Yeah, covering external PM versus internal PM. My name is Kirsten Bandetta and I have been in product for almost nine years, nine-ish years, almost a decade. Most recently at LinkedIn as a senior product manager and then a group PM. And in the time that I've worked in product, I've had the opportunity to work on several different products in lots of different spaces. And a lot of those products have fallen into two categories. Some of them the same type of product, but I've spent a lot of time in external B2B, B2B to C, and then also as an internal product manager. So that's what we're going to focus on today is the differences, the similarities and the specializations between these two types of PMs, internal and external. And one of the things that I want to acknowledge and call out before we get too far is, first of all, there are different types of external product managers as well. We're not going to dig into those. So B2C versus B2B, there's lots of content out there. Product School has you covered. Please check out any webinars. I think I have one on my LinkedIn as well. Also, I have lived and breathed, I'm doing a breathing. I have lived and breathed B2B and B2B to C technology products. So the examples and the experience that I bring to you today is through that lens. I know the products community, we are full of learners and shares. And so if you have something to share, you've had a different experience. I absolutely leave some comments would love to learn from you as well. And lastly, I'm not going to give you any real details. So we will be talking about no real people and no real situations. But the stories and the lessons that I'm trying to drive home, I can still do with some modifications names to protect the innocent. So the first thing I want to start with is so Marty Kagan, pretty popular guy in the product space over at Silicon Valley product group. He has a couple of books you might have heard of empowered and inspired. And one of the things that he says that I absolutely agree with is that a product, a successful product. And again, I'm looking through the technology lens. So successful technology product requires solving for the customer, your business and technology. And so what that means is as a product manager, let's say your product organization is super customer centric and you have all the best tech. But everything you roll out doesn't drive towards your mission, your brand or revenue monetization for your business. And you have great products, but it's not a successful product for your business because it's not driving the value that your business needs. So these three things are very important in a successful product. So that's the first thing product managers are driving successful products across those three areas. The other thing that Marty says is that out of and you've probably heard this a product that is product managers work on products that are valuable, usable, feasible and viable. And specifically Marty says that product managers are responsible, absolutely responsible for valuable and viable. Now when we talk through those three, sorry, those four things, excuse me, the value risk is will customers buy this? Will users use it? Like is this solving someone's problem helping them get a job done or framework to use? The usability risk is can users figure out how to use it? Can they use it well? The UX and your design teams usually mitigate that particular risk. There's the feasibility risk which is technologically feasible. So can we within our time, our skill sets, technology available to us, all of our constraints, can we produce a valuable, viable, unusable product or solution for our customers? Hopefully without creating a lot of technical debt. And then business viability is really important. One of the most important for product managers is this is viable for our business? Is this going to support all the areas of our business? I guess not support, support's probably not the right word, but does it drive towards our revenue, our growth, our brand, our mission? Does it do something for our business and drive value? I don't know why I can't breathe. So let's talk about the similarities between these two types of PMs. And the first one is soft skills. Now I've broken a cardinal rule with the slide deck and I put a massive amount of text on here. So sorry, but as a takeaway for you because you will get these slides, I want you to see what the similarities are. So in soft skills, I could have listed a hundred more. These are some of the key soft skills that product managers have to have, whether you're internal or external. So key is being able to accept feedback or criticism, right? Your product is not your baby. Your product is your customer solution. And so can you accept feedback? Are you adaptable? Do you have high emotional intelligence? So you understand how to read a room, negotiate a room, move people into alignment. So soft skills, super important, 100% transferable between the two roles. And I would say entirely all of them are required for both. For hard skills, the only exception here is it's an exception for every type of PM, whether you're one of the multi types of external or not, really depends on the context of your role, whether or not you need to actually understand, do you need a fundamental level of knowledge about an API or how APIs work or if you actually need something a little bit deeper because the tool that you're working on or the product that you're working on is highly technical and you need to be highly technical in order to understand the discussion. So it can vary, but these also can be either or. So these are also highly transferable. There are product skills in here as well that are super important. So product requirements, creating strategic road maps, understanding how quality assurance works and how important it is for your product. And most of all, really understanding how you use data. Are you data informed? Are you data driven? How are you making your decisions? Hopefully not just by your gut feeling. The last thing that's really, really similar between these two types of PMs is how you work. Now, I put a big asterisk on this because you can have an external PM role that is absolutely just a backlog jockey, a backlog jockey. And is, um, uh, Wait. Oh, I saw, I thought I saw something pop up. So sorry. Um, so, uh, is, where was I? You guys, I can't remember. Uh, so absolutely, uh, you can have an external PM that is a backlog jockey. That is a feature factory that is not making decisions. Just ferrying the backlog through the work that is just crunching bucks or whatever it is. That's not very product. Um, or you can have an internal product manager that sits within the product org that runs highly autonomous and powered teams. So the context with which we talk about this, let's put that aside and pretend everybody has a perfect, perfect, they're all reported into the product or they're all seen as product managers. And this is a perfect setup. And they're all product led. Um, so frameworks and methodologies also very similar between the two. So jobs to be done, for example, you can combine jobs to be done and outcome driven, uh, innovation along with continuous discovery. Um, Moscow method of North Star framework and work in agile scrum, uh, as either an internal or external PM. Some of these methodologies and frameworks are really specific, though, to external PM. So we can start to see that we're, we're starting to take the similarities and we're splitting out just a little bit. So how are they different if we have so many things that are so similar? How are we, um, how are these roles really driving value differently for a business? So let's take a tale of two surgeons. We have a heart surgeon and a brain surgeon, and both of them have been through medical school. Both of them could help you with standard medical care. They understand, um, medical practice, surgical procedures, operating procedures, post-op procedures. Could they both help you in a medical emergency? Absolutely. But their specializations are important enough distinction to say that without upskilling in the other specialization, you might not want to really use these two surgeons interchangeably. The hospital would not send a heart surgeon to do your brain surgery unless he's been trained to do so. And so internal PMs and external PMs are very similar in this manner in that you have a specialization and that specialization sits within your differences. So let's talk about what those are. So first of all, the difference in your focus as an internal PM, you are solving your organization's problems so that they can best serve the customer. So if I'm solving a business problem, I might be creating an internal ticketing system. That system could also be front-facing to customers, and then you're actually kind of both, but let's put that over on the side. Focus on internal PM cursing. So if we look at 37 signals, you may or may not know 37 signals, but in 1999, they were a design firm. And as their clients held grew and their projects grew, they needed a way to really manage their projects. When they evaluated the systems and the applications that were off the shelf in the market at the time, they just were not meeting their needs. So what did they do? They built an in-house project management system that was just for their business to use. Excuse me, from scratch. Now whether they had an official internal PM at the time, that I don't know. But the product itself is definitely what an internal PM would work on. Now on an external PM, your responsibility, your focus is to solve customer problems, external customer problems that can drive value for the business. So you sell these, or maybe you offer them up and it contributes to your brand or your mission. But your focus is external. You are focused out on customers, not internal needs. So an example of this is Basecamp. Now if you know 37 signals, you also know Basecamp. Because Basecamp is actually the project management tool. 37 signals built and then took to market. So it was so good. Their clients are like, this is awesome. Can we please have this too? They pivoted from design firm to a product line of project management, application and software, and away they went. Now do all internal products turn into external, sellable products? No. But some of them are meant really, really specifically for one business. But sometimes you do find something that you can really harvest and sell out and add as a product line. So internal PMs are super important in that way. So that's one example. Now the customers, there's another difference is who are your customers? And an internal PM, your customers are internal users. So employees, contractors, partners. So Satya works at Microsoft and maybe he needs to run some reports. And he has a special tool internal PMs have built just for him to use. And just for the executive team, let's say. Now on the flip side, I happen to know that Microsoft eats their own dog food. So there's a very good chance Satya actually leverages Power BI for all of his executive dashboard. But if we're talking about external PMs at Microsoft, an external PM might work on Dynamics 365 and sell it to customers. So Dynamics 365 customers consist of Chipotle, L'Oreal, Doc Martens, Gibson guitars. Now Chipotle would have bought Dynamics 365 from Microsoft for maybe the COO is purchasing that for overall operations. And the corporate strategy team is using Dynamics 365 for managing their CRM relationships. So in these two examples, one, I am building only for Satya. Two, I am building to sell a product for Satya's business. So for Microsoft. And that means that the individuals or businesses that purchase my product are my customers. Now the stakeholders, the difference for stakeholders. If you look at these two lists, they're very similar. They're similar because you have the same stakeholders and a lot of you might not have the exact same person, but you will have a stakeholder that's in senior leadership, let's say in each of these roles. And you have a couple more on the external side. The difference is not in who it's more than how and the why. Because on the external PM side, when you're going to solve a customer problem, you're talking about a pricing strategy, how you're going to launch it to market, how you expect sales to sell it, operations to support it, deliver it, support it, to support it. Your stakeholders are going to have ideas, requests, they're going to have a lot of input. They may even have some requirements. They're asking you, your operations stakeholder could say, hey, super cool products and all, but I just noticed that if you deliver this, it's going to take me eight weeks to ramp every single client on this. How can we take this down a notch? But you absolutely can get some requirements from your internal stakeholders and your external stakeholders as an external PM. Internal PM is a little bit different. You're going to get all the same stuff, ideas, requests and input. But you're solving for the business. Who knows how the business runs better than the business? Hopefully you like you eventually have to know how it runs better than they do. But they know a lot and there's nothing wrong with that. And they will bring any requirements. You still have to negotiate what's going to be best for the business in the long term and not the short term and make it scalable. But they will absolutely come with requirements. It's just a different part in the way that you manage stakeholders. The last big difference I'm going to cover here. Then we're going to go into some of the challenges and the gaps in case you are thinking about pivoting from one to the other. Or you really are starting your product journey and you're not sure which one to start with. So the last one is measuring. There are more differences but these are the top four that I picked. So when you're looking at measuring success between these two products. Now think about it, right? Let's say let's use a non-product example or not my experience. So your grandfather is a chef. He's a home chef. He cooks amazing meals. Maybe he makes the best tacos in the world. He's memorized your family, your neighbors, everybody's needs. He knows whether you're gluten free, you're dairy free. What your favorite kind of taco is. You appreciate the vegetarian tacos versus like, give me that carne asada. He's the best and he cooks and everybody's happy and everybody's well fed and meals run like a well oiled machine at home. He decides he wants to open a taco truck. That is an entirely different proposition taking all of his cooking skills and his knowledge and putting it out into the market and trying to sell it. So same thing here when we're talking about how to tell us something successful whether we're internal or external. The metrics that we measure are going to be a little bit different. So I don't, for internal PM, I don't count acquisition. I'm not acquiring, could I take an external metric and try to shove it into an internal scenario? Yes, but it doesn't mean the same thing. So I try to avoid that. So, you know, I'm not looking at user acquisition. I'm not building a premium funnel to try to convert people from free to paid. I need to know how long it takes an onboard user to actually activate and use my product. I need to know am I saving the company costs by driving everyone to an internal central events management platform versus everybody swiping their card and using six different ones and having no centralized events data for our sales, marketing and HR teams, right? So there's a very, very big difference between internal and external measurements of success because on the internal side, you're driving productivity, time saved, costs saved. Am I making my employees faster, better, stronger, more productive, working smarter, getting the customers faster in the right time in the best way? Like those are the things you focus on on the internal side. In the external side, you're focusing on how do you get this product out into the market? How does it fit? How can you sell more of it? You are not processing all of the change management and how people do things once they buy your product. You can and some companies do differentiate that way, but it's not really what drives it. One last comment on here. I do have revenue per employee on the internal PM side for a measurement. It's a really broad one and hard to attribute to one single thing, but companies do look at that as an overall marker for productivity. So if your internal PM team is doing really well and delivering successful products to the business and making the business operate more efficiently, then revenue per employee should go up. It should be a good number that people want to see. All right. Sorry, I talk really fast when I'm excited about stuff. So how do I pivot from one to the other? Or if you're aspiring PM, which one should I go for? Before we get too far into this, I just want to say to all of the aspiring PMs who are currently sitting in a specialized role within their company. So maybe you're a business analyst, a project manager, your sales, your marketing, whatever that might be. Internal PM may look like the easier route to go, and it often is. For example, HubSpot actually takes their APMs directly from their pool of current employees because they know that the domain knowledge is one piece, but training up as the product manager is the other. And just like consultancy firms, they want to train you to do product the way they do product. So it is possible to come into APM rotations for internal and external roles, but if you're a BA or a project manager, I think it's probably easier to get into an internal. Like I said earlier, I started external, but I have mentored, well, I don't know, a couple hundred maybe, product managers. And those folks do generally tend to see it being easier to get into internal. But let's talk about the differences and challenges because the only thing about these two is which one do you want to do? So let's talk about what you need to know to be an internal PM, a great one. To be a great internal PM, you need deep business analysis skills. If you don't do the analysis, someone needs to do it for you, but you still need to know what you're asking. So you need to know processes. How do we do things today? People, who are sponsoring us operating this way? If you don't report up through product, for example, and maybe marketing has spun up their own product team so that you can build all their marketing tools for them, can kind of make it hard to operate in a long-term scalable way because the people that you answer to are the same people requesting something from you. So you need to really understand where you sit in the people space, who the key decision makers are, who your cross-functional teams are, stakeholders, et cetera. For programs, this might seem weird, but you actually do need to know the different business initiatives that are in place. The reason for that is you may get hired to build events management, and there might be two programs already running with two vendor tools that have been purchased by two different teams. Obviously, I'm talking about large companies here, but that could also be in a smaller team where people are swiping credit cards. So you need to understand the programs that are already in place. The projects that are in place are really important. IT works separate from you. You are not IT as an internal product manager. IT might be rolling out different collaboration tools to everybody. If you're building something that conflicts with that or competes with that, and you're working on the team, you really absolutely have to know what other projects are going on, what vendor relationships are going on, and how that vendor management is going to work out and integrate with what you're building. The other things, three other things you need to know, products. What does the product ecosystem look like internally? What is everybody using now? Even if you got hired to just focus on a person, you still need to understand what everybody is using in that context, what their whole ecosystem is, because you certainly don't want to spend time building something that is mimicking another product they already have. Why? That's expensive. They might not know when to use which one, and at some point something is going to get sunset, because it's going to confuse them. Performance. So you are not doing competitive analysis, if I'm building an events tool internally I am not trying to compete with Eventbrite, that's not the point, because that external product manager working on Eventbrite is trying to make it so that many different customers and types can use it. What I mean by performance for internal product managers is are you performing as well as the market leaders when it comes to things like, let's say it's a CRM platform, how fast is your data loading? How fast is your reporting platform? Are people spinning for two minutes and you're just like, well, that's how that works? When platforms that they worked on at other companies run much, much faster from these other vendors. You do need to understand at least somewhat of what's expected at the market, the bare minimum for what for users are expecting. The last one here is productivity because your main responsibility is going to be how do we work for our smarter, more beautiful. How efficient are we now? Where does it hurt? What do we need to accelerate? Maybe we need to take something out. Maybe there's too much going back to the duplication. Maybe there are too many products in here duplicating each other. Those are really the seven things. These other ones, I'm not going to spend too much time on them. Again, I made these slides for you to take away, so I apologize that they're not prettier. These are also important internal metrics. There's a very different strategy to go to market internally versus go to market externally. That's something that you need to understand. You need to understand that you are a manager of change. Yes, you are with external product as well, but external product you are selling and not necessarily delivering. I mean, you do and you don't. If you sell a CRM platform, the people that buy that from you are ultimately responsible for making that work well with their business. You are not. If you're doing internal, you are responsible for making it work well with their business while also building it. So change management is important. Potentially leading digital transformations is important. I will add here that I have avoid ruinous empathy with your users and stakeholders. That is because you get to work with them all the time. You can have a lunch with them if you want. It's really important that apparently I have to pick up Alex because it's very important that I lost my train of thought that you don't placate your users. You can end up being friends and they can be like could you just fix this one thing? Your job is to make sure that the business can scale on what you build and not that you're making individuals happy. So bringing the data, it's fine if what they've asked for matches with the data. That's great, but otherwise it's important to avoid this. All right. External PM specialization. So this is very different. Taking a CRM to market is very different than taking a CRM to your internal customers. You have to understand competitive analysis. You need to be able to do market research and understand what that even means. What are the market dynamics? How do those apply to my products? You have to watch the macro. You have to look at industry trends. Understand product strategies, growth strategies. Your go-to-market and launch strategies are going to be so so different that that's a pretty big gap. When you're talking about build versus buy versus partner internally, that essentially is are we going to buy something? So you're just vendor essentially and you're deciding which one. Build by partner externally is do I want to build it? Do I want to buy it and white label it and add it in and then try to figure out what those margins are? Do I want to partner? And if I partner is this going to be a great go-to-market for the both of us to say, hey, we're friends now like you guys want to come and buy our products together because they're really powerful together. Very, very different than doing that internally. Product positioning you do that internally, but again very different in how an external PM has to approach it and pricing strategies you don't touch. The only time you're going to touch pricing strategies as an internal PM is if you're actually helping the pricing team or the product team implements pricing strategies, but you yourself are not pricing out your product working with external stakeholders, understanding sales cycles. I do want to add one more thing here with the external product metrics. I apologize that I'm talking fast. When you look at product metrics like customer lifetime value I know that it's tempting if you work an internal product it's tempting to take these external ones and try to mold them into working for internal. They don't mean the same thing it's not the same value so if you are flipping from internal to external you can learn all about the external ones and figure out when you should use them. If you're flipping from external to internal we'll talk about that a little bit but it's really tough to like walk away from all the metrics you used to use because then suddenly realize like oh that doesn't mean the same thing in internal the business doesn't care. They just want to know or be moving better faster stronger making more money because you're saving us costs. Okay challenges I'm going to go time it over like maybe five minutes so I hang in there with me but for external PM to internal PM challenges going from external to internal one thing that you will need to be mindful of it depends on your context but you may have to onboard the business to a product mindset from a project mindset so what does that mean? That means if the business is used to bringing requirements and you process them and you spit it back out that's really project based so we're going to take this we're going to solve this problem we deliver it we move on to the next problem we're going to take this project we're going to and what really happens in a project mindset is you spend more time data gathering gathering information but then you do in the innovation piece and you do a lot of that gathering up front so that's not to say information gathering means you're not product or anything like that but there is a very big difference between working in a project mindset and working in a product mindset and that can be tough to grant one other thing on here organizational dynamics are given but it is a little bit different when you go into internal PM but I do want to know that I put users are very accessible as a challenge that is because when you operate as an external PM you operate a lot of ambiguity and you don't always have the data and you have to place some bets you have a little bit more risk and when you're innovating you're putting something out in the market you're experimenting you're trying to hear back and see what happens users are super accessible in internal PM roles a lot of times you're not lacking any information you may have exactly what everybody wants and needs, you have why, you have the outcomes and so because they're so accessible a lot of times you again end up up front collecting all of the information versus what you would do as an external product manager which is take the base of what you need and do some experimentation and roll with it so a little bit different I'd like to call out HubSpot so I think one of the really important things the differences between internal and external PM is that it's not necessarily that your specializations are different that is very important but how you get to operate is based on how your company perceives how you should operate and this goes for both external or internal you can both end up being feature factory backlog jockeys or you can both end up being highly autonomous reporting up through the product or being product led and I don't put a pen in the text well it's a different interpretation of product led I don't want to get in trouble but having a product mindset and so HubSpot is great they just actually released this article a little bit ago on their blog talking about how their internal product teams fuel their sales growth I thought that was great to just show you there are companies out there that are building their internal products with as much fervor and product mindset as they are with their external and it makes all the difference in how they run for internal PM to external PM a couple of things here one because the internal PM has got you know let's say like a 20% gap in skill set you know we walk through all of those gaps interviewing can be a little bit tougher because you're going to get questions like pricing strategy competitive analysis how do you build a strategic roadmap against a competitor it's not really stuff that you do as an internal PM and so it's a skill set you have a practice maybe in a while and so there's a potential for down leveling when you interview there's also a potential to not make it through an interview so if you're a senior product manager as an internal and you go for a B to C expect it to go down at least a few levels to either a product manager or an APM because the job just is really really that different if you're going B to B you may keep the senior product role and they give you a six month ramp to try to understand how they work externally but there are a lot of external PM skills that you'll have to ramp on also users are not as accessible and external so it's something that you have to get used to you have to get used to not having as much information so I will wrap with this and turn and by the way thank you for entering my very fast speech I'm very sorry but internal PM versus external PM there's there's not one that's better than the other many organizations need both really to drive and deliver competitive advantages from all angles that I mean you can see it in the market today companies are in a year of efficiency and trying to get more out of less and you know internal PM's can do that bringing together all of the different tool sets that they need and build products that do something that maybe they're off the shelf product just isn't delivering the value that they need they are specialized roles however so that I this isn't official but I'm going to say it uses about 80% of the same skill set roughly lots of transferable skills in there but when you talk about that 20% I mean it is it's the difference between a brain surgeon and a heart surgeon could you do it in a pinch sure but it is a really distinct role both of them are very distinct roles and that 20% makes a difference and so if you want to pivot between the two understanding what your gaps are and how to fill them is the most important thing so I hope that helps you guys understand a little bit about internal versus external if you want to chat more about it you can reach me on LinkedIn or you know grab some time with me on kriya and happy to answer any other questions that you have but thank you so much for attending today