Nobody starts off as a founder.
That’s significant since the roles we were doing before care about different things than founders do.
And whatever you did before instilled ways of thinking in you that may be holding you back as a founder.
This week I’m diving into how to think through and address this, and make sure you’re thinking like a founder.
Thanks for being a member! Since this is one of our ✨ members-only ✨ deep dives, you can read the full post below.
Shed Your Old Mindset
What You Do Directs Your Priorities
I started my career as a software engineer.
And I cared about the things engineers cared about.
For example, I cared a lot about writing high-quality, performant code.
In the 10 years or so since then I’ve launched my own businesses and worked on products going through true hyper-scale.
Don’t come after me for this, technical founders, but one thing I realized early on was that founders don’t really care about code quality.
Sure, good founders understand that having spaghetti code will hurt you in the long run, and that letting critical bugs go live on prod will degrade user trust…
But their first priority is making “the long run” possible at all by delivering the actual value that users want.
New founders often underestimate the amount of inconvenience or pain that users (particularly early adopters) will deal with in order to get what they came to your product to get.
Two great examples of this:
Pieter Levels’s Projects
First, I was reminded of this yesterday from this tweet where the founder shows how one of Pieter Levels’s popular tools has a bunch of pretty easy-to-fix-looking bugs.
Omg @levelsio website is full of bugs
— Dagobert Renouf (@dagorenouf)
2:36 PM • Aug 30, 2024
Pieter is a massively successful bootstrapped solo founder who has a ton of active projects generating revenue.
You might think that a well known builder getting exposed for having bugs in his product would be embarrassing, but the insight is that it actually doesn’t matter.
Pieter correctly identified why users would be interested in this product, what value it would be delivering, and he made sure it was able to do that.
Megaphone
When I started Megaphone as a fun project, I set it up using Zapier and Airtable.
Once it started generating revenue, I brought in an engineer.
Building the product on top of an Airtable backend has created challenges both for me and our users (latency, namely) but we’ve been able to add and retain hundreds of paying users despite this because the product delivers results.
Thankfully we’ll be moving off an Airtable backend this coming month, but the point is that it worked well enough for a year to allow us to focus on other priorities.
Are Engineers Wrong?
The engineer mindset vs the founder mindset is just one example.
The same is true in different ways if you were a designer, ops person, consultant, marketer, or something else.
This doesn’t mean those learned instincts are wrong, it just means that being a founder has its own set of priorities that are different than what you were prioritizing before.
I cared about code quality as an engineer because that’s something engineers should care about. It’s their job to build and maintain the codebase.
The founder has a different job.
And, in most cases for founders, the 80/20 rule applies:
Relentlessly focus on delivering value to your users first and, only if you succeed, you’ll reach the stage with your startup is stable enough and you can start letting your team members focus on the parts of their job that they uniquely will care most about.
Here’s a good example of that playing out at Linear:
A few months ago, we changed the way we address bugs @linear. We prioritized bugs over everything else. If you have bugs assigned when you wake up in the morning, you don't do anything else before they are addressed.
This approach felt scary and quite radical, but our theory was… x.com/i/web/status/1…
— Tuomas Artman (@artman)
8:17 AM • Aug 20, 2024
Get the next one.
One essay every Sunday on the decisions that make or break founders.