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.
This is the second article which describes another type of venture, one where the product release was done to an ever-growing audience of testers which were not controlled. Because of these complexities, dealing with and offering support to our initial users required a different approach.
Growing your Minimum Viable Product Testers Rapidly – A case with a Web-based Plug-in
In this case, I want to talk about experiences that pertain to a different sort of Minimum Viable Product release – a web-based plug-in – whose process differed from the previous example in part A of this article (the iPhone App) which, in turn, provided some unique lessons to be learned.
This case actually involves several web plug-ins which were developed to supplement an existing platform that had the potential to reach more than 10 million users. One’s ability to market the products within a marketplace is where you can offer the most out of your products, perhaps even leading you to approach several additional sub-markets.
When we started developing our products, we based all our initial research on the need that the market has for these particular products. From these conclusions, we defined our product requirements. We also checked for alternative products that offered similar features. This managed to help us understand exactly where our value lies, somewhere within this range of products that we are planning to develop.
For each product we developed, we had a list of the initial Minimum Viable Product features and included any additional features on a list so that when we may want to add more to our product, we do so only after we understand the market potential. Once we finished the development process of the Minimum Viable Product and QA, we released it to the main marketplace by offering it as a basic free version that also had a premium version that was for sale.
Minimum Viable Product Users
Our users in this case where random, not hand-picked or pre-selected, but essentially users who ended up being the ones that where the early adopters of our products. These random users were more akin to our real target audience, and since their feedback counts the most and is essential for our product’s success, we had to be very responsive and quick in releasing our bug fixes and newer versions, every time we discovered major bugs in our product.
The feedback we received arrived in two ways – the first was through a Contact Form that we provided, which helped us open trouble cases and track them until they were closed, and second, we had an open discussion forum where users could share their views with us and each other and also post questions. The open discussion forum was, on one hand, a great way to share users’ good feedback and engage new users, but on the other hand, whenever we came across frustrated users who didn’t manage to properly install the plug-in, due to some technical issues on their side, they would often flame the forum, causing damage to the overall good feedback we had gained.
The users that interacted with us directly helped us to receive feedback on time. Whenever we could, we always made sure they were happy with their experience of using our product. But in some cases, we had to reimburse people the cost of their purchase, especially once we realized that the plug-in could not meet their needs or expectations. This happened when, for some reason, they understood differently the list of features and functionality we were promoting as included in our premium version when it ended up that they were out of the scope of our product’s goal to add these features.
Early Release Testers
With several users we managed to create some sort of a working relationship which was based on our ability to quickly help them solve issues they had and their interest in being the first to receive new releases of our products and test them before we release to all other users.
This was a great help for us since we could receive better feedback and test our product on several more installations before releasing them.
We always made sure that the users helping us will be heard and supported in the best way we could so this relationship could pay for both sides
Unsatisfied Users
The users that interacted in the open forum was a completely different story. Here, every response is documented and other users could read them, perhaps even judging our product and brand upon it. In this instance, we had to be very careful with the wording of our responses and suggestions, but we nevertheless made our mistakes!
Whenever our responses came to users on time, we usually managed to receive some good feedback from them. But then there were several cases where our response didn’t arrive to them in the timeframe that the user expected it to arrive (usually over the weekend). In these instances, not all users were polite to us and some even caused damage to our product reputation.
It was also sometimes very difficult to solve each user’s problem, since sometimes it involved an understanding of the platform and environment in which the plug-in was installed. It was practically impossible to do a good job responding with a fix for every user. In the end, we only did this for our premium users, because we assumed that this may provide us with some insight into configuration issues and bugs. In such cases, we asked for the user’s permission to log into their system and track the problem ourselves in order to solve it.
This didn’t work so well for us within the overall open forum community. We could not support everyone who had some kind of installation problem, nor did we have the time or the ability to login into every system to find out what was causing the problems. We simply didn’t have enough resources to do this kind of support very well and we paid the price of not being able to satisfy all our users.
Efforts needed to support Users
Along the process of supporting our users, we learned that what we need to invest more effort into was in creating the supporting documentation that went along with our product. By preparing a well-documented users guide and perhaps also some video tutorials, we probably could have avoided many of the problems our users experienced. Once we did this more thoroughly, the user-guide helped us to receive more precise requests from our users and to lower some of the frustration from them in the open forum. The side effect of this was that it also helped us market our product better, which in turn, gave us a great return for the effort we invested in preparing our user guide.
Summary
Supporting your Minimum Viable Product testers is an ongoing process. Your support of them needs to be taken into consideration when developing and releasing your Minimum Viable Product product. It is essential to your testers that you provide them with on-time responses to their questions and feedback. Providing good user tester support will sometimes lead you into a more personal one-on-one relationship with him in a way that gains their trust, all while you are collecting the feedback you need. Sometimes you will find noisy or angry users which you cannot satisfy. The best thing to do in these cases is to try your best to help them (which can be highly time consuming). If you leave the troublesome users alone, you have to take into consideration that the price it costs your reputation, while they try to publish their disappointment everywhere they can… Once releasing your product to the market, you should think ahead of time on the resources you need to provide for tester support, and remember, always keep your users as happy as possible.
Looking at the two different cases described in these last two articles, the approach of the lean product development, where one can easily add a small group of users each time to the circle of testers, is much more of an efficient way for developing your Minimum Viable Product. But this assumes that there are minor time or budget restraints or that users can easily be selected and added gradually. On the other hand, in the case where the only way to expose our product to the market was through the marketplace, the development cycle was much quicker and we had to deal with giving support to many users at once. Even though this brought in a lot of feedback and bug fixing insight, it was very time-consuming and we could not support large amounts of users in a satisfactory way.
