@nico_jeannen tells us the success story of how he made $65,000 from a project that creates logos automatically using AI with 0 budget and having learned to code just 9 months ago. Beyond the success story itself, his approach to the project has some ideas about dealing with uncertainty and risk that people, startups—even if it's just the startup of you— and companies in general, can learn from. These ideas are also seen in modern product management and agile.
Nico already knew how to make logos, but he had the idea of making an app that could generate them with AI rather than manually.
I had a sudden idea. What if I made an app to generate logos using AI?
While it appears that logo generators were a thing since forever, from his perspective it looks like many logo generators didn't use AI, there were just mixing predetermined icons with random fonts. Having a generative AI could make a difference in marketing.
Rather than immediately running to build the fully featured app, spending many months in the process, he first formulated his assumptions:
I needed 2 hypotheses:
Can I make logos in an automated way?
Would people pay for it?
Why is important to focus on your assumptions before building? Because we want to optimize to be wrong. If we discover that our assumptions are mistaken, there's no point in moving forward with the original idea, we've saved time and money and gained valuable insight. The sooner we learn that our ideas are bad, the better.
The two hypotheses he formulated are about feasibility and desirability: can we do it, do they want this?
Experiment to minimize risk
The hypotheses Nico recognized were probably the riskiest ones: if it turns out he can't make logos with AI or that people aren't willing to buy them, there's no point in continuing further.
In general, we want to start looking at the hypotheses we know the least about that are also the most critical to the success of the idea or business. If these hypotheses are disproven, it all fails.
With the assumptions at hand, he proceeded to experiment to verify if there was interest and if people were willing to pay. The experiment was cheap and crappy:
By crappy, I mean a static HTML page linked to a Typeform to collect payment. The back end was literally me generating the logos and sending them by email. No framework, no fancy stuff, just text and pictures.
Cheap, fast and “crappy” is what we want at the beginning.
Consider it to be a bet. Initially, our bets should be small. If we fail, we don't lose a lot, if we “win” it means we have more evidence that our idea might work, and the risk decreases. From there, we can make bigger and more expensive bets to get more evidence, until we have enough evidence to take the risk or the bet cost is bigger than taking the risk itself.
What Nico did is called a Wizard of Oz experiment. While the clients thought there was software doing it all, he was the one creating the logos manually.
The Wizard of Oz experiment is an experiment that gives us strong evidence of desirability, feasibility, and viability. Usually, teams might want to run discovery experiments first, which are cheaper and tell us if the general direction we want to take is correct and allow us to learn faster (remember the bet).
The result of the experiment gave him strong signals. It was time to take it to the next level.
The next step was to make an automated version, so I made another challenge of making an automated version in 48h and launching it on @ProductHunt
Notice that, again, he didn't spend weeks or months building the finished and polished product. There was still a critical assumption he needed to test: that it was possible to create logos automatically with AI. With a 48h experiment—you could call it a spike— he demonstrated that his assumption was right.
The rest is history.
Don't assume success
Now, keep in mind that it's not my first shot at entrepreneurship. In the last 5 years, I launched around 35 projects, and most were total failures. Just between October and December 2022, I released 7 different apps.
In a world of uncertainty, many ideas will fail, that's the default. Expecting success, predictability or that we know the answer can lead to disaster. His success story is just one out of the many “failures” he had, failures that were also valuable learning experiences.
This story also makes me think that, in uncertainty, in a VUCA world, committing too hard without enough evidence is a recipe for unrecoverable failure or improbable success—and survivor bias stories. We want to keep our options open, probe, sense, and respond. Optimize to be wrong.
Hey 👋! If you've liked this article, I recently created a newsletter where I write about my eclectic thoughts about software, agile, culture, product, architecture, etc.
Go here: alejandronapoles.beehiiv.com