Dear founder,
Sometimes software founders are a weird bunch. They've built their businesses on open source software and the contributions of people who've done a lot of work for free. They've benefited at great length from infrastructure and tooling built on open standards that facilitate free exchange of data and ideas.
Yet when it comes to their own software business, they hold the opinion that you should have as much vendor lock-in as possible when it comes to your users. The moment somebody signs up on your platform and invests their data into it, I've heard founders say, "You have to lock them in. Make it as hard as possible for them to leave."
And that is a retention strategy for some. I think it's a horrible practice.
A quick word from our Sponsor, Paddle.com. I use Paddle as my Merchant of Record for all my software projects. They take care of all the taxes, the currencies, tracking declined transactions and updated credit cards so that I can focus on dealing with my competitors (and not banks and financial regulators). If you think you'd rather just build your product, check out Paddle.com as your payment provider.
I believe that you actually increase your retention and strengthen your product by making it as easy as possible to import and export data at any given point. And I'm going to make a case for this today.
If you already think this is true, well, you might come away with a couple of ideas on how to make this even easier and how to communicate it more clearly to your customers. And if you think it's a stupid idea to make it easy for customers to export all their data, I would ask you to give this a listen and then share your perspective with me afterwards.
I am generally of the opinion that informed consent and informed choice is the highest-value retention strategy you could possibly have in a software business. If somebody buys your product because they understand that not only is it going to be easy to use, but it will also be easy to leave—the chance of them sticking around or buying it in the first place goes up immediately.
It's a bit counterintuitive that an easier offboarding process might cause people to stick with you longer. But if you think about it realistically, people will lock themselves into any software product you give them. They will, just by the sheer inertia of a process once it's established. Changing things will always be hard, and it is often quite hard to change a process in the first place.
So anything you can do to make it feel like if such a change is ever instigated, you will not be blocking the way—that's going to be a strong signal to a customer. In the software-as-a-service world, that means making their data in your platform movable. Just allowing people to get a full data export of their entire account, to not have to scrape things manually, but to have it facilitated easily.
And often, just the promise of this is sufficient. They don't need to actually get the data. But when it comes to the due diligence that they do on your business, they will see that you thought about it. Thinking about people's end goals, about their job to be done—which, for many people, is simply to keep running their business as it is—is a very important thing to do. It's a strong signal that shows your customers you understand them. You get it.
Let me give you a real example from my own experience. I'm running a business called Permanent Link—you'll find it under permanent.link. It's a URL shortener, but also an archival tool in some ways.
My customers there are rightly concerned with the long-term survival of this business, because the whole point of Permanent Link is for that link to be permanent, right? If you link to a website and that website goes down—because link rot is a real thing—then the chance that your visitors won't be able to see it is quite high. Permanent Link helps by rerouting visitors to an archived version of the page, either a publicly archived version or a version that we archive ourselves.
So Permanent Link, the service itself, is responsible for this rerouting activity. If we don't reroute users correctly, if our service is down, then even if the original link were working, we would not be able to forward visitors to where they need to be. Permanent Link itself needs to stay there. And like any software business, people are concerned with the long-term survival of that business.
So instead of just saying, "Yeah, yeah, we're going to be around forever," I said, "Here is our contingency plan." And I outlined it on the homepage.
If this business ever shuts down, our dynamic linking will be turned into a static link system that would at least guarantee that all the links you currently have are going to keep working until their original sources expire. Or you could change them to always go to the archived version on the Wayback Machine, and then they would never expire as long as the Wayback Machine works.
For the long term, Permanent Link also offers a full export of every single rerouted and forwarded link, formatted to be used on a self-hosted Apache server, a Caddy server, or an Nginx configuration. If you just want to download all your links and automatically forward them yourself, we have the data format ready for you. You can just run it on your own domain and nothing would change. We export all the configuration. You would just have to run the server.
This has been received with a lot of positive signals from the community. People were like, "Yep, wouldn't have bought it otherwise, but now I know that whatever happens, I can always export this data and just run my own server. That really helps."
And it helps because it gives optionality. It helps because it gives people the expectation of what would happen in the worst case. For people who know how precarious the situation of software companies can be—even if they are low expense, like Permanent Link doesn't cost me more than a couple hundred bucks a year to run—you still want to give that optionality.
And it generally feels good, particularly now with AI systems, to have a full data map and let anybody—either a machine, a person, or an AI—do an analysis of your data. It might be really useful for you to just export all your data, load it up in some kind of AI system, and then have it number-crunch and figure out if there are any inconsistencies in the data or if there are patterns you've missed. You will find that these tools can do a lot with the data that you have. So allowing customers to use that is giving them additional insight potential into their own information.
That's the export side of things—what people can take away should they ever leave your business. But it is just as important to make it easy for them to get into the business, to take their existing data from other places and not make it harder for them to use it.
What I recommend here is to also make it extremely easy to allow people to import their data into your system. And by import, I really mean: do you have the capacity to get them set up with a good-enough version of the process they've already established in their business, as quickly as possible?
I'm looking at my friends over at Fathom Analytics here. When Google announced that their Google Analytics version was going to change—a lot of people needed to move off the Google Analytics platform because it just wasn't giving them what they needed anymore—they needed to find another platform to run their analytics on. But obviously, they wanted to keep their data around.
So what the people over at Fathom Analytics did, quite quickly as I remember, was build a Google Analytics importer service. I think Jack Ellis talked about this very publicly on Twitter, and it was fascinating to watch just how much resonance that import feature got. A lot of people came onto the Fathom platform because there was a way to take that old data with them. They were not locked out from using it. They were actively encouraged to take that data and bring it into this new service with them.
I find this both inspiring—because it clearly worked for these customers—and very important for the software-as-a-service business itself. Because not only do you have a new customer that starts using your product, but from their data, you get a massive level of insight into the needs they might have.
You see just how much expected capacity is going to come through your system. If somebody has ten billion page views in the last month and they sign up to your product, and you know nothing about it—you give them a JavaScript embed, and all of a sudden, you have ten billion new items in your database over the next thirty days. That's a big surprise.
But if you, in the process of importing their data before they even start using your service, see that there's going to be an expected number of these items, you can already pre-provision systems to make this run smoothly. This is customer anticipation that you can do by allowing for data imports. That's a pretty important part, and it gives them continuity.
In a way, it's a kind of soft lock-in, because they take their old data with you. As Google rolls down their service and their data vanishes there, now you are the only source for their data. So if you then also facilitate full data export, now they have the most possible peace of mind. They know that even if they would, at any point, leave your service, their data is safe.
And they will not try to find alternative ways to store that data, which might even make them go for another potential vendor that has a less restrictive policy when it comes to data exports. You're making it harder for your competitors to compete with you on ease of use if you're the easiest to use in the regard that when something might happen—if something ever happens—you will be the least complicated solution in the space.
That's my recommendation: allow people to import, export as much as they want, and support exporting and importing of relevant tabular data.
That's my last point. I've noticed this with Podscan, I've noticed this with Permanent Link, I've noticed this with Feedback Panda before—in every single one of my SaaS businesses, B2B, B2C, somewhere in between. People want to be able to export any table of data.
If it is a table—the moment you have tabular data with rows and columns—put an export button there, and you will see some people use it for whatever purpose it might be. They might want to have a local copy in their Excel. They might want to throw it into an AI system for analysis. They might just want to have a backup of the list or go through it later.
Import and export with comma-separated values wherever you have tabular data—that's where export functionality for tables is always going to be useful. Wherever you have a table in your software service that has meaningful business data, allow export functionality, and you will find that people are going to use it. They're going to find new ways of using that data, and that will make them more sticky customers as well.
So yeah, allow everybody to import and export everything. It's going to make them customers who have more use for your product. They're going to use it more easily. They're going to join more easily. They're going to subscribe more easily. And they're going to retain for longer, because they know they don't have to look for an alternative. If anything ever happens, it's going to be easy to leave, so they don't need to prepare.
It's a peace of mind solution, and it's not going to cost you much. In fact, it's going to make you stand out from all these other founders who have vendor lock-in as one of the central mantras of their business strategy.
We're the podcast database with the best and most real-time API out there. Check out podscan.fm — and tell your friends!
Thank you for reading this week's essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!
No comments:
Post a Comment