The main reason why I am so much into early product validation is because I’ve failed spectacularly at getting this right when I founded my own startup.

Of course it’s easy to be hard on oneself in hindsight. On the one hand, I definitely feel dumb for making these mistakes. On the other hand, I am seeing a lot of startups I am coaching struggling with this as well, jumping right into building stuff. The common denominator between past me and the startups struggling most is this: They’re first-time founders.

Having gone through the process and reflecting on it will hopefully help everyone getting their own idea off the ground, avoiding the pain and sense of wasted time I came to feel.

Therefore, in this post I will explain

• the 2 and a half phases we went through,
• what the biggest mistakes at each stage were and
• how we could have done this better.

Let’s dive in!

Phase 1: B2C Platform

Phase 1 was by far the longest one, spanning from May 2017 to February 2018. Shortly beforehand, my co-founders-to-be approached me with their app idea: Real estate search augmented by information about the vicinity. The solution was to enable folks to filter not only based on the real estate property’s characteristics, but also by proximity to e.g. schools, kindergartens, parks, etc. The idea was based on my co-founders’ research and it made sense at the time. We also wanted to aggregate properties from existing platforms into one interface.

Somehow, everyone around us got excited about the idea: Consumers and local media saw potential for alleviating the housing crisis (modest, right? We actually believed this), agents saw potential to save costs. This was definitely reassuring. And yet, nothing about founding the startup was based on facts but anecdotal data at best: Customer segments, problems, acquisition channels, revenue streams, partnerships, ... you name it.

Mistake: Building software way too early and for way too long

This had to crumble, and it did. Which leads me to the first big mistake: Encouraged by this bogus data and (perceived) media hype, we got to work and developed. And developed. And developed. We aimed at a February 2018 launch, a full 8 months later.

It was in the later stages of development, half-way through our funding, when we started questioning our beliefs, especially the revenue stream based on affiliates. Of course, this was way too late to change anything of significance about the product. We launched on March 1st and used that point to reflect and pivot.

What could we have done better? A lot.

Anything that gave us a better understanding of the problem space, who, how and what people would potentially spend on such a service. In fact, we were in the typical situation of having a solution in search of a problem and a market.

I feel like two-sided markets (real estate agents on one side, renters and potential buyers on the other) are particularly tricky for idea validation, so even in hindsight I can’t pinpoint the one thing we should have done back then. But I am 100% sure that building software with so many unknowns was the one thing we should NOT have done.

Phase 2: B2B Product

It was as feared: After an initial traffic spike nobody cared about the platform. We wanted to re-use some of our algorithms and pivot towards a B2B solution: Generating map images with proximity information for real estate agents’ PDF exposés. Again, this idea was based on anecdotal data. But we managed to do 2 things better than before:

1. This was a narrower customer segment to which we had okayish access.
2. We reached out to those agents and incorporated them into the development process.

We then took another 2 months to build this second product based on the requested features.

Mistake: Listening to what customers say.

When we got back at them with a (barely working) product and asked them to now pay in exchange for excess, all of them refused. Their telling us what they wanted did not translate into willingness to pay and it makes sense: They had nothing to lose anyway!

We should have asked for a commitment

A commitment is important to identify genuine demand. Asking for signing a subscription contract upfront or sharing development cost would have prevented us from investing precious development time into this product. Customers not willing to give a commitment should have meant that the value provided by the product is not big enough.

There would also have been better and faster ways to get insights regarding demand. I conducted a Fake Door MVP experiment for a similar idea and the same customer segment which provided actual data on acquisition metrics, possible price points and contact information for qualitative follow-ups. Such experiments would have been a much more valuable investment of our time.

We missed these opportunities and, disconcertedly, moved on to the next phase.

Phase 2.5: Exit

Our next attempt was to use the value proposition of our last product as a basis for a different customer segment: Large real estate CRMs used by agents. We were willing to adapt our algorithms but were unsure about the exact direction. To find out, we tried to get a commitment first and decide based on this data.

Surprisingly, it didn’t come to that. One of those potential customers was interested in our software and we became part of that company by October 2018.

The gist: Validate early, build later

The main thing I learned from this painful journey was this: Building software without evidence for its success is likely to end in disaster.

Luckily, there are ways to get the necessary learnings fast and make informed decisions based on data. There’s a ton of great books out there explaining them, such as The Mom Test, Lean Startup, The Right It or Inspired. Although methodologically diverse, their underlying process is the same: Find the most critical aspects of your product idea, create artefacts (interviews, pretotypes, MVPs, etc.) to gather meaningful data and iterate towards what works.

It is a simple principle in theory, but hard to come up with yourself as a first-time-founder and even harder to execute without experience.