Harmonypark’s ADP #6: Produce minimal viable feature set for private beta

Having validated and estimated features and developed the information architecture for the first iteration, production can commence. The output of the first iteration should be as close as practical to the minimum viable feature set that provides value to users and meets some or all of the business objectives.

This iteration is then released as a private beta restricted to ‘friendly’ users such as those who have been involved in the prior steps throughout the process, and potentially others that those users wish to invite. Ideally these users will be willing to provide detailed feedback on their user experience with this first version of the application. Use of analytics tools, heat maps, etc will also provide feedback data. This feedback is the basis for the second iteration.

Iterate to public beta based on feedback in private beta

The second iteration evolves the closed private beta into an open public beta, where any user is able to access the application if they wish.

Feedback and data gained from the private beta informs what is changed, along with the introduction of further features from the backlog which weren’t of a sufficiently high priority to make it into the first iteration.

When the public beta goes live, an initial marketing/communications plan may be launched to drive users to the application. Conversely, growth can be organic from existing users who have participated in the private beta, and from SEO and social media strategies.

During the public beta it can be beneficial to utilise A/B testing, i.e. trialing two different versions of various pages and features, to determine which has the most appeal and uptake by users.

Iterate to launch based on feedback in public beta

The timing of the full public launch is generally determined by business and/or marketing factors, but allowance should be made for a third iteration to improve the application based on the results from the wider, public beta phase.

During this iteration, optimisation and scalability should be addressed in terms of any caching strategies, re-factoring and infrastructural changes required to meet the expected user load. (While these considerations should inform the application design from the outset, it is also the case that pre-mature optimisation hinders agility and increases the duration of iterations, so a balanced approach is required.)

Where there is a significant marketing budget, the full communications plan will be expected to drive significant volume of users to the application.

Now that the application has reached full production, continuous improvement principles apply. Further iterations are expected to refine and improve the proposition to users, reacting to the feedback and data they generate. These further iterations generally will occur more irregularly and over a longer span of time, as they may be dictated by KPI success or other business factors.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.