Introduction

Over the past 8 years, Indexnine has assisted more than 70 customers in creating and testing their software ideas and, as a result, has developed a distinct design and development workflow. Our approach effectively identifies the features that will have the greatest impact on the customer, enabling us to deliver software solutions that meet their needs.

In this document, we will discuss how we go about building MVPs (Minimum Viable Product) and how you can partner with us to build your MVP.

Software Product Building Is A Marathon

Developing a software product is a complex and challenging journey, often requiring multiple pivots before achieving the right product-market fit. Based on our experience, it typically takes between six months and a year after the MVP release to establish this fit. At Indexnine, we are committed to supporting our clients throughout this journey and ensuring their product meets the needs of their target audience.

Start With A Discovery Workshop

A discovery workshop is a meeting where we build a comprehensive understanding of the product we are trying to build. Typically, this involves various stakeholders (customers, designers, and architects) getting together and brainstorming on the features that are needed for the product.

The output of a discovery workshop is a mind map which contains all the features of the product. It’s important to note that identifying the features should be done comprehensively, making note of features that might be built much later (even after the MVP is complete).

In addition to identifying features and task flows, the discovery workshop also helps to identify personas and a high-level architecture of the product.

A mind map built as a result of a discovery workshop

Identify Personas And Design To Them

Most products today have a combination of backend and frontend functionality. Even if the product is a backend-heavy product, such as an API, it will still need an admin user interface for configuration and settings.

We like to start with UI wireframes because they provide clarity to the development team and can be used to create the right API design for the product. Of course, before you jump into wireframes, start by identifying the personas that will use the product.

It’s easy to get carried away with design, so the design needs to be time-boxed. Typically, try to time-box the design to 4 weeks if you are targeting a 120-day MVP. Please note that most medium-sized projects need a design cycle of 6–12 weeks, depending on the number of screens.

It is also important to avoid building obscure personas covering all cases during MVP to avoid distraction from the main goal.

By definition, an MVP should be simple and easy to use and understand for the target audience. Pay attention to the user experience by putting yourself in the end-user’s shoes while reviewing the product design.

Sample wireframing identifying the user journey for the main personas

Identify POCs Early

Most successful new products comprise 80% of well-understood features and 20% of unproven ones. It is crucial to identify and run Proof of Concept (POC) sprints for the unproven features since they can make or break the product. POCs can be identified early in the process, sometimes during the mind-mapping phase. While the design team may suggest innovative ideas that require a POC, core functionality POCs can be identified alongside wireframe creation, making it a parallel activity to design.

Start Development ASAP

Since many products consist of a significant percentage of boilerplate code, it helps to avoid the development time and costs associated with this boilerplate. At Indexnine, we have invested in building cloud-agnostic starter code that can be deployed quickly and easily and checks all the boxes when it comes to quality, reliability, and traceability. This helps you start developing core features early. Typically, aim to start development 2-3 weeks into the project to get a jump on building core functionality.

Define API Specification

Typically, back-end development is done first, and front-end development follows. However, most of the time, back-end development can hit roadblocks that may not be easy to resolve and can hold up front-end development. To run both front-end and back-end development in parallel, both teams should discuss an interface specification, which the front-end development team can then use to run ahead with the UI creation while consuming an agreed-upon data format. Typically, front-end development is the longer pole, so it makes sense to accelerate front-end development as much as possible.

Sample API spec that front-end developers can use to implement the UI even if the backend is not fully developed

Track project

To estimate an initial release date, create a high-level development plan and track the project closely. Use sprint goals to forecast the release date after every development sprint. In our experience, assigning QA to manage releases improves the quality of the product and ensures that designed features are fully functional. Staggering Dev and QA sprints also allows QA to perform due diligence on the sprint releases. Additionally, conducting end-of-sprint demos to showcase completed work helps keep everyone on the same page regarding challenges and issues encountered during development.

A sample tracking board on Trello, JIRA and Azure Devops are other options to track the progress of the project.

Be Involved

As a customer, it is important that you drive the product requirements or designate someone to do so. As the product reaches MVP, new features and other requirements will emerge, so it is important for the product owner to define priorities and a roadmap for the product.

Test With End-Users

Once the product MVP is released, work with design partners to help validate the product. It is important that the design partner is a potential customer (B2B) or a user of the product (B2C) who would be willing to provide honest feedback and improve the product offering. Resist the temptation to enlist family or friends as end-users as much as possible.

Note: Design partners can also be brought on earlier, once the design is ready. Using a prototype, one can present the application as it would appear after development much earlier to the partner. This can result in early feedback that is valuable and can be used to adjust the design.

Measure Success

Use analytics to identify user behavior and feature usage. Prioritize features that are frequently used to improve the user experience in those areas. For B2C mobile products, track download and retention rates to find out how engaged your users are with the product and what features they love.

Solicit feedback and track the app stores (for mobile products) for user reviews or complaints. Engage with the end-users and provide a feedback mechanism to solve their issues as soon as possible.

Remember, the goal of building an MVP is to test your assumptions, validate your idea, and gather feedback. Keep your MVP simple, focus on the core functionality, and iterate based on user feedback.

Ready to start building? Get in touch with us to discuss your project. We provide a free consultation with no obligation. We can’t wait to see you get started on your product-building journey!

About Indexnine

Indexnine is a cloud product engineering company founded in 2015 and has had a great run over the past 8 years. We are experts in UX Design and UI Development, QA Automation, and end-to-end cloud product engineering. We have grown primarily on customer referrals. Our customers love us!

Our offerings include:

1. QA automation strategy and teams
2. Augmentation and UI development teams
3. End-to-end engineering of cloud products
4. Migration to the cloud

We have built products in the following verticals:

1. Cybersecurity
2. IOT
3. Fintech
4. Healthcare

What will it cost me?

To discuss your problem statement, get in touch with us! Drop us a note here, or directly schedule a meeting with our co-founder. Consult with us for a no-obligation exploration of your project idea!