This is a transcript of episode 283 of the Troubleshooting Agile podcast with Jeffrey Fredrick, Douglas Squirrel, and special guest Ulrik Lehrskov-Schmidt.
If you have one product per customer and aren’t charging a princely sum, you’re not pricing your customers right. Listen to this episode of Troubleshooting Agile to find out how you can take lessons in pricing a train ticket and apply them to your SAAS sales, with special guest Ulrik Lehrskov-Schmidt.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Read the next episode in this series here.
Introduction
Listen to this section at 00:11
Squirrel: Welcome back to Troubleshooting Agile. I’m sorry, listeners, we had a minor audio difficulty with our recording and lost the first few minutes of our talk with our fantastic guest, Ulrik. I’m going to summarize those minutes briefly and then take you straight into his really exciting insights about pricing. We started by asking Ulrik to introduce himself and he told us that he’s an expert on business to business SaaS pricing. SaaS is “software as a service,” many of you are providing and probably all of you are using SaaS products of various kinds. He helps companies that provide those services get the best prices, and that turns out to have tremendous application to the construction of software and to agile development. Ulrik works as an advisor to tech companies across Europe, Asia, and the US. He’s done commercial redesigns for over 100 B2B SaaS companies, and he’s the sort of person that you have come and talk to you if you can’t quite get as much out of your software as a service commercially as you’d like to. Then we got into his book, which is The Pricing Roadmap. In his book he makes this really interesting analogy to an earlier pricing problem, which turns out to have tremendous application. This pricing problem was “how do you price a train ticket?” It turns out that a train service has some similarities to software as a service, i.e. you have to build a whole bunch of rails, you have to put in a whole bunch of effort to create some kind of service, and then running it is a relatively simple operation and not so expensive. So pricing is not obviously linked to the effort that you put in to actually deliver the service. You have to somehow price for the tremendous effort that you put in at the beginning. Train services when they first started didn’t really understand how to do this. They’d sell a ticket, and the ticket might take you across the United States and save you going around the horn of Tierra del Fuego and taking months and months and months on a very dangerous ship voyager. But the train companies couldn’t charge the premium price that they would like to. The challenge for them was in setting different types of prices and different levels of service because the market wasn’t telling them exactly what levels of service to provide and what people were willing to pay. So that’s the point at which we manage to get Ulrik back on the recording and we can hear his explanation for how train companies solved that problem and then how that is relevant to software. So let’s go into Ulrik’s response now.
Undesirable Ammenities
Listen to this section at 03:33
Ulrik: The first thing they realized was they actually weren’t trying to price the train ticket. They were trying to price the train customers. So the analogy is that you shouldn’t try to price your product, you should try and price the way that your customers use the product, which is a different question that is actually answerable, because it is in the use that there is value, which can then be to some degree quantified or priced. The example in the book is from the Transcontinental Railroad, when they first built the tracks from Philadelphia on the East Coast to I think it was Sacramento in California, because too many people were in the East, and there were not enough people in the West, so the federal government wanted to move people over there. So the train company said “We’re going to have first, second, and third class.” They had this from ocean liners that got people from Europe to the US in the first place. First class sort of invented itself because it was just all the features that you could put into it, which is also what happens in software. Usually what people do when they build a software solution is that they envision this first-class experience, “We’re going to take people to from A to B, we’re going to solve a problem, we’re going to do it with everything we’ve got. It’s going to be fantastic.” But then what happened was that they had two other sort of lesser types of tickets, the second and third class, and really they didn’t know how to differentiate these. So they just said, “Well, we’re just going to do a worse version of first class.” So in packaging, maybe you hear terms like good, better, best, but usually what happens is that we actually create the solution like we think it’s meant to be, and then we just create less good versions of that, but market as base or upgraded. So the problem that they ran into historically was that they sold out of the third class tickets, because people did want to go to California, but they couldn’t sell the second class tickets because it wasn’t an opportunity for luxury. Nobody cared that there were a few extra amenities or better seats or whatever, compared againsst “I want to have the money in my pocket when I get to California and I’m starting my new life. There’s going to be a train again next week, so if third class sells out, I’m just going to wait and then take it next week.” In a wagon caravan, it would take six months to get across.
Jeffrey: So waiting a week is not much of an opportunity cost, or even two weeks or three weeks, versus six months. Waiting a few weeks is not a big deal.
Ulrik: Yeah, I think the cost-price of transporting a passenger by rail was like $6 or $7 and, and the price for the wagon in 1825, 200 years ago, was like $6,000. So basically it cost you all your money to go across and it takes half a year. And a lot of people didn’t make it, like 10% or 20% would get lost, or fall off a cliff, or die from typhus or diarrhea. It was dangerous. But this was also the seed of innovation that finally solved the mystery of second and third class for these railroad tycoons, because what they did was they said, okay, so in order to sell second-class tickets, we have to make third class less good. And then they started experimenting with it. So they pulled off features. They took out the chairs. Didn’t matter. All these Quakers and so forth, they just, you know, sat on the floor.
Jeffrey: They were tough. They just sit on their luggage.
Ulrik: Yeah. And then they went on to take away the windows. Instead of having passenger cars, they’d get cattle wagons and deliberately not clean them. So they made an effort to make the experience less and less good in order to try and force the upgrade.
Jeffrey: I think I’ve been on that flight, actually.
Ulrik: Yeah. I think we’ve all been in that software as well. Finally they sort of reverted to their original thinking, which was “why did we build the railroad in the first place? What’s the core problem that our solution is solving? We’re going to take them to California quickly, cheaply and alive.” That’s the value proposition. Brutal as it is, it’s sort of a piece of innovation in capitalist history. What the story teaches us is that there is a market for a lot of different versions of a product. You have to find the core of what it actually is people are buying. This is often what also what I’m trying to find out in the projects I run with my clients: “So you think you know what you’re selling, but what are your customers actually buying from you? Let’s figure that out and then maybe we can get somewhere.”
Why is Anyone Buying This?
Listen to this section at 08:56
Jeffrey: That seems like the key insight here. Those changes made the service worse, and that’s true. But the point was it still delivered on a core job to be done. There was still a core value that even after you took the roof off, the third-class customers were like, “Great, that’s still good value for money for me.”
Ulrik: Exactly. And it got to a very key distinction that existed in the market, which was that some people actually had the money and were willing to pay for that extra functionality, and some people didn’t have second-class money but were willing to take the train on third class. So you can see that the packaging structure actually gets at some preexisting qualities that exist in the customer base and sort of extracts them. That’s how the monetization works, right? So this is why I’m saying you shouldn’t try to price the train, you should try and price the train experience or the customer experience with your product. That’s really how you differentiate and get the most money out of your market.
Squirrel: I see. And that gives a tremendous benefit for the technology team as well, which isn’t intuitive, but I’m often counseling my customers—I’m working with one right now—to help them to match their technology investment to the value of the customer, because it’s so easy to get that wrong. A very common pattern is for a technology team to build software because customers demand it, and they will build highly, highly custom software. They’ll wind up with multiple versions of their product, each for just one customer or for a small class of them. And the price for that is way out of whack because those customers are paying a kind of standard, maybe second-class or a third-class fare, and they’re getting super first-class limousine service. But what I’m working with a client right now on is a common solution to that on the tech side, which is to identify what the standard classes are. What does third class look like? What is something that we can do for people with no effort whatsoever for us so that the investment we’re making also matches the price? I wonder, is that something that you look at as well? “What investment can we reasonably make? Do we have cattle cars to hand?”
Ulrik: So the way I usually look at it is the concept of a job to be done, which I just define as a problem that is being chased by demand. Sometimes I even start with what I call the point of first demand. What is it that the customer reaches out to you to get solved? Because that means they already have taken action, which means they likely have budget, which means they are willing to pay for whatever it is that they’re looking for. So let’s say that a customer comes to the door looking for predictive maintenance in airports. Then that is a pretty good title for your core module, right? You shouldn’t try to change that. That’s what what the demand is. Let’s build that. You can always do, “efficient operations in airports” and “airport improvement” or whatever in your other packages. But centering around sources of demand is, I think, a critical way to go. If you do that, you can actually get alignment between customers and product and sales. Often in my projects it is this way that I can get the product team and the sales team to agree what it is that we’re selling. “In this package or module, we do X.”
Squirrel: So that makes it very clear that this kind of packaging and tier solution works well for the pricing side. Jeffre I’m sure can can tell you that on the investment side, on the engineering side, it really helps to figure out what you actually need to build and get away from this kind of over-customization. So this sounds really valuable, Ulrik. I really want to ask you about what happens when this doesn’t work. What happens when in technology we have tech debt, or otherwise you might say commercial debt where you’ve not done this, and you wind up with a mess. But I think we’re out of time for today. Ulrik, would you be willing to come back next time and we’ll ask you more about this commercial and technical debt and how they relate to each other?
Ulrik: Yeah, sure, I’d be happy to.
Squirrel: Fantastic. Ulrik, where can people find you in the meantime?
Ulrik: So my book is called The Pricing Roadmap and it’s on your local Amazon. My website is willingnesstopay.com so you can also find me there.
Squirrel: Fantastic. Thanks, Jeffrey and Ulrik.
Jeffrey: Thanks, Squirrel.
Ulrik: Thanks.