Introducing Userless

Less data, more headache? The other way?

Hi! Can here. Today, I have an idea.

First Came The Cloud

The Cloud gets a bad rap sometimes. The idea is simple: instead of owning the machines, you rent them. But you can extend this notion of turning fixed costs into variable ones quite a bit, and people do. We went from putting a bunch of servers in a closet room to virtualization to co-location, to the cloud, to containers, and if you are super progressive about it, serverless.

Some of those are just marketing terms, but the idea is paying for only the resources you need and focusing on your core competencies. For example, if you are developing business software, your ability to keep a bunch of servers cool should be irrelevant to your success. So, you build your software in terms of functions, simple mathematical formulas that take a bunch of inputs, and return some result, and put it on Serverless. Amazon et al takes care of doing everything in between taking those inputs and spitting out an answer.

There are a bunch of bad things about this model. Some people worry about losing control of their data and compute resources. Others worry that as more things move to cloud, things become more centralized. They are both real issues - and there are a bunch more - but neither has stopped the way of the future from taking hold.

So, clearly, there are also good things. Running computations and storing data on the cloud could be more expensive per unit, but the sheer headache of maintaining a bunch of servers is not worth it for many small businesses anymore. Cloud providers are (probably) better at keeping the blinkenlights on than you. 

The significant improvement, at a high enough level of analysis, is turning your business from a fixed-cost one to variable-cost one. Instead of paying upfront for stuff you don't need, you immediately align your costs with the service (and goods, sure) you provide. This enables you not just to start a business quickly, and there's an aesthetic purity to this way of accounting. Your costs are straight-up associated with your work.

We talk a lot about data here. One of my somewhat contrarian arguments is that data has hidden liabilities. The more of it you store, the more you accrue. In fact, there's probably a point where you store so much data that the crosshairs on your servers make that trove of data more of a liability than an asset.

Now, one thing I've been noodling on for a while is how you could somehow improve on this. And I think the "serverless" model gave me an idea. Since this newsletter is nothing but Ranjan and I rambling about things we find interesting, I'm going to run it by you.

I call this model userless. I am a cheeky person.

Introducing Userless

Here's the principle: Instead of collecting a bunch of data in the name of "users" on your service, just allow people to accomplish their immediate tasks by collecting the least amount of data required. In other words, similar to how using a serverless architecture is about being intentional about your resources, be intentional in your data collection, instead of opportunistic.

It’s easier to talk about this with an example. Imagine a food delivery app. Instead of ever creating an account upon download, you get a list of places that deliver to you; you send the app a bunch of items you want to be delivered, the app charges you with the credit card stored on your device, and voila. So, does this work?

Let's talk about The Good, The Bad, and The Ugly.

The Good

The significant benefit from the business side is obvious: reduced friction. No one gets out of bed in the morning to be a row in someone's user database or fiddle with the various onboarding steps you throw at their face. The fewer steps you can put between your user and their goal, the more business they should give you.

The other benefit is reducing your attack surface. This sort of goes along with the data-as-a-liability theme. The less you know about your users, in most contexts, the less you have to deal with various complications of having so much data. For example, if you don't know where your users live, you can't accidentally leak that data. If you never store credit card information, you don't have to worry about compliance. If there's no personally identifiable information, some European or American (Californian?) regulator will be much less likely to come knocking on your door.

And honestly, there's a nice aesthetic alignment of interests here. This way of building a company forces you to think, at every step of the way, whether your actual line of business is aligned with the interests of your users. Instead of pretending to provide a service that only exists to collect data that you hope to monetize later, you are required to focus on the fundamentals.

This may not be a good thing for certain businesses, but you can see how this is good for society. Making money off of people's inability to comprehend your business model that's hidden in some complicated legalese should not be sustainable.

But of course, there's no unadulterated good in this world.

The Bad

There are many problems with this model.

The big one is eschewing any sort of long-term relationship with your customers. This can maybe go in the "Good" column, depending on your views on marketing, but if you can't ever reach your customer via email outside the order flow, how do you market to them? You can potentially maintain an anonymous or a semi-anonymous relationship with some user ID and such, but by definition, the reduced fidelity will mean a less successful marketing effort.

And that's just the beginning. There are a bunch of product issues too.

How, for example, do you support a basic "Past Orders" feature, if you never have an account for that user in your database? Or how are arrears, refunds, support tickets, and various other customer issues are dealt with? You can potentially store some contact data that you throw away after a certain time, but it does dirty our userless model quite a bit.

There are also other issues. In my food delivery example, I assume that the payment options are stored on the device. You could even imagine, with things like Sign-in With Apple, that the entire user information is channeled through the device, or a single company that hides the identity of the user, but provides just enough data for the task at hand.

This might appear as merely moving the responsibility from one place, the service, to another, the device and its manufacturer. There's a decent reason to believe, for example, Apple does not store user profiles through actions that happen through its payment and identity solutions, but not everyone is in their ecosystem. What happens all this goes through Google, or WeChat, or Facebook? And who is to say Apple won't ever change?

And there's the ugly.

The Ugly

Not storing any user data may not be an option for some businesses.

When you do not ever store data about your users, you are not just dropping a ton of features, but also making tremendous sacrifices in terms of safety and security. As more and more of the world is moving online, the electronic data trails spread across various services are not there for feature development, but also due to regulatory and compliance reasons.

For example, you can't have a service where you move money across borders without running into various KYC, AML, and sanctions screening regulations. Even within a single jurisdiction, certain types of interactions mean that you have to store data on users for long periods.


Yet, I find this an instructive way of thinking about users and their data.

A good model here is the notion of staggering data collection and verification until you need it. Instead of knowing everything about your users beforehand, you ask them what you need at the moment you need it.

None of this is really rocket science, mind you. For example, when I floated this idea on Twitter, a bunch of people commented with how e-commerce sites moved to a model of creating an account after the purchase is made. A few people mentioned how Craigslist, for example, allowed you to participate almost fully without ever creating an account but always relegating things through verifying things via email for every interaction. 

I've mentioned you can see the outlines of this approach in Apple's strategy. There are some selfish motives here; Apple would prefer more things happen on its devices than on the web where Google and Facebook dominate; hence, things like Sign-in with Apple and Apple Pay. 

However, finger to the wind, this is where most of the regulation outside the US is moving towards also. One of the core tenets of GPDR is this notion of intentionality. Companies are to make it clear to users what they need the data for and use it only for that purpose. You can't, for instance, ask people to verify their phone numbers for 2-factor authentication and then use that number for marketing.

I'll be the first to admit there are huge gaping holes in this idea. Yet, both as someone who cares about where my data ends up, but also someone who wants to, sometimes use an app to get something done and not deal with it later, I find this idea quite intriguing. Maybe there's something here.

👋 Hello New Readers!

Ranjan and I use this space part as a way to think out loud and part to connect with people shared interests. We recently got a big surge of subscriptions through long-time reader (and occasional VC) Hunter Walk’s plug on Twitter. Welcome! The Margins is a labor of love, and the connections we make with our readers are the purest, most awesome form of rewards.

We command a sizable audience, and one (I assume) that’s relatively wealthy, well-connected, and influential. So I have a personal request: if you are a new reader and found us through Hunter’s tweet (or not!), consider a donation to Human Utility Project, a charity that helps families pay their water bills. Hunter recently pledged his birthday as a fund-raiser and while that campaign is over, I’m sure he’d still appreciate it.

Thank you, and hope to have you all as readers for a long, long time.

What I’m Reading

What Really Brought Down the Boeing 737 Max? - A relatively technical piece from a pilot on the 737 MAX accidents. Is it the poorly educated pilots that’s at fault?

Crash Course: How Boeing’s Managerial Revolution Created the 737 Max Disaster? - A more economic and political look at the same issue. Is it the MBAs?

How Much Is Your Privacy Really Worth? - “No one knows. And it might be time to stop asking.”

Four Years in Startups - A good excerpt from Anna Wiener’s upcoming book.