30 August 2019

The Equalture Story (8): This is why we have rebuilt our product and what we have learned from it.

The Equalture Story. A series of stories to give you a look behind the scenes of our company. Milestones. Failures. Lessons we’ve learned. Just the honest story about a SaaS startup trying to conquer the world.

In this blog: Why we have rebuilt our product and what we have learned from it.

Seven months ago we decided to rebuild our product. Next week the first clients will be launching our new product together with us. And wauw, it was such a rollercoaster. New frameworks, new techniques, unforeseen difficulties and a Product Owner (read: me) without any experience in that job.

But most of all: It was one of the most amazing and educational rides in the rollercoaster called Equalture so far. Therefore I’d like to share the lessons we’ve learned during this project.

Why we decided to rebuild our technology.

Before we dive into the useful lessons we learned, let me start by quickly sharing why we actually decided to rebuild our product – because it’s not something you should do if it’s not necessary.

When Fleur (my Co-Founder) and I started this company we had no clue about tech. But really no clue. Our solution at that point was to search for a team of freelancers that was able to translate our ideas into a platform. Luckily enough we found that team pretty fast, so all of a sudden we had a Backend Developer, a Frontend Developer and a UX-Designer. Cool!

Our pitfall here was that we didn’t have enough understanding of this project in terms of tech to be critical behind the scenes. The result is that we built a theater. We built a beautiful place to bring people together, inspire them and provide them with an unforgettable experience. With the most incredible stage. A stunning set of special effects. And a mind-blowing show. So everyone is happy, right?

The one thing that we forgot to take into consideration was the engineering plan. Because how many people could really fit into this space? How safe is everything? And is there a well-considered emergency plan?

In other words: Our product worked, the algorithm worked, but we didn’t know whether this product would also work for 1,000,000 applicants per day instead of 1,000. And what the consequences of these enormous volumes would be.

So that’s why we decided to rebuild our product: Because we wanted to welcome thousands of clients with 1,000,000 applicants per day in total with a smile on our face instead of sweaty hands.

Lesson 1. The W-factor is not about Wauw. It’s about Why.

I’m very demanding when it comes to our product: I want the best design and the coolest features to create a Wauw-effect. Thanks to our CTO I actually realized seven months ago that the focus shouldn’t be on the Wauw – it should be on the Why.

Every single feature in our product was evaluated based on the next three questions:

  1. Why are companies working with our product?
  2. Is this feature contributing to this reason?
  3. If yes: How?

When asking yourself these three questions every time again you prevent yourself from building an over-the-top product with 1,000 features while only 100 of these features contribute to your Why. After all, people aren’t working with you because they want to look at a product with a super fancy design all day. They want your product to help them making their life easier and actually solving their problems.

Lesson 2. Embrace feedback.

When we started this rebuilding-project seven months ago we had already collecting an enormous amount of feedback from our clients. However, I believe you can never receive too much feedback; for me feedback on your product is like the fuel for an airplane. Airplanes won’t fly without fuel, where products can never aim for the moon without getting feedback.

So we started collecting feedback from every single client. We scheduled a video call with all of them to ask them two questions:

  1. Does our product currently help you tackling the problem that actually made you work with us?
  2. What do you believe we should add or change to help you tackling this problem even more effective?

We made a Google Spreadsheet (I know that’s old-fashioned, but let’s call it lean & mean) where we mapped the clients with the same buying reasons and the feedback they got. Then we mapped this feedback to specific features in or product (or missing features) et volià. Now we had an overview off all feedback categories, mapped to all different buying reasons and existing/missing features.

Luckily enough this feedback actually didn’t change over the last seven months, so we could hold pretty tight to the roadmap we created.

Lesson 3. Perfect is a stupid word.

The third lesson is maybe the most valuable lesson I’ve learned and that’s thanks to our amazing Development Team. I’m always seeking for a unicorn product that’s going to blow away our clients from the very first second.

Well, here’s a reality check: Technologies will never be perfect. And they also don’t need to be, because that would mean that there’s no room for feedback from our clients, while feedback is the fuel for our product.

Our clients know that we’re a startup and therefore there will always be some things missing or things that could be done better. For them perfection is not why they bought our product; it was the vision we have and the willingness to change the status quo to help them solving their problems. And since problems are changing, products will change as well. So there’s not something like perfection. You should call it product-market fit. That’s what every product company should be seeking for.

I can’t wait until next week and start doing this cycle all over again. Because we will receive feedback. And there will be missing features. So I can tell you one thing for sure: Within two years it’s a whole other product again with the same goal we already had two years ago: Helping companies to build winning teams.

Cheers, Charlotte