That code's going to get run like three times

If you’ve ever worked on a new tech product, feature, or service, the following scenario will probably sound familiar to you:

Shepherd: “I’m sick and tired of always having to be the one that brings the cows in from pasture. I wish I could get someone else to do that.”

Friend: “Maybe you could call and ask Anna and Joe’s daughter if she’s willing to help out a few times per week.”

Shepherd: “No no, I want to solve this problem for others too. Let’s build a mobile marketplace that matches up shepherds with people willing to help them take care of their animals.”

Friend: “I don’t know, seems a little overcomplicated to me. Can’t you just pin up a job posting at the tavern asking if anyone’s willing to help bring the cows in, then call around and ask a few other shepherds if they’re willing to help chip in if the new hire brings their cows in too?”

Shepherd: “No no no, I want to fix this for everyone. I want to start something. We’ll get flooded with requests from other people and won’t be able to keep up unless we automate this thing.”

… and so on.

By the end of this, the shepherd has spent a year hiring a team to build out a slick mobile application that matches up shepherds with people that will help them… and there are 10 shepherds who know about it, but 80% of them don’t use it because it doesn’t really match what they need. The shepherd has only talked to 2 of those people, and he’s not really sure why it doesn’t match their needs, but it sure is frustrating.

I would say this describes about… 99% of the new products or features that I write. I’m the shepherd here.

My new rule of thumb is that, until proven otherwise, I assume that all code for new products will get executed many, many fewer times than can possibly justify automating the task.

My pitch to the shepherd here: text a few of your friends, find people that want help, find someone who’s willing to help. Get out a pen and paper and figure out how to split the helper’s schedule. Text out the schedules to your friends. Rinse and repeat, get feedback on why your schedules are rotten, fix them. If you start to feel like sending a particular type of text is really repetitive and a giant waste of your time, then maybe it’s time to automate it.

Zipping back to the present, I genuinely believe that experienced engineers from big tech companies make worse technical decisions in early-stage products than people who have no idea what the heck they’re doing. We have so many preconceived notions of what counts as “real engineering” because it’s required to scale successful services (fancy databases, backends running in the cloud) that we completely forget that 99% of new services aren’t successful. For new things, you should be spending more time figuring out how to not build things (e.g. faking automated services through manual work) than you spend actually building them. Only automate processes when the manual part gets painful.

In my experience, the real villain in this story is “friction” - basically, however much harder something is to use because you didn’t do it the “real” way. In the above story, it’d be easy to convince yourself that the reason that shepherds/helpers aren’t signing up is because there’s no website to do it at, or there’s too much delay in receiving their schedule because it’s not automated, or any other way that a multi-billion dollar marketplace might be better than you texting some friends.

However, I almost always find that:

• Especially among early adopters, friction is less of a deterrent than you probably think it is
• Friction is more of a deterrent when you’re not talking directly to prospective customers, which you probably should be at the start
• While friction can be a deterrent, it can be mitigated by being upfront with customers about the early state of your product and making up for a poor quality product with customer service that’s drastically better than what they’d receive elsewhere
• Friction can be greatly reduced through manual work (e.g. responsive texting / emailing)

The problem is that, in rare cases, friction actually is a deterrent that prevents you from meaningfully testing your product. But that’s the exception, not the rule.

The seminal article on this whole space is Paul Graham’s Do Things that Don’t Scale - if you build new things and haven’t read it, it’s definitely worth a read. However, I read that article when it came out and still made all the mistakes that it warns against. Repeatedly. Builder beware.