How to Build Processes in a Team That Needs to Create an MVP under Deadline Pressure

In the fast-paced realm of product development, the role of a Minimum Viable Product (MVP) is paramount. An MVP is not just a preliminary version; it's a strategic tool focused on capturing real user feedback early on, saving time and resources by prioritising essential features.

Embracing an iterative approach, working on an MVP ensures user-centric evolution. In this article, we dissect key strategies integral to successful MVP creation. From acquainting the team with MVP goals to refining communication channels, and visualising work, we delve into each crucial step.

Decision-making, task definition, prioritisation, and continuous improvement are the pillars that support an effective MVP development approach.

Any process optimisations are useless if the team does not have a shared understanding of what they are doing and why. This point is often overlooked because, under tight deadlines, it seems that "Everyone is on the same page," "Everyone understands everything anyway," and "Why do we need another call," resulting in miscommunications, kludges, and other specific aspects of software development.

Each team member should understand what an MVP includes. To ensure this, it is important to draw attention to the following:

• Highlight the goals of an MVP and the metrics you want to achieve.
• Describe the functionality that will be available to users upon release.
• Record this information in a document and keep it up to date.

Then, hold a brief meeting where you initiate the team into the goals and tasks. Make sure everyone is on the same page. This is probably one of the most responsible moments when working on an MVP.

There are numerous methodologies, frameworks, and approaches to development. In conditions of high uncertainty and tight deadlines, we tend to use Agile methodology and particularly its most popular tools:

• Scrum framework
• Kanban method

If you have time and resources to implement frameworks - good for you, it's worth getting involved. If you are short of time, there are several options:

• Take a risk and implement one of the frameworks simultaneously with the MVP development in tight deadlines. You get all the benefits of the framework in the form of ready-made processes, transparent and predictable work as one of the obvious advantages. The downside is that the team represents a living organism and often resists such abrupt changes, which, in conditions of tight deadlines and increased stress, increases the chance of demotivating the team and wasting time on rituals, the values of which you do not understand and do not share.

• Tune to the situation and arrange the process based on the tools of different frameworks that will be convenient for your team. If the team has never used story points in their evaluation and does not understand the value of retrospectives, then, considering the tight deadlines and limited resources, the implementation experiment may be extremely risky. The main thing is that the team's work should be predictable.

A large and unclear MVP development process (like any other software) can be broken down into stages. Each stage should have a clear goal and end result, upon achieving which, we can move to the next one. The detailed elaboration and the number of stages can vary from companies to even individual projects within companies, but the most basic stages of software development are:

Product Requirement Analysis
At this stage, it is important to get a fundamental answer to the question: what are we doing and why.

Planning
At this stage, it is important to get answers to the questions:

• How are we going to achieve the result?
• Which teams (who) are going to work on the tasks?
• How much time will they need?
• What are the risks?

Development
The end result of the stage is a written code, ready for testing.

Testing
The end result is a well-tested code, ready for deployment.

Deployment
Deploying the ready-to-use functionality to the user and/or product customer.

By breaking a large project into small stages, it becomes easier to manage the progress of the project and control intermediate results. The same principle should be applied to tasks within the stages. Task decomposition is a key step to ensure the ease of management and result predictability. Break down large tasks into smaller ones, the progress and visible result of which you can track on a daily basis.

Below is an example of stages and tasks within them that we often use as a basis when working on tasks in Cloud Retail:

Gathering Business Requirements (aka Product Requirement Analysis)

• Schedule a kick-off meeting with a stakeholder.
• Prepare a document with described business requirements, goals, and tasks that need to be achieved.
• Agree on the resulting document with the stakeholder.

Planning and Estimation

• Define teams (resources) required to achieve the goals.
• Decompose business requirements.
• Communicate business requirements and goals to team members: get a plan for technical implementation and an estimate of timeframes for each task.
• Draw up a work plan.
• Schedule regular meetings to review work.

Development and Testing

• Update the dynamics of work on the project on a daily basis.
• Promptly solve emerging difficulties.

Deployment

• Agree on the date and time of the release with the stakeholder.
• Designate people for operational support in case of force majeure in production.
• Take the project to the analytics and stabilisation stage.

These are just examples of actions that we use, and the number of stages and subtasks in them can vary depending on many reasons, such as:

• Project complexity
• Time for implementation
• The number of people in the team

Each project is individual, so we always adhere to two main principles, our work and the team's work should be transparent and predictable, and this can be achieved in different ways.

One of the main pitfalls of tight deadlines is the desire to save time on things that seem optional. And the victim is often prioritising. There is a huge number of methodologies on prioritising tasks. All of them require different amounts of information about the project, the task, and the final result, and often prioritising tasks according to such methodologies takes much time, which is usually scarce.

Under tight deadlines, we often use the Eisenhower Matrix. It is a simple and effective tool to quickly determine priorities, taking into account the importance and urgency of tasks

Important and urgent tasks: These are the tasks that require immediate attention and have a high priority. These can be critical issues requiring immediate resolution.

Important and not urgent tasks: This quadrant includes tasks that have long-term strategic value. Although they do not require immediate intervention, their importance makes them a priority to be completed within a limited time.

Urgent and not important tasks: Here are the tasks that require quick execution, but their impact on the overall success of the project is limited. These can include information requests or minor adjustments.

Not urgent and not important tasks: The tasks in this quadrant have a low priority, and their execution can be postponed or even excluded, if necessary, to meet tight deadlines.

Applying the Eisenhower Matrix under deadline pressure allows the team to clearly define which tasks to focus on for maximum impact on project results.

In the development of any product, the key role in ensuring efficiency and transparency of work is always played by communication between teams. At the same time, it is necessary to find balance and not go too far with the number of meetings, so as not to take away the team’s valuable time that can be spent on development.

Here are some rules and tips that will help save time and make meetings effective:

1. The meeting should always have a goal or end result with which the participants or the organiser should leave the meeting.
2. The meeting should have an agenda. It should be clear from the description of the meeting, what participants are going to discuss, what topics and questions are to be discussed. If there are documents for review – they should be attached to the meeting materials.
3. Define the time of the meeting. You need to make sure in advance that all participants are comfortable with it.
4. Limit the number of participants. Avoid crowded meetings. The more participants, the more "expensive" the meeting for the company and the harder it is to keep focus on the subject of discussion.
5. Always record deadlines and agreements. If you agree on something at a meeting, document the designated person and the deadline for their feedback.
6. Bonus. Chats. Minimise communication in personal messages. Use messengers where there are threads to make sure other participants are not distracted and the information is always publicly available.

In one of the last projects we tried to minimise the number of meetings, while making them as predictable as possible.

• A project kick-off meeting with the team

What we got: The team understands the goals and tasks that lie ahead.

• Q&A session on requirements from the development team

Answered pre-prepared questions on the requirements and implementation. Development and testing teams understand what and how to do.

• Set up daily 15-minute calls with the team

What we get:
1) Understanding the current status of development and testing, which allows managing expectations and deadlines for the project.
2) Record problems, determine further steps and designate those responsible for them.

Thus, we minimised the time for calls while not losing the quality in communication and transparency.

The main task of any process is to be transparent and predictable. This is largely achieved through the visualisation of the work process.

We believe that the best solution is a properly set up Kanban board.

How we set up the board in Cloud Retail:

• Typify tasks.

Different types of tasks require different approaches and it is very important to reflect this on the board. There are the following types of tasks:

1. Technical task (aka tech. debt)
2. Research task
3. Bug
4. Task to improve the current product
5. Paid feature for a client

• Specify statuses on the board.

You can use the standard three statuses: backlog, in progress, done, but, as a rule, more detail is needed. For example, separate statuses for each environment (dev stand, stage, etc.) and teams (dev/qa).

• Set up filters for teams/projects.

Several teams work on one board at once and you do not always need the information about everyone at once. In such cases, custom filters are very helpful, allowing you to highlight the necessary working groups or components.

• Plans service in Jira.

Allows you to quickly work with a project plan and build Gantt charts based on the board or filters added in the previous point. It is convenient because it is built into Jira and there is no need to duplicate and maintain tasks and stages in an external service.

Regardless of the development approach you choose, it is necessary to digitise the team's work, look for patterns in successes and failures. For example:

• You can estimate how many tasks the team completes on average over a period of time.
• You can typify tasks and see what type of tasks you do most and how much time it takes.
• You can identify the average time from the task’s entering into development to the release.

Without metrics and analytics, it is extremely difficult to make informed decisions. These are just examples of a few simple reports that can be easily collected in a short amount of time. Nevertheless, they will allow you to see the real helicopter view on the project and draw conclusions.

In addition to analytics, it is very important to keep in mind that there are people in the team besides you who can suggest improvements in work. It is useful to gather with the team every 2-4 weeks and discuss what went wrong at what stage and how it can be improved. Such a meeting is called a retrospective. Retrospective is a mandatory ritual of the Scrum framework, but we see the meaning in it regardless of which methodology you use. The main thing is to properly organise and facilitate the meeting, using the tips from paragraph 4.

Creating an MVP in tight deadlines dictates its own conditions. You will not be able to do all incoming tasks and you must understand what is really important and necessary at the moment.

In the process of developing an MVP, it is extremely important to say "no" to additional features, provided that the amount of resources, the scope of tasks, and the deadlines remain the same. It is important to understand that if the team or the customer understand and agree with the risks related to project deadlines, then the MVP can be expanded.

Below are several principles that will help to refuse when necessary.

• Focus on the main functionality. MVP development is aimed at creating the minimum necessary set of functionality to test the hypothesis and collect feedback from users as soon as possible. Most often, the main functionality is defined and agreed upon BEFORE the start of development. Typically, by the time of development, a balance has already been struck between "normal" and "hardcode" solutions, so a refocus on additional features can seriously harm the product and the deadlines in particular.
• Saving time and resources. Probably, the main reason for refusal is precisely the absence of time or people to complete the task/functionality.
• Speed of receiving feedback. The main goal of an MVP is to get real feedback as soon as possible. Any modifications will delay this moment, which automatically increases the cost of testing the hypothesis.
• Minimising risks. Adding any new functionality to the system can destabilise its current behaviour, which can entail additional load on the development and testing teams, which is not permissible in tight deadlines.

Saying no is a strategic approach that allows focusing on the key features of the product and saves time to deliver the MVP to users as soon as possible.

Our article meticulously outlines the crucial moments and key considerations essential for the development and planning of Minimum Viable Products (MVPs). We have identified and incorporated these factors into our work processes to ensure adherence to deadlines and successful implementation of tasks critical to the product and its release. Keeping to these principles helped us to efficiently develop a comprehensive solution for eCommerce under tight timelines. This solution, initially utilised by our team, is now available for retail companies. Feel free to reach out to us, and we will be delighted to provide you with further insights and help.