One Year Of Sakneen: The Mistakes We Made

February 15, 2021 by Nazli Kassem
Image of Sakneen's co-founders

Exciting things are happening at Sakneen. We’re happy to share that we’ve successfully raised a $1.1M USD seed round bringing our total amount raised to $1.25M USD. These funds will help us continue to rapidly develop our team, product, operations, bringing us one step closer to our vision of bringing joy and intelligence to home buyers and sellers.

2020 was not an easy year by any stretch of an imagination. But from our vantage point, if anything it has shown the resilience of real estate, technology, and real estate technology specifically. With the need for housing proven inelastic and the ability to view properties limited by the pandemic, the demand for higher quality online experiences has exploded. In the US, Zillow’s stock price has multiplied by more than 3x from $50 to $160 hitting a market cap of $36.6Bn while Redfin shot up from $23 to $70 for a market cap of $8.4 Bn. OpenDoor’s market cap has more than doubled in 6 months since being acquired by a SPAC.

Here’s a link to our Press Release to read more on the round.

But beyond the regular details and business speak, we wanted to write a short post to add some color to the headline.

When you raise a round from great investors it’s clear that quite a few things have gone well. Still, the most valuable insights remain in what has gone wrong. Failure is more “robust” than success as Nassim Taleb reminds us.

Without further ado, here is a condensed list of mistakes we made and what we learned from it.


1. Optimized for investors, not customers.

The best investors are very smart and we’ve had the pleasure of speaking to quite a few of them. Invariably they have long track records of picking winners and their careers are built off of their ability to identify winning ideas and teams.

When said investor point blank tells you “I’d love to fund you but only if you do X instead of Y” the temptation is to do it. When you have enough of these conversations you start to realize that all the smart people are contradicting one another. This isn’t to imply that any of them are wrong necessarily, just that intelligent people can have a different thesis about a problem space you’re tackling. Some of them will be aligned with you, and these are the people you want to work with.

The reason you are being funded is because you have a unique insight, a nugget of hard earned customer understanding that others don’t have. Trust that insight.

2. I was at times a salesman, not a scientist.

With a salesman’s hat on you have an answer to every question and you deliver it with complete certainty.

In scientist mode you have an initial hypothesis, a prediction, and a convincing and airtight approach to put it all to test.

As a leader and founder the temptation is to feel like you need to have all the answers - something that for me was not only draining but also makes for less productive communication with investors. This is something I was personally guilty of early on. The less secure and confident I was about what we were doing, the more I felt the need to speak convincingly. Fundraising towards the end I didn’t shy away from answers like “We don’t know yet” or “we’ll have to figure that out” and the best investors responded.

3. Tried to hire away problems.

As an early stage company, you're probably trying to solve complex problems - usually a whole bunch all at once. When it’s just founders and a limited team it’s easy to keep focus on solving one big problem at a time. As soon as you’re funded the temptation is to start hiring more people to solve more problems.

In my experience this year this has tended to work out poorly. If you can’t solve a problem it’s usually because you don’t understand it well enough - which also means you’re unlikely to hire the right person to solve it.


1. Focused on new features more than what customers already loved.

After our first product release, we were still in the midst of fundraising. We felt that we needed to continue releasing new features as fast as possible, thinking that if we released enough features we’d stumble upon some magical combination that would lead to product-market fit. We also thought that shiny new features might demonstrate our capacity and ambition as a tech company.

In actuality, we should have focused more on refining the features that our users loved most. The first batch of users really enjoyed using our filters to quickly find the homes that meet their needs. When we reprioritized our product roadmap, we chose to once more focus on developing our search experience in particular.

The other thing that you learn when trying to release many features at once, is that every feature is a product. In order for a feature to gain traction, you really have to focus on usability in addition to functionality. It’s not enough for the feature to exist, it also needs to be built in a way such that users will find it and intuitively know how to use it.

2. Tried to build too much from scratch.

The concept of “good enough” was often very alien to us, especially relative to the long term vision we held for what we’re trying to build. It drove us to optimize excessively on the product side - for example, we initially avoided using SaaS tools to support Sakneen’s functionality because they don’t come with the exact customizability we’ll need to add hypothetical new features down the line.

The fact of the matter is our product vision evolved every day as we learned more about our market and what our users actually want. It didn’t make sense to optimize for things down the line, when we were in the present trying to survive. When we learned to leverage existing tools, we were able to move much faster as a company.

3. Allowed product milestones to extend beyond two weeks.

There were times where we would unnecessarily complicate the requirements of what we were building when we were developing our product. We would start with a simple idea that would maybe take a week to implement. In the process of brainstorming how we could expand on the idea, we would add several layers and integrations, and eventually end up with something extremely bloated that would require several weeks of development.

The brainstorming was actually extremely helpful in terms of contextualizing what we were trying to build in the medium term. However, when you allow development cycles to extend beyond two weeks, it’s easy to lose focus and urgency. When we kept our product milestones contained within that timescale, we not only produced better output on the software side, we also managed to stay more focused on the strategy side.