If you missed the second article in this series, no worries! You can catch up here.
By now you should have sketched out your App ideas on paper or a whiteboard, and starting creating the design and technical specifications that your visual designer and developer(s) will need. They will help to fill in any missing blanks that you need.
So now it’s time to consider creating your application. This can be a big task, so it’s best to break it into smaller pieces. And since developing software is not a linear process, it makes sense to start small and grow it from there. This means starting with an App with less features and functionality, but enough to test it with your target audience(s). Some reference material call this an MVP (minimum viable product), but there are, in fact, multiple versions of a MVP.
Rather than viewing a MVP as a standard process, think of it as being more like a philosophy. The idea behind is to get a much smaller version of the final product out to the market as soon as possible, where changes can be constantly made based on user feedback. Why waste further time on things that may not be essential to the running of the App? Once again, the developer (and possibly, the designer, depending on the feedback that is received) would be involved in this process.
The first version of your MVP can be as simple as putting up a landing page or small number of page describing your ideas, including some of your more detailed mockups to a targeted and generally private audience. You will have primary goals with MVP #1, including:
- To test your ideas on a small group of trusted testers;
- To collect ideas from them about whether if/how they would use it;
- To get their contact information (name and email address) if you don’t already have it.
The next version of the MVP (MVP#2) will be the no-frills prototype that only solves the key problem, and will have no bell and whistles. It will not look finished. It will not allow the users to do all the expected functions. In short, it will test your ideas and generate considerable conversation to get more feedback from trusted targeted users.
MVP #3 comes later, and will be a presentable product that could be or lead to a beta testing product. Once again, you are collecting information from a (probably larger) trusted audience about how they use the product, and what would make them pay to use it. Remember that having a user pay to use a product is your ultimate goal, and is the ONLY time that you know that you have a viable product.
There are multiple tools and methods for collecting information about your MVP’s, including mouse tracking, heatmaps, and direct observation.
At this point we need to review the difference between what you might think of as testing, and what a product manager and developer think of as testing.
Alpha Testing: early testing that attempts to identify any bugs and problems within the app. This testing is done by the developers near the end of their development phase, but is done before beta testing (as it is not open to the public). You may hear phrases like unit testing, functionality testing and end to end testing – in the end they are all to find and remove bugs, and ensure usability.
Beta Testing: Performed by a number of the app’s ‘real users’. Beta testing relies heavily on user feedback, and is considered as the final test before the app is made completely viable. Google also has resources on Alpha and Beta testing.
If, by reading this article, you have picked up that there is substantial testing during the development process, go ahead and give yourself a pat on the back right now. Testing will take a substantial amount of the overall time to deliver a new application.