Get cozy at work
This is an honest look at what we've learned at Station over the past 3 years and why we are moving forward with a new product.
In October 2017, we launched the first version of Station on ProductHunt. We gathered over 8,600 upvotes to date and became one of the top 10 most upvoted products in the history of the platform. A few months later, we got into YCombinator and raised a $3.2m seed round with top-tier investors from the Valley.
But behind that early success lies a more nuanced reality.
After nearly 3 years, we are throwing away 99% of the code we ever wrote, and we are launching an entirely new product. In other words, we are breaking up with our solution to fall in love with the problem again.
It took us 4 steps to get to that epiphany:
Over the last 2.5 years, we went through an erratic motion of growth, then stall, then growth again. We are not alone in this of course. Behind the tweets and fundraising PR announcements hides a painful truth: building a product that (many) users love is very hard.
This is what our growth looked like in the last 2 years (added some comments for context).
Going up, but not exactly your famed hockey stick growth.
Meanwhile, this is what our number of monthly signups looked like. We never paid a single dollar for an ad.
Those two pieces of data tell an interesting story: we were able to generate a lot of interest in the product but we had a hard time keeping users.
Even after using Station for months, many users would still drop. Slowly, but surely. Leaving us with a leaky bucket that even 10,000 signups per month couldn't really fix.
Retention can only go one of 3 ways:
From Sequoia on retention.
In the meantime, we kept receiving hundreds of glowing messages every week from users saying how amazing Station was. They would spend 8h per day in our app and they had tried several of our competitors yet still preferred our app.
You can't go wrong with that much love you may think.
But such a gap between what the users are saying and what the numbers are showing is a bit unsettling.
On the one hand, we had no issue attracting users to our product and word of mouth was real. People loved Station and kept talking about it. On the other hand, they kept breaking up with us months after trying the product for the first time. We'll dive into the reasons.
After you launch, it can only go one of 3 ways:
A. you grow insanely fast
B. you lose users aka no one cares
C. a group of users care but you are not growing that fast (→ our situation)
A is a no brainer, it's working.
B is a no brainer, it's not working.
C is hard because it's ambiguous...
As we were struggling with the ambiguity of our growth and engagement metrics, her words rang really true to us.
In essence, the lesson here is that your product may have gotten some traction but it doesn't necessarily mean product-market fit (PMF). Peter Lauten and David Ulevitch summarize it well and refer to this as getting to "product-user fit". That's exactly where we were at.
Because getting those first 100 or 1,000 people who love your product is hard, it's tempting to think there must be 10 million other people out there just like them. But it could very well just be wishful thinking.
Many products won't ever get those first 1,000 die-hard users. And I'm incredibly proud of what our team has been able to achieve with the first version of Station. The next step after that though is figuring out whether it's a real signal towards product-market fit and how big the market really is in the end.
YCombinator will tell you that it's better to have 100 people who absolutely love your product than 10,000 who don't really care. We clearly had more than 100 people loving the product but the trap was to think this meant Product-market fit. The greatest sign of Product-market fit should have been sustained growth through our ability to bring value to more and more users in the long term, not just for a few months.
Counterintuitively, I have realized that when it's "sort of working", it's actually harder than when it's not working at all. When it's not working, taking radical action is the obvious thing to do. But when it's "sort of working", you hang onto something, and you may very well confuse perseverance with insanity. It's really hard to confront the truth because there are still reasons to believe while there are many users out there you don't want to disappoint.
Product-market fit, it seems to me, looks a lot like a romantic relationship. You need 3 key ingredients:
In short, at Station, we were a hot date but not marriage material for most of our users.
Around the same time, we came to this realization, we started facing an increasing number of technical challenges related to the backbone framework we had chosen to build Station (called Electron). For more details on the technical challenges, you can read a great piece written by one of our engineers here.
Those technical challenges sparked performance issues (high CPU and memory usage), as well as an incredibly wide range of bugs that broke our users' workflow. As our team bravely tackled those technical issues, one obvious question came up: are we even on the right track?
Our users said it best in the survey we sent out after 2 weeks of inactivity.
In short, we were facing 2 major challenges:
It's tempting to try and tackle each challenge individually, but what if one could make the other irrelevant?
In the end, the tech is here to serve the product, not the other way around. Hence, we decided to ignore the technical challenge and ask ourselves a more fundamental question:
If we were starting from scratch again, would we build the same solution?
Answering that question means letting go of quite a few cognitive biases.
When it comes to making the right call, our ancient human brain is often our biggest enemy.
It's easy to fall into what we could call the "solution trap" or our tendency to favor a specific solution regardless of contradicting evidence.
From my experience, you can break it down into 2 main cognitive biases:
It's very easy to suffer from one or all three at the same time. And we did at Station in various ways.
Let me give you 3 concrete examples:
All I can say from our humble experience at Station is to watch out for those biases.
It's very common to fall in love with your solution. You've spent so much time on it that questioning its very existence feels like a betrayal.
This has a name in behavioral economics, it's called a sunk cost fallacy. The bigger the sunk cost, the more difficult it is to change direction. Our sunk cost at Station was 3 years of hard work and 150,000+ lines of code.
Marc Andreessen summarizes it well:
In my view, entrepreneurial judgment is the ability to tell the difference between a situation that's not working but persistence and iteration will ultimately prove it out, versus a situation that's not working and additional effort is a destructive waste of time and radical change is necessary.
Falling in love with problems rather than solutions is one way to filter out the situations in which additional efforts are likely to be a "destructive waste of time".
Since a product often starts with a set of assumptions about what the problem(s) might be, it's not rare that a product ends up solving different subproblems. Intuitively, it may seem like the more problems you solve, the more value you bring. But there is a law of diminishing return when you are a small team trying to prioritize what will have the most impact. As an early-stage company, the more problems we tried to solve, the more we spread ourselves thin.
So we asked our users for more guidance. We ran a survey we sent out to two categories of users: those who had churned and those who were still active 3 weeks later. For the latter, here are the results:
You can see we were solving 4 main problems for our users:
A. context-switching between apps
B. keep a clean work environment
C. manage multiple accounts
D. stay away from distractions
Trying to solve all 4 problems was a lack of focus. We had to make a choice.
How did we choose then? For us, it was based on 3 key variables:
Context-switching ultimately came out as a clear winner:
Finally, we dug into the data and we also found out that when looking at heavy adopters of our unified search feature, retention went up 25% and started to stabilize. In a way, our original version was a form of canvas giving us the blueprint for what to build next.
Our problem was chosen. Now the question was clear: assuming we had never written a single line of code, how should we go about solving that problem?
There is one rule of thumb our investor Steve Loughlin from Accel kept repeating to us at every update: in the early days, it doesn't matter if you are right, it just matters how fast you learn.
Building a new web browser from scratch using a framework (Electron) that was never designed to do it meant iteration cycles were slow. Very slow. We were not learning fast enough. On top, we had to build features you simply expect as standard in a browser and fix bugs that users wouldn't typically experience in a regular browser. That taught us nothing at all.
But it remained a general feeling so we looked at what our users were asking. We basically listed all of the feature requests and bug reports we got on our community and separated between what is browser standard (aka it's slowing us down) and what's actual added value for our users.
The lesson here is: by spinning in circles trying to solve four massive problems in one solution and reinvent the entire browser from scratch, we had not chosen the path of least resistance.
At Station, it took us way too long to fail and that was our biggest issue.
The path of least resistance comes in two flavors:
Building an entirely new browser from scratch not only made building the product longer but made it harder for many non-power users to adopt it ultimately. Instead, a smarter approach is to focus on the few key aspects that will make a difference in the user's life.
Andrew Chen elegantly talks about it in his article "Minimize your Time to Product/Market Fit":
Instead, you want to keep the fundamentals the same (80%) while substantially reinventing 20% of the product. That addresses the issues above. There’s a lot of stock methods of reinventing the 20%- you can do this in the cheaper/better/faster variety, or to go to a niche, or to go with some other segmentation.
With the Station native app, we were trying to reinvent 100% of the whole browsing experience and solve a large variety of problems all at once.
Building right within the browser rather than reinvent it makes sense both ways:
Once we had agreed to solve one problem at all costs and choose the path of least resistance to get there, the fog started to dissipate and everything became a lot clearer.
For us, it now means: