On Failure Points

2026.10.25

CLXXV

[Death by a Thousand Cuts; Failure Points; Deleting the Unneeded; Opinionated Automation; Systematize The Inputs; Software as Art]

Thesis: Every time your user gets confused is a chance for you to lose them.

[Death by a Thousand Cuts]

If a user experiences too many bugs or hits too many failure points while using your software, they will start blaming every problem related to the software on the software itself.

This is bad, because at some point they’ll lose faith that they can get the software to do what you advertised.

Think about what happens when you first buy a piece of software: you're excited to use it to do what you bought it to do.

The first time something goes wrong, you might get a little upset or confused - did you mess up here? Is it your fault? You'll probably invest a little bit of time in trying to work around it and figuring out how to get it to do what you want. In other words, you'll be giving the software the benefit of the doubt.

The second time there's an issue, you're more likely to think that it's the software's fault. The third time, you're even more likely to think that.

After some number of times, you'll hit a switching point: you'll now believe that the software is 'just buggy'. This is really bad for the software creator, because now whenever an issue comes up, your instinct will no longer be to try to solve it, it will just be to think that you're dealing with a buggy piece of software that the creator needs to fix.

When this happens, feature requests become bug fixes (why doesn't it do this thing that it doesn't say it does anywhere?) and customer support sky rockets.

It's a gradient across your customer base, of course, but we've experienced more of this than I'd like to admit at WhiteWhale. It a disease that terminates with a customer thinking your software is unusable. They might be nice and say "I don't think it works for my use case" but this translates to, "Your software is unusable."

As I've spent the last couple of week spam fixing failure points and bugs, we're realizing just how much better a User Experience can be when the number of failure points and bugs is cut even in half. Obviously, we think fixing these failure points is more important than the rewrite I mentioned a couple of weeks ago, or we wouldn’t be spending our time on it now!

We'll do a brief tour of 3 recent changes we made, and how each one is an example of deleting, automating, or systematizing something we were asking our users to do; but first, more on failure points.

[Failure Points]

It's really not just bugs in the conventional sense that you need to worry about, either. There's this other part that Jack & I have taken to calling 'failure points'. (I'm sure there's another name for it somewhere.)

A failure point is where a user's ability to get value out of our software is gated on whether or not they make a certain decision or configure something right.

In all honesty, some of this shit is worse than bugs, because you've designed your product so that some percentage of users have to make one of these decisions.

Imagine adding a multiple choice test that popped up every 5 minutes to your SaaS. Any user had a 95% chance of getting it right; anyone who got it wrong would just get to experience a random bug that reduced the value they received by anywhere from 5% to 100%.

And, if they got it right... well, the software keeps working! Still, they actually don't even know if they got it right, because you don't tell them. After all, you were framing it like it was about their opinion, not objective reality.

If this was your SaaS, you'd get rid of the stupid pop ups every 5 minutes in a heartbeat.

This is what a lot of failure points are like. Yeah, some configuration and user input is needed, but we know we're asking for way too much. How many fewer people would buy iPhones if the setup flow required reading 3 essays and cross referencing technical documentation? What if you had to select 5 settings with no defaults before you could use iMessage?

Most of your buyers will not want to do that.

You can slice and dice this class of failure points a million different ways, but I always go back to the one that Tim Ferris uses for business across the board: ones that can be Deleted, Automated, or Systematizes, in that order.

• Delete: The most powerful and the first to consider - can we just remove this failure point altogether?

• Automate: Can we automatically do whatever we were asking the user to do, even if we need to let them change it or roll it back later?

• Systematize: Can we force the user to make the decision in a very clean and clear way when it's actually needed?

I'll go through each with one recent example of a feature we've treated this way. To be clear, this delete / automate / systematize framing can be applied anywhere, but I'm applying it where users have to make decisions to make our software work.

[Deleting the Unneeded]

It's really easy to forget that for every feature, you just have the choice to delete it. Deleting it is always the best thing to do. It's less surface area and technical debt to deal with later!

As an example, we had a filter in our search functionality that let's users save ownership of account objects as part of a filter. This sounds fine, but these specific filters are used to help the users find more accounts.

So, if they do a search for accounts that they already own, we won't ever be able to find new accounts for them! (New accounts are inherently ones they don't own.)

This is a heinous failure point because it's a nuanced decision the user can make that doesn't really add anything. It's maybe not technically a bug because the SaaS does what it 'says' it will do... but if 1 out of 20 users use this feature, and each one has a worse experience because of it, it's pretty obvious that we should just delete it.

Don't get me wrong, there's a kind of nuanced case where it makes sense, but we've solved this elsewhere much more elegantly.

It would be over engineering if we tried adding more documentations or explainers around it, because even if we did, what would it really accomplish? If it's not a feature that drives value anyway, what does it matter?

[Opinionated Automation]

You can also just automate the decision making for the user, and maybe let them roll it back or change it later if they really want to. And, if you actually think it would be helpful for them to.

Our signals can scope the data they find based on publication date of sources. Users used to have to manually add this by entering into the signal "in the last x months." Now, we’ve updated this to do this on the backend no matter what as a default, because most of them wanted a 12 month lookback anyways.

Interestingly enough, if we asked our users what they wanted, they'd probably say 3 months, but in a lot of cases, we know they get better results if we can show them in our final output information from the signals that occurred over the last year.

However, if we go back further than a year, it's a total turn off, because it makes the data seem old and outdated. A lot of users just expect that it doesn't show them anything older than a year ago, either. But before we made this change, they had to know how to configure this to fix it. Now, they don't. Another failure point gone.

We also have many of the signals we generate still spell it out by including 'in the last 12 months' in the signal, so they know they can change it later by editing that string.

In this way, we've been opinionated about what the user needs: we believe that on average, our users will get the most value by gating signals to the last 12 months, so we automatically make this decision for them. If they want to make it tighter later, they can.

But, the default is automatically selected for them, and it's a default that works really well. This is now one less thing that they need to think about or be aware of to get value.

[Systematize The Inputs]

Something important for a user to do with a super customizable system like ours is to make sure that the output is exactly what they want. This is actually really, really hard to do, even when you have them on a sales call and can ask a bunch of questions.

If you ask people what they want, they'll tell you. But, sometimes they won't know what they really want until you show them what they don't want, or until you ask them the right questions.

I can't tell you how many times we've had users in a sales calls say they want to see companies in the US with 100-5000 employees with signal x, y, z. Then, when we show this to them, we hear something like, "Oh, I can only sell to companies on the east coast!" Or, "Oh, that company is too big!"

This is a strange thing that happens where they seem to either not know what they want or not really be thinking of it until we show them. So, one thing we're experimenting with to systematize this is adding a phase in setup where they review 5 samples of data and tell us which ones are good and which ones are bad and why.

We just pushed this, but are hoping it's a way to systematize collecting feedback from the users so we can use this as fuel to automatically make the configuration tweaks that will help them succeed. Thus, our systematization will feed into further automations.

If you enjoy following my journey of a two man bootstrap to $1M ARR, please subscribe below!

[Software as Art]

I'm of the view that a lot of artistic beauty comes from functional things. I'm not a purist in that sense, I also appreciate flourishes and what not.

I do think, though, that beautiful software is software that does the thing it's supposed to do in as simple as possible a way.

It can ask you to invest in it to learn it and make it better, but that ask needs to be proportionate to the reward. I love Neovim; even though the investment to get it functional is higher than a full ide, once you figure it out, many of the speed boosts are immaculate.

However, when you're building mass market software, you do have to realize that only a small percentage of users will ever care to invest much time in it anyways. Really, a lot of buyers are more willing to invest capital than you think, and less willing to invest time and effort than you think.

In that sense, it is quite beautiful when someone spends their hard earned money on your software, follows through the journey you've set up for them, and it just works. Then, if they want to get more out of it, they should be able to - but they should need to do as little as possible to get value.

Live Deeply,