About two years ago, a friend of mine came up with a simple app idea: 20 second audio recordings that can be shared publicly; it was “Twitter for audio recordings” (there was no Vine back then). We had the right team to work on the app, but we all knew we would lose motivation very quickly (there was no profit incentive, no marketing plan, etc). So, he challenged us (and himself) to build out the app in one week, and if it took any longer, we agreed to abandon the idea.
Exactly ten days later, a team of three (two developers and a designer) built a backend & a hybrid mobile app, and submitted it to both the iOS & Android app stores. The app allowed users to record short audio clips, saved them to a backend database, and shared them publicly on the app. It had no other features, no following, no private messages, nothing else; it was dead simple. We had gone from product idea to market testing in just ten days! And to our surprise, random users started leaving interesting (and sometimes funny) audio recordings for the world to hear.
A MVP (minimum viable product) is a product with the highest return on investment versus risk. In our case, our return was the valuable information we collected from our users (that’s another way of saying we had no financial returns ), but we only risked the ten days of our time we invested. Since then, I’ve had an opportunity to work with many tech startups, and build and launch my own tech products as well. To no surprise, a majority of product launches were failures; no users wanted to use the product (for various reasons). But what’s worse is that almost all of these failures had about three months of development time invested into them (on average).
Now, I don’t expect startups to launch a product in ten days, but I believe the average development time to build out a MVP can be reduced to about six weeks (again, this is just an average, I understand that every product is unique). For all of these failures (including my own failures), what started out as a MVP strategy quickly turned into a “let’s build a perfect product” strategy. From personal experiences like these, and many others, we at Kanda Software Development follow some simple rules to launch a product as quickly as possible, and therefore keep risk as low as possible. The following is an approach that we practice, of how to develop a low risk MVP.
Planning, Budgeting, and Wireframing
The “Twitter for audio recordings” was a low-risk development success (purely by accident) for the following reasons: 1. we had given ourselves a hard deadline, 2. we had zero budget (believe it or not, this can be a blessing sometimes), and 3. we had a detailed design in place before we started programming. This planning, budgeting, and wireframing stage (hard deadline, zero budget, and designing in our case) saved us critical time during the programming process; we knew exactly what to develop, and nothing was vague or left open for discussion.
Similarly, for every project that Kanda Software Development takes on, we spend the first week understanding our client’s vision, wireframing every detail we can, setting up the database structure, planning out the APIs, and of course, giving our clients a fixed quote and hard deadline. This first week is the most critical, and it normally determines if the programming process is going to go smoothly or not. This stage challenges our client’s vision, and gives them an opportunity to say “Ah, I didn’t think about that!” It defines exactly what the product will do, what it will not do, and leaves almost no room for modifications during the programming process (we save revisions for the end).
Know Your Target Audience
A past client of ours, Con Artist Collective, had a virtual community of artists on a private Google Forum. Once they outgrew what Google Forum’s free service had to offer, they hired us to build a Beta version of their own online forum, exclusively for their artists community. They are a perfect example of knowing your target audience very well, and in their case, they knew their target audience even before they built a Beta product! Their users were screaming loud and clear that they needed a product like this, and that’s a good problem to have!
Unlike Con Artist Collective, most startups will just have to build out a Beta product in order to get user feedback. In this case, it’s very easy to lose sight of the end goal when deciding what features to add. A low-risk MVP development strategy means that every feature added to the product should serve the purpose of “getting user feedback”, and not “building a perfect product”. Speaking from past experiences, Beta products that were full of “features” normally had a very low success rate. We work closely with all our clients to share our past experiences, and help them build a quick, feature-slim product. We much rather see our clients in a stage where their users are screaming load and clear of what kind of product they need, instead of investing in a “perfect product” only to find out their users have no need for it!
Revise, Revise, Revise
One product that I was involved in building was Legítimo, it allowed users to build multi-language legal contracts on their mobile phones within minutes. Some basic features that you would expect from an app like this didn’t exist in the initial Beta launch. Users constantly emailed us complaining that they had no way to export their contracts in a PDF format, so we decided to build out a PDF exporting function. We looked at our analytics and realized users were downloading the app from all over the world, so we decided to support contract building in multiple countries. The app continued to grow due to these small revisions, and we continued to learn from our users; these revisions played a very important role in the growth of the app!
For all our clients at Kanda Software Development, we offer to make revisions even after the product has launched. Most clients will eventually move the product development to be in-house, but until that doesn’t happen, we make sure not to abandon our client in any way. Without continuously revising the product, all the hard-work of building it in the first place may end up going to waste.