Starting a business
How to build a minimal viable product (MVP)
This post covers how to build, release and iterate on your first product. It’s difficult to know how to begin, when to release your first product into the world, and (most important) what you do next. If you build it, they won’t come, overnight successes don’t exist but learn how to best your chances of succeeding.
Building your first product
Make sure you’re building a product that is solving an actual problem. Many people fall into the trap of wanting to start a business without considering how it will provide value to users. If you’re not solving a user’s problem, why will they use it?
Start by building for a small audience; don’t build to cater to everyone. Everyone has different problems and preferences, and trying to build for everyone on the planet will result in a mediocre product for many, rather than a powerful product loved by a few.
“It's better to have 100 people that love you than a million people that just sort of like you. Find 100 people that love you“ - Paul Graham
It’s better to have 100 people love your product, and are willing to pay and share it, than a million people who sort of like, try it and end up forgetting it (or worse, not being a product they see enough value in to pay for long-term).
TryHackMe reached 2 million user registrations, and never invested in any paid acquisition methods (no paid ads). Our growth was completely organic and through word of mouth; people loved the product, championed it to their network, and got like-minded people to sign up, who then ended up loving the product, and the loop continues. We didn’t start by building a product for everyone but focused on beginners who needed training to break into their first cyber security career.
When you’re building, set a timeline for when you want to release your product by, and set exactly what features you need to create to develop the smallest viable product that you can get in front of users.
Your first product doesn’t need to be scalable, in fact, its better if you build it in the most manual, quickest, and unscalable way possible, as your product will evolve a lot after you’ve started to talk to users.
When building your minimal viable product, ask yourself on a regular basis if the feature you’re working on is essential to the product to show users how you’re solving their problem. Do you need a fancy sign-up page, or (to begin with) even payment options?
Build it quick and cheap.
Summary
Ask yourself what user problem your solving
Start by building for the few, not the many
Give yourself a timeline and constantly evaluate features
Do things that don’t scale
Knowing when its time to release
If your product is anything near perfect, you left it too late. It’s hard not to make everything absolutely perfect, but you risk wasting valuable time, and it will only be a few key features you build that you end up focusing and iterating on.
When you have the absolute minimum product developed that allows users to use your product, release it. The idea is to present users with your rough solution to start refining it; your first development won’t be anything near what you have in version one.
Once your product is made live, don’t expect users to rush to sign up when you first release your product. You’ll need to be proactive in getting users to know about it. There is a lot to acquiring your first 100 users, and perhaps that’s for a future post, but you want to start advertising your product in places where your users are active; think about who you’re targeting, where they are active online, and how you can have them interested in your product.
Ashu and I (co-founders) built TryHackMe for ourselves and was a side project we loved creating. After sharing the first version with a few friends, the word quickly got around about our product - in the first few months, we posted useful articles about TryHackMe on cyber security sub-reddits, social media and even convinced our Universities to use it within computer science classes.
Summary
If your product is perfect, you’ve left it too late
Don’t expect people to actively sign up when your product is first live
Talking to users and iterating
Now that your product is available to the public, you have something to show users. You want to understand your user’s needs, validate the assumptions you’ve made when developing, and gather information to start building a user-centric product.
Here are a few tips to keep in mind when interviewing users
👥 Speak to more than 1 user - Speak to a few users, don’t let one user dictate the entire product. You’ll waste a lot of time building a specific feature for one individual - validate it with multiple people.
✅ Prepare questions - Before a user interview, prepare what you’re going to ask. You want to form questions that help you build a better product. Ask yourself how you can form questions to help you achieve that?
🔁 Talk to users regularly, not once - Speaking to users is not a one-time thing. You’ll want to take your learnings from talking to them, iterate on your product and then talk to new (or existing) users to continue a close product feedback loop.
🤔 Ask for problems, not solutions - You want to deeply understand your user’s problems, and not ask them for solutions. If they had the right answer, they wouldn’t need you. It’s your job to discover, build and continuously improve a solution.
Talking to users is an art. You want to ask questions that will help you understand how to provide value to customers best. You are building a product for them after all, so why shouldn't they get a say?
TryHackMe’s first version was extremely underdeveloped, and users could just about use the product. However, we were proactive in talking to customers and making improvements. We found users were happy to give feedback, and it developed champions as they saw TryHackMe improve day over day.
Founding companies with big pivots
Talking to users and witnessing their behavior can lead to ground-breaking product changes or complete pivots. Here are a few stories that describe how applications loved by millions today started off very differently in the early days:
Instagram - Did you know that Instagram was first called “Burbn” and was originally a whiskey app? The founders noticed how people were using the app and found the photo-sharing part was highly loved. The app then pivoted to a dedicated photo-sharing application, rebranded as Instagram, and acquired by Facebook (for $1B) less than 2y after being founded (now worth >$100B)
Slack - The popular messaging application Slack started out as a game called Glitch. The game had strong internal communication functionality, and they found it more valuable to users than the game itself. They quickly pivoted into messaging and were later acquired by SalesForce (for $27.7B).
The takeaway? Speak to users. If these products didn’t change, they wouldn’t have existed today.
Things you don’t need to do yet
Make sure you’re always focused on high-impact tasks. There are a few things you don’t need to do yet that I’ve seen many waste time on:
🏗️ Making it scalable - you want to validate your idea as quickly as possible, don’t waste time and money making your app scale to millions of users when you’ll most likely only have a handful using it in the first few weeks/months. Validate, then scale.
™️ Trademark - Do you need a trademark for your product immediately? Again, 9 out of 10 businesses fail, and the risk of failing is high. Increase your chances of success by focusing on solving your user’s problems, not protecting your logo/name.
🌎 Think big but start with a short-term plan - Your product and company vision could be very different from day 1 of release to day 90. You should have a plan and vision in your head, but develop a short-term strategy with long-term considerations. Once your product is validated, then it’s time to sit down and plan far into the future.
🗑️ Low-impact rebuilds - If you’re a technical founder, don’t fall into the trap of repeatedly redesigning your applications tech stack. I’ve seen founders rebuild useless parts of the product (such as their authentication systems) multiple times. Don’t waste time rebuilding unnecessarily.
Subscribe for weekly advice on how to succeed in building and scaling your first company.