As I've scaled Dataquest, one of the hardest things for me to come to grips with has been that there is no one right way to build a business. This may be surprising to you. After all, it doesn't seem like a very complicated truth. But the reasons why this has been a persistent belief for me are informative for others in my shoes.
When I started Dataquest, I didn't start with a top-down plan of how I was going to build a business. Instead, I started with a problem - in this case, that data science education wasn't focusing on teaching real-world skills. Most technical people that I talk to start a business this way.
As Dataquest started to scale and get thousands of users, I knew that I was solving at least some of this problem. But solving a problem isn't a binary endeavor. It's not either solved or unsolved. In my case, I wanted to solve the problem for more people, in more topic areas. This meant adding more breadth and depth to the product I had.
To do this, I had to scale the company. This is distinct from scaling the product. The company is the infrastructure that builds the product. This point is where things started to get messy.
Reading online about how to scale a small software company inevitably leads advice from VCs and accelerators. I personally read a ton of advice from YCombinator. The advice says to raise a seed round, then keep raising more money until you IPO (my summary is reductionist, but generally accurate).
There's nothing wrong with this way of building a business. The important thing I'd add, though, is that it's a way not the way. Unfortunately, it's often presented as the only way to scale.
Following this advice meant that I turned my focus from how to solve a problem to how to convince investors I could solve that problem. These are unfortunately two very distinct skills. You can be great at solving a problem without being great at convincing investors, and vice versa.
I see many other technical founders fall into this trap. I think it's because we're seeking determinism in the act of building a company. When you're coding and building, there are relatively straightforward ways to know pretty quickly if you're doing the right thing. While the same thing doesn't exist for building a business, advice from investors and accelerators can make the problem seem deterministic - "if you follow this checklist, you'll build a successful company".
Inevitably, that particular checklist means that the goal becomes raising money in a highly structured way. At some point, the way you're building the business and what you want to build the business for no longer align.
To combat this, my main advice is to first figure out what type of company you want to build, then work backwards to figuring out the way you want to get there.
This is another principle that seems quite simple, but is actually difficult to nail down. Figuring this out involves figuring out what you really value. Do you want to build a really effective product for a small group of people? Do you want to build the biggest business possible and reach as many people as possible? Do you want to be a manager or a builder?
It's only through answering these questions that you can figure out what type of business you want to build. And you're the only one who can figure that out.
In my next post, I'm going to dive into more depth around how to figure out what type of business you want to build.