Inside MVPRockets: Our Step-by-Step Guide to Creating Your MVP

Purpose of this document

This document outlines the overall product development process MVPRockets/Napses Product team would follow for successful completion of a project – with high quality and adhering to the timelines planned

Owner of this Document

Giridharan N – giri@napses.com

Tools Used

  • Notion for Road map, project management
  • Slack for Inter team communication
    • Whatsapp/Call in case urgent

Overview

Our overall product management revolves around 5 important steps

Understand —> Write —> Draw —> code —> Ship

As we get closer to Ship, the mistakes & changes are expensive. The earlier we get clarity on the product to be built, the better it is. The entire team should work towards getting clarity & building the right product as early as possible. This essentially means that each of these steps are sacrosanct & can not be skipped.

However, these 5 steps happen across different phases in each of the project & the different phases of the project are as explained below

Contract Signing —> inception —> Estimation —> Development —> Roadmap

Contract Signing

Talk to me on giri@napses.com 🙂

Inception

Once the basic contract is signed, we go through a 1 month “Inception” period. The aim of this process is to get complete understanding of the overall product – the user, context, problem & the proposed solution.

Here a team of 3 interacts with the entrepreneurs.

  • Product Lead – Typically, the product lead is one of the senior folks in the company (CPO/CEO or someone of similar experience) who has done multiple MVPs in the past. The role of the product lead is to give oversight to the entire product, ask the right questions & facilitate the right design & development decisions
  • Product Manager – The product manager is the single point owner of the entire product. the responsibilities include solving/answering the questions through research & prototyping, manage the product end-to-end, maintain the documentation, explain to the developers the overall product scope & is responsible for the entire delivery of the product in time & with highest of quality
  • UI/UX Designer – The designer brings the design thinking to the overall product, understands the user, problem, context & is responsible for the overall experience & visual aspects of the product.

Understand

Owner: PM [Secondary Owner: Product Head]

Output: Business Explainer Document

Purpose: To clearly understand the the business & about the product being built. this is a document that the entire product team, including the developers should read before going into a product. Once the document is complete, the ownership transfers to the product manager of the product. For all practical purposes this is a larger version of the popular business model canvas where we try and pen down the users, user context, their problems, unique insights, hypothesis to be validated/invalidated through MVP, possible solutions, competition, business/revenue model, TAM/SAM/SOM etc..

Format: A notion document – Our template can be found here –

Business Explainer Format

Approval required: yes, from the client

Write

Owner: Product manager {Secondary Owner: product head]

Output: Actors & Jobs to be done, User flow, Epics & stories

Purpose: To convert the business problem identified in the previous step into tangible user stories & create a clear Roadmap/backlog

It should contain the following sections

  • Context
  • Problem
  • Solution
  • Acceptance criteria
  • List of screens

Format: A Notion inline board + “By epic” View

The same can be found here –

Roadmap Format

Approval required: yes, from client, Product head

Draw

Owner: Designer

Prerequisite:

Brand guidelines, Design guidelines – to be given by the entrepreneur

Output:

Visual direction
Wireframes/Mocks
Purpose: To convert the user stories written in the previous step into a visual form

it should follow the design guidelines provided by the client

Format: Zeplin board – Screenshots to be embedded in the respective cards

Approval required: yes, from Vinayak + Product Manager, client

Estimation

Once the inception team has created the product docket, we add the tech team to the project & the first step here is to estimate the overall complexity of the product – timelines required to complete this.

We follow the agile process of development diligently & use story points based estimation. The concept of story points is fairly simple. The entire team, along with the inception team sits & looks at each of the stories written in the earlier phase & looks at the designs. Once a fair understanding is reached by everyone, we look at each of the stories & try to estimate the complexity of each of them. The story points is the measure of the complexity & we use a Fibonacci series estimation where a story can be 0, 1, 2, 3, 5, 8 or 13 points(We try to avoid 13 pointers as much as possible)

Once each of the stories are estimated, we have the total number of story points for the entire project.

Based on our prior experience, we know what the velocity of a team would be. With this velocity, we would be able to estimate the total time required for the entire project.

This is when we communicate the timelines for the overall project.

Development

Once we have the team in place & the estimation in place, we split the large deliverable into manageable chunks called milestones & the milestones internally have 1 or 2 sprints in them this is communicated to the entire team along with the entrepreneurs.

Code

Owner: Architect, Lead, team {Secondary Owner: Praveen M V}

Output: Architecture Document + working Product

Purpose: To clearly architect the solution & build the right product 🙂

Approval required: yes, from Praveen (Head of Engineering/Delivery)

Ship

Owner: Devops, Satish(CTO)

The Product set up should have

  • Dev server
  • UAT
  • Prod Server

The movement of features should go from Dev —> UAT —> Prod

Testing in the Dev server should be done by the Dev

Testing in the UAT server should be done by the PM (QA should report into PM)

Once when all the unit test cases pass & PM gives a go ahead for a feature, should it go to the Prod

Roadmap

Once the MVP is launched, the team continues to work with the entrepreneur and help with the roadmap and continues to do so until the entrepreneur is ready to take the product development inhouse.

Project Structure

A project should ideally follow the following structure in Notion

  • Project Name
    • Business Explainer
    • Business Docs
    • Road Map
    • Tech Docs

Submit your response

Your email address will not be published. Required fields are marked *