I created eesel with a friend as a side project. In less than 2 years, we incorporated a company, raised money, and hired great people. eesel became a finalist for the product of the year on Product Hunt, one of the best productivity apps for FastCompany, and helped thousands of user in companies such as Atlassian, Google, Facebook, and Revolut.
The idea
At Intercom I had to collaborate with many people every day. Many people sharing many documents: Github issues, Google Docs for project briefs, Amplitude dashboards, Google Slides reports etc. Re-accessing these documents was a pain. A pain that I could tell was shared by others in the company. A friend of mine, Product Manager at Intercom, was one of them and together we decided to explore solutions to this problem.
Why API hubs failed
For the longest time our explorations were focused on what was the status quo at the time: API hubs. API hubs allow users to connect their apps so they can access all their documents in one place. We tried to use some API hubs in the past and didn't stick to them. This was consistent with what we observed with our teammates and we identified 3 main reasons:
Hard to maintain: Building and maintaining dozens of API requires a big effort. Effort that can't be put in other dimensions like the user experience, bug fixes, performance etc resulting in apps that often lacked of quality.
Limited: It's very unlikely that an API hub will be able to support all the tools that people use. And no matter what, API hubs will always have to play catch up with new tools. If the solution is not exhaustive, the risk is that users won't form the habit of using it.
Scary: In order to connect their tools, users have to grant the API hub access rights that are sometimes pretty intrusive, like accessing all the docs created in the organisation. When we were testing API hubs, we definitely hesitated a few times at the permissions step, and we even sometimes gave up when the hub felt too shady.
All in all, the perspective of building another API hub wasn't really exciting, and our hope to tackle our problem stayed very low for a long time.
Eureka
I remember the scene very well. We were brainstorming one more time on the white board, going one more time through the issues with APIs, and thinking one more time about ways we could overcome them. My brain suddenly made a weird connection, probably thanks to my early years learning about semantic HTML: The web is an API. It's a set of standards designed to enable software like browsers to integrate with websites. What if instead of trying to integrate with dozens of APIs, we were only integrating with one – the web?
After weeks of stagnation, the idea instantly felt exciting and inspiring. We quickly made the decision to start by simply filtering the browser history in order to only show pages relevant for work. That was almost enough to start.
Validating our direction
As excited as we were by this new direction, we knew we needed to validate some assumptions before investing more into it.
First, our solution would only work for documents opened in the browser. If re-accessing "offline documents", like a Word file, was important, our solution would fail.
Second, our solution would only work for documents previously opened. If accessing documents never seen before was important, our solution would fail again.
Luckily, we had plenty of opportunities to test these assumptions in our daily jobs, and after a few weeks of research we got 2 very clear answers:
Re-accessing documents is a problem that is way more acute in the browser. Offline files are becoming more and more rare, but even then, re-accessing offline files is less of an issue. That's because people usually have 1 or 2 "main tools" that they use outside of the browser. Think of the native Figma app for designers, or Visual Studio for engineers. Files in those tools are usually pretty easy to access from the start screen. That's different for the myriad of links shared by my teammates on tools that are secondary for my job.
The need to access something never seen before is very rare. Most of the time, the pain comes from trying to find something that you know exists, and you know it exists because you already opened it.
This was finally enough to go to the next step and start prototyping.
The prototype
We quickly built a very simple version of the browser history filter for work. There were a lot of ideas that we obviously descoped, a lot of questions that we didn't properly explore, but there's one thing we knew we needed to get right from the beginning: habit formation.
We knew that it would be hard to ask people to form new habits when it comes to accessing the documents they open dozens of times every day. That's why we tried to build on existing habits as much as possible. For us, that meant stacking on the new tab.
The first version of eesel simply showed links from a few selected domains that we knew were work related. After a few days of "internal usage" (we were really just 2 users), we quickly realised that this was already incredibly valuable, and decided to start a closed beta. My teammate had already left Intercom at the time so I started recruiting beta participants at Intercom on my side. We got our first users and we quickly realised that we had unintentionally built a great virality engine with the new tab. In just a few days, multiple people started asking me (and other beta participants) what was this app in my new tab after seeing me accessing docs while presenting in a meeting.
And in just a few weeks, our closed beta grew organically to more than 100 users. More importantly, these users were engaged, opening documents with eesel every day. They were also sticking to eesel, and we had great retention numbers from the very first days. Even more importantly, we were receiving overwhelmingly positive feedback that fuelled our motivation to bring eesel to the next step.
The product
The natural continuation was to open the beta to more users. In order to do that, we decided to launch eesel on Product Hunt. But we still had a few things to work on before that.
Our first decision was to bring an engineer onto the team to help us turn our prototype into a robust production ready app. We were lucky enough to convince one of my best friends, who is also one of the best engineers I ever worked with. In just a few weeks, he rewrote the app entirely, fixed tons of bugs, implemented a robust design system, and a new onboarding.
In our onboarding, we aimed for an early "aha moment" by showing people's documents without the need to setup anything or even to sign up
We also had to work on the marketing to prepare the launch. eesel ("Obair" at the time) didn't even have a real name. I was driving a large part of this work, which was a challenge because I never really had worked on marketing before. We landed on a name, a logo, a visual style, a tagline, and a basic marketing narrative to explain the "why" behind eesel. I used all of that to build our first landing page:
We launched on Product Hunt in April 2020. Thanks to the amazing support of our existing user base, we managed to finish product of the day and grew our user base to 1.5k users.
The great engagement and retention numbers we saw in the closed beta were confirmed and the positive feedback was overwhelming and motivating. That's when we started receiving chat requests from investors.
The company
It took us a few months to decide to fully commit to eesel. We tried to raise in the autumn of 2020 and at the beginning of 2021, we closed our round, and the 3 of us started to work full time on eesel.
We had a product that was working well, but instead of monetising or looking into growing our users base quickly, our plan was to find a use case for team collaboration. The rationale was that it would be hard to monetise an app like eesel if we were targeting individuals and with the inherent virality of the new tab, we were hoping that keeping eesel free would favour bottom up adoption inside teams. We also thought that there were adjacent jobs involving team collaboration that eesel could help with; in particular the idea of building a shared source of truth for team projects with all the relevant links always up to date.
We thus focused our effort on building "eesel Folders":
An example of eesel Folder with all the links for a team project
An eesel Folder is a list of links that can be shared with teammates. We wanted to design something that would work with very little manual work. The idea was to automatically organise pages into the right folders based on default rules, but to allow users to manually override these rules if needed with a simple rule builder:
The UI to manually configure how pages get added to a Folder automatically
After months of iteration, Folders never really found the usage we were expecting. Roughly 10% of our user base was using Folders, but only for individual usage, and people were almost never sharing their Folders. We identified multiple blockers to Folders adoption over time. For instance we learned that users simply struggled to remember to create Folders for new projects. We built "Folder suggestions" to automatically detect new interesting keywords in the browser history and suggest to create Folders for them:
eesel automatically suggests new Folders
This feature has been very well received, but that still didn't unlock the collaboration usage we were hoping to see.
The end
At the end of 2022, we decided to stop investing on this team use case. I spent a lot of time reflecting on what went wrong.
Our initial assumption was that by keeping eesel free, we would enable bottom up adoption inside teams. We were wrong. eesel grew, but very slowly. At least until we've started investing in marketing. I think we should have started our marketing effort earlier. Passing milestones like our first 5k users, our first 10k users would probably have helped to create momentum for organic growth.
The second issue is that our unique approach of not using API was great for the individual use case (no setup, no sign up, no permissions, etc) but was too limiting for the team use case. With our approach, the key question for collaboration was: How do we know which pages of the user history should be made available to the rest of the team? (because we definitely didn't want to share everything) Our only answer was to ask people to put shareable pages inside shared Folders. The problem is that a Folder is a very indirect way to do the job. People have to create a Folder, add pages to it, and then invite their team. That's a lot of steps that are not even directly connected to the sharing job. More importantly, folders have what I call an asymmetrical usage / benefits ratio. I can be the perfect user and create all the right folders, always add the right pages, and always invite my teammates, but if my teammates don't do the same, I don't get any benefits from it myself.
Is there any way we could have identified these issues earlier? I think the marketing question required some experience that we didn't have and we should probably have asked for more advice on that. On the product side, I think we should have explored higher level directions earlier (e.g. should we have compromised on our "no API" approach for the team use case?). We also got fooled by the blockers we identified and all the small improvements we brought in as answers. They were often enabling more people to use Folders, but none of them were really deeply impacting the collaboration usage. We should instead have worked on understanding how critical the "building a shared source of truth" problem was for teams. We didn't really have the tools for that at the time I think, but since then I read the excellent book "Monetizing Innovation" and I think some early discussions on the willingness to pay for Folders would have helped us understand how painful the problem really was.
eesel in April 2023
I left eesel in April 2023. The company isn't totally at an end, but it's starting a very different chapter, moving away from our initial vision.
In 2 years we managed to grow eesel to 11.5k active users, delivered a lot of value for many of them, hired and met amazing people, but we failed to build a sustainable business. This still remains an incredible learning experience full of very high highs and very low lows.