This post is the second of a two-part series about my first attempt at a startup and the challenges I faced along the way.
I hopefully managed in my first post to genuinely convey the motives that made us optimistic about our success.
I made it a point to first walk you through the feature set and potential value of Remini as such that I can better express the reasons that led to our failure.
In this post, I will first expand on how it all started to then address the problems we’ve encountered and the lessons I have learnt from them.
Towards the end of 2014, my co-founder and I had hit rock bottom.
We had come to the conclusion after spending day & night breathing Remini for the past year or so, that we wouldn’t be able to pursue our dream anymore.
In spite of everything, I can certainly say without a doubt that it’s been one hell of a ride despite the constant struggles.
Setting out to build Remini definitely was the most challenging chapter of our lives — Full of ups and downs, thrills and setbacks, but most importantly, personal growth and flourishing.
As a first-time entrepreneur, you’re constantly at the limit of what you can and cannot do. You’re never certain of your ability to achieve a task because it always requires teaching yourself a new skill and doing it fast.
There is no clear learning path — You workout the path yourself. This can get pretty scary; especially when you realize your startup is at stake every time. But it’s also where all the magic happens.
The crazy part is that when we first set out to on this journey, we had no experience whatsoever. At first, it was pretty unsettling and particularly frustrating — But it’s funny how the right circumstances can push you to do things you normally would’ve abandoned by fear of not being up to the task.
Overall, it’s amazing how fruitful with respect to skills development and self-teaching this turned out to be.
I guess every first time founders need a certain level of naivety or innocence to get really started. If I had known back then the sacrifices it takes to try and build a successful company, I probably would’ve been too discouraged to even attempt it.
How It All Started
Now that we’re over the whining part; let’s explore how the idea for Remini came about.
After reading my first post, some of you might have noticed that Remini shares many similarities in value proposition to a certain app called Timehop — Heck; you might even think that it’s a total rip-off!
Well here’s the thing: I immensely respect what they were able to achieve in recent years, and I give them the most credit for having developed the “reliving your past” concept under a strict lean approach methodology — Execution always wins in the end.
Not being capable of being agile at all times in our approach of building Remini played a big part in our failure (more on that below).
But for now, I would like to single out the fact that believe it or not, the idea for Remini transpired long before we even had the opportunity to fully dedicate ourselves to it.
At the time, my co-founder and I were based in two different countries and both in the process of earning our masters’ degrees in Paris and Madrid respectively.
Remini was originally born from the single inspiration that we usually attach our best memories to objects. It was all about that powerful feeling of nostalgia and how we could make use of it to build a meaningful product.
Back in early 2012, we had already envisioned a diary app where your photos would be presented to users on a chronological timeline with an interactive map, something that wasn’t really common back then.
With time, we eventually backed away from that direction after seeing Facebook and Instagram (to name a few) introduce their own timeline and maps features later that year.
However, the real spark of inspiration for what would later become Remini came from an unexpected source: Location reminders for iOS.
It was a simple feature — Yet it kick-started the whole thing for us.
“How do we make use of that hint? What would the benefits be? Is it even possible to move beyond location towards other means of resurfacing the past?”
Those were all questions we asked ourselves.
Moving beyond the value proposition of manually browsing your photos towards having the app naturally resurface them was then the only coherent course of action.
But, you must be thinking that this is already almost 3 years ago, that’s a long time, especially in tech.
Thing is that at this stage it was only an idea, and we all know that ideas by themselves don’t get you very far. Unfortunately, we only had the chance to fully commit to our endeavor much later, in August 2013.
In due course, Remini eventually evolved into a full-fledged and trimmed-down feature set and we went full steam ahead to design and build it.
At the end of the day, once the honeymoon phase was over, things started to go south.
What Went Wrong
Some of the following missteps might shock you, some won’t. In any case, I fairly attribute most of them to the pitfalls of working on your first start-up.
Play By Your Own Rules
If I had to boil it all down to one big mistake, I can probably blame us for believing that we could squeeze out that many benefits from the product without bearing the consequences.
In other words: We tried to bite off more than we could chew.
Being as ambitious as we were when building Remini meant that we wanted to create a platform that would easily reach critical mass. What it also meant is that we continuously had to work our way around Facebook’s API.
Our underlying reasoning has always been that many would not enjoy Remini, if it only had a limited number of moments to resurface.
It is true that we regularly capture our life using our phones and upload a portion of it on Instagram but if you come to think of it — Instagram has only been around for a few years while smartphones have only not long ago gained mainstream adoption.
And what about all those Facebook moments that date back to as long as 2004?
Put differently: If we wanted to provide the best possible value for users, then we had to find ways to incorporate Facebook’s social data into Remini.
That ultimately proved to be easier said than done — What we were trying to achieve basically meant we had to create our own social graph on top of Facebook’s already complex one.
This led to various complications with respect to user experience:
1. Data Ownership
If you look at Remini’s value proposition in a one-dimensional way, there shouldn’t be anything wrong at first glance.
A user would simply join the app:
- Relive his best moments
- Share them to create conversations
- Visualize the stories of his friendships seamlessly building-up
As I’ve mentioned before, our long-term vision was to become “the place for your life” and the keystone of that vision was the frictionless and collaborative aspect of content creation.
Everything was built in a way to enable users to seamlessly work together on adding new moments to their shared albums and filling up the information gaps. This was discreetly integrated in the “Reliving” experience and the process seemed bound for exponential growth.
We genuinely thought we were on our way to achieve what no one had ever achieved before: creating the one-stop shop to contemplate all your life moments in the most comprehensive and detailed social photo collection.
However, issues started appearing when the complexities of social interactions were taken into consideration.
The first problem was that of content ownership.
More specifically: I could be sharing a photo that I didn’t originally own on Facebook. If I was the first of my group of friends to share it and add it to my profile, the question of who becomes the owner on Remini arises.
Obviously, there can only be 2 possible answers to that question; either I become the owner, or the owner remains the same. But let’s take a closer look:
Solution 1: The first user to add a photo on Remini becomes the owner.
This solution immediately leads to an obvious problem: Is that fair to the original owner of that photo on Facebook?
Imagine joining Remini and exploring your friends’ profiles at activation, only to notice your own pictures were now their property and that there was no way for you to reclaim ownership or delete them from the platform.
Even worse: imagine that you had privately shared some of these photos on Facebook with a select group of friends.
How would you feel knowing that they were now publically available to anyone on Remini?
The number of similar potential conflicts keeps growing as edge cases of data ownership are studied, so I’ll spare you the details. However, it’s worth mentioning that the decisive argument against changing ownership of photos on Remini is related to our long-term objective of filling up the gaps on Facebook’s social graph.
It goes without saying that modifying photo ownership directly defeats that purpose and would have turned it into a dreadful list of conflicting data between our graph and Facebook’s.
Solution 2: Data ownership remains the same on Remini.
From the above, it clearly seems that keeping the original owner of the photo regardless of who shared it first on Remini, is the right way to go. But picture this scenario for a second:
You’ve just shared a photo that was automatically added to your profile, only to notice that you don’t even have permission to delete it. Somehow, the only thing you can do to remove it is to untag yourself, despite the fact that you were the one who just added it to Remini.
Needless to say this would be confusing to any user. Not to mention that this is far from being a rare case and could statistically happen more often than not for early users.
Again, this is only scratching the surface of all the potential data ownership issues. For simplicity’s sake, I chose not to expand on other nightmarish use cases that eventually came up.
As you can clearly assess, both solutions are impossible to implement. So how do you choose the right answer to such a crucial question without running the risk of damaging the keystone of your long-term vision?
2. Friends List with FB API V2.0
You might recall that on Remini, as I relived and shared my life, I could tag all the friends who were part of a moment, whether they were on the app or not, for the sake of adding photos to my friendship albums.
This could be done thanks to access to your full friends list via Facebook’s API, which also allowed for these photos to be automatically added to these friends’ profiles once they joined Remini.
Indeed, when we first set out to build Remini, this did not pose us any kind of problems as we were working with the early API version.
But all of this changed on April 30th 2014, when Facebook introduced a first major update in 8 years to their Open Graph API. The new API rules only gave us access to a list of friends who were already on the app.
Strictly speaking: I would not be able to start building up my friendship albums without my friends being on board. I would now have to wait for all my close friends to join me on the app in order to enjoy the full value that Remini had to offer me.
This was a huge blow to the product’s potential and what made it even more unbearable was the fact that it also made the Data Ownership problems worse than they already were.
Choose Your Environment Wisely
Although this is an often mentioned topic in the startup community, I still feel like it is not being stressed enough.
We all fall into the trap of thinking our product is so special, that we’re somehow predestined to make it work no matter the hurdles.
As founders, we simply can’t allow ourselves to believe our own individual efforts or sacrifices are sufficient to pull through obstacles.
It simply doesn’t work that way — Passion by itself is never enough.
Having said that, not fully grasping the importance of our environment played a major part in our downfall:
1. Lack of Funding Opportunities
Despite my co-founder and I both having dual citizenships, we had to pursue Remini out of Madrid at first, then out of Beirut for personal reasons.
Leaving aside the fact that we were based out of some of the best co-working spaces, I can certainly say without a trace of doubt that the startup eco-system in both Spain and Lebanon are still too early in their infancy.
The major obstacle was certainly the lack of proper access to funding opportunities due to the scarcity of tech investments in those regions. This can become a very serious problem when it inadvertently creates a risk averse approach to funding.
A friend of mine once told me how in those parts of the world, angel investors tend to act more like venture capitalists.
Well, he couldn’t have been more right.
Investors in those regions oftentimes overlook innovative products in favor of clones with demonstrated revenue streams that can be replicated in other emergent markets. As a result, we often see develop ideas such as: “The OpenTable for the Middle-East” or “The Task Rabbit for Spain”.
While copycats with proven business models are certainly an attractive proposition, there is unfortunately little room for riskier undertakings.
Remini certainly fell into that category. Designing a social network meant that we naturally needed to focus more on acquiring users and achieving product/market fit before even considering of implementing our business model.
The worst part is that mainstream investment tools such as convertible notes are barely used in favor of equity financing which can sometimes be very detrimental to any startup if not handled properly — Sadly, that is constantly the case.
Consequently, the quandary going into raising external funding eventually presented itself: Should we keep struggling to raise money? Or pack-up our suitcases and seek greener pastures elsewhere?
Ultimately, we felt that bootstrapping and staying put until we could achieve significant traction, was our most viable option in the hope of eventually joining an accelerator in the US.
2. Lack of Available Talent
Working in an unfavorable environment also taught us the importance of surrounding yourself with the right talent.
Technical talent is hard to find anywhere in the world — We knew that very early on. But what we also knew is that for the sake of delivering a relatively complex product such as Remini, we needed more people in charge of development.
We therefore took the often-criticized decision of seeking help from a development company.
Not that we chose wrongly, it is just that there was no available local talent willing to join us for equity without any kind of fixed monetary compensation. For this reason, going for local outsourcing companies always looked like the cheapest and most viable option.
As a consequence, we also had to radically expand our knowledge as to better execute tasks ourselves.
At the end of the day, I can say without a doubt that this situation actually turned into something positive as we were constantly pushing ourselves to the limit.
Use An Efficient Testing Approach
There’s no need for me to point out the importance of testing and gathering all the insights you can get while building your product. You’ve probably heard that advice on countless occasions.
However, what people often fail to mention are the two underlying characteristics of efficient testing:
1. Find the Right Balance
First of all, you have to find the right balance between quantitative testing, qualitative testing and following your own gut feeling. It’s crucial to be able to determine which of all 3 possibilities holds the right answer.
Despite our best efforts, we were often prevented from approaching problems through an agile development perspective — This was mainly due to slow progress in product implementation.
Those constraints made us occasionally rely too heavily on feedback from qualitative testing vs. more quantitative measurements.
Still, I firmly believe that the key to building a successful product isn’t only about shipping different versions just for the sake of it.
Instead of waiting too long to have functional iterations built for the purpose of quantitative analysis — We favored the more pro-active approach of constantly mocking-up multiple versions and testing them via prototyping apps.
2. Determine the Right Sample Size
The second and most often overlooked characteristic of an efficient testing approach is the way you manage the size of your testing pool.
It’s crucial to progressively increase your numbers of testers in order to better assess your assumptions at different scales. What works with hundreds of users doesn’t necessarily hold together with a thousand.
This is especially true when you’re building social products where the intricacies of social interaction get more and more complex as the user base grows and connections are established.
In that sense, Remini was relatively hard to test due to the nature of its value proposition. As you must know by now, not only was Remini based on a friendship model but it also depended a whole lot on the context of its users.
Therefore, the only way to make sure that all assumptions were properly tested was:
- First, to find the right number of “circles” with pre-existing social connections such as common photos shared on social networks.
- And second, to make sure that these “circles” were in proximity of each other to make features such as reliving moments with friends happen.
That is to say that our failure to gradually increase our sample size often led to misguided predictions on expected user behavior.
We should definitely have done better at releasing more than a few iterations and testing them with larger samples for the sake of covering all our bases.
All in all — The more data at hand, the better, and the more time for insights to emerge, the bigger the odds of achieving product/market fit.
Our journey has now ended — We’re not the first to fail and won’t be the last.
Things could be worse, and I’m grateful that’s not the case. Without a doubt, I feel incredibly fortunate to have been given a shot at pursuing my dream without critically suffering from my failure.
My fear of failing has now gradually subsided to be replaced by a growing sense of excitement for new things to come.
Next time around, I hope I’ll be able to rightly put my experience into practice. I like to think that resiliency is the most important lesson I have learnt – When tough times arise, working harder is often the right answer.
Finally, I just wish to add that I am immensely privileged to have gone through this journey with my co-founder, Marc Zovighian. It was without a doubt the best decision I made to go through this path with him. The perseverance, discipline and hard work he brought to the table were indispensable during Remini’s brief existence.
Thanks again for reading, hope it was interesting!