We grew from $0 to $150k in 6 months, then pivoted. Here's why.
Honest reflections as an early stage founder going through a pivot
When Nick and I started working on what would be Nucleus in December 2021, we had both felt the pain of building infrastructure platforms and felt compelled to solve this problem for other companies. Our core thesis was that companies shouldn’t spend 6+ months and 2-3 engineers’ time building internal developer platforms from scratch. Instead they should adopt an off-the-self platform that they can implement in weeks which would allow them to focus on delivering their core product.
After all, why spend all of that time and money to build and maintain something that you don’t sell when you can buy it? We spent time validating the problem with prospective customers and combined with our own experience, felt that there was a real problem to be solved.
Thanks for reading The Early Days by Evis Drenova! Subscribe for free to receive new posts and support my work.
We spent the first 6 months starting the company, going through YC S22 and building the product. We then brought it to market and started signing up customers. After 6 months of being in market, we had closed 8 customers, all with 3 year contracts, signed $150k in revenue and had doubled revenue every month.
On paper, everything seemed to be going in the right direction. We had a working product, customers and revenue. But deep down we both had this uneasy feeling we couldn’t shake.
We decided to take a step back and reflect on the last year. What was working? What wasn’t working? What had we learned? As an early stage company, it’s hard to pull your head up and reflect because there’s so much to do, but sometimes it’s exactly what you need to do. We spent the next few days having honest discussions about the company, market and product and it became clear that something needed to change.
My hope in sharing this is that it helps another founder or founding team who is going through the same thing. I don’t think our experience was unusual, in fact, in talking to other founders, I think it’s more common than we realized.
So why did we decide to pivot when we had something that seemed like it was working? Ultimately, it wasn’t just one reason but a combination of reasons and, in some ways, more importantly, feelings.
Here we go.
Dealing with founder psychology
I haven’t been a founder very long but I think most founders would agree with me that one of the biggest double-edged swords of being a founder is that you need to be persistent and optimistic to succeed but that persistence and optimism can also cause you to be myopic and rigid. The hard part is reconciling those two things and identifying when you need to double down on persistence or when you need to step back and see the bigger picture.
I think what makes startups so hard is that for every case study that teaches you to do one thing, there is another case study that disproves it. Airbnb worked on the same idea for 2 years with pretty much no revenue before hitting PMF while Segment spent 18 months pivoting before hitting PMF. Why didn’t Airbnb pivot? And why did Segment? There are countless stories on both sides.
It’s easy to pivot when your thing isn’t working at all and it’s easy to stay the course when it is, but it’s those times in between when something is kind of working that it’s hard to decide what to do. If you’re a year into a startup (like we were) and seeing some growth but not seeing the growth that you think you should be seeing, being intellectually honest probably means telling yourself that things aren’t working and that something (big or small) needs to change.
But optimism and persistence tells you that you’re seeing some growth and maybe you’re being impatient and just need to put your down head and forge on. But are you then ignoring that gut feeling that is telling that something is off? Are you being intellectually honest with yourself? How do you reconcile those feelings? How do you know when something needs to fundamentally change? These are all of the questions that were running through my head that I was trying to answer. Unfortunately, I don’t think there is an easy way answer to these questions. The best I can do is an unsatisfying, “it depends”. But what I do know is that if you’re asking yourself these questions, like I was, then you owe to yourself, your team and your investors to investigate why you feel this way and not just ignore it. These feelings kicked off a period of deep and honest reflection and eventually led to us pivoting.
I had this intuition that there was a class of problems that on the surface seemed like great problems to solve but in reality were terrible markets. I didn’t really know how to describe it until I saw this video and heard the phrase ‘tarpit problem’ and then it clicked. We were definitely trying to solve a tarpit problem. If you’re not familliar with with a tar pit is in general, check this out. How did we realize that we were trying to solve a tarpit problem and why didn’t we see that coming?
Let’s start with the second part first. The inherent problem with tarpit problems is that it looks great from outside, but it’s only once you get into it, that you realize its a trap. That’s why it’s called a tarpit! In our case, who wouldn’t want to save hundreds of thousands of dollars and 6+ months of time building something that they don’t sell when a cheaper and better alternative exists? The ROI and value seemed pretty compelling and the CTOs we talked to and the customers we signed agreed with us. The trap was that there were battling competing interests from developers and CTOs, too many table stakes features, market timing issues and competitors who were years ahead of us. It was the combination of these problems that led us to the conclusion that helping companies build, deploy and manage their services on Kubernetes is a tarpit problem. There are other companies that are working on this problem and this isn’t to say that they won’t build a big business solving this problem. They might. But we’re not going to be the ones that do it.
So back to the first part, how do you tell if you’re in a tarpit market and trying to solve a tarpit problem? Here are some observations that led us to that conclusion for our market:
We felt like we constantly had to build features to just get to table stakes and could never get to the point where we could truly differentiate ourselves.
The market was fragmented and our growth, while it started strong, wasn’t clear if it would continue at that rate.
There are a lot of open source alternatives and those alternatives are heavily leveraged.
There was a graveyard of startups that tried to do the same thing as us and failed
This video also really helped. After watching this video and spending a few days talking through these problems with Nick, it became clear that we were in a tarpit and something needed to change.
Market assumptions and the product journey
Before we started Nucleus, we looked at the competitors in the space and came up with a list of reasons of what we would do differently and validated that with early design partners and customers. We felt like we could ultimately build a differentiated product that would win. And our design partners and customers seemingly agreed. So what happened?
I think it comes down to the underlying assumption that we made about our market size and how our product would function in that market in the short and long term. One of our bets was that the market was big enough that several competitors can exist at once. In turn, this will allow us to acquire customers in the short term while building a differentiated product to win in the long term.
I think this is an easy trap to fall into for 2 reasons. The first is that most markets aren’t winner-take-all markets. There are many markets where there are seemingly a lot of competitors that do the exact same thing (Observability, Compliance, CDP, CRM, etc.), yet many of them grow and some even IPO. So it’s not totally illogical to think that a market can support multiple companies providing similar products. But I think that’s where most people stop thinking about it and don’t go a level deeper and analyze why that market can support multiple of the same providers. Is it because of the market size? low switching costs? something else? It’s easy to see multiple providers in the same market at first glance and conclude that you can also enter the market but you really have to go a level deeper and understand the why.
The second problem is that when we as founders describe our product to someone else, we have the tendency to describe it in the end state. Especially if we haven’t built it yet. And in that end state, it has all of the great features that make it different and awesome. So the person you’re describing it to usually agrees that it will be great because you’re describing a product after years and years of development. So while selling a vision to customers and investors is fine (even necessary), we have to actually sell something in the mean time until we get there. And that has to be something that people want and is sufficiently differentiated that they will buy your thing instead of something else’s thing.
I think we fell into the second problem more-so than the first because while customers agreed that our vision was compelling, we didn’t really go into depth on the journey that the product would take on the way to that ultimate vision during our initial validation. And we often asked ourselves, “do we sell what we have today or sell the vision of what we will have tomorrow? And if we do the vision, then should we just focus on building until we get there?” Some companies can sell the vision and spend years building the product but we weren’t capitalized or staffed for that. So there was a capital and product vision mismatch given the product we were selling and the market we were in.
The Platform Problem
We started with a platform and that wasn’t the right approach. In fact, we’ve pretty much banned the use of the word “platform” at our company. I’m now convinced that pretty much no startup should start with a platform.
The Nucleus Cloud product was a dev tool and served developers. Developers interact with a lot of different systems that don’t always work well together. Additionally, there are a lot of ways to do the same thing. This combinatorial result of many systems multiplied by many ways of doing the same thing is a big reason why there are so many devtools out there. Someone always wants something different because they do things differently. I could write a whole blog post on how this is a fallacy and a people problem but I’ll leave that for another day.
Our goal was to create one product that solved a lot of the problems that developers faced every day while building, deploying and managing their services on Kubernetes. The bet that we made was that someone is looking for a platform that solves all of these problems in one place.
What we learned was that in reality most people are looking for a specific solution to a specific problem. And a platform, by it’s nature, does not solve a specific problem. It’s a combination of tools and features that solve a class of problems. That’s why most companies sell platforms when they have full-fledged sales teams who can take on more of a consultative sale. Most customers can only see what’s in front of them and unless they’re trying to solve many of their problems at once, they’re more likely to buy a focused solution vs. a platform.
The takeaway here is that, as a startup, the hair-on-fire, acute problem that you’re solving can’t be the sum of a bunch of smaller, less acute problems. It really should just be a single, well-defined problem. Then as you grow, you can expand into other problem spaces.
So how do you avoid this problem? Looking back on it I think a good tell is when you’re describing how your product solves a problem. Do you use multiple verbs to describe how you’re doing it? For ex. in our case, it was “build”, “deploy” and “manage”. Each of those verbs are their own problems but we felt like the right solution had to address all three. In retrospect, this wasn’t the right approach. We should have just focused on one of those.
This is a really easy trap to fall into for startups. If you find yourself going down this path (like we did), this is a sign that you should stop and re-evaluate the problem you’re actually solving. If you find yourself thinking and referring to your product as a platform and you’re a young company, I would urge you to reconsider and refocus.
So why are platforms really hard? Especially for startups?
As I mentioned above, people look for specific solutions to specific problems. Platforms solve a class of problems. Therein lies the disconnect. It’s really hard for a startup to solve a class of problems when you’re small, cash-strapped and operating on a limited timeline.
From the product perspective, a platform causes you to think that there is so much to build before you feel like you can adequately solve the problem you’re trying to solve. So you convince yourself to just keep your head down and keep building. You justify this by saying that once you finally have all of these features then the market will want it and until you have those features, you probably won’t see the explosive growth you want to see. This is such an easy trap to fall into. Especially for builders, we revert back to what we know and, more importantly, can control, which is writing code and building. Why? Because it’s easy, completely in our control and makes us feel like we’re being productive.
We fell into this trap. We started selling early on and were seeing growth but justified the growth rate as a function of just not having built enough to adequately solve the problem. Ultimately, the slope of your growth and the repeatability of your sales cycle matters.
Trusting your gut
I mentioned at the end of the intro that there a number of reasons we pivoted and in some ways, more importantly, feelings. As entrepreneurs we usually prioritize logic and reasoning over feelings and emotions. I think if we had done this we would still be working on the original Nucleus Cloud Platform and I’m very glad we didn’t. It really was a gut feeling that caused us to take a step back and reflect.
I remember when Nick and I were first talking about it, I found it very hard to describe this gut feeling. I just kept saying, “I don’t know, something just doesn’t feel right.”
If you’ve worked in early stage companies and other startups that have been successful or you’ve felt that pull of PMF, then you know that it’s more of an art than a science. You feel the market pull. The metrics are usually lagging indicators despite what you’ve all read on that Superhuman PMF blog.
In our case, I just didn’t have that gut feeling that we were on the right path despite what our metrics were telling us. So we bet on feelings over metrics. What a weird thing to say as an entrepreneur. We’ll see if it pays off.
There were a few of other reasons that we felt like pivoting was the right move that I didn’t explain in detail. Some were based on our GTM. We had a big dependency on Kubernetes and while it’s very widely used, it’s not easy to see what companies are using it from the outside-in which makes it hard to do efficient targeted outbound. Some of them were personal, such as Nick and I both agreed early on that if we were going to fail, we wanted to fail fast and move onto another idea. One of our fears was running a “zombie” company. One that is doing well enough to stay alive but not well enough to really succeed.
All in all, I think that we’re better founders because of this experience and have a much clearer picture of what we want to do moving forward. We’re already working on a new idea, one that we’re super excited about. If you’re curious, you can check it out here.
I’d be lying if I said I don’t think about if we should have just stayed the course? I mean we had a working product, customers, revenue and were starting to get a little recognition. Did we pivot too soon? Maybe. But probably not. If anything, we should have pivoted sooner. I guess time will tell but it doesn’t really matter anyways because we already did it. No point in looking back now. Burn the boats and onwards and upwards.
Thanks for reading The Early Days by Evis Drenova! Subscribe for free to receive new posts and support my work.