Turning an Idea into a Minimal Viable Product (MVP)
You have a business-worthy idea. Hopefully, this idea is related to an area where you are an expert and you validated the viability of your future product with potential customers. Now, it is time to build the product.
Bringing a new product to the market is always a risk. Startups typically have one priority when beginning their business journey: to grow. Growth usually requires money. By committing to a “lean” approach, new businesses can better use funds while scaling up.
To build the product quickly and to stay lean until the product has been validated in its’ niche, lean methodology dictates that we start by building an MVP. MVP development follows a “build-measure-learn” process; with the goal is to provide immediate value quickly while minimizing development costs.
The two most common reasons for startups failing at an early stage are poor research and overextending resources while developing the first product. “The Lean Startup” author Eric Ries defines MVP as “a version of a new product which allows a team to collect the maximum amount of validated learnings about customers with the least effort.” MVPs allow organizations to validate their ideas quickly, and possibly pivot until the product find its niche and a viable business model has been discovered.
In practice, Minimum Viable Product includes a feature or features required to solve a core problem for a set of users.
Our company’s core value proposition is turning an idea into a Minimal Viable Product (MVP) in four to five months. In order to build quality software products reliably and repeatedly, we follow a system or a protocol of sorts. This system, in addition to the highly experienced and acclaimed team of engineers and designers, is what allows Diophant to consistently deliver products on-time and on-budget.
If you are working on your first MVP, or perhaps failed in the past to build a product on-time, and are looking to up your product game, please review our nimble system for references.
MVP Development Stages
Design Sprint. One week. Deliverable: static UX prototype and product pitch
Prototype Design. Four weeks. Deliverable: dynamic interface prototype.
Development. 12 – 14 weeks. Deliverables: full product source code, developer documentation, infrastructure configuration, CD/CI pipelines, unit and integration tests.
Handoff. One week.
The one-week Design Sprint stage is perhaps the most important part of the MVP development process. We base our design sprints, on the Design Thinking methodology – an agile process allowing designers to identify problems and find solutions. The idea behind Design Thinking is to first understand customers’ underlying problems, rather than presenting them with a solution built from the developers’ view-based assumptions. Design thinking emphasizes user desirability and identifies potential blind spots within the stakeholder’s understanding, or assumptions the stakeholder is making.
In a nutshell, the goal of the design sprint is to have clear answers to the below questions:
What is the problem your product is going to solve?
How you expect to solve this problem?
Why is this problem worth solving?
The sprint begins with setting product goals and identifying user personas. Then user-experience designers produce the storyboards and sketch individual interface components. The next step is producing a static interface prototype using wireframing or another appropriate tool. The final step in this sprint is to gather feedback, known as “user testing” and to incorporate it in the interface prototype.
The next step is to design a product UX prototype – high-fidelity dynamic representation of the product user-interface. The prototype should represent the structure of information, visualize the content and demonstrate the basic product functionality.
An interactive prototype is an invaluable tool to get feedback from product stakeholders and as well as to visualize the product for the engineering team.
While the design team is finishing the product prototype, we start working on the software architecture. The goal of this step is to identify the key logical software components of the product, the technologies best suitable to build it, and the hosting platforms and as well as third-party services necessary for the product to operate and grow.
Deploy project templates and infrastructure configuration templates, configure continuous delivery pipelines, including automatic solution auditing, automated build testing and performance monitoring.
DevOps is the merger of software development and operations. Properly done, DevOps facilitates achieving synergy among development, security, quality assurance and IT operations disciplines.
Often product development teams make the mistake of adding DevOps as an afterthought. We believe that the best approach is to build both DevOps and DevSecOps into the infrastructure and code pipelines, from the beginning. Containers and microservices are more widespread than ever, making it increasingly difficult for developers to have a production-like environment. DevOps allows presenting developers with consistent development environments, thus eliminating possible friction during the development process, making it more streamlined. We recommend embedding software security and license auditing right into the build pipelines, to generate a security report for every automated build.
Diophant DevOps engineers start by customizing existing our ready infrastructure-as-code configuration templates from our proprietary DevOps library, saving customers weeks of labor and guesswork.
A key component of agile software development is putting people first. We utilize user-stories as the core product development management unit, since user-stories put actual end-users at the center of the conversation.
Before user-stories could be easily implemented in software, we map user-stories to tickets. While user-stories create context for developers, it is possible that implementing a single story would require multiple developers working together on multiple software components. We utilize “user-stories” as a backlog of work, which needs to be “groomed” – transformed into tickets, where each ticket is a relatively small piece of work covered by a single engineer.
Components are considered ready after the code is peer-reviewed and covered with automated tests.
Developing unit and integration tests simultaneously with developing software components, greatly improves software quality and maintainability.
Keeping Stakeholders Involved
Regular work-in-progress product demonstrations, as well as access to preview software for the product stakeholders, allows providing designers and engineers with feedback early in the process, further amplifying the “build-measure-learn” principle of the lean process.