 Hello everyone. Welcome to my webinar for product school called when your customers have customers. My name is very right. I'm a group product manager at Spotify and I'm excited to be talking to you today about a topic that has been near and dear to a lot of my product management career. As mentioned, I'm currently a group product manager at Spotify and my career has spanned a few different iterations all kind of leading through the product management space that are relevant to today's topic which is related to B2B product management and the unique qualities that come to light in managing a B2B product management relationship. My experience begins in university. I went to Duke University, have a degree in mathematics where I spent a lot of time learning both mathematical research techniques which I did not want to continue my career in but also teaching techniques which have been really relevant to my product management approach over the past decade. In particular, thinking about how different people in the room are able to understand things how they take different information from how a single presentation might come across to a broad group and how to integrate different perspectives and different methodologies into getting ideas across whether that's in a one-on-one session or in a much larger context. I began my career technology at a company called Hawks Learning Systems. They do educational software primarily based in mathematics courseware which was the through line between my school experience and my first work experience. I started there as a textbook editor and eventually moved into product management. That's where I learned how to do my first product PRDs, my first testing experience, my first customer interviews and got a really interesting lens into B2B product management beginning here in selling software to large universities, large community college systems, organizations which have a lot of other end customers and a broad reach with the products that we were selling to them. Following that, I moved into the ad tech space. I wanted something that was a little faster paced that moved a little bit more quickly. Math has been kind of the same for the last few centuries although how people teach it changes quite a lot. Ad tech was a really exciting, volatile, changing space that really caught my interest and I joined a startup called Videology in the Baltimore area doing video advertising technology and stay with that group through an acquisition by a company called Moby. For almost 10 years spent time learning more individual product management skills as well as building product teams and here had another really formative experience in the B2B space in that we sold software both to advertising agencies who have individual customers and advertisers who have end customers themselves and also TV broadcasters who were selling advertising space to these agencies who sold services to advertisers who were trying to please their own end customers. So really long chain between us and the end customer which really informs a lot of the thinking that you'll see here today. And most recently I started working at Spotify where obviously Spotify puts forth a number of different products to a very large customer base but I actually work on a team who serves internal customers through a platform of Spotify and so now have a third lens on what it's like to have customers who have their own customers. And that is kind of the crux of the topics of today's talk as you can see in the bottom section here I also have a personal lens to my career trajectory and that I've been working in the improv comedy space for a long time and actually it's opened up a theater in the last year and that has brought a different lens to how I think about collaboration really thinking about how to listen to different perspectives in the room and how to incorporate everybody's ideas into a holistic picture for how we move forward with decision making. And you'll see that in some of the examples that we talked through for managing these complicated relationships that happen within the B2B space. So agenda for today really breaking this down into three pieces. The first is just this overarching concept that all roads lead to the customer. We'll talk about what that means or what it implies for what you do in a B2B product management situation. And then let's talk about two mental frameworks that they use for B2B product companies that I think can be helpful in different problems scenarios if you pull back and abstract what you're doing to these structural frameworks you can find often the source of tension or problems in how you're working with other teams or in how you're planning and delivering value. And then finally I talked about three specific techniques that manage the complexity of the B2B experience and how you can apply those to problems ranging from user interviews to road mapping to stakeholder management. Let's dive in. So the first thing I want to start with is whether you're in a B2C company making an application direct for consumers whether you're B2B or whether you're B2B to B2B to B2C or more all roads end up leading to the customer. The chain always ends with a C. There's no point in having B2B software if there's not somebody at the end of the day using it and getting value from it. And what creates a lot of complexity in the B2B space is really understanding where that chain goes and where it might branch off and how it's being considered because everybody along that chain has different goals motivations and strategy that ultimately lead to serving the end customer. And the complexity of everything from relationships to metrics to planning goes up exponentially when you have to consider the fact that your customers have customers themselves and those customers might even have their own customers, which creates a really, really complicated dynamic. But if you zoom back out and think at the end of the day who the end customer is, that can really drive a lot of clarity in how you think about product design and how you think about what every person in the room is really being measured against, which often can make something that seems very, very tense or very, very misaligned reveal an underlying theme or an underlying goal that we can all realign around. And the first framework that I'll introduce here is built off of the three horizons model. You'll see this in a lot of consulting presentations and it's usually presented with respect to the research and development aspect of a company and how you invest in products which are on the far horizon. They may potentially provide a large amount of future value, but they're speculative. Or you have things on the near horizon and sure products that are generating cash generating profit for a company that you want to invest and maintain in with the middle being these growth products that you've already got some traction towards, but you need to invest resources into actually scale. And we can think of a similar framework when considering the different stages of customers in a B2B customer relationship. So if you think of yourself as having a product software company or you're selling software to another business who has their end customers, that business is taking on your software to achieve some goal within their organization that ultimately motivated by whatever their business model is itself. And you can think of the relationship maturity between your company selling software and theirs as reflected by the degree of end customer focus. At the very onset, while there may be an initial spike of this in terms of why they're even looking to contract with you at all, the first horizon of a relationship between you and another company is a pipeline focus on pre-contract sales products. These are customers or potential customers who either in the RFP process, in the diligence process, they're out there looking for a solution to their problem and it might be you. And at that time, the focus is really on, will this be a fit for the business? Will the business be able to integrate the software? Will they be able to take on this project? Do they have the budget to do so? And there's a really high focus between the company selling software and the company buying the software and not a lot of immediate discussion or action that goes to what the end client is doing. There may be, of course, a strategic pitch or a vision for why this software might help the end customer or drive end customer metrics. But in this moment, there's a lot of project management. There's a lot of organizational discussions about how to actually try this software out. And it's very focused on the two businesses working together. After you get over that initial hump of signing the contracts, sending the first payments and actually, you know, maybe sending some credentials over to start working, we move into the second horizon of adoption where the onboarded clients are integrating this new software into their business. They're figuring out what it's like to use the software to do their own job to deliver value to their end clients. And at this point, we start to see a shift where some conversations are going to be really focused on how do I get this software to work? How do I log in? How do I get support if I need it? But more and more, you're going to start to see conversations shift to how do I use this software to derive end customer value? How do I justify bringing more teams on board of the software? How do I justify spending more of my time day in and day out using this product? What does it benefit me in my role as delivering value to the end customer? And then finally, we get to this third horizon of relationship maturity where if everything is going well, then the conversations between the two businesses in this B2B example start to realign almost entirely around end customer value. Is the product delivering good efficiency? Is it delivering good results? What can we do together to change processes or to introduce new features that turn into end customer value? If you hit this point, you get a really, really great team relationship that is focused on just doing better work and you really gain stickiness, you really gain stability in this relationship because both companies are getting what they want out of the situation. The other framework I'll introduce is actually around the three stages of a B2B products company growth. And as you can see on the screen, they're pretty straightforward. They will revolve around how many different customers you have. This is a problem for platform businesses and for general B2B companies in that there are two pretty difficult transitions between your first customer to several customers and from several customers to many customers. I always tell people the easiest thing to do as a product manager is have one customer because you can succeed pretty effectively by just listening to what they do, what they ask for. It's not maybe the best way to build software, but it is an effective one to maintain a relationship and grow the company. And it works for a time, but eventually if you're successful with one customer, you'll have more than one. You'll have several customers who all kind of feel like you're their number one concern and they all act like they're the one customer in the first example. And that is really, really hard to deal with. I'll come back to that in a second because once you make the leap to many customers, things actually get a little bit easier. You have diversified revenue streams and so if one client is being particularly demanding and you can't have the resources to cater to their every whim, you can afford to let them languish in the priority queue. And if they leave, you have 45 other customers to make up the slack. And in fact, you're probably growing those customers. You also have the opportunity to more easily segment your customers into manageable groups. Whereas with several customers, you may have seven different clients that all sort of feel like the same but have their own unique differences and that creates a lot of switching costs and mental complexity in figuring out what to do next because it doesn't really line up in any really obvious meaningful groups because there's not enough data. There's not enough similarity among different customer groups to make any heads or tails of it. And so thinking about where you are in this journey can really inform how you act as a product manager and we'll see that come through in a couple of the different techniques that we'll talk about in a few moments. But it's really just important to step back and assess where you are as a company. Are you at one customer? Are you at several or are you at many? And think about what that implies for how your sales team thinks, how your marketing team thinks, how your engineers have to deal with support requests and new features and how you are assessing the market and growth opportunities. So the first technique I'll talk about is customer and stakeholder mapping. This is particularly challenging in the world of B2B2B to see customer groups. The longer this chain gets, the more complexity is introduced. And it's represented by the diagram that you kind of see on the screen here where we have the major stakeholders, your software company, the client you're selling software to and the end client they're delivering value to hopefully. But you can imagine this chain extending if necessary. And within each company you have different stakeholder groups. And we all have internal working models to our own organizations. There's a lot been written about stakeholder management. And there are a lot of great techniques for how you keep different groups of people aligned, especially in a product management context. But when multiple companies get involved, several new problems come up that make this work exponentially more difficult and can lead to really what feels like good work actually producing bad or misaligned results. And the obvious challenge from this diagram here is there are really pretty standard processes for each company. Each individual company communicating among its different functions. Your software company has a support team, a sales team, a project management team, an engineering team. And you know who to talk to. And there are probably pretty well-established ways of working among those different groups. And that's going to be true of your client and going to be true of your end client as well. And there's also a pretty well-worn pathway from software company to client and from client to end client. There are account managers. There are project managers who have weekly meetings and QBRs and all these different ceremonies to exchange information. But those lines don't really connect with the individual team lines that you see in this diagram. And that can cause a few problems to have. The first is what I describe as the bloated telephone where you have really effectively two large meetings in this structure. One between all of the teams at the software company and most of the teams at the client. And then a separate one between some of the teams at the client and all the teams at the end client. And you have two really big expensive meetings, disconnected project teams. And a lot can get lost in translation, both internal to each meeting represented in the red and blue circles here. Both because there are so many teams involved. There's so much to get through that everything has to be really written down in the lowest common denominator if we're going to get through everything in 30 minutes or 60 minutes. And then because there's such a big communication gap between the red meeting and the blue meeting, only what is absorbed by the person in the room who's having that transition call is going to make it to the next meeting and vice versa. And this can lead to what feels like a really effective relationship between the software company and the client, the B2B situation. But that turns out after two or three quarters, it's not actually delivering the results that the client bought the software for. And that can be really surprising. It can lead to the client switching software frequently and it can lead to a lot of churn for you as the software company product manager. The second version of this, which a lot of organizations end up in is they recognize the challenge of not meeting with the end customer. But they fail to put in enough structure to coordinate work streams. So they end up with these siloed work streams where the engineers and the engineers are all talking to each other. They have good working relationship. The sales teams are all meeting together to make sure that we're talking about the right things to deliver to the end client. Maybe have operations and support working together in a shared Slack channel or through a shared ticketing system. And so you've established these good functional working relationships, but you haven't invested in understanding the impact back to the individual organizations. This can cause another set of misalignment where each team thinks they have control of the relationship or the overall roadmap for the project. And then when they come back internally, they find everybody wants to do something a little bit different. And then the internal machinery within the organization works. And maybe it doesn't spit out the same result at the software company and the client and the end client. They try and bring that back and you just have a cycle of negotiation that doesn't end up going anywhere. So this is also another problem. And further, there's so many important conversations that really do need multiple functions in the room. If sales is just talking to sales, you're going to get a lot of really interesting features that are generated and not a lot of assessment about whether those are realistic to build in a certain timeframe. And so the model I like to encourage people to consider is what I describe as aligned flywheels where you have both the work stream and the functional based communication on a more informal, more frequent basis to work through the day to day aspects of using the product or selling the product. Or building the product. But there are regular syncs that happen consistently across the different members of this value chain software company and the client and the end client. So that a small group of people at each organization can come together and talk about the problems that they're having and what each of their experts has brought to the table. And they can easily and with context importantly bring that back out to the individual organizations. And I find this works really well when each organization brings a product manager who's focused on the market and kind of has the same connections internally. And a program manager or project manager depending on what your organization calls them to help align the project planning and the organizational, you know, management of all of these different functions together. The second technique is to consider metrics in particular product metrics by the customer motivation and these map to the stages we talked about in the first framework. If we think about what customers need while they're in pipeline, while they're in the adoption phase and whether in the performance phase, they're very different and they're very different things to measure. So if I think about a customer who is in pipeline, they are thinking about buying a new software that they're going to integrate into their business. And that's a pretty scary proposition. That's often a very expensive decision. It's one that comes with a lot of political risk. And it's also one that has a lot of uncertainty compared to improving an existing process or trying out a new sales model potentially. And so what they want to do in that stage is to de-risk the purchase, ensure that they can integrate smoothly, and they also want to have the tools to sell that new concept internally. And so as a product manager, I want to be thinking about things like what's my level of engagement in the test environment? What's my time to activation? What are my lead conversion metrics? What are these leading indicators that will tell me that the pipeline stage is going smoothly and that can tell me whether I need to invest further in making onboarding easier, making testing easier, making demonstrating the software to internal teams easier to get more people into the system? For clients that have moved on to the adoption phase, they're talking about figuring out how to make that product part of their business as usual. They're creating stickiness via process adoption at various teams in their organization, and they're trying to remove questions and barriers to continue to use because they want this product to be successful. So here I'm looking at what are the metrics that are demonstrating that things are getting easier for the client and things are getting ready to scale? That could be integration support tickets dying down, going from rapid pace during the integration phase down to zero. That could be measuring how long does it take each customer to launch their first whatever it is that you do, whether that's an advertising campaign or a cloud computing instance, or a sale of a product on an e-commerce site? How long does it take to get those first one out? How long does it take to get the 100th one out? How long does it take to get the first active user and the 10th active user? All these things can kind of give you a sense of the shape of adoption. Often we can get misled by the first thing that happens because they have some advocate at the company who's really excited to use this product. I think a more effective tool is to understand the fifth user or the 10th sale or the 10th sale from a unique sales person. That's going to tell you when something's really caught on and when you've achieved kind of a fit within that organization. Then finally, for customers that are in this performance stage, the conceptual goals shift to end customers almost entirely, delivering value, maintaining stability, and then opening up avenues to demonstrate potential new value and grow the business. Here, again, depending on what your software does, you should be thinking about things like cost for end customer action, clients, sales growth, and even simple operational things like how often are people copying the workflow that they used for a successful sale? And that people copying a particular campaign or a particular instance of how something was set up. That can really tell you things are coming along, things are working, and people are just using the software to execute. Finally, the third technique, which is near and dear to my heart, is to invest in configuration to deliver a customized experience. One of the really, really difficult things, especially as you transition from one customer to several. And if you're not careful from several to many is that each customer wants a slightly different version of the product. They talk about that as a custom product, but really, you don't have the resources or the time to manage 50 custom products. Unless you are a consulting firm and you're getting paid by the hour, which gives more power to you, you need to invest in tools that help you scale what feels like a custom experience. The two biggest tools in my view for this are investing in strong permissions and admin workflows and investing in onboarding workflows and products. On the left hand version of the diagram, you can see kind of what happens if everybody asks for things on their own, you get a lot of one off features that maybe only one or two clients use. And you have a lot of confusion in terms of how you segment customers and market to them because each experience has been bespoke. Each journey to a particular configuration of the product or even customization of the product can be very, very complicated and hard to untangle. But if you invest ahead of time in saying, hey, we're going to turn these features into configuration tools that were exposed to our clients, then you start to see things in terms of sets of features that can be turned on and off and combinations of features that can be packaged and sold. And if you have that in place, you can take four or five different features and combine them into a much broader set of use cases if you so choose. This is a simple exponential scale problem where if I have two features independently controlled, that's four versions of the product, four features to 16 versions of the product and eight features to 256 versions of the product. And that can start to really feel like something that was tailored to me. And alongside this, the complexity of managing those eight different switches is very different than 256 versions of the product. What you see in an organization that gets stuck on a custom software loop is overhead scales linearly and sometimes super linearly because of challenges with writing contracts and training operations teams and training sales teams to do what normally would be single elements in an onboarding manual or the work that a sales engineer would do to customize the experience of a product based on a set of pre-built configuration options. And so you need to think about what time in my product's life cycle, what time in my company's life cycle is it right to invest in these tools? You don't have to do it right at the beginning with one customer, but pretty soon you should start to be thinking about how you can build feature flagging, how you can build permissions and add in workflows, and how you can build self-serve onboarding workflows that help people add logos or UI white labeling or load their data from another system so that you don't have to be doing this every single time you bring on a new customer and you don't have to be rethinking what your product packaging is every time somebody asks for something new. All right. So in summary, we've talked about a few different concepts here. We've talked about how in B2B product management, really everything ends up leading to the end customer. And if you ever get stuck, the way to think about what everybody in the room is thinking about is to go back to the end customer and see what the value they're supposed to be getting is. We talked about two frameworks for B2B product companies. One is based in the level of maturity of the client relationship and how that changes from focusing on how do I get the software on board to how do I scale the value that it's providing to my end customers. And then we talked about three techniques to manage the complexity of all of these stakeholders and all of these people involved in a B2B to C company experience that includes stakeholder and customer mapping that includes looking at how different metrics come into play as companies evolve and clients evolve and it looks at how do we use customization techniques and configuration techniques to build and create a custom experience at scale. Thank you for listening. I really enjoyed talking about this today. If you have any questions, please do reach out. You can reach me on LinkedIn or via email and looking forward to continuing the discussion. Thank you.