Recently there has been a lot of noise made about minimum viable products (MVP). MVP was the topic at this month's Chennai Open Coffee Club. Unfortunately I couldn't make it at the last minute, so there are my thoughts on MVP and our approach to building Tour My App.
We recently launched a new product called Tour My App. This is a product through which you can create "tours" to guide users step by step through the actions required to complete tasks in your web application. In this post I'll explain how we are applying the MVP concept in Tour My App.
First some history.
We've always wanted a tour functionality in our other product - Tools For Agile. We searched for various solutions, but didn't find anything that fit our needs. In the meantime, The Startup Center had an event called In 50 Hours. The premise of the event is simple - build a product from scratch in 50 hours. Kausikram went ahead and built an initial prototype of Tour My App over the weekend. The idea was to later on incorporate that into our product. However, during the demo at In 50 Hours, many people expressed interest in having that functionality in their products as well. We then decided to split this functionality into a separate product.
Tour My App was born.
Having decided to build it out into a separate product, we now needed to figure out our release plan. Here is where the MVP concept enters the picture. MVP is a principle to build just enough of the product to validate your assumptions. They may be assumptions on user adoption, pricing model, sales model, technology... anything relating to the product. We have some idea about all these factors when we start, but they are all assumptions. How do we validate it? What we do not want to do is to build a big product and then learn that many of our assumptions are wrong. So, our goal was to build the product piece by piece in order to answer the most important questions up front.
Out of all the questions, the top questions right now were
But this is just one data point. Were there other companies like this? And would they pay to have it solved?
These were the questions we wanted to answer.
So we did something unconventional - we charged for the beta.
Generally beta testers get the product free. So why did we charge for it? In usual terminology, beta testers are testers. This means that they are given a buggy product and are expected to report bugs. In exchange for this service, they get the product free. In our case, the product is not buggy. We even have a demo page showing it in action. We want people, not to test the product, but to solve their problems.
The initial beta pool is a set of companies who really have a serious problem, are willing to pay to get the problem solved and the problem is serious enough that they want to explore solutions right now, rather than wait for the application to go live later.
In other words, we want to filter out the people who signed up for beta expecting a free toy to play with, and focus on those who need Tour My App.
So what does all this have to do with MVP? And if the product is production quality, then why are we in beta? Simple, the quality is at production level, but the product isn't finished.
You see we only built the bare minimum functionality to run a tour. There is still no UI, no sign up page, no login page. In order to save a tour, we have to go into the database and create user accounts and store the data manually.
Why did we do this? Because building those features now doesn't help us answer the questions we want answered at this point. The MVP is the minimum you need to build to get answers to your questions. So we cut out these features for now. We'll build it later.
We are sitting down with the beta companies, and together figuring out what different kinds of tours they need. Based on that we will add the data to run the tour into the database and the tour can then be deployed live into the app.
The discussions will also highlight whether we need to add more functionality into Tour My App or not. We have thousands of potential features in our minds. We are not going to implement any of them until we come across a beta customer that needs it. Then we will build it. So we are not building features based on assumptions, or coolness, but only when see a need in front of our face.
In this phase we want to answer the question: Can we build the kinds of tours that customers need?
Once we figure out the answer to that question, and are satisfied that we are doing a good job of solving beta customer problems, only then will we build out the frontend, the website, the signup page, login page and all that. All that is simple - there is no unknown risk there.
Then we will open to the public with the live application.
PS: Do you think you are losing customers (and therefore, lots of revenue) because some proportion of users cannot figure out the steps required to complete tasks in your web application? Is the problem so bad that you want a solution right now and are willing to pay to have it solved? Then give us your email and we'll bring you into the beta program.
We recently launched a new product called Tour My App. This is a product through which you can create "tours" to guide users step by step through the actions required to complete tasks in your web application. In this post I'll explain how we are applying the MVP concept in Tour My App.
First some history.
We've always wanted a tour functionality in our other product - Tools For Agile. We searched for various solutions, but didn't find anything that fit our needs. In the meantime, The Startup Center had an event called In 50 Hours. The premise of the event is simple - build a product from scratch in 50 hours. Kausikram went ahead and built an initial prototype of Tour My App over the weekend. The idea was to later on incorporate that into our product. However, during the demo at In 50 Hours, many people expressed interest in having that functionality in their products as well. We then decided to split this functionality into a separate product.
Tour My App was born.
Having decided to build it out into a separate product, we now needed to figure out our release plan. Here is where the MVP concept enters the picture. MVP is a principle to build just enough of the product to validate your assumptions. They may be assumptions on user adoption, pricing model, sales model, technology... anything relating to the product. We have some idea about all these factors when we start, but they are all assumptions. How do we validate it? What we do not want to do is to build a big product and then learn that many of our assumptions are wrong. So, our goal was to build the product piece by piece in order to answer the most important questions up front.
Out of all the questions, the top questions right now were
- Is Tour My App solving a real problem?
- Will people pay to have this problem solved?
But this is just one data point. Were there other companies like this? And would they pay to have it solved?
These were the questions we wanted to answer.
So we did something unconventional - we charged for the beta.
Generally beta testers get the product free. So why did we charge for it? In usual terminology, beta testers are testers. This means that they are given a buggy product and are expected to report bugs. In exchange for this service, they get the product free. In our case, the product is not buggy. We even have a demo page showing it in action. We want people, not to test the product, but to solve their problems.
The initial beta pool is a set of companies who really have a serious problem, are willing to pay to get the problem solved and the problem is serious enough that they want to explore solutions right now, rather than wait for the application to go live later.
In other words, we want to filter out the people who signed up for beta expecting a free toy to play with, and focus on those who need Tour My App.
So what does all this have to do with MVP? And if the product is production quality, then why are we in beta? Simple, the quality is at production level, but the product isn't finished.
You see we only built the bare minimum functionality to run a tour. There is still no UI, no sign up page, no login page. In order to save a tour, we have to go into the database and create user accounts and store the data manually.
Why did we do this? Because building those features now doesn't help us answer the questions we want answered at this point. The MVP is the minimum you need to build to get answers to your questions. So we cut out these features for now. We'll build it later.
We are sitting down with the beta companies, and together figuring out what different kinds of tours they need. Based on that we will add the data to run the tour into the database and the tour can then be deployed live into the app.
The discussions will also highlight whether we need to add more functionality into Tour My App or not. We have thousands of potential features in our minds. We are not going to implement any of them until we come across a beta customer that needs it. Then we will build it. So we are not building features based on assumptions, or coolness, but only when see a need in front of our face.
In this phase we want to answer the question: Can we build the kinds of tours that customers need?
Once we figure out the answer to that question, and are satisfied that we are doing a good job of solving beta customer problems, only then will we build out the frontend, the website, the signup page, login page and all that. All that is simple - there is no unknown risk there.
Then we will open to the public with the live application.
PS: Do you think you are losing customers (and therefore, lots of revenue) because some proportion of users cannot figure out the steps required to complete tasks in your web application? Is the problem so bad that you want a solution right now and are willing to pay to have it solved? Then give us your email and we'll bring you into the beta program.