How validating early helped us avoid building a product nobody needed and what we’re doing now

Hello everybody! This is Bruno and Tim and we‘re working on a SaaS business called Anzu to increase the velocity of product teams. We‘re big fans of startups building in the open and creating sustainable businesses, so we‘re also getting our foot into Indie Hackers! Nothing seems like a better fit for a first post than talking a bit about how we started out and what issues we‘ve encountered in our pre-product / early phases. Hopefully, this will be helpful for some of you to possibly avoid some of the mistakes we did (which were no different from things many people before us did, too). Do let me know what you think of how we're building and talking about it :)

The tendency of tech-heavy co-founders to just start building

Bruno and I are both technical from our backgrounds. While we do specialize in different fields within our business and general skill set, we still are „software engineers“ in both our day jobs as well as on our work for Anzu. But, and of course, this is not backed by statistics besides my own experience, this leads to a natural tendency towards (first) building (some) pieces of a product before doing a larger validation of the idea/concepts.

Now, this doesn‘t necessarily have to be a bad thing, as many ideas do come from experiences of working within our fields (and so does our vision for Anzu) and a very great benefit for founders is to solve a problem they‘re actually having themselves.

Still, I do want to emphasize that it might be good to take a couple of steps back before actually investing significant amounts of time into building your product. Otherwise, you might have to learn the hard way that a „great idea“ does not always facilitate a great product. So did we.

Practically, we‘ve spent around 2 man-months of work before actually talking to a single person besides ourselves. In those two months we did build an impressive platform, but only later we found out that this did not solve pretty much any problem of the teams we were talking to and it also did not seem like much of a disruption or innovation enough to justify acting against those indications.

We should have listened to teams much earlier on

As Bruno‘s blog post was getting some traction within engineering circles, we did come across the chance to talk to a couple of teams. The vision we had around this time was very broad and would‘ve allowed to address a wide audience, so we talked to very tech-heavy and mature teams as well as to some more earlier staged ones.

It turned out that the product we were building did not solve a problem for them. Even less so, it was trying to solve a problem that was already much better solved by technologies much more advanced (and open) than what we were trying to build. And it did not matter if we‘ve talked to early-stage companies or the aforementioned tech-heavy one’s.

And while we were aware that compliments mean nothing, as we did „baby‘s first validation interviews“, they might have still skewed our perception a bit too much to just take some steps back.

So we‘ve built some more things in hopes of getting more trust from (possible) earlier customers, as we felt that was a thing missing to convince teams. It still is, but in a different way.

We should have asked different questions

While our questions did give us enough information that the product we were building did not solve any real-world problems, we didn‘t learn much else. Generally though, an interview can be very helpful in extracting a lot more information for your business. So we‘ve read „The Mom Test“ (the book’s name is a bit confusing, as it‘s not about the sexist-termed so called „mom test“ but more generally about running validation interviews) and did come up with a question catalogue that provides a much better insight into the world of the people we‘d be talking to.

Here we go again

Now, with that prepared, we were ready to shift our focus, while still applying our same vision. We‘ve conducted five interviews for now, and to be honest, we still don‘t know if we‘ve actually validated our idea or not. Those interviews were much less of a „hard no“ but also far from a „yes, please for the love of god build it now“. So, we‘re doing more interviews until we‘ve come to a point where we feel like we‘re not learning much more out of those. Our target group de-facto became much larger with that shift in focus (from infrastructure-related issues to more general product questions), but we think that allows us to talk to a whole bunch of people where we are able to find a niche that is a good fit both for us as well as for the market.

What you could take away from our mistakes

Some of us have built many products and are already well aware of all of those occurrences. We‘ve also listened to a lot of people and blogs but still managed to fail at some of the exact points everybody keeps pointing at. So, I‘m going to point at them, too, also to keep ourselves responsible:

• listen to a whole bunch of potential customers before building anything and ask questions that don‘t skew them positively towards confirming your hypothesis (while I‘d love to provide some good first questions, there is simply not a simple answer to this and this highly depends on what you‘re building)
• get the word out there, get it out early and get it to the right people (we‘re building a product targeted at developers, so we do know where to reach them and yet did not do that until much later in our development — also, really, nobody cares as much about your „release“ as you do, so just get it out)
• don‘t build two months worth of product without talking to anybody ;)

What we are building now

Anzu shifted from a visual infrastructure coordination platform to something much more broad: a toolkit for product teams to pick building blocks from so that they can spend time on building the things they want to build. We like to think of it as a much deeper (as in: it gives our customers much more context) Firebase, but at the same time, it‘s also a very different product. We would have loved to have a product like this for building our product(s).