Providing support for your Minimum Viable Product testers (sometimes known as Alpha version users) is an ongoing process that requires preparation and considerable time and effort in order to receive the kinds of feedback that you are after.
Recently I have come across several complexities when working with Minimum Viable Product testers. Here I describe two ventures; each with a different model for using Minimum Viable Product testers, and consequently chosen because of different users’ needs and approach for each. Here I share my experiences and lessons learned from dealing with both types in this two-part article
Growing your Minimum Viable Product testers slowly and gradually – A case with an iPhone App
Presently, this venture is still in its very early stages, It involves developing a mobile app exclusively for the iPhone (this is by itself another post for discussion – Which platform is better to initially develop your Minimum Viable Product upon?). In this case, the processes chosen were meant to launch the Minimum Viable Product version of an iPhone App in slow steps to a growing circle of testers.
The Initial App we developed has not been released to the Apple Store yet, so in the meantime we had to use each device UDID separately and add it to the iPhone’s Provisional Portal. On the other side, we asked our testers to register with TestFlight so that it will be easy for them to install each newer version we release. At each stage of the process, whenever we managed to process the inputs from the users and release a new version, which included the most significant feedback received and the most significant bug fixes, we grow our circle of Minimum Viable Product users by adding 5 new users.
The development process worked in sprints. Each week we had a new version ready to be released, re-testing it against previously known problems and issues. We didn’t add new users to our testing round until we were sure that we had managed to solve all the known issues of the previous rounds. This made our circle of users grow according to our ability to overcome the previous obstacles we found.
Finding test users was easy at the beginning. We first collected testers from among our friends and family, which ensured that our initial testers would have the patience we needed to get us through. Having users who were willing to give us the needed feedback over time was extremely valuable, especially because, in the early stages, our App was not functioning in the way it was supposed to function.
The Lessons we learned from our Users
First of all, not all users found it easy to work with TestFlight. Although it seems to be very easy and strait forward to use, which made us travel and meet users face to face in order to help them register and install the first version of the app and also guide them through process of how to upgrading the app to the newer versions.
Our App didn’t include a way for the users to interact between them, so we had to engage each user separately and, from time to time, collect their feedback and follow their online activity in the app, analyze it and then try to gain some lessons to learn. Each week we summarized our finding and prioritized our tasks based on our development availability. Through this process we had to determine what was essential for us to keep for the next release, and what were our low priority tasks that could wait for future releases.
Some of our testers failed to use the App. They didn’t have the time or interest in using it. We had to understand why they didn’t use it and in some cases, after trying to resolve the problems they encountered, we came to the conclusion that not all our testers would provide us with the kinds of feedback we are after, and by then it was time to add new testers anyway.
Locating our testers was easy, we started with friends and family who we knew had an iPhone. Then we moved closer to our potential group of target audience to whom we had access and started offering to them that they begin to use the app. This happened only after we managed to include enough testers from our friends and family group, where we had managed to bring the app development up to a place where it was easier to use and essentially bug free.
It turned out that the process we choose was in this case optimal for growing our circle of testers gradually, slowly taking into account our ability to work in small steps towards our goal with enough air to breathe in between waiting for the user feedback to arrive.
It also gave us enough time to test out the functionality of the app and to adjust it according to our users’ feedback. It also meant that our financial burn rate was kept low, because we had the ability to proceed only on the inputs of our users and we didn’t have the additional pressure from market sales or investors requirements to show results that meet their deadlines.
Summary
The App development described in this article is a classic case of a lean startup approach to developing a product. This conclusion is supported by the fact by going slowly, the our initial users are able to provide us with precise and qualitative feedback which can help us improve the app gradually over time. The approach is also based on the fact that our burn rate is very low and we have enough seed funding to help us move in this pace without the need to show results as soon as possible. We plan to go to the market only when we feel the time is right and our app is at the place we think it should be.
