How to Launch a Project in 100-days: MVP Delivery Guide 

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.

Here are some assumptions related to MVP development:  
And here is a short list of all 100 days MVP delivery goals: 
  • The MVP approach is applicable to greenfield Digital Product development. But with some twist can be used for product upgrades as well.
  • Product Owner is either on the Vendor side or Client side, but our experience shows in most cases it’s on the Vendor side.
  • Onboarding and Communication practices/frameworks are important to align with the Client team to reduce miscommunications and wastes.
  • bring maximal value from business perspective in fixed timebox;
  • make product development process very predictable and transparent;
  • increase development speed at the same time leaving enough agility for business;
  • embed quality in to reduce maintenance and regression.

As you can see, MVP product launch can be a great starting point, but only if you’ve done everything right. That is why it is so important to hire a professional team of developers who will not only write high-quality code, but also communicate with you and keep you updated about project progress up to the MVP launch. 

Vendor development team

To illustrate great development team composition, we took our own one as an example. Altamira team includes the following roles: 

Project Manager (PM)
is responsible for overall product delivery, including such key things as development process, engineering practices, quality assurance, staffing, reporting.
Product owner (PO)
is responsible for product vision, business idea(s) gathering, requirements management, product backlog prioritization, acceptance of done work, continuous feedback to the engineering team.
Architect/Tech lead (SA/TL)
is responsible for architectural solution, technological stack proposal, technical team guidance and coaching.
POD team
one or several cross-functional teams, having all required roles inside to implement product features independently FE/BE developers, QA/QC engineers, DevOps engineers, etc.

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:

Key stakeholder (SH)
a decision maker on the client side responsible for success of MVP delivery and vendor engagement.

Product owner (PO)
optional and agreed with the client during the alignment phase.

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.  

lamp

Get a free consultation

Already have an MVP project in mind? We can help you shape all your ideas and proceed with the development.

#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:

  • Initial tech stack proposal to make sure everybody can work with this stack, tools and architectural approaches (PM + SA + POD) 
  • Dependencies and external endpoints integration map. It has to be shared with all involved counter-parties to fulfill the endpoints availability (PM + SA) 
  • Architectural vision of the product that is confirmed with the client and software development team (PM + SA/TL) 
  • Proof of concept to validate selected technology stack (PM + SA + POD) 
  •  Quality assurance strategy to ensure quality will be manageable and not affect development speed (PM + POD)
  •  Environments and CI/CD topology to make clear what environment is used for what and how artifacts are propagated (PM + POD)
  •  Engineering practices set up based on team experience, technological and product context (PM + POD) 
  • List of risks including their effective mitigation strategies (PM + POD)

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. 

01

Project Vision

You will get clear product vision with well-defined goals of the MVP (PM + PO) 

02

Backlog preparation

The team is responsible for initial product backlog, prioritized by business value (PO)

03

Risk mitigation

The team prepares a risks matrix with mitigation strategies (PM + PO + POD)

04

Knowledge base

Problem statements and goals definition for the MVP that become a part of the common knowledge base (PM + PO + SA) 

Must-read
It is hard to underestimate the importance of the Discovery stage and its deliverables. Check out this blog post covering Discovery stage in detail and highlighting what benefits you can get if you start with it.

#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:

  • quality definition and criteria;
  • metrics and reporting;
  • test management;
  • defects management;
  • logical tests distribution;
  • test automation approach;
  • test data management;
  • non-functional requirements and quality attributes;
  • test environments;
  • risks management;
  • tools list;
  • quality assurance practices in development process.

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: 

  • POD is in the same time zone, so all team communication could be done efficiently; 
  • a communication-specialized multi-channel platform has to be used for an official team, it could be something like Slack or MS Teams; 
  • daily stand-ups are a must since they help to synchronize on goals achievements, risks management and other important topics to detect and prevent issues ASAP; 
  • PO should be present at least on the key meetings like planning, PBR (product backlog refinement) or grooming, demo; 
  • all questions from development team should be answered by PO within defined SLA, ideally in common channel within communication platform (not in private mail threads); 
  • all important product or development information has to be shared in a common Knowledge Base (usually wiki-based like Confluence).

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:  

01

“fail fast” approach to evaluate ideas quickly and avoid wasting time on failed ideas;

02

continuous feedback cycle to make sure that the whole team is going in correct direction;

03

ideas discovery with spikes and prototypes to clarify the unknowns and reduce uncertainty.

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: 

  • ideas gathering (epics/stories);
  • ideas elaboration (epic -> stories);
  • MVP/spike extraction (stories, spikes -> stories);
  • design approval (stories);
  • ready for grooming (stories);
  • groomed (stories);
  • ready for development (stories)
  • in development (stories);
  • done (stories);
  • accepted (stories).

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.  

Related topic
MVP is a go-to option for most startups. Therefore our experts decided to dedicate a separate blog post to development of MVP for startups and shared how to avoid common mistakes, where to start, and what kind of team to choose. Don’t miss a chance to read it.

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.  

👍 Rating — 5 (3 votes)

Top