So why do we then see so many failed attempts and burnouts in product development? Why do people end up burning money in creating something their users don't need? I will try and answer this question in the following post. But before that, let’s understand what an MVP is. Wikipedia says,"The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." This means a product that is built with maximum validation, but only has the minimum features that a customer requires.
Let’s understand how a Minimum Viable Product is shaped up at Srijan.
1. Structuring the thoughts
Let's take up a typical example of a product development exercise: A team of x and y get an amazing idea from which they can start a business. Usually such a team has had considerable work experience and they understand the business well. They understand its implications and are capable of creating and running the business. Excited with their idea, they are likely to jump right in and create an RFP with details of what they want. Usually, that RFP will have a plethora of features that cover almost every aspect of web development. Not enough thought goes into exploring why they are creating this. Even when brainstorming happens on the relevance of the features, they really don't know if their customers think the same way on the requirements. This is when they hire a development agency or a technical team to build their product. So the requirements are detailed out and each feature is built, without much thought on “Why are we building this feature?”
What's the solution then? Shouldn't it be easy for people to know what minimum features they want in their product? In reality, it's not that easy. Structuring the thoughts/features of a product into well-defined user stories/journeys requires the intervention of an experienced business analyst. Not many entrepreneurs or Product Owners (people from the product idea company who takes the lead in the product development management) have the knowledge of structuring and estimating the MVP.
2. How Srijan helps in structuring the thoughts of the Product Owner
At Srijan we use Agile estimation and the backlog creation process to find the MVP for our prospects/customers. This is the most important exercise on the products we develop. After the initial engagement to create a backlog for the first 3-4 sprints (production cycle), we carry forward the project with a dedicated business analyst who helps in developing the architecture of your product.
When we start any engagement with a prospective customer team, we try to understand why we are building the product. We translate this into loose wireframes to capture the user workflow. During this process, there are several brainstorming sessions that take place with the customer team, documenting the thought process of a user and structuring it into a user stories backlog or wireframes. User stories capture the path of the user. See the example of a user story below:
If you look closely, it clearly defines a user workflow for a specific task. Now such a story allows a developer to understand how much time he/she requires to complete the task. This understanding is needed to craft the MVP.
3. Crafting MVP from structured user stories
While creating the backlog, we try to capture all the stories that the product owner has thought through, and estimate the effort required to complete a story. The business analyst and the product owner start selecting the stories that require the minimum effort yet provide the basic functionalities to the user. This process of creating the backlog, estimating it under the Fibonacci series and then crafting the MVP out of this brings absolute clarity to the owner. He/she understands what he/she needs to create in the first phase with minimum effort. Also, note that this is a complete functional product with which he can go to market to test the waters and find out if the product makes sense to the users or not. The customer then comes back to Srijan with the market feedback, and the brainstorming on the required features starts all over again, leading to the new backlog of user stories. The cycle continues, till we have a product which is in sync with what the real users want.
Once we have identified the set of user stories which define our Minimum Viable Product, we staff a dedicated team to carry the development to completion. The team works on two-week sprints and runs a demo of the decided upon stories to the customer at the end of each sprint. The customer can review it, test it with prospective users and share the feedback.
4. Launching a Minimum Viable Product
Usually, in our first month of development, we are able to launch the minimum viable product for an initial set of users, who then give valuable feedback to help us develop the next version of the product. While launching, we also integrate a few valuable tools like VisualWebsiteOptimizer (for doing A/B testing), Crazyegg (for creating heatmaps, which allow admins/devs to understand user behavior with regard to design and functionality), and Google Analytics (for tracking and measuring traffic). We also use some more advanced tools like Clicktale for specific products. Tools integration can vary with the needs of each individual product.
After the launch, our primary goal is to understand user behavior and collect feedback to understand the next set of feature requirements. This iterative method is repeated again and again by creating the next set of Requirements → Wireframes → User stories → Development. Through this method, we remove a lot of development waste, and define our product features in a way that resonates with the needs of users.
We have successfully worked with many clients on building their MVPs, and as we grow, we are learning to make ourselves better. We at Srijan believe that being agile is just not about following a particular development process; the company needs to change its DNA to become agile in every respect. We have invested highly in training across offices to make our people better informed on agile processses, and are continuously refining our working styles to reflect the same.
We would love to hear from our readers on what they think of MVP, and their experiences of creating an MVP.
