This is article #2 in my series How not to build a business. I open up about all the mistakes I made building a software as a service and all the lessons I learnt in the process.
My mistake: My product was a nice-to-have
As I explained in my post about how I validated the problem I was solving, when I was talking with my clients to see if the problem was acute enough, I finished the interviews convinced by my interlocutors’ feedback that the sale was practically done. Since I had already shown my users the prototype, I only had one task left: build the product.
In order to provide restaurants with the best digital menus, we designed a double faced product. On one hand, we created the digital menus that the diners would see after scanning a QR code on the table of the restaurant. On the other hand, I came to the conclusion that restaurants would need a dashboard to modify their menus quickly and swiftly. The dashboard allowed restaurant owners to add dishes easily, change the order with a fancy drag and drop, create menus, delete them and much more. Feature creep loomed upon us but it was worth it because, as I said, we were convinced we already had clients. After spending around two months building, we were ready to pay another visit to our clients. The tonic of this interview, compared to that of the first one, quickly changed. Contrary to what I had been led to believe, the clients that I had interviewed were not as excited as I was (bad signal). I experienced first hand that it is very different when someone tells you that they will buy something rather than when they actually buy it.
After all this process I discovered my solution was an absolute vitamin. Of course a digital menu is better than a physical menu. However, restaurants were not about to throw away physical menus, so my solution just added another layer of complexity to their already hectic business. If I took away my service, they would not suffer at all. In order to solve this issue, I kept on building feature after feature thinking the next one would change everything. But clearly the trees did not let me see the forest. A few restaurants actually bought the software, but I was the only one using the dashboard to change the dishes and create the menus because restaurant owners were too busy to learn how to use it. It was way easier for them to send me a photograph of their menu and ask me to update it. Of course, I obliged. It was then that I realised we could have launched much faster without building such a beautiful dashboard.
Key learnings:
As always, mistakes are a treasure trove of learning material. These are the key learnings from validating my solution:
#1 Sell first
You have to try to sell first, before building anything. The only way to actually know if someone would buy something is not to ask them if they would do so, but to confront them with the situation so they make a decision. The way to make this task feasible is not through complicated psychological tricks but making sure that the problem you are solving is acute enough that the customer is willing to pay you in order to obtain a solution.
You may think: how am I going to sell something that does not exist yet? Well, you should not hesitate about this. There are many ways to mask the lack of a product and you would be surprised by the amount of customers willing to pay for a product which is under construction. The great entrepreneur Pieter Levels masterfully did this with his book “Make”, which helps people understand how to live the life of an indie hacker, creating businesses around the world. Instead of writing the book and then selling it, he created a landing page with the book subject together with a link for people to reserve their copy once it came out. Thousands of people reserved the book and when it came out, Pieter already had customers.
#2 Keep it simple and do not overthink it
If I had to repeat the product we built for iMenoo, I would just create the page that the diners accessed when scanning the QR code. It was one page with a list of dishes, so we could have probably coded it in one day. There would have been no fancy dashboard, no nothing. Eventually, we would have had to build a dashboard, but only after having a few paying clients. We would not have spent months creating a product for a problem that only arose as a result of overthinking.
I often have friends that come up with a business idea and their first question is: how much does it cost to build an app for X? My reply is always the same: do you really need an app? Is there no way you can do this manually and mask the existence of that app? The mindset when building a product can extend to multiple types of businesses. In my opinion, the right approach is to focus on the added value that you provide and try to do things manually. Depending on the type of business being built, it will be more or less difficult to create a minimum viable product.
Types of prototypes
I will cover how you can build cheap and fast versions of services depending on the type of product you are building. We will only see four broad examples but the point extends to other categories and the lesson to learn here is that there is always a way to do more with less.
Hardware products: these types of products are expensive to develop, specially at scale. However, you are lucky because since you do not have clients yet, you do not need to scale. You need clients. In my opinion, the two best ways to launch a prototype for a hardware product is doing a crowdfunding campaign (with a service such as Kickstarter), or doing a pre-sale (with a service such as Shopify or Typeform). You can build a clunky prototype. It does not have to work fabulously, just when you are pointing the camera at it for the Kickstarter promotional video. This kills two birds with one stone because, not only do your clients validate they like your solution with their money, but they are actually funding the product development.
Software products: this can vary greatly, but most of the time software is just used as a way to exchange information. That is, clients input information and you have to give them something back. More often than not, you can use tools that help you collect that information so you can focus on providing the service manually behind the scenes. For example, in my case, I could have created a dashboard with a Typeform to collect the restaurant menus from the restaurant owners.
Real estate: people in the real estate world have discovered the minimum viable product way and create 3D renders for pre-sales. That way they can sell real estate without having built anything at all.
Marketplaces: this is one of my favourite examples. If you go to the first principle of a marketplace, what does it provide: it provides connection between people who sell something and people who want to buy that thing. People often think that all marketplaces require a ton of technology and spend thousands building apps that never get used. The best way to launch is the following:
Find people from the segment you are focusing on that are selling.
Find people who are interested in buying.
Create a Whatsapp group and include them all in it.
If you manage to drive sales through a Whatsapp group, your business will be a success and it justifies spending more money on building.
You have to bear in mind that there are certain areas, such as deep technology, where it is more difficult to create something fast, so I cannot help you there! For all the other situations, if you are not embarrassed by the first version of your product, you have not launched fast enough.
Conclusion
You are now out in the real world, you have made your first sale and the stakes are high. How do you not mistake what to do and what not to do? Check out how not to build your competitive advantage entry.
"I have no special talent. I am only passionately curious"
Throughout my life I have lived in Hong Kong, France, England, Spain, United States and El Salvador. This has given me the opportunity to explore and learn from different cultures and societies, meeting wonderful people all around the world.
I am a very proactive individual who works well in teams and with strong leadership skills. I love public speaking and hearing about projects and ideas.