Choices are Bad: The Anti-Settings Principle

Bee holding a 'no settings' sign

This is crossposted at

What's the most absurdly provocative way I can put this? Never imagine what your users will want! Apps must only ever do one single thing! If-statements considered harmful!

Yes, this is all pretty rich coming from the people who built a goal-tracking app with, if I'm doing this math right, multiplying out all the various settings... 73,728 types of goals. Not to mention all our reminder settings, pledge settings, ways to schedule breaks, settings for what happens when you derail, weaselproofing, etc etc etc. We've learned this the hard way, ok? Also we're exaggerating. Some settings are great. And Beeminder is a big beautiful bounteous beast that can do amazing things that we, the creators, have never thought of1 and that's wonderful and we're very proud. But there are some important rules of thumb that are counter to a lot of people's -- especially programmers', especially our own -- instincts. So listen up!

I know it's exciting to imagine far-flung use cases and to try to please as many people as possible but it's like Abraham Lincoln says: You can't please/fool all of them all the time. If you're very sure you've identified genuinely divergent use cases (and that you genuinely want to support both use cases, which as a startup you probably don't!) then maybe it's ok to add the setting.2 My rule of thumb -- and this is a necessary but not sufficient condition -- is to wait for a user to make an impassioned argument for their use case. Never add a setting speculatively, i.e., by imagining what a user could want. Default to total paternalism where you decide what the user wants.

Or look at it from a programming perspective. As you add more settings you increase the number of possible code paths and places for bugs to hide exponentially.

Literally exponentially! It's 2020 and we're all clear on what exponential means, right? Say your app has a few simple checkboxes as settings and your code needs to work for every combination of them. Then you add one more measly checkbox. You've just doubled the number of combinations. I mean, not always. Maybe your app is pristinely designed and your settings are beautifully orthogonal. But probably not.

When debating a design choice, never say "let's make it a setting!"

Need more reasons? We have a whole smörgåsbord for you to choose from! Documentation is much, much easier the fewer settings there are. Customer support even more so. And if you add a setting that turns out to be stupid, someone will get attached to it and it will be a big ordeal to get rid of it. Worst of all, it's all too easy to add a setting due to uncertainty about what the right design choice is.

"I guess we can ship that as long as we include a setting to opt out of it" should be a glaring red flag. We've violated this a lot and I suspect we were always dead wrong to do so. An especially painful example was when we shipped a now-defining feature of Beeminder that both doubled our revenue and made Beeminder drastically more effective for users. We called it precommit-to-recommit at the time. Now we don't call it anything because there's no such thing as anything but precommit-to-recommit. But that's my point. At the time we were too timid to ship that -- goals that automatically continue and recommit you when you derail -- without a setting to opt out of it. Which was a massive thorn in our side and source of complexity, user consternation3, and technical debt for years.

Here's one more reason to eschew settings: they're a burden on users. In "Chapter 3: Choices" of Joel Spolsky's User Interface Design For Programmers he argues hilariously against adding settings for most things, focusing on how baffling or obtrusive excess customizability can be. In a similar vein, see Basecamp's exhortation to "Make Opinionated Software". Your app should not be flexible and agnostic. It should take sides and have a cohesive vision.

Anti-Settings and Anti-Magic

If we wanted to get fancy or philosophical we could say that the Anti-Settings Principle and the Anti-Magic Principle are special cases of a more general principle: "try not to let the business logic branch". Of course, most of the time there's no choice (about there being choices). That's just what the business logic is. If X then do Y else do Z, etc etc. But, just... resist it. Ask yourself if the business logic inherently must bifurcate or if, at least for the initial implementation, you can take just one of the paths. When you come to a fork in the road, do not take it. Pick a single tine. Bifurcation will bite you. This also relates to software engineering concepts like premature optimization being the root of all evil, and YAGNI.

Don't Take Our Word For It

I think this is all becoming very conventional wisdom despite how hard-won it's been for us. The huge open source encrypted messaging service, Signal, sums up the Anti-Settings Principle nicely as item number one of their development ideology: "The answer is not more options. If you feel compelled to add a preference that's exposed to the user, it's very possible you've made a wrong turn somewhere."


Image credit: Faire Soule-Reeves

Blog-Post-Driven Development

A bee swimming in documents

This is crossposted at

It seems like every time I talk about principles of software engineering to you all I get jaw-droppingly insightful replies. No pressure.

Ok, if you google "documentation-driven development", it seems to be a lot of people saying that documentation is so important that you should write it first blah blah blah. But I think there's a deeper insight here that I want to run by you.

Making design decisions -- like deciding what to build -- is really hard. (That's not the deep part yet.) We live and breathe Beeminder and we wallow around in its code all day long. Even if we were to establish design criteria like "reduce cognitive load" our first-line thoughts on these are different than our users'.

Power users may live and breathe Beeminder all day long, but we know how the literal bits go together, which parts are wonderful, and which are eldritch abominations. When coming up with ideas, we will naturally discount those which are difficult to implement. Ease of implementation is good to factor in to the decision-making but not good if it shapes what the decisions even are and what ideas are even thought of.

A trick that helps us decide what to build (we're finally at the deeper insight part now) is to pretend the thing exists and fully write up how you'd describe it to users, both new and old. I've been surprised how much clarity I can end up with about the right thing to do by doing that.

"Pretend the thing exists and fully write up how you'd describe it to users"

I sometimes call it blog-post-driven development even though I haven't done this on the blog before, just beemails and forum posts.

There are downsides to actually publishing the posts. When I floated the idea of requiring a credit card in order to create a goal, everyone freaked the frack out and we were too scared to do it for years. Then finally we did and it was immediately obvious that it was way better and no one (well, maybe literally one person) minded a bit.

But you can always write the documentation or blog post and not actually publish it until the thing it describes exists. Which is the point: let the documentation guide what you build. I feel like I need to say it another way to drive home the profundity of it. Maybe in another language? So far I'm making it sound too obvious. I think the key, and the part that you need to try for yourself, is to put yourself in the mindset of the thing already existing and then start writing. That forces a lot of design decisions that you'd otherwise weasel out of making by writing things like "and then we'd either do X or Y". Not allowed! Commit to a decision and see where the document goes. You'll often back yourself into a corner and have to backtrack. Which is wonderful, to be doing that before any code is written instead of after. It's a lot like writing a spec.

So that was the armchair quarterbacking. Now let's actually try it. I'm using a design question we've been heatedly discussing: the right way to make do-less goals have teeth.

Fictional Feature Announcement 1: Auto-Derail

This is all in italics and block-quoted so you don't forget that it's all make-believe at this point. I mean, at least three of these are make-believe.

We've had Pessimistic Presumptive Reports (PPRs) for seven years and they're so much better than nothing but still are so gross, magically adding made-up data to your goals. The problem they solve -- Beeminder goals must derail if you ignore them -- is as critical as ever but today we are announcing a better solution: Auto-Derail.
Auto-Derail is like PPRs but much simpler and much more draconian: instead of gradually derailing you by eating through your safety buffer if you stick your head in the sand, we just force-derail you immediately if you hit your deadline without having entered data for that day. It's like an ultra-PPR, but doesn't touch your data.
And it doesn't have to be immediate. Auto-Derail is specified as a number of days you're allowed to go without entering data. By default this is zero for do-less goals, 30 for do-more goals, and 7 for weight-loss goals. But you can set it to whatever you like. You can effectively opt out of the whole feature, just like you can opt out of PPRs, by picking a huge number of days as your auto-derail.
I personally (as user-me) am excited to have a zero-day auto-derail on do-less goals like my sugar consumption. I used to let PPRs come through and then every couple days I'd correct them (if I could remember -- otherwise I'd estimate or let the pessimistic amount stand). Now I'm grateful for the greater discipline of a red goal screaming at me to enter my number by the deadline. It's like any other beemergency this way.
What about scheduled breaks, you ask? It's already the case that you need to turn PPRs off before going on vacation. (Actually there's a trick you can use to give yourself safety buffer for a vacation without turning off PPRs but it's obscure enough that it might as well not exist. The right answer to this is a future feature we call True Breaks.) So with auto-derail you just also have to remember to turn up your auto-derail to be more than the number of days you'll be going offline. That's bad, having to remember to do that and especially having to remember to undo that when you come back, but since the previous status quo was as bad or worse in that regard we feel good about shipping this feature first and then improving scheduled breaks separately.
Bonus: This also solves a potentially frustrating corner case discovered by Grayson Bray Morris where a change in slope in your road can mean that PPRs take way too long to derail you. With auto-derail there's no uncertainty about how long you can go without entering data -- on any goal, not just do-less -- before derailing. It's exactly the number of days you specified.
Here's a big question you probably have at this point: How does your graph indicate how close you are to derailing? If you're deep in the green based on how far above the the yellow brick road you are on a do-more goal, how does the graph reflect that really you're in the orange because you've almost used up your number of days before auto-derailing? I guess I better answer it! The answer is that we've written new code (beautiful, shimmering new code) to make all the countdowns show the minimum of the normal countdown and the auto-derail countdown and we've overlaid a ticking time bomb graphic on any graph where the auto-derail is due to happen before the regular derail.
Does that mean that a do-less goal will always have a time bomb on it regardless of the auto-derail setting? Sigh. Consistency dictates that it does. It goes away when you enter a datapoint for today but you generally do that at the end of the day and the time bomb reappears as soon as your deadline is past and it's the new day.

Aaaand, emergency eject. It was going so well and then things started getting pretty dicey. If we were dead set on auto-derail we'd have our work cut out for us to flesh out that time bomb idea. Instead, let's move on to another approach.

Fictional Feature Announcement 2: Customizably Pessimistic Presumptions

What if we doubled down on PPRs and improved them?

Pessimistic Presumptive Reports (PPRs) are critical for do-less goals but they've felt really wrong to a lot of people and for good reason: they're magically adding made-up data to your goals.
Today we are announcing a simple solution: When you create a goal to, for example, eat less sugar, we include a step where we say, "if you don't tell us how much sugar you ate we're sure as heck not presuming zero so tell us what we should presume!"
Now PPRs are both less magical and less made-up, since you pick them explicitly. You can also change them any time in settings.
We encourage you -- by which I mean the UI encourages you by defaulting to it -- to pick a PPR of twice your daily rate, same as the previous status quo, because that has a nice property: Just as with flatlining on a do-more goal, it means that you lose a day of safety buffer with each day that you ignore the goal.
If you want to be forced to enter data every day on your do-less goals (as I personally emphatically do) you can just choose a PPR of (in my case of dessert/candy-minding) twice your body weight in sugar or whatever amount is more than any safety buffer you might ever accumulate.
And you do have the choice to set your PPR to zero if you really want to. We don't think you should and mildly discourage that by still putting the ugly PPRs in your list of datapoints regardless. We consider implicit zeros on a do-less goal to be anathema. If a zero is being graphed on a do-less goal, it's going to show up as such in your datapoints. This also means you can no longer delete datapoints on do-less goals -- only edit them.
But as always, entering a real datapoint makes the PPR self-destruct.
The hard part about this was generalizing all the graphing code to understand arbitrary PPR values, as well as the now special case of "whatever twice your current daily rate is". It's also not great how many users will likely insist on picking ill-advised PPRs and make themselves infinitely safe, which may look weird or ugly on the graph, not to mention defeating the point of Beeminder. But we're all adults, right? The interface makes clear that you shouldn't touch the PPR setting unless you know what you're doing.
Bonus: Weight loss goals now work much better! In the old status quo if you had a very shallow yellow brick road and then fasted or got sick and found yourself well below the road, you'd suddenly have an absurd amount of safety buffer and be able to stick your head in the sand avoiding the scale while actually gaining weight. You'd back yourself into a corner where, by the time you finally had to weigh in, you'd be hopelessly above your yellow brick road. (Many of us resorted to meta-goals until now, a separate do-more goal for actually stepping on the scale most days.) Now, your "max daily fluctuation" is also your PPR. So your weight-loss goal never lets you go long without weighing in.

That went better! (The weight loss bonus part applies to auto-derail too, of course.)

Fictional Feature Announcement 3: Meta-Goals Now Come Standard

Here's a very us approach...

We've had Pessimistic Presumptive Reports (PPRs) for seven years but they're so inelegant.
Fundamentally, the problem PPRs solve is to force you to enter data on your do-less goals. Do-more goals don't have that problem because if you don't report on a do-more goal we presume you did nothing and that eventually derails you. PPRs were a kludge to make that be true for do-less goals as well. If you didn't report on a do-less goal, we'd presume you did more than your daily rate. That would eventually derail you.
Well, we have a much better way than that to force you to do things. Do you know what it is? It's Beeminder.
From now on, when you create a do-less goal, we automatically create a sister goal for it that ensures you enter data.
Isn't that overkill? Too much clutter on your dashboard? Confusing for newbees? Yes, yes, and yes. Which is why we hide the meta goal and automatically populate it. As part of do-less goal creation we ask how many days per week you want to commit to adding data. That generates the meta goal -- a do-more goal that gets a +1 whenever you add a datapoint to the do-less goal.
Then a miracle occurs. We show you only your primary goal in most cases but give you access to the meta goal when you need it, without that being bewildering to newbees.

Ouch. Moving on.

Fictional Feature Announcement 4: Hitting Users With Hammers

I think this rounds out all the possible approaches to forcing users to do something. We know that nagging can never suffice so there have to be some kind of consequences.

Pessimistic Presumptive Reports (PPRs) are no more!
How do we ensure that users don't stick their heads in the sand on their do-less goals and accumulate infinite safety buffer, you ask?
We simply hide all your other graphs if you end the day without entering data on any do-less goal. Now, when you look at your dashboard, if you have any do-less goals without a datapoint for yesterday, all your goals except those goals will be blurred out. So you have no choice but to enter the missing data first.
A message at the top of your dashboard, as well as on the graph page of each blurred-out goal, will explain what you need to do and link you to the most urgent do-less goal (ties broken arbitrarily) that's missing data.
And what if you only have do-less goals? There are no other goals to blur out so in that case we hit you with the only other hammer we have: After 7 days of no data, and lots of warnings, we delete the goal! Use it or lose it, beetches.

That's sounding extreme enough to abort for now, though I'm not convinced that something like that couldn't work, if done really thoughtfully.

Back to Reality

It felt weird to write those. I guess I'm not used to writing fiction. Or it just weirds me out to write things that aren't true. And at least some of those fictional feature announcements can't ever be true, since they contradict each other. Which is the other reason it felt weird: Writing each one I started to feel attached to it, like it was truly the Right Answer and the thing we really should do. At least at first. Then as I was forced to think it through well enough to cover everything users would need to know, the cracks started to appear. Which is how I know that none of these proposals are ready to start building yet! That seems obvious looking at the proposals now but it genuinely wasn't until I went through this exercise.

I'm now excited to debate with you all, both at the meta level, about blog-post-driven / documentation-driven / spec-driven development, and at the object level, about which of those fictional features we should actually build.


Image credit: Faire Soule-Reeves. Thanks also to Faire Soule-Reeves, Adam Wolf, Mary Renaud, Christopher Moravec, and (as always) Bee Soule for reading and commenting on drafts of this. Adam Wolf was especially helpful in thinking through all the fictional feature announcements and even co-authoring part of the intro. Thanks also to all the daily beemail subscribers and forum participants who commented on an early version (without the fictional feature announcements, though an early version of one of those was also in the forum).

Upside-Down Support

A workerbee making an assembly line of humans do its bidding

By popular demand... (I.e., thank you to our fantabulous community for the impetus to write this post!) This is crossposted at

Not to brag but our users are constantly telling us that Beeminder's customer support is shockingly good. The best they've ever seen, even. Long ago we wrote about our secrets of success in "Beehind the Curtain" and that's all still true and it's one of our classic posts that we refer to all the time. Today we're sending our users out of the room to tell our fellow startups and small businesses more about one of those secrets, and, importantly, to give it a concept handle.

Upside-down support is what we call it when we turn a support request from a user upside-down and ask for the user's help to improve the app or website the user needs support with. We've collected various techniques for doing this over the years and it makes so many things in support so much better. We even have a much better way to say no to users!

First, in case any of our users are still in the room1, we should emphasize how great this is for everyone involved2. It turns out that trying to be the diametric opposite of helpful to users in support delights them all the more. Weird, right? But less weird than it sounds. Let us explain, first by quoting ourselves from seven years ago, since this has clearly stood the test of time:

I spotted this in an old email from one of us: "Let me know if there's anything else I can help you with!" Perfectly informal and sounds so friendly and helpful. But I’ve come to believe that it backfires.

First, people are thoroughly cynical about companies wanting to "help" them. Second, psychology! People want to help people. They go out of their way to do so. People are nice, even altruistic. They don't want to take up our time asking questions.

When we were just getting started and willing to do pretty much anything for our initial users, Melanie, our resident fitness expert, would offer advice and coaching and people would think to themselves "well, that’s not fair, I’m not paying for that".

You can bend over backwards offering help and it makes users feel guilty or suspicious and ignore you. If you ask them for help -- or make clear that asking you questions is not a burden but a vital form of feedback that you need for improving the product -- then they respond effusively, and bend over backwards to help you.

It's an empirical fact. People respond better to helping us than us helping them. To be clear, this is no gimmick. Users only need our help in the first place because our website sucks. We're not helping them, we're just making up for the sucking (and learning how to unsuckify it). So no matter how much you help someone, don't talk about it that way. Turn it around and explicitly thank them for helping you suck less.

Since we wrote that, we've really doubled down. How so? I'll start with a fictional example from our job posting for new support workerbees. The scenario is a user who's being kind of obtuse and a little demanding:

Hi! Oops! Sorry! I didn't submit my information on time again and then I didn't notice this until today so the charge has already gone through. This wasn't a legitimate charge because my cat ate my phone and I couldn't enter the data. Afterwards, I hit the wrong button (button A) again instead of... button B, I think? So now my goal is broken again. Can you fix that for me? I know there's a way for me to fix it, but I've been really busy this week and I just can't remember how it works and keep breaking it.

One goal is to make them happy, of course, but our primary goal is to turn the interaction upside-down and make it about helping Beeminder. Here was my own off-the-cuff attempt, pretending I was in support replying to that person:

hey userperson! eek, we need your help! can you show us a screenshot and write down some of your internal dialog so we can figure out how to make this button-A-vs-button-B thing easier for people? and then the same for fixing it (button C is probably what you're thinking of). the fact that you can't remember and worry about breaking it is really important for us to understand better. (if you do break it, we'll of course fix it for you; we just really need to understand how that kind of confusion/frustration arises.) thank you so much for helping making beeminder better!

ps, i did the refund for this goal. it really helps us when you can reply quickly when something's not legit.

Here's a non-fictional example where a user called non-legit on a derailment because they didn't get Beeminder's reminders and we replied like so:

Yikes, that's extremely bad that the Beeminder emails stopped coming through for you. Can you go to and confirm that the checkboxes for email are still checked? You can also go to an individual goal's settings tab and send a test reminder and see if that comes through. Really appreciate your help figuring out what went wrong there! Deliverability problems with email could be devastating for us.

PS, canceled the charge and undid the derailment on your ____ goal.

In both cases above, we ignored the user's actual request (until addressing it in a PS as an afterthought) and instead recruited them to help diagnose what went wrong. Importantly, we include "user was confused" as something going wrong with Beeminder!

(Clarification from Support Czar Nicky: In the case of an actual refund or canceling a charge, it's probably worth making it a prescript rather than a postscript. It can still be written as incidental, just that users can be very anxious until getting the reassurance that their money's safe and sound. After that they can better engage with the rest of the reply!)

I think doing this is harder than it seems. For my cofounder and me, it comes a bit more naturally. Beeminder is our baby and whatever caused this user to email you, it's ultimately our fault and it stings and our thoughts immediately go to how to fix the root problem -- how to make Beeminder better.

But even for us, it's taken training and practice and pushing ourselves out of our comfort zones. Our support workerbees -- Nicky and Simone and Robin -- are extraordinarily good and kind humans and every instinct in their bodies screams at them to leap to your assistance when you email support with a problem. So it takes very conscious control to flip the interactions upside down.

Tips and tricks

Big companies have ruined most variants of "thanks for the feedback". Here's a way to not just express appreciation but demonstrate it:

Keep this kind of feedback coming; hugely helpful!

I like how it's particularly unapologetic about the upside-down-ness. It's literally an imperative: keep doing this (because it goes without saying that the point of support is improving Beeminder). Or here's a less direct version:

Ok, I fixed your thing; thanks for highlighting the confusingness of this; it really helps us figure out how to make this work better for newbees!

Sometimes it seems like there's no way to turn a support interaction upside-down. The user has some problem, only you can fix it, so you do, and now you need to tell them you did. Even then, we reframe it as helping Beeminder. Think about what the ideal version of Beeminder would've done to have avoided the problem in the first place.

Oh no! I think ideally Beeminder should __ or __ in a case like this. Or maybe ____ would make it moot? Thanks for the help in thinking this through!

PS: I fixed this for you for this instance.

Next trick, from Support Czar Nicky again: for any support interaction which isn't 100% routine, you want to come away with at least one piece of useful feedback. For instance, we often get people asking us to put in breaks because they won't be able to enter data. It'd be easy to just do that, assuming they forgot. Don't assume! You've got to ask. So here's an example:

Oh no! Normally when you need breaks, you need to put them in a week in advance, because of the akrasia horizon. It would help us a lot to understand better how that can go wrong for people. In your case was it (a) not knowing how to put in breaks or (b) not knowing you needed to do it in advance? I've gone ahead and put in the break for you since it's too late for you to add it yourself, but definitely let us know what tripped you up! It really helps us figure out how to improve the interface and the documentation.

A better way to say no

Suppose a user is all entitled and asks for special treatment in some way, like, "can you short-circuit my pledge to go straight to $810? I don't want to pay for a month of premium to do that for just that one goal?" We're way too fairness-obsessed to say yes to something like that, but upside-down support gives us a much better way to say no than something like "I'm sorry but our policy is...". We can instead do this:

Hi ____, I sure love how you think! And this is also really good feedback that it feels a little ... unfair? money-grubbing? I'm not sure how to put it... that we don't let you set your own pledge level without the fancy premium plan. Some of the history behind our thinking on this is at

​Actually it would be really good to have you read that and see if it changes your mind about our stance on this, or if you have ideas for us on either how we could convey this better so that it seems more fair or, if it doesn't convince you, what actually would feel the most fair to you.

​​Thanks so much for all the beeminding and helping us think this stuff through! Can we send you stickers? Tell us a postal address if so!

That's not exactly a no. The door is open a crack to change our minds, but they'd have to make the argument from Beeminder's perspective, not their own. (Also notice that they're getting stickers as a consolation prize.)

Don't be helpful!

In conclusion, don't do things for users that they could do themselves. Point them in the right direction and ask for feedback about how easy it is to find and do. And even when the support request really does require you to do something for the user, always explicitly shift the focus to the user helping you (the business/startup/app), not you helping them.

I also want to re-emphasize the genuineness of all this. We really do need users' help in understanding what Beeminder could've done better to have avoided the problems users email us about -- figuring out the root issues. And asking for help is really hard. But it's worth it and we've gone to great lengths to overcome our fear of doing it and Beeminder support interactions tend to be pretty amazing because of it. Well, that and our amazing support workerbees.


Image credit: Faire Soule-Reeves

Strategy Memo: Beeminder Is For Nerds

Beeminder logo wearing nerd glasses and a pocket protector

This is crossposted at

For years we've gotten advice to widen our appeal. We shall now explain why you're all wrong1.

Let's start with an intuition-shaping factoid: GitHub is focused 100% on developers even though writers and designers and many other categories of people could be -- ought to be! -- using version control. (Additional factoid: GitHub was worth $7.5 billion when Microsoft bought them, with tens of millions of users -- all programmers.)

And Facebook, despite all its mainstream appeal now, started out focused exclusively on college students. Harvard students, specifically. In fact, their early growth strategy was to very carefully and deliberately add a single university at a time and only much later expand beyond university students.

Or take Habitica -- bigger than Beeminder while catering strictly to people so nerdy they're into RPGs. Or Discord, a perfectly general chat app which got huge by focusing on gamers. They have like a quarter billion users and only relatively recently showed any interest in anyone but gamers.

Running with the GitHub-is-for-devs example, you can imagine how they must make all their design and strategic decisions: "What works best for Daphne the Developer?" They're not afraid to scare off novelists who don't know programming lingo. GitHub is brilliant for novelists and there's nothing stopping them using it, but that's not who GitHub is for. There's a lot of value in only having one kind of user to worry about. Product design and making users happy is hard and gets combinatorially harder the more kinds of users and use cases you have to support.

"Beeminder is probably not for you"

For Beeminder, we make all decisions from the perspective of what's best for Quentin the Quantified-Self akratic ambitious self-aware high-integrity lifehacking graph-loving data nerd. Also he loves puns. If none of that speaks to you then, for now, Beeminder is probably not for you. We don't want to actively push you away, we just need to only be thinking about our core demographic.

We should emphasize that there are plenty of issues with Beeminder's usability to this core demographic; more on that below. Also, I'm exaggerating how narrow our core demographic is. "Data nerds" probably suffices.

Isn't that placing an unnecessary fence around expansion?

Counterintuitively, it's the opposite! Paul Graham explains it pretty well in the "Well" section of his essay on startup ideas. He describes two types of startups: those that a large number of people need a little, and those that a small number of people need a lot. (He also explains why startups can't be the best of both, and why he calls the second type "digging a deep well".)

Nearly all good startup ideas are of the second type. Microsoft was a well when they made Altair Basic. There were only a couple thousand Altair owners, but without this software they were programming in machine language. [...]

In practice the link between depth and narrowness is so strong that it's a good sign when you know that an idea will appeal strongly to a specific group or type of user.

Or here's Patrick McKenzie of Stripe in an old Twitter thread explaining why the book "Writing for Software Developers" is focused on software developers when there seems to be no reason for it not to be way more general:

It's an artifact for the consumption of software developers which includes basically no software.

It's a book about writing which intentionally anti-targets 99.99% of writers.

Why? Because constraining the topic to the needs of software developers specifically makes the artifact much better (you know you're writing for someone who cares about e.g. blog posts to get senior developer jobs and not midlist fiction, and can tailor advice appropriately).

And note that you certainly could have hypothetically written Writing For $PROFESSION for literally any profession but choosing Software Developers means you structurally have a client who has effectively infinite budget for books which deliver career effectiveness.

This lets you *clears throat* Charge More.

Or here's a different old Twitter thread where he's talking about businesses rather than books, though it's all the same lesson:

When I was consulting life got better in every way after I said “Eff it: B2B SaaS businesses, $10M to $50M in annual revenue, probably engineer-led” as the target market. Pitches got crisper. Results got better. Rates went up.

What does this mean we should do?

It's mostly about what we shouldn't do. Like if we're, say, explaining a hypothetical new feature to show a non-cumulative version of graphs, we can call it a derivative and not bother to define what a derivative is2. In other words, we should do what comes naturally to us. When talking amongst ourselves, it wouldn't occur to us define terms like "derivative". So the main thing to do is not hold back -- let our freak flags fly!

At this point, when this was just an internal memo, I emphasized that I was less certain about this than I sounded. Now it seems almost obvious. But also it matters less than it sounds in terms of Beeminder's roadmap. Regardless of the degree to which we want to double down on nerds, there's a long list of things we need to do to make Beeminder better for nerds and normals alike. Things like lifecycle emails, smoothing onboarding friction, getting confusing advanced shıt out of sight of newbees, fixing the miasma of brokenness with scheduled breaks / ratchets / weekends-off / restarts, interactive graphs and and The list goes on and on and there's a huge newbee focus in most of it.

When normal humans can pass hallway tests -- and it's critical that they be able to! -- only then, at the earliest, should we think about adjusting copy and marketing and UI and everything to target them. In the meantime, almost all our onboarding and newbee-related problems have best-of-both-worlds solutions. We're not backing ourselves into any corners (not more so than we already are, at least) with our nerd focus. The work ahead of us, at least for some months, involves improving onboarding and reducing confusion in ways that applies equally to nerds and normals.

At some point we'll find ourselves deciding between choice A that's better for QS-y Quentin and choice B that's better for Normal Norman and that's when we can revisit this. (But probably the answer will be a resounding "Choice A! Norman can suck it" for the foreseeable future.)

Other benefits of focusing on nerds

First of all, it helps our own focus, our clarity, even our motivation to be helping fellow nerds. Relatedly, our distinctive voice and vibe and culture is pretty key to us having True Fans (which holy cow do we ever have, and it feels amazing). Next, being a bit exclusionary -- even alienating users who aren't quite your target audience -- attracts and endears and generates passion among those who are. They feel part of an in-group.

As a bonus, nerds tend to be easier and more valuable in support. Maybe sometimes they can be a bit much, but very positive on net, we've found.

Troll filtering and expectations management

It's infuriating when people leave low-effort 1-star reviews in the app store. Sometimes they do that without even logging in and there's little we can do about that. But -- and this one is more conjecture so far -- making it obvious that Beeminder is for nerds (equations on the splash screen, we're not sure yet) will tend to make those trolls' eyes glaze over and not bother trolling.

Or imagine someone who's like "Goals? I have goals!" and starts signing up and then sees graphs and numbers and is like "WTF? 1 star." The more front-and-center the graphs and numbers are, the less likely they are to feel frustrated and disappointed.


Take our oldest competitor,, targetting anyone with goals. Or you could say they target anyone who's akratic -- those who struggle to stick to their intentions -- but that's still far too broad a swathe of the population. They're clearly trying to have mainstream appeal and they just end up being, well, StickKly.


On that slightly meanspirited note, we rest our case. Broadening our appeal too soon is at least one classic startup mistake we've avoided. We can cross the chasm in due time.


Image credit: Faire Soule-Reeves