Rapid MVP Process
At ClearSummit, we specialize in taking products from concept to completion. The quickest path to launch is to create what's called a Minimum Viable Product (MVP). This page outlines the process we use, and the goals and risks associated with each step of building a Rapid MVP.
The transition between each step can be fluid, but they are 3 distinct processes. Following each one in strict sequence is called waterfall development. At ClearSummit, we typically use agile development practices; however, we do incorporate elements of waterfall development when we build a Rapid MVP. This helps our clients control costs because they are usually operating with fixed funding and need to keep the project's scope narrow.
Discovery & Planning
We align on your product's north star and derisk your concept from the perspectives of engineering and product development. We define and evaluate your objectives, and plan the best path forward to launch a working product that meets focused, key objectives.
Scope creep - The largest risk in building your MVP is scope creep. At the start of Discovery, we have a general concept of your product based on your budget, but if too many features are incorporated into the MVP it can blow your budget. Some of these changes may seem small - but they can quickly add up and increase design and dev time by 20% or more unless it's kept in check. We work with you to keep the key objectives in mind, and save some of the bells and whistles for post- launch improvements.
Being all things to all people - we work with you during this phase to focus on one or two user personas for your MVP. Others can be added to later versions. Developing a product for too many types of users can waste time and resources early in the process.
High Level Wireframes
Weighted Feature Set
During this phase we will iterate and propose both user experience (UX) and user interface (UI) design. This process happens over a series of meetings and feedback loops. We build in time to allow your team time to digest the designs and give structured feedback so we can build the best product.
Design phase risks also include scope creep - At the start, we already have a clear concept of your product from the discovery process, but if features are added during design this can increase the budget and delivery time.
Unexpressed assumptions - It is important that if you have an assumption about how something in your app should work - for example, that the app should also work offline - it is expressed and communicated to the designers. We may flag it as scope creep, but it is better to flag it here than in the engineering phase. To borrow an old adage - the goal here is to measure seven times and cut once.
Screen and/or Page Designs
Feature Backlog in JIRA
You can read a detailed overview of our design process.
This is where the coding happens. We build the project as designed and documented during the previous phases.
Once again, scope creep - As you review beta builds of the product in your hands, it is easy to think about how features can be enhanced. At this point we suggest adding them to the backlog.
Third parties - If engineering is dependent on third parties, such as API providers or subject matter experts, delays caused by these third parties can have ripple effects.
Weekly Progress Scorecards
At the end of the process: Version 1.0 of Your Product.🎉.
Go here to read a detailed overview of our engineering process
Once the MVP is complete, there is additional work to consider: the features backlog, maintenance (required for new operating systems, API updates, security and library updates), and getting feedback and analysis of how users are using the application. We work with you to get a post-launch plan in place.
Let’s build something great.
Together, we can assemble and execute a plan to hit your key objectives with a software product that looks, feels, and is a top-of-the-line technology experience.