Table of Contents
Time to market is a critical factor for any company aiming to launch a new digital product or upgrade the existing one. In many cases companies do not have expertise and proven methodologies to target aggressive product delivery timeboxes. So they search for vendors with such expertise.
Based on our experience working with 100 plus clients on Digital Product launch and delivery we came up with an approach for delivering Minimum Viable Product (MVP) in 100 days. Therefore in this post we’d like to share our experience and knowledge with you, and unveil all secrets of successful product launch. With that being said, let’s get started.
Minimum Viable Product: required team and crucial roles
To begin with, let’s define MVP. Basically it is a basic version of a digital product with enough features to validate product ideas, market demand and collect customer feedback.
Many startups have started with minimum viable product development and transformed into solid huge projects with time. So we definitely recommend it, especially if you have a complex project in mind but are not sure whether you should invest a lot of time and money in it.
MVP launch will let you work out the main pain point you try to target and resolve, test out your business hypothesis, prioritize all the features, define key performance indicators for your actual product and find its early adopters.
Vendor development team
To illustrate great development team composition, we took our own one as an example. Altamira team includes the following roles:
Client Team
Apart from the vendor team, there is also a client team. The fruitful cooperation between two teams helps to save time and achieve successful product launch. The client team usually includes two main roles:
When it comes to development of minimum viable products for startups and businesses, they all go through several main phases. Each phase is well organized and helps us to proceed with the launch strategy while preserving all deadlines and set time frames. Vendor and client teams both participate and make certain input to the project. Let’s take a look at all development phases and what they include right away.
#1 Alignment phase
At this phase the vendor team is working with the client team on onboarding to propose an approach for 100 days MVP delivery framework and receiving a buy-in. This is one of the most important elements that can’t be taken lightly.
While starting the Discovery phase we aim to receive formal and informal buy-in from the client team, confirmation on the understanding of all the roles, inputs and artifacts needed for successful execution of the next stages of digital product creation.
#2 Discovery phase
The goal of this phase is to complete market research, validate business ideas, and test how the product fits customer needs and how we can build it. Vendor team prepares everything for active development including business domain understanding, architectural vision, technological stack proposal, MVP scope discovery, minimum feature set, appropriate POD Teams setup, development process, launch strategy, etc.
In iterative development processes, this phase is usually named Iteration 0. It may take much more time depending on client maturity level and scope readiness.
Here are checklists of activities and artifacts important for this phase with responsible roles, split by different perspectives.
Customer perspective
These activities require collaboration of our team with client stakeholders and should provide the answers to the following questions:
- Do we understand product opportunities?
- Do we understand the user or target market?
- Do we understand the users problems?
- Have we identified possible solutions?
- Have we validated proposed solutions?
Among the artifacts that can be produced at this stage there are Lean Canvas, Customer Persona, etc.
Engineering perspective
There are several activities/artifacts that have to be prepared from an engineering perspective to start active digital product development. Some of them assume POD Team engagement, so staffing has to be performed as a preliminary step. Both vendor and client teams participate in the process, and here is what should be prepared:
Product/business perspective
The list of the activities/artifacts mentioned below have to be prepared from a product/business perspective and some of them assume PO engagement, so it is critical to be aligned between PO and product team as a preliminary step.
#3 Development phase
For active development phase short cycle iterative processes (one-week or two-week Scrum or XP) or more flow-oriented Kanban (for more mature teams) could be used. Short delivery cycle is important for continuous feedback from the business side and according goals/roadmap adjustments.
Development phase has releases, like Beta one, to validate some assumptions and decisions. Problem – solution, architecture, technological stack, etc. can be validated and some corrections implemented when required.
And now we would like to define some key elements of the development phase that you should keep in mind while working on your digital product.
Quality
Well established QA processes must be focused on embedding quality in the product instead of controlling it and fixing continuously. Improper QA processes are one of the largest waste generators in the development cycle.
Each product/project is unique and has its own quality requirements. These elements have to be covered in QA strategy:
Most aspects of quality control have to be implemented as quality gates and Definition of Done at different levels (development task, story, iteration, product release).
Engineering practices
Set of engineering practices depends on team maturing and product/technological context, but general recommendations must be taken into account. They are the following:
- code standards have to be defined by POD and shared in the common Knowledge Base;
- dedicated quality gates in specialized tools like SonarQube have to be configured for defined code standards to control them during further development;
- shift code standards left with common IDE settings and additional plugins to detect and prevent violations on developer’s machine;
- code review practice has to be established with proper leadership model and tooling;
- test automation has to be implemented, measured and controlled according to approved QA strategy;
- all CI/CD pipelines have to be configured including policies, rules and environments;
- containerization approach is preferable for artifacts delivery because CI/CD, configuration management, environments preparation could be done in common way and differences between environments are significantly reduced;
- accelerators could be used to speed up initial technical setup (VCS, code review, CI/CD, SonarQube) and make it more standardized.
Communication
Proper communication channels are a critical factor in any development process. Following key practices help to reduce communication waste and improve development productivity:
Reporting
It is very important to make the development process completely transparent and with key metrics gathering and trends monitoring. Traditional tools like JIRA, CI/CD and SonarQube reporting dashboards have to be configured to see not only current picture from all perspectives but historical trends:
- product roadmap and release burndown with optimistic/pessimistic predictions;
- current iteration or development state on task board;
- quality metrics like defects count, defects distribution by components and severity;
- quality control metrics like test coverage, manual and automated test execution statistics, tests distribution by level;
- maintainability metrics like code standards violations, potential defects, security issues.
Scope and requirements management
The main idea of scope management is to make it very value-driven with focus on MVP product delivery. Supporting set of practices include:
Instead of fixing product scope it is important to reflect initial feedback gathered from all involved parties. Continuous scope reprioritization by value helps leaving only the most important parts to meet deadlines and maximize achieved business value.
The starting point for discussing the product requirements has to be the Product Vision. The document describes critical functionality of the product, value proposition, target audience, business and user needs. It is used to create alignment and shared understanding of the product for everyone involved in the development effort including stakeholders and development team.
All ideas have to be prioritized by business value and could be estimated in complexity points by POD to get some understanding about feature cost.
Requirements preparation pipeline
It is critical to implement only well-defined ready for development requirements to avoid wastes. But it is not always the case because PO is not always disciplined enough, and some uncertainty/unknowns present in most ideas.
Visualization of all stages of requirements preparation helps to reduce wastes and improve requirements quality. Some common early stages of such pipeline:
Each stage has a clear Definition of Ready and WIP (work in progress) limit to avoid multitasking. Having such a pipeline in hands, it is easy to identify bottlenecks in the requirements preparation process and manage risks.
Final thoughts
When using proven approaches based on 10 plus years of experience developing digital products for different business industries, it becomes possible to make client-vendor relations work very efficiently.
In this blog post we demonstrated an approach that significantly reduces risks, wastes and increases the predictability for the client. With it we can achieve a minimum viable product developed within a 100 days fixed timebox. So if you need a reliable team to build your MVP fast without compromising project quality, just drop us a line and we will help you with everything.