Step
02:Software Requirements Specification (SRS) Preparation
Step
04:Plan the estimated timelines
Step
04:Plan the estimated timelines
How Anuyat Plans for an MVP?
(Minimum Viable Product)
The first rule of planning a Minimum Viable Product or MVP – have a big vision but a small MVP.
And this is where planning will lead the way.
The essence of a Minimum Viable Product lies in its:
- Simplicity
- Quick launch ability
- Being market-product fit
For this reason, the plan for an MVP must focus on steps that get you closer to “need to have” MVP features rather than “Nice to have” ones.
At Anuyat, we address planning an MVP with five extensive steps –
Let us paint the picture for you with an example of building an MVP for an Online Rental
App.
Step
01:Defining the scope
As a business owner, you must have already researched the potential of your idea. The product you wish to develop must solve a particular problem that you may think exists among your target group.
Online Rental App
-
An online platform for multiple sellers and buyers to rent the new or used stuff.
We add more to your research with our scoping process.
The scope of an MVP tries to answer a few elementary questions before diving into building an MVP.
Q1. What is the main objective of the business?
This question must have limited answers, probably one or two. This clarity is of utmost importance as it will help achieve your MVP concept's “Minimum” attribution.
Your Online Rental App can provide n-numbers of advanced features, but we need to limit the app to a single business objective, i.e. Sellers should be able to list the products to sell & buyers should be able to buy those products.
Core business objective: Multiple sellers & buyers can do rental transactions.
That is a good start and a base to build your MVP.
- Remember: All further efforts will be made to achieve this single business objective only.
Any deviation from this may distort the viability attribution of our MVP concept.
Q2. Who are your target users?
Again, limit your customer personas to a minimum; we narrow down the audience for your product to build a focused MVP that caters to the requirement of that group only.
Instead of asking what features they would need in our proposed product, we ask them questions that better understand their pain points.
From here onwards, we will understand this group’s:
- Problems, in more detail, for which we are offering the solution.
- How often do they face that problem?
- If a solution is provided, are they willing to pay for it?
- Can they refer to other people who may have the same problem?
User Personas
- People just shifted to the metro & do not want to buy household stuff.
User Problems
- They are always on the move due to their job; hence it is challenging to buy and set up a home every time they make a city shift.
The brainstorming leads to a high-level process flow for the identified users' activities on the platform.
Something like this:
- User visits the App
- User search for the household item
- User finds the seller
- User added product for renting, in the cart
- User proceeds with checkout
- User added shipping & billing information
- User completes renting process
Things seem to come out together from hereon, where we can slide into shaping the features that would be part of the MVP.
Q3. What should be the features on the first day of MVP launch?
The list of features can continue to grow and may distract from being “Minimum,” hence we follow the prioritization- matrix to understand what features should make a cut for the first launch and which ones should wait for future iterations.
For our Online Renting App, we can define the “User visits the App” feature into sub-sections:
User visits the App
User search for products in the search box
User browse through the categories & sub-categories
User uses filter options
User select seller's category
User uses review function
We carry on with this schema for the rest of the process flows, and for each of the sub-features, assign a value, based on:
- How important does the user find it?
- Do we expect the feature to be popular?
- How much would it impact if we launched the MVP without this feature?
At the end of the scoping an MVP process, we are ready with the set of features that are “must-haves” for the launch of the MVP.
Step
02:Software Requirements Specification (SRS) Preparation
- Software Requirements Specification or SRS is our way to lock the MVP features officially on the formal document to make sure everyone involved remains on the same page.
- The document has a mix of theoretical discussion and an outline of the discussed features. Generally, an SRS consists of the following elements:
- Description of the functional requirements
- System requirements
- Technical requirements
- Constraints
- Assumptions
- Acceptance criteria
The SRS is shared with our clients for discussion, approvals, and moving to the next exciting level.
This document will act as a blueprint for Anuyat’s MVP developers and clients.
Preparing an exceptional SRS document
Effort and time go into designing a perfect SRS document. An exceptional SRS document must have all the touchpoints needed for the reference of the MVP developers and the clients.
Here is what you can expect from a nicely done SRS:
- It must maintain the correctness attribute by including the exact identified requirements.
- It must exhibit completeness by covering all the functional and non-functional requirements of the client & system.
- Take caution while maintaining the consistency of concepts, jargon, & requirements throughout the document.
- The unambiguity of an SRS refers to the fact that all the stated requirements must lead to only a single interpretation. Using modelling techniques like ER Diagram is helpful to keep SRS unambiguous.
- Designing an SRS must be practiced by keeping a “modifiable quotient” under consideration. Remember, requirements are subjected to modification. Hence, making the SRS flexible to accommodate the changes is highly important.
- If a requirement is not verifiable, it is better not to be a part of the SRS. By verifiable, we mean a requirement must be quantified for its functionality, importance, and useability.
- The traceability feature is relevant for all the owners and users of the SRS document; designers must be able to locate the requirements for wireframing, developers for coding, and quality analysts to understand "for what they need to test the system".
- SRS does not specify the implementation details. This constraint is essential to induce design independence so the designers can have freedom with different design options.
- Test cases and plans become easy to generate if the SRS defines the requirements and system expectations in a well-structured manner. This practice portrays the testability attribute of the SRS document.
- SRS is undoubtedly a reference document for system designers and developers. Still, it should also address the questions for the end-user, in the language, as simple as one’s mother tongue.
Step
03:High-level User Stories
SRS is a compact document that provides a high-level understanding of the system or application to be built. Creating user stories is a more technical part of planning an MVP.
Anuyat’s SRS document scopes out the user-level details to lay out the blueprint for interactive elements or the actors of the MVP system.
Let us see how we plan the high-level user stories:
Let us see how we plan the high-level user stories:
a) Map out the user journey(s)
- Identify who is going to interact with the system. Technically, we call them actors of the MVP.
- Identify the story ending, i.e., the end goal of each identified actor and their expectations from the system.
- Identify all user-specific actions that must be taken to achieve the identified end goal.
b) “Pain and gain” map for each action
- Mention a complete list of user’s actions when using the product/system.
- Then, write down the pain points for each identified action.
- And finally, make a list of the gains for each action
This defining of user journey helps generate the application's flow, along with focusing on the core value proposition for the target audience.
Step
04:Plan the estimated timelines
Anuyat’s MVP scope estimation calculator helps our customers and other users identify the cost and time needed for transforming their idea into an MVP. It is a self-help platform.
For a customizable MVP scope, you would need an expert consultation to understand the approximate cost for building the MVP and the duration.
As a promise, Anuyat works on “MVP in 90 days” principle - from an idea to a market-product fit, in just 90 days.
The estimated timelines come with a few assumptions and constraints, which are also defined clearly in the SRS document.
Step
05:Kickoff the project
SRS is a compact document that provides a high-level understanding of the system or application to be built. Creating user stories is a more technical part of planning an MVP.
After rigorous planning, discussions, and approvals, the MVP is ready to kick off.
But wait, before we share this document with our design and wireframing experts, there is one more thing to plan – project management.
Anuyat uses modern-day, highly advanced projects and agile task management tools such as Confluence, Asana, Trello, ClickUp, GitScrum, Jira, etc. For better tracking of MVP’s design and development process.
These tools help us maintain the team workspace and effectively communicate the progress of the project with stakeholders and clients.
Anuyat uses modern-day, highly advanced projects and agile task management tools such as Confluence, Asana, Trello, ClickUp, GitScrum, Jira, etc. For better tracking of MVP’s design and development process.
These tools help us maintain the team workspace and effectively communicate the progress of the project with stakeholders and clients.
Meet our MVP planning
team
Jivan Ghadage
CEO & Director
Tushar Dattu
Chief Information Officer
Salil Natoo
Chief Technology Officer
Help
Case Studies
Useful Links
Contact Us
Anuyat © 2024. Powered by www.anuyat.com