Our last article covered the various ways of analysing the usage and behavioral data collected from early customer use of your minimum viable product. In case you missed it, you can read all about in Analysing Your MVP Results. This time, we're going to delve into the typical process of evolving your MVP, one step at a time...
At this point you've shipped the first version of your product and you are beginning to gain valuable insight into the products strong points amongst your customer base. You are now at a stage where you can employ a cyclical approach to your continued product development – plan, develop, analyse and repeat. This iterative, cycle-based approach is the modern way to develop software and is built on top of the AGILE software development methodology.
This approach involves using the analytical results from the previous development cycle to plan for the next. A cycle, or "sprint", typically lasts one, two or four weeks and involves the development, testing and deployment of one of more features. These features are then released at the end of the sprint. Analysis after the release can then begin and be used in the planning for the next sprint.
Using the results of the analysis gained from your first release, you will now need to review the prioritized list which you created when first defining your MVP. You can then identify the feature or features that will make up your next sprint.
You will want to keep the sprint clearly defined, and refrain from any adjustments to the plan once the sprint has commenced – instead, any changes should be added to the following sprint. It's common to define the contents of a sprint as a series of "stories", similar to what was discussed in the use of test cases in the Development chapter.
With the sprint clearly and concisely defined, work can commence. This will typically start with the design and development and will then move quickly into the testing phase before being shipped out for mainstream use.
Design is usually the first port of call. From the new feature requirements, the designer will take the concept, and create any necessary user interfaces, graphics, colour palates or design guides. These static design assets will be incorporated by the developer who will put the functionality and interactivity behind them in place. Development can often get started without having all the graphical assets completed.
Although it's best to provide the developer with these assets as soon as possible, the bulk of the work that the developer will be focused on will be functional, and sometimes the assets can be incorporated after work has started.
During the sprint cycle, you will see the user stories transformed from specifications into fully functional features within the product. As the design and development work is completed, the updates will be deployed to a "staging" environment. This is where the work can be reviewed to ensure that it meets the specification set in the sprint plan.
Any bug fixes or necessary tweaks should be passed back to the designer or developer and the amendments will be re-deployed. This process should be repeated until the functionality detailed in the user stories is catered for in full. At that time, the updates can be released to the production environment, where they will be visible and accessible for mainstream use.
Feedback & Analysis
Once the new version has been shipped out to the customers, the data and feedback collection mechanisms established in the Analysis chapter will again become invaluable. User behavior data will continue to stream in and with any luck your early adopters will ensure you're aware of anything that they're happy or unhappy with. This information will be essential as you and your team prepare to do it all again. This process is called The Feedback Loop.
In most cases, there would have been a lot of issues to overcome to get to this point, but if you've made it to a point where your customer base is swelling beyond what your technical environment can handle, then it's time to scale.
Scaling is the process of upgrading or optimizing your application or product, as well as the infrastructure/hosting it lives on, so that it can accommodate more data, traffic and usage than it could previously. This is a common problem when building out an MVP. Scalability is often overlooked when teams are trying to quickly get a solution up and running, it can however cause a lot of issues later on. This is when it really pays off to have hired a skilled and experienced technical architect in the Architectural Design step of developing your MVP.
Incorporating scalable architecture into your product design will vary significantly between solutions. There are however some best practices that can be followed to ensure your MVP has the best chances of scaling easily when necessary.
- Cloud-base hosting providers such as AWS, Microsoft Azure and Google Cloud Services provide the best options for hosting an application or API on scalable infrastructure. These options make it easy to ramp up or down the processing power that your application needs to function.
- Avoid blogging frameworks like WordPress. Although it's easy to use WordPress in the early stages of your MVP, limitations will quickly become apparent when you need to scale.
- Be cautious of any third-party services that charge by bandwidth or usage amounts. A flat rate is ideal for any third-party service when it comes to scalability.
- Ensure there are no manual onboarding processes. This is essential for you to be able to scale rapidly.
This list covers a few key methods for improving scalability, but it really only scratches the surface. There are tons of things that, from a technical perspective, can be done to ensure the product is as scalable as possible. Ensuring your technical architect is capable will mean it's unlikely that you will encounter scalability bottlenecks as your product gains traction.
Next time, we will take a look at ways of how you can obtain outsider investment to keep your project running or to take things to next level. Stay tuned until next time.