Agile series: How we work — “Ship It” to your users
At aFrogleap, we use a four stages process for turning your brilliant idea into an awesome product. It’s called “Think It, Build It, Ship It, Tweak It”. This is the fourth in a series of articles on how we conduct this process. Read the previous articles on the “Think It” and “Build It” -stage to get a comprehensive picture.
Now that we have built your Minimum Viable Product (MVP), we shift into the “Ship It”-stage. The purpose of this stage is to gradually roll out your product to 100% of the users, while measuring and ensuring that the product fulfills its promise out in the wild.
“Ship It”-stage checklist:
- Release to a small percentage of users
- Measure, learn and adapt
- Release to all users
1. Release to a small percentage of users
Remember, in the “Think It”-stage we tried to answer the question “Is this product worth building?”. By creating a prototype and conducting interviews with real users, we tried to drive down the risk to actually build the product to a minimum. Now, with the MVP build, we can test if the hypothesis we defined hold up. If necessary we can also iteratively improve the product. By releasing the product to a small percentage of all users (typically 5–10%), we’re able to collect data of real users.
Remember, in the “Think It”-stage we tried to answer the question “Is this product worth building?”. By creating a prototype and conducting interviews with real users, we tried to drive down the risk to actually build the product to a minimum. Now, with the MVP build, we can finally test if the hypothesis we defined hold true, and iteratively improve the product as necessary. By releasing the product to a small percentage of all users (typically 5–10%), we’re able to collect data of real users.
Using this data and gathering user feedback we can learn from those early adopters, and answer question like:
- “Is this big feature really used as much as we expected?”
- “Are all the products possibilities clear for the user?”
- “Are users missing a feature?”
It is almost impossible to get it right at the first try, and part of the strength of this approach is that we don’t have to. We can now improve the product based on real usage.
2. Measure, learn and adapt
With the input of the first real users we can test the hypothesis we defined for your product, and improve it where necessary. For example: Your product is asking users for private data, like address or phone number. In order to gain the user’s trust in order for them to share these, two possible ways of persuasion could be:
- By creating an “on-boarding”, which guides the user through the product, while clearly explaining why their personal details are needed.
- By showing how many other users of the product shared their details.
Sometimes there is a clear winner in the different approaches, sometimes there is not. If there’s not, we can let the user decide. By creating the two variants (let’s call them A and B) which we show to similar users at the same time, we can compare the different approaches. This way we can A/B test (or split test, if you like) and see which approach performs better. The one that gives a better conversion rate, wins!
By building small items, we can test how they compare to other small items. We measure, learn and adapt our product in a cost effective and data driven way.
3. Release to all users
When we jointly agree that the product is having the intended impact on the small user group, we gradually role it out to more users, while still measuring and improving. This gives us time to deal with operational aspects such as hardware capacity, monitoring, continuous deployment and scalability.
This stage will end when the product is available to all users. It is now available in its minimal form with necessary improvements, while already adding value for all its users. After this stage the product will continue to evolve and more features added, in the “Tweak It”-stage. More on this in a next blog post!