With my cofounder Simon, we are now discussing how much time we should devote to building vs selling or validating. As a software guy, every cell in my body screams, build, build, build!
My road to entrepreneurship started like most people do. I was way overvaluing building my idea in secret before the final reveal.
The first side gig product I tried to build was a ticket-selling system for events. I spent months working on it, only for it to be used twice by a person I made it with and then never touched after 🙂
Since then, when I built something, the time before I tried to validate the idea got shorter. Ideas are very cheap, but execution and market validation are where it is at!
Selling beaver hide first
The ultimate top of this evolution is to sell or validate the idea before you start writing any code. Most podcasts and books on the topic suggest validating first, too.
We are also planning to run several experiments, as we call them.
We want to prepare several landing pages on people’s problems and buy some traffic via LinkedIn ads. The result of these tryouts will then inform our conversations and what we should be highlighting.
Of course, there are exceptions as to anything.
Small boy stuff
I have not validated the Wix plugins I have built, even though I made them recently. It is more than ok there because the scope is small.
Ultimately, selling is to see clearly if the market will be interested. In the case of these plugins, building a viable version takes a few weeks. There is no better validation than putting it up on the marketplace and seeing if somebody buys it. All the research and customer conversation would take the same amount of time and be less conclusive than just building and launching the thing.
Big boy stuff
Another exception I am experiencing now is with the Blive project. The whole energy segment is not super simple. There are a lot of communication protocols and APIs different parties use. Some parts are standardised more than others.
Building prototypes, as we have done for smart charging a fleet with just a touch of peek-shaving on top, was a great way to learn about these communication protocols and their challenges.
Many meetings we scored now are because we had some OCPP experience.
Having the cake…
So, in the end, we decided to focus on research, but timebox that for two weeks and then get back to building. So, kind of, we will do both 🙂 Let’s see how that works out.