Steering the ship

There's a common saying that when you start working for yourself — at least in SaaS — you go from having one big boss, to having hundreds of tiny bosses. I even joked about that in the beginning when I first went full-time on Keygen. But I haven't found that to be true in practice.

Sure, I have hundreds of customers — and thousands of users. But I don't really afford any of them the right to tell me what to do, or what to work on, or how to run my business.

I started working for myself so that I could work on what I wanted to work on. I was tired of being bossed around.

So I've made it a point over the years to not have mini-bosses.

One of your customers might have a good idea, sure, but most of the time their ideas are not that good — or good, but not fleshed out.

You see, users have a particular way of expressing problems, and one of the ways they do that is by asking for features.

Usually, what users ask for isn't what the feature they actually need, or it isn't a feature that's going to work for the other thousand people using the software.

That's totally fine — expected, even. They don't have the context that you do. They don't see how the other thousand users do things. They just know how they do things, or how they want to.

Their request is usually a simple solution to a very niche problem, and you need to de-niche it. But to understand how to de-niche it — to understand the problem — you have to not say "yes."

You can sink a ship by saying "yes" too often. It's death by a thousand feature requests, each one adding weight until — all of a sudden — you find yourself unable to stay afloat.

So I say "no" a lot. Like, a lot a lot.

But I also listen a lot.

If one customer comes along asking for a feature, and it doesn't seem like a good fit for everybody else, I tell them that we'll make a note of it but that it's not something actionable yet (and I usually do make a note of it on GitHub, unless it's one of my "hard no"s — like Keygen becoming a payment provider).

Sometimes what doesn't seem like a good fit becomes a good fit once you realize that feature request dots from tens of other customers over the course of a few months — or even a few years — start to connect and sprout something useful.

But my users usually aren't the ones who come up with that something themselves, I do. I spend days, months — years — collecting feedback, expanding my context, connecting dots, so that I can act in a way that I won't regret later on. So that I can act in a way that works for the individual, but also for the collective.

There are features I want to support but that I keep on the backlog simply because I don't fully understand the problem space yet. But that's okay — there's nothing worse than implementing a feature badly because you didn't actually understand the problem.

I've let good features sit on the backlog for years before implementing them, and that's because I decided to wait until I'm able do it well.

Every feature has a cost, and taking control of your ship can help avoid costly mistakes. Trust me — I've had my fair share.

You can build for your users without obeying them.

Until next time.