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:
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.
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.
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.
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)
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.
You will get clear product vision with well-defined goals of the MVP (PM + PO)
The team is responsible for initial product backlog, prioritized by business value (PO)
The team prepares a risks matrix with mitigation strategies (PM + PO + POD)
Problem statements and goals definition for the MVP that become a part of the common knowledge base (PM + PO + SA)
#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.
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).
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.
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).
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:
“fail fast” approach to evaluate ideas quickly and avoid wasting time on failed ideas;
continuous feedback cycle to make sure that the whole team is going in correct direction;
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.
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.