Station’s Blog

Get cozy at work

Falling in love with problems

Julien Berthomier
August 25, 2020

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:

  1. Confronting ambiguity and facing reality
  2. Avoiding the "solution trap"
  3. Picking the right problem
  4. Choosing the path of least resistance

The long and winding road

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:

  • declining (that was our case)
  • flattening (in a non-pandemic world, it just means users stop dropping after a certain point)
  • smiling (that's when users drop but then come back, most common with collaborative products). That's the holy grail.

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.

Confronting ambiguity

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...

Merci Victoria Grace who was an early employee and former Head of Growth at Slack summarizes this scenario very well in one of her tweets.

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:

  1. A passionate first date → a small set of die-hard users at first who love your product and couldn't live without it (the "Very Disappointed" category in the Superhuman methodology for finding PMF)

  2. A date you want to introduce to friends and family → basically growth through word of mouth (from those die-hard users)

  3. The kind of love you want to marry → users have made your product a part of their life aka you get long-term retention.

In short, at Station, we were a hot date but not marriage material for most of our users.

Facing reality

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:

  • a technical challenge: could we continue to add significant value at a high velocity with our current stack considering the technical challenges we faced?

  • a product challenge: have we built the right solution for the problem we are trying to solve?

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.

Solutions are a trap

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:

  • The Einstellung Effect: when faced with a problem, we tend to be predisposed to solve it in a specific way even though there may be more appropriate ways to solve that problem. As Abraham Maslow phrased it in 1966: "I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."

  • The Confirmation Bias: our tendency to search for and interpret information in a way that will confirm our prior personal beliefs or hypotheses.

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:

  • Einstellung Effect → our excitement around the idea of building a new browser from scratch (the very foundation of why we started Station in the first place) had us believe without a doubt that it was the very best way available to solve our users' problems.

  • Confirmation Bias → when users asked us to add browsing and implement tabs within Station because that's the most efficient way for them to get work done, we sort of ignored it thinking "They just don't get it".

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".

All problems are not born equal

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:

  1. the number of users experiencing this problem
  2. the margin for improvement to bring more value to our users
  3. how painful and frequent the problem is

Context-switching ultimately came out as a clear winner:

  • it was the most reported problem (with nearly half the user base referring to it)
  • we have tons of ideas on how to solve this problem for our users
  • the average person spends 25% of their time searching for information at work while switching windows on average 373 times per day to complete their tasks. Clearly, it's a very frequent problem.

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?

Choosing the path of least resistance

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.

  • 47% of all feature requests were about catching up with traditional browsers. As Henry Ford said: "If I had asked people what they wanted, they would have said faster horses".

  • 36% of all bugs and improvements revolved around the fact that we were trying to render web apps (aka doing the browser's job)

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:

  • for you to build your product (build time)
  • for your users to adopt your product (ease of adoption)

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:

  • it will allow us to build value much faster for our users
  • it will bring that value right where users are already getting work done

Looking into the future

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:

  • focusing on one single problem: searching and finding the right information across the many applications we use at work.

  • delivering our value in the simplest form possible: a browser extension that integrates into our user's workflow rather than forces them to adapt to a new one.

If you'd like to test the new Station, you can request early access here.
Feel free to email me directly at with any question or feature request!

Julien Berthomier
August 25, 2020

In the same category

Product Hunt

Product Hunt: How We Became Product of the Year in 90 Days

If you're looking to get real traction for your product in the least possible time, launching on Product Hunt is key. Here’s exactly what it is, how it works and how to get featured on Product Hunt to skyrocket traffic and user growth.
Romain Richard
April 21, 2021

Station Desktop 1.0: the technical back story

Building an opinionated browser is hard. More than three years ago, when the team started the development, we chose Electron as a foundation for our application. Out of the box, the framework embeds Chromium and NodeJS runtimes to write cross-platform desktop applications.
Hugo Mano
August 23, 2020

Your way of working belongs to the Stone Age

You probably have a lot more in common than you think with the two people in the picture.
Julien Berthomier
May 16, 2017
  • Product
    • Power-Ups
    • Release notes
    • Roadmap
  • Enterprise
  • Support