Defining the right pricing for SaaS products - with Markus Hafellner @Bitmovin

Welcome to the Product Bakery Podcast. I'm Christian and I'm today here with my co-host Alex as well as a lovely guest from Vienna, Markus Haffelner. Hi Markus, lovely to have you here with us tonight. So it's my pleasure to introduce you to the audience today. So you are a product leader in the software as a service space and you're actually around since quite some time, I would say almost early 2000s and you went through a couple of different roles also in your career. I think this is something that we've also seen quite a lot like in the product space that's not always a very one-directional way. So I've seen you worked like in research and development, you worked like as a developer, even as a CTO and you at one point founded your own company and now you're working as a product manager at Bitmoving. So yeah, maybe you can just share a little bit like what Bitmoving is about and what you do on your day-to-day basis. Sure, yeah. Thanks for the quick intro. Maybe to Bitmoving, as you mentioned, what we basically do as a company and we are still a very young company, I would say. So we are currently in a scale-up phase and what we generally do is we provide a cloud agnostic encoding solution that helps media companies prepare their content. So what this essentially means is that whenever you see something or stream something on Netflix, YouTube, or something like Hulu, it means that this content piece or this video has been prepared by a provider like us to be able to stream it with an adaptive bitrate ladder for specific devices, make sure we consider different network conditions and so on. And taking that off the load of the providers like Netflix and Hulu is basically what we do with our encoding solution. We also have other products to complement the stack. So we also have player and analytics products that help our customers also to play out and analyze if something is going wrong. But I'm mostly focused on the encoding product of Bitmoving. Sounds like a pretty important space, actually, now that everything is moving more and more into the Netflix space. Since when are you around as a company? So the company started in 2012. That was basically when the two founders together, as they worked on formulating Dash, that is one of the standards that is used for adaptive streaming in Klagenfurt together on their PhD thesis. And together with that, then during their PhD, they started the company. And really the first product and still also our biggest product is the encoding product, where they really took the experience from their PhD from the definition of Dash and applied it to a company and founded it and had the first customers build their knowledge up to provide the best services there. And from the beginning, it was always a B2B company that was focused on mostly enterprise customers, but also with making sure that they provide a good service for developers. So the user persona was always people that work for platforms like Netflix or YouTube and want to change out the encoding part of their solution, make it as easy as possible for them to integrate that. So you really tried also to target the users and not necessarily who is like the deciders above, especially on an enterprise level of who would use the tool or buy the tool? Yeah, I think there, especially also at the beginning, there was a big focus on the user, definitely. So it was because our founders, Stefan and Christopher, they both come from the, like our developers and they come from that space. And so for them, it was very important to build out a solution that is easy to use for developers. So from the beginning, they said, okay, we want to focus on the user. We want to go user first because we want to make it in the community also provide a tool that is easy to use for the people that interact with it. Yeah. Cool. Yeah. Makes a lot of sense. Markus, I remember last time we talked, we had a quick conversation also about some pricing changes that you introduced, like to the overall product. And I think pricing obviously is a very important topic, especially when you talk about software as a service and you have like users who are regularly using the product or getting used to it. Maybe like from a pure product perspective, can you share a little bit about how you tackled the whole issue? Yeah, sure. I think one thing that is important to remember here, and this kind of ties back to the user focus that I mentioned before is that in the early stages, Bitmoving really concentrated on making the barrier of entry as low as possible. So there were different self-service plans that started from about $150 per month, making sure that even small companies can really start using it. There was a free trial for everyone to use, experiment, a lot of documentation around that to make sure that users have a nice onboarding experience and really can get started quickly. But I think especially when then growing as a company and exploring that space and also the market more, there we saw that basically this part of the users of the market, while they generate a lot of usage and they try out a lot and want to explore it, we saw that the big blocker mostly is that people know a lot about development, but know very little about video development most of the time. So there you have to do a lot of education about what, if we provide the tools and SDKs and APIs to configure an encoding, you still have to make sure that people understand what is an encoding, what codecs do we have, what configurations do we have to apply to really get a good result out of that. And so that is where we saw that with our business model and our strategy, we invested a lot in kind of educating users. And that was mostly kind of high touch sales, right? It was mostly done by solution architects and support, but we invested a lot of time in making sure that they understand how the product works, but more so understand how encoding works in the first place to make sure that they can use the product. And this basically then also led to the problem that we saw is that we invested a lot of time for users that never really converted to customers. So we saw that with that change, we had a lot of the ROI of the users was really low because we spent a lot of time, but the customer lifetime value was really low in comparison or an average because only very few actually converted. And that was the point that we said, okay, we have to change something on this model because it doesn't, it just doesn't match. We are doing a high touch model for the user, basically, and for self-service customers, potential self-service customers. So at that decision point, and that was roughly one year ago, basically where we said, okay, what are the two options? What do we see basically as the options for us as a company to move forward? And we back then saw two different perspectives. One is to really invest into a product-led approach and simplify the onboarding, take off the load of our support and solution agents, and make sure that the people that want to try it and our developers from various companies, small scale, big scale, doesn't matter. They can just try it without much asking, without much guidance from our team. Or we say we narrow the funnel earlier. So we make sure that only the ones that really want it, that have a budget, that have a project and really have to do it because there's a business need, come through and then try it. And we can focus on these customers and can make sure that we give them the most attention that we have and don't spread our resources too thin, but really focus on the ones where we see high potential. Markus, you mentioned that at some point you realized it's not that easy anymore to convert customers or the number of customers that are not converting is getting too big. How did you analyze that? So this was mostly done on the support and then on the resource need side. It was mostly that we saw just that when we looked at the requests that were coming in for support requests, we saw that just too many of these were from non-customers. And then we looked at, okay, so how many of these are connected to a real opportunity? And there we just saw that this didn't really match up. So it was not specifically to, for example, the signup flow or any conversion thereafter, but it was really mostly that we saw we spent too much time on opportunities or users leads where there was never really an opportunity. That was the analysis that we did. And it was also the trigger point that brought us to that decision point where we said then, okay, we have to change something because we can't just add more and more people to support users that never really sign up or never really want to pay. the amount that we actually want to charge for the product. So instead of going crazy with cohort analysis and stuff like this, you just realized the number of feature requests coming from non-customers, it's just so big that you're going to need to make a change. Yeah, it was not even a feature request, but it was just requests to understand how to set up an encoding, for example, with our SDKs. So it was mostly really like, how do I do that? I want to do an encoding and I have found your product and I see you do that and you do a really good job in that, but how do I do it as a user then? Like how do I set it up? And we had a lot of support conversations where it was, can you send me an example? Can you do this? Can you do that? Can you, I'm stuck here. What is this bug? And there were a lot of conversations ongoing where we saw that in the end, then when everything was resolved, there wasn't a real business opportunity. It was just somebody trying it out. And so that was the issue that we saw there. I think it's actually super interesting to see how important customer support also is like in terms of giving you the insights, because even more, I'm not sure if it's like more on the enterprise side thing, if it's an enterprise side thing, or if it's a consumer, because working also on a consumer product, it's something like where we uncovered most of our usability issues also sometimes, where if you listen to your support agents, it's just like really the direct connections to the, the direct connection to the user sometimes. Yeah, definitely. Definitely. On this point specifically, was this something that you measured also in terms of like numbers or was it really more like qualitative conversations of, of constantly having touch points also with customer support? So from how I saw it, or I experienced it was mostly something that we got as a feedback or input from the solutions and support organization. There we saw that it's just, it was more qualitative, let's put it this way. So it was not that we saw, okay, it's this amount now, and we can't handle that. And we have to reduce it to this amount. It was mostly a qualitative analysis where when looking at the tickets and following it for a couple of months, they just saw, okay, we're working on the wrong stuff. We are investing on tickets where there's no point in us going back and back again and giving more time for something where we don't get anything in return basically. So you as a product manager, would you sit down regularly or how do you like, what's the best way to, to make sure that you hear a customer support? Very good question. So for that one, I think the best way is to also do it in product reviews. So that is, I think for me, the right place to bring that up and to also get that input from the other departments, especially support here, and to understand better, what are the things that are influencing their work that is also based on product topics. In this case, it was specifically because our usability and our support page and our like docs were not on par to handle these requests. And so this was mostly something that came as input then from solutions and where it wasn't like that back then. It was just because there was an ongoing like thought and initiative to do that. But I would do it like that now that I say, okay, the product review that you should do quarterly or so, that's the place where you want to ask for that kind of input as well from the other departments. I want to dig a little bit deeper here. If you would just put yourself into the shoes one year ago, when you started coming to the realization, or when you were faced with the challenge of doing too much for non-customers, what would be the one thing that you would do better now? In terms of discovering it or? Exactly. In terms of discovering it. One thing I think that I would do better now is to also get more into the details, get more granular in what is the specific issue and how can we actually prove that it's an issue, right? Because when thinking back now, it's also that I took this also partly over when there was part of the decision already done and like part of the senior leadership, for example, also mentioned that, well, this is something we have to do. This is something that we see there. And one thing that I would do differently probably is to probe more, to dig more, to say, okay, where is your proof that this is actually the reason? Where is your proof that we are spending time actually on these users? I think that would be the one thing. Cool. It makes a lot of sense. So coming back to the two options that you had, I think like we stopped you there and I'm super curious actually on which was the option that you took in the end. Yeah. So I'm just going to repeat it now so everyone knows again, what are the actually two options. So at the decision point. Or maybe we make it as a quits listened well enough to know which one the two options are. So just press the button on the phone for option one. You press the one and option two. And based on this, the conversation will lead into a different direction. That would actually be a good idea. Yeah. It was this Black Mirror episode, right? Speaking about Netflix, where directly on Netflix you could pick like. And it took me at least 30 minutes until I realized when the counter is moving down that you can press something on that screen. So I was just by accident seeing what the computer was randomly choosing. But I think you're probably one of the only ones. Everyone knew what this episode is about before even watching it. That's the part behind Alex. All right. Anyway, option A and option B. All right. Yeah. So basically option A was to invest into a product led approach and simplify the onboarding, the docs, and just make it easier for users to understand and use the product. And the second one was to narrow the funnel earlier. So allowing fewer people into the product to focus on these people that have really high intent of using the product, that have a project, that have most likely already a budget as well for it. And this said, what we then decided doing was actually the second approach. So narrow the funnel earlier to focus on high revenue opportunities. And the main reason why we did that was that we just saw that this was easier for us to accomplish with the organization that we had in place, with the processes we had in place. And building out really that product led approach and the docs and simplifying the whole product would have taken way longer than what we could have, like what we had time for in the frame that was proposed, because we wanted to change it over the next quarter, maximum the next half year. And so that meant we really had to figure out, okay, what was the approach that meant we can still do it, support it with our organization, and we don't have to redo really major parts of the product. Redo major parts also of how we deal with new incoming leads with signups and how we get them to sign up basically. And overall it was then, so from the product side, we brought that proposal and we prepared that proposal, but it was then in the end, a collaborative decision with all the stakes holders. So sales was involved, marketing was involved, also solutions to make sure that, so when I say solutions, it's always also support on our end, but really to make sure that the people understand, okay, how will this impact now also as a user journey, our buyer journey, and how will this change things for our users? And I think there, it was especially important to really get everyone involved. And when I say everyone, the departments and there it was in our case, the department heads basically, and especially, and I think even more important here is to get the temperature from key stakeholders before presenting to a wider audience. So what I really did there is also, I remember because that was in our office in San Francisco when I was there and sitting together with our CEO and CTO and our senior vice president for sales and really defining and figuring out, is this a possible solution for our problem that we have and how would it look like? And is this something where people generally agree on this level, right? Before we then went into more and proposed that to the wider audience basically. I really love that you mentioned this temperature feeling. Yeah. But I think especially on the temperature feeling, like just double checking if I get it right, because if you're trying to narrow the funnel, this actually means that you have a massive impact on conversion rates, on signups and so on. It's also something where you as a company need to revise KPIs. I'm not sure how you track things, but I know a lot of organizations who would simply measure success also of a product manager by looking at the numbers. So in that sense, you're saying, okay, maybe you were not, but it's like you have a steady number of users that you're bringing to the tool and you are introducing a feature that actually reduces this number proactively. It's something that I imagine is not super easy to communicate also to an organization or to investors. Yeah, definitely. And I think on this case, it was also like to the point of getting the temperature maybe also. What I noticed there also was that the CEO and the CTO actually had different opinions about that. So there was the CEO was mostly still in the mindset of, hey, we started this company to cater developers and we want to make sure that developers are satisfied with the results. developers can actually also use it and experiment with it and so on. And the CTO was more on the direction that he said, we don't get anything out of all these users. Yes, it's a community, but now we have to think about what is the best for the business and getting the revenue. We have to get to the numbers also because you mentioned also investors, right? So one point here was that they just saw, okay, currently the funnel doesn't work for us. We don't like we spend the resource that we have on the wrong point of the funnel. And we are wasting them there rather than helping others with a high intent to really get through the funnel. And the issue there was from the sales and marketing perspective also that we were not able to efficiently identify out of 100 users, which are the ones that we should target, which are the ones we should focus on and so instead of saying, okay, we just let all of the 100 in and we will figure it out. We just let, let's do it first. Let's block all the ones where we get nothing back and so on. And let's just one of the ones in where we already get a signal of they have high intent and then say, okay, all the ones that are in and they're trying out our product, we already know they have a high intent because they already told us, so they already get, got back to us and mentioned what are they looking for? What is their project? What is maybe even their budget? And yeah, they are to getting back to that kind of don't fight somebody else's fight. It was really super valuable to have that temperature check with the senior leadership and also let them discuss this direction. I had a proposal. I wanted to go into a certain direction, but for me, it was important that this discussion happened in a small group and these two kind of made up their mind of what is it now that they want to focus on so that I can also drive that initiative then forward and know that when I'm presented to the wider group, it's not going to end up in a kind of huge discussion between senior leadership and I'm in the middle of this. I think the worst thing you can do is presenting such potential big changes in the bigger audience because people will go nuts. And that's why I said earlier, I really love that you mentioned this double checking because something that I've learned from one of my mentors was, Christian, whenever you want to communicate a bigger change or if there's anything that you propose that needs to be adjusted in any way, always make sure that you catch up with people in a smaller group or even offline before you come with a kind of big bang to a CEO, for example, because if a CEO has never seen what you have presented, there will be always questions. And if you're honest, if there's something that you don't know and you don't understand potentially your first response is no, especially on a higher level. So that's why we really like that you took the time. And I think also to the aspiring product managers or product managers out there who are listening in right now, make sure that you really over communicate on an offline level or on an individual level to then make sure that in a bigger audience, you get the buy-in from everyone. And maybe to also add on that, and I think something that I also think is great is that you had two options. You actively thought about two options, analyzing what could work and what couldn't. And in this case, there was like also a restraint and the limitation based on like simply the time and focusing like also on the specific goal that is reachable also in that specific. And if I would be a CEO, I wish, if I would ever be in that position, I think it's also hard like to not buy in into this because what you did was like aligning business goals, company goals with the best option that is in the room. And I think that it's fairly easy to buy in as whatever stakeholder, or maybe you can share a little bit like what also the biggest tensions or where the biggest pushback was like from the company. Yeah, I think biggest pushback, I'm just thinking back. The biggest problem here was really, I think that there was the idealistic way of doing things, right? And how we would all love to do it. And it was a realistic way of doing things. And so I think that was also the biggest conflict. So yes, there were the two persons also that said, okay, I want it this way. I want it this way. And they had to get to an agreement, but I also overall felt like this was something where we saw the biggest tension because it was just being realistic versus being the kind of vision focused, the founder persona that thinks we should do it this way because that's how we created it and that's how we actually want it, right? I think that was definitely the biggest issue, the biggest tension, the biggest thing to resolve with these two options, I think. How did you help the C-level with the older mindset? I think it was a CEO, right? Yeah. How did you help or influenced him or her to change their mind? I think back then, what I tried to do is I had a couple of things that we had ongoing also in the front-end team. Back then I was, we had a special team that was focused really on the dashboard, on the docs and all these things that we also thought that should contribute to these initiatives and which would have really been in a place to do also the product-led approach and simplify all of that. But as part of that, I also saw what are the things that are already on our plate and what are the things that we are currently doing, right? And how does it actually work in terms of what would we have to change to really get the users through the process, get them through the journey and really get them to sign up. And as part of that, I already saw also that we just covering the needs of the specific products. So encoding player and analytics and working towards these goals of the bigger products that didn't allow us to really focus on that product-led approach. And so how I did it then mostly for the CEO is on the one side, I piggybacked on the arguments of the CTO, but on the other hand, it was also a little bit saying that we could potentially do it. But what it would mean is that we would really have to expand the team. We would have to make sure that we have a team that really focuses on that. And we have a lot of other things currently on our plate that I'm telling you, we can't do it on top. It's just not possible. And that I think was also the forcing function that taught them. I think there also in his mind was, well, okay, we can't really expand the team. There's just from like head count and so on, it's not really possible, right? Yeah. And so I think this really also helps to force him also in the way that we say where the only real option that we have right now is going down the route of narrowing the funnel. It's the one we can do as an organization right now. The other one is the one he would wish for, but it's just not realistically possible with the current structure and the team and what we can afford to invest into an initiative like that. How was the pricing then rolled out to the customer? For that, maybe let me start what the specific changes then were basically. And that one was that we actually changed the pricing as mentioned, we made it more enterprise. So we reduced to one self-service plan. We removed all the monthly plans as we also saw that we need yearly commitments to really also make it worthwhile for us to invest the time on the support side, to get a customer up and running. And we also decided it's just going to be a minimum of 5k per year that variants the high touch sales that we are doing right now. And this rollout then was done in the front end team, basically after discussing what the actual changes were that we planned within about one or one month, I think it was roughly where we said, okay, this is what we have to tackle. This is the changes on the website. These are the changes on the dashboard where you can actually book the different plans and so on. And from there, where we had to kick off, we then got back into the different departments, so sales, marketing and solutions, especially, and also on us, on the product and engineering side, we implemented the change. They did the changes on the specific, on the structure, basically off, for example, the sales process and how they target specific accounts there and so on. And there was really the time pressure to do it quickly. So that was why it was rolled out within one month. There was no specific communication upfront to further leads or any like contacts to promote this change. It was more whoever would sign up and whoever would actually get in touch with us, we just told, for example, the sales team, so these are the new options, right? You can't offer any plan lower like that. You can't offer monthly billing anymore. This is just basically the restrictions that we introduced as part of that, where then within one month, the new guidelines also for our sales team to qualify their leads. Was it a big bang rollout in the interface that from this point on everyone saw the new pricing or did you roll it out in stages? It was basically big bang. Yeah. I think it was the week before Christmas last year and then we just said, okay, nobody's going to surprise. Merry Christmas. If you sign up, you're going to sign up for the next year. It was last Christmas. We increased the prices. But, but so what did this mean for users who were already on the platform? Did you have to renegotiate or what happened with those? No. Yeah, that was actually also one, one discussion point. And that is, we already had a. couple of discussions in the history while I'm at Bitmovin about how we do these pricing changes. And in this particular case, since we already had old customers from, let's say Bitmovin encoding version one, we had a different system and we sunset these customers and all the accounts. We did basically the same here. So we said, we are not going to cut anybody off, but as soon as they want to renew, these are the new options, right? They can't renew on their regular plan anymore then. So these are the options. So you were very strict in making the cuts to the new pricing in that case. Yeah. In that case, yes. But basically the existing customers, or if they had, for example, also an ongoing monthly plan, then that was fine. So some of the customers would still continue on their auto-renewing monthly plan. Just the ones that had already yearly plan, but where they previously negotiated, for example, something like 3k for the yearly plan. We then with the renewal, we said, look, this, these are the options. We don't offer that plan anymore there. We have to find a way to upgrade you to that volume, to make it work for both parties. This was to get done together with a different change. So this just reminded me the upgrade and how we treat or how we dealt with the customers that had have a current plan. We also at the same time changed our pricing methodology in terms of how we actually calculate how much a customer is charged for their usage of the encoding product. The methodology in our case is we have inputs. When you have a one hour movie, it depends on how you actually process that movie. How much we then calculate, how much you're charged for that particular content piece. Since there are a lot of different levers, you can use a lot of different configurations. It can be a very different outcome. If you use a very basic version, you maybe are charged the same kind of, we use minutes as a methodology as you put in. If you do very complex computations like Dolby Vision and 4k videos, it's maybe 300 times what you put in as the content. And because of these differences, we also decided that we change our methodology that kind of determines how much this overall factor is to align it better with customers that have high needs that really want to do 4k and Dolby Vision and so on. And we would just know this is expensive for us to do. So we have to forward that cost to customers. So rather than increasing the general price for one unit, so to say for all customers, we decided we are going to go into specific use cases and determine how much does actually a specific use case cost us and how do we forward that to customers. And that was another case where we still have ongoing conversations with renewers, with customers where we see we have to apply this new methodology and how it affects them. And now we are really in the details of pricing and coming up with the prices and so on. I have many questions. Business models, economics, whatsoever. Very blunt here as a designer. Is this the job of the product manager to actually do these calculations and come up with the prices or how does this happen? At least for us, it's the case that we say we have usually since we have very specific workflows and very specific configurations that need specific amount of computation. Then our engineering comes up with how much does it actually cost us to just run this and to perform this operation. And then it's on me to basically determine also what are different offers that we see on the market? How does it compare to what we are achieving? How does it compare to the value that we provide also with this new capability, for example, and determine what is an acceptable level also that we say, OK, we can actually charge that for that new capabilities. So there, at least at Bitmoving, it's definitely the case that and especially in my role, I'm very involved in the pricing and I'm the one also determining what is the pricing for a specific customer? How do we price new features? How does it compare to others and to stay competitive there as well? How is your collaboration when it comes to pricing with the sales team? So there it's mostly, I would say, we determine how the pricing looks like and come up with why is it that way and how does it benefit the specific customer? And then we mostly use sales to also carry that over to the customer. I would say in the current way, it's not really that collaborative, but we take obviously also the signals back from sales. It's not specific for a specific feature, for example, where we then have specific discussions with sales, but it would say, OK, I don't see it like this or I don't see it like that. But what we get back from the market is really to say, for example, from our VP in APEC, they say this and that feature or this and that pricing doesn't really work in my region for these specific reasons. And we take this as input again to think about how we price the product and think about what are the specific dimensions, also how we can change it and make it more interesting also for specific regions, specific segments, and make sure that we hit the sweet spot. Is that on the roadmap at the moment to be able to configure the pricing or offer different pricings based on location and region? Not right now, because most of our pricing is basically done with like approval process internally anyway for the accounts. And so therefore it's very account specific. So if a sales guy from APEC reaches out and says, OK, I want to offer this price for these reasons and it's within what we can actually make work with the product, then I would approve that and say, OK, this is a price that we can offer and this is a price we can go for. And there, I would say, the requests from the sales guys are very different per region and you have to also treat it a little bit different with the knowledge of the market in that specific region. So I thought Christian has a lot of questions around pricing, but Dave, he's not shooting them. I'm just jumping so fast, so I need to adapt. I think the conversation is super interesting and still talking also a little bit like about how it was like received by the customers and so on. Did you actually see any negative impact in terms of losing some of the old customers versus like how much did it improve the goal that you had initially, like in terms of narrowing the funnel and having more quality leads that bring higher revenue also per lead? Yeah, there are two different aspects to it. The one is about the signup funnel and the leads that come in there. And I will first talk about that and then jump to the second part of your question. But for the first part in the signup funnel, what we did, as I mentioned, it took us about one month to really implement the change. And how we did it was that we actually used the pre-cap design studio by John Cutler, because this helps really to frame what you want to achieve. What you do is basically at the beginning, you define what should be the outcome when you do a review meeting at the end of your experiment. So you think about what is it that actually we think where we are. In our case, it was in three months. And this was done as a collaborative exercise where I sat together with the different stakeholders from marketing, sales ops, sales and so on. And we discussed what are the different impacts. It was, for example, what do we think is the business impact? What is the impact on the user? How does it change the journey and so on? And then the nice thing is that this is basically a table that you can just dig up again when you do the recap at the end. And you can then see what you actually thought at the beginning that you will achieve and where you thought you will be in two or three months. And then do the check and see we didn't achieve that. We're way ahead of that. That is completely different. And so this was a really good tool for us also to do something that we haven't done, I think, for any other changes. We haven't been big on experimentation at that point. And it was one of the first really projects and changes in the product where we did it methodically and thought really about what are the metrics that we are tracking? Who is tracking these? Who can actually provide the data? And who is also responsible at which point in time to provide the data again? And all of that, I basically set up with the stakeholders and said, so here's the sheet and we're still using it actually. And thought, okay, what are really the KPIs? What are the success KPIs that tell us, okay, if we improve that dimension, if we improve that KPI, it signals to us that we are going in the right direction. And what are control KPIs? We saw that, for example, we wanted a success KPI was that we wanted our users to be more active during the trial. And then a control KPI was that we didn't want our users to go under a certain level. So if with that change, we suddenly would only have two new users per week, it's not going to, even if they are super active, it's not going to be a success for us. And so that was how we also separated here in that experiment or in that KPI tracking sheet as well, for example. When it comes to the KPI tracking and also the whole process you mentioned, I'm just feeling like it was very structured last time you did it. You said you involved the stakeholders, you thought about the KPIs, you had the conversations, you did the math, et cetera. I would be curious to know from you, let's say there is a product manager. who just got started in working in a similar area and wants to learn everything about pricing or take ownership of defining the pricing for their products. What kind of tips would you give the people to be structured from day one? What's important for a change like that is that you really have to think, and pricing is definitely one of these things, that you have to also think about second order effects. What I saw is you have to think a lot about what will change based on the change that I'm proposing. So what is going to happen then next? And I think this really helps to come up with what are all the different cases, what are all the different processes that are affected by this change, and helps you to then also realize for yourself, I need to structure this in a certain way. I can't just go ahead and change it here because of all the dependencies and all the effects that I'm creating. This is a forcing function for yourself to come up with the structure and make sure that you actually sit together with the stakeholders. So in my case, for example, I also sat together a couple of times with our inside sales director and also with our marketing leader to make sure that we define beforehand already what are the different workflows and what are the checkpoints in the flow that will change based on the change that we do in the signup flow. How does it influence, for example, when a new lead pops up in our marketing system? How does it influence when somebody's moved over to our sales system and so on? And this was also mostly because thinking about how these changes and influences also the other departments and their processes, that it helped me also to realize early on, the more I involve also these parties or these stakeholders, the more it helps me to also make this process a success and avoid surprises for them. Which brings us back to our previous episode about stakeholder management. There's always this loop. There is always this ongoing loop, yeah. Alex and I, we have a very, very good plan. I think it's simply, and I had this conversation where we were waiting for you, Christian. I think there is just a few things that are probably related to our jobs. Stakeholder management is one of that. Yeah. And we're not talking about the steaks on the grill. True that. Maybe just one additional point, and then I think we should slowly try and get to our wrap-up. But especially when also looking at the prices, and I have to say when it comes to encoding of videos, I don't know the competitive landscape, but how does your pricing compare to some competitors and the display role in the whole decision? Yeah, it does compare in a way that it doesn't compare. So the thing is like everybody in that space really prices their product very differently. And I think this is mostly also caused by the history of how encoders work. Since we apply a completely different architecture than other encoding vendors, we have also a different pricing. The traditional way of doing things is that you have a hardware box that has specific capabilities where you support a specific codec, for example, and this box can run this all day, right? So this is, you have a hardware expense at the beginning, and then it just runs and you can encode all the time. And what some of the vendors then did is to say, okay, let's take this capability and let's just put it on a different instance in the cloud, and then it's the same thing. So we can price it the same way. So we can just say, okay, this is now running there and because it's now running all the time, it's now SaaS and you can pay us per hour or per day or whatever. But for us, we didn't have this kind of border or this kind of box of what can it actually do and what are the capabilities. But for us, it really depends on how complex is the operation on how we scale it. Since we horizontally scale, we can just say, if you, if it's super simple, we just take one or two instances in the cloud. If it's super complex, we're going to take 120. And in this sense, our pricing works really with the complexity of the specific task at hand. It really depends on what you're actually, the video is super complex, it's going to be expensive, super simple, it's going to be cheap. And for other vendors, it's more like whatever you send us, we have the same thing running. So it's just going to cost you the time that it's running. And so therefore, on the one hand, it makes it easier for us to determine or define specifics of the pricing because it's not comparable. On the other hand, we have seen it a couple of times that we have to really help also our sales organization to understand how it compares to other models, to make sure that they can also lead the conversations with our customers and make them realize how we compare and why our pricing is in this specific way and how it benefits them. So transparency is the model. Yeah, definitely. And this was also one of the big changes also with the methodology that we did last year, that we just said, okay, it's going to change. It's not going to change for most of our customers because our goal is not to make it more expensive for people. Our goal is to distribute the costs really to the ones that are using us for that. The ones that get more value out of it, they should also pay more for that. And so with this approach, it took really a lot of time and because it got more complex as part of that, we see it also for the onboarding, it is more complex to understand, it's more complex to explain, but in the end, it really also benefits our customers. And I think that is really the main point and how we underline it also and how we provide it to our customer. It's more transparent. It benefits them. Awesome. Sounds great. And it's a very user-centric approach. Maybe as we're approaching the last minutes, before me and Christian jump into our debrief, you would, for the audience, have to summarize it into the one, two main key takeaways. What would those be? The one point is when starting something like that, do the second order thinking. Think really about what is affected by the change that you propose. Work together with these stakeholders then. I think it's very important to be structured in that approach and make sure that all the expectations are aligned. And there, I think I can really recommend the pre-cap by John Cutler. It was really super helpful and I really got good feedback also from the other stakeholders that it made it more transparent for them what the goal is and how it changes their workflows. And I think the last one then maybe is when you do a change like that, be prepared, especially in a B2B and sales organization, to be there, be present, be available, and offer that also to everyone who struggles with the change, be it a sales guy, be it a customer, to be the backbone of that and make sure that you can explain and help people understand why you are doing this change and how it benefits them. Great, Markus. One last question. Where and how can people find you on the internet? Yeah. I'm very active on LinkedIn, so that is one part where everybody can find me. And what I also like to do in my free time is actually write about strategic topics, about product management topics, and kind of also digest what I find on the internet and read in my newsletter. And that you can find on stradilite.substack.com. You should definitely give it a try. We will link everything into the description. And with that... Markus, it was lovely having you here. It was a great conversation. I know how to price my product in the future whenever I launch one. And that's it. I wish you an amazing night. Thank you very much, Markus. Thank you for having me. Alex, you said you now know how to develop a pricing for your future product. Just to double check with the audience, how would you do it? Depends on the KPI. Damn, I was close to saying gotcha. I think I personally would love to simply not price products because it brings you the most people. But you cannot offer everything for free. It's definitely a different way of looking at things. And I never actively worked in enterprise, so I'm also not really familiar with it. I never experienced the pain of having to onboard and to manually talk to so many people without them using the product. Usually when you simply launch products and I can have a free trial and my cost was maybe a couple of cents because they have one entry on the database if they don't use it. So it's not a big problem. But I think in the context of enterprise, following the approach and like really saying, OK, we need to have like high quality leads and we therefore need to change the price and especially also being conscious about what you can do. Because I think for a product manager to say, well, we could do like this product focused approach. where we completely rethink the onboarding and the whole experience and we make it better, or we change the pricing. I think like for every product manager, it would be a bit more exciting, at least initially like in their hats to go for the second approach. I think going for the pricing approach because you're conscious about what you can deliver and then in the process, finding the excitement and finding the perfect process to actually like work on the pricing model and to use this to increase revenue per user is pretty powerful. But that's all I wanted to say. But at the same time, I do have one question back because I feel like you wanted to put me on the spot with a question. Do you invite support to product review meetings? Yes, I do. That depends on the KPI, Alex. Yeah, I do invite customer support many times, but I have to say it depends on the feature and the situation. And also here we're talking about the enterprise business that you have a different support structure than you, for example, have in a typical B2B business, which is not an enterprise level. Therefore, it depends. But generally, I'm always a big fan of involving all the people from the key departments. And I see customer support definitely as a key department. Yeah, it's super important to have them in the product development cycle. But I do think like sometimes they are under, like people underestimate the value of customer support and they do product reviews like in smaller circles or maybe don't even consider customer support, except it is like really in terms of like customer support needs to be aware of a product change on being able to support people on it. Do you know what's a hot tip to stay connected to the customer via customer support? Tell me. So many people talk about, hey, a product manager should regularly sit in customer support and do this job for a couple of days, which definitely makes sense. But there's a shortcut you can take. And shortcut that I took was, I just talked to the head of the customer support or the customer success representative that I knew. And I said, hey, I want to talk to the customer. So please, here's a time slot. I have one hour. Just connect me to the system and let me talk to the customer directly. So instead of trying to block a whole day, just reach out to them and make sure that once you have a time slot free in your calendar, that you just sit next to them or whatever kind of tool you use. So these days you can maybe do it from your laptop to directly talk to the customer and try to do this once a week, twice a week or. Lucky you if you have the person that can help you fill that slot in this one hour. It's definitely a good approach, but obviously depending, I think probably depends on the company. You might free a day, you might free some hours. It's very important though, that you make sure that you're technically set up to talk to customers. That's often the problem. And I think that's where it often like also, where people are being stopped. But I do have to say many people feel stopped or just waiting for action from the other side. But my recommendation is as a product manager, make the first step. Make really the first step and try to be as proactive as possible. And going back also- With everything, honestly. With everything, absolutely. And going back- People wait far too often. And going back to the conversation with Markus, what I really enjoyed was seeing the change that he has made over the time at Bitmoving as a product manager. Because when he got started, for sure there was this big decision to make between two options where it was quite forward because costs and time speak for itself back then. Nevertheless, he as a product manager took that approach and took the data he had to talk to the C-level and then really love this temperature checking and making sure that you onboard people and discuss with people in a smaller round. But what I really like is after that, when he was faced with the next pricing changes and challenges, he took a way more structured approach. And there you can see how important it is to take the experience from maybe not the most successful product or maybe not the most data-driven decision you have made. But what you're gonna do is, when you start, is you create data points by every action you take. And what I, a strong advocate of, is take these data points and don't lose them. Don't see everything from a negative point of view, even if you fail, because in every fail, there's something you can take out of it and make it better in the future. That was something that I really enjoyed during the conversation with Markus. Awesome. And one final thing. I have to publicly admit that I have never heard about pre-kept design before Markus mentioned it. So if any one of you feels the same, I just looked it up. It's pretty interesting. John Cutler, anyway, super interesting person to also follow on the internet and to read his stuff. So we will make sure to link everything in the description so you can also have a read after the session. Other than that, feel free to drop us a line at hello at product-bakery.com. Or alternatively, you can find us on LinkedIn by just searching for the Product Bakery Podcast. LinkedIn, Instagram. We're trying to get a little bit more active on social media. So also with some additional content on those channels. And yeah, I think that's a wrap. Great. Then Alex. Bye everyone. Bye. Bye Christian. Bye.