3 weeks into our exploration, we were becoming edgy about starting to build one of our explorations. 4 of the 5 people in the team were engineers. At the same time, we didn’t want to work on a project without being convinced by it.
To make the decision easier, we defined what we expected from the prototype and its scope. The goal of prototyping was to validate some known unknowns in the project. We would try to fit the prototyping within the timeline of a single month, so we could take all the shortcuts needed and remained completely okay about discarding it. Prototyping was a complete part of the exploration, and was a two-way door decision.
It took us 6 weeks to start prototyping a project. Before then, we were not convinced enough to commit a full month from the whole team.
Please note that we did mockup prototyping for several projects during those 6 weeks. So we mean actual working prototype here.
6. How to react during stalemates
Another challenge that arises in this exploration period is the fatigue attached to not having a vision that you strongly believe in. At moments, we would arrive at a stalemate, having invalidated all the ideas we had. At that moment, we would do 2 things:
Go back to the ideas we have had in the past few weeks and the reasons why we investigated them and invalidated them.
Have another brainstorming session.
The first step is important, as it ensures that you have all the learnings you have accumulated for the brainstorming sessions.
This explains why some old ideas we investigated at the very beginning resurfaced with some small tweaks later on.
Should pre-PMF startups look like this in the end?
About 80% of startups don’t find product-market fit. This means for most of them that they haven’t identified the need to pivot and explore other approaches early enough. So you might wonder if a pre-product market fit startup should look like this!
This mental map shows all our explorations. At the far right, you will see what we’re currently building: an open-source data integration engine - the OSS ELT.
In the 1st month of investigating this idea, we did 21 customer interviews, and identified the same patterns across companies.
Current cloud-based solutions - Fivetran and StitchData - don’t cover all their integration needs, so they still need to build their own integration pipelines, which are cumbersome to maintain.
Their pricing indexed on volume limits how they can move their data.
They were very sensitive to having full control over their data and its privacy, through a self-hosted solution.
We started prototyping after the 5th interview, as we saw those 3 patterns emerge. The 16 other interviews enabled us to validate our assumptions further and understand their exact requirements and needs, in addition to building up a list of prospects, once our MVP was launched.
We would like to finish on this note. If we were investors, we would have much more trust in a team that moves fast and iterates a lot, rather than a startup that only investigates one approach.
What do you think?
The data movement infrastructure for the modern data teams.