Fear No. Uncertain development budget Fear No.
20.11.2019 Let's discuss what usually scares clients about agile development of a minimum viable product (MVP) and why it pays to get rid of those fears today so development becomes more deliberate.
MVP, or how to avoid endless development
Why businesses need an MVP, how to test a product idea in the market, and how to avoid unnecessary costs from premature development.
- Fear No. 1. The product will be low quality and damage the reputation
- Is the fear justified or not?
- How do you deal with it?
- Fear No. 2. Uncertain development budget
Fear No. 1. The product will be low quality and damage the reputation
Nobody does that (in our niche, in our region, etc.) Fear No.
It is hard, and you will have to put in effort Conclusions Reading time: 12 min. Read the article on vc.ru. MVP (minimum viable product) is the initial version of a product that delivers the main value to the customer, but does not include full functionality and may not yet have a fully finished visual layer. It is easy to understand: remember the cupcake principle. Before selling a huge cake, you need to let the customer try a small pastry with the same filling.
If people like it, you can scale it and refine it to perfection; if not, you save money and time and improve the recipe based on feedback. Software development is the same. Before building complex software, it makes sense to create a prototype first, test it on real users, and only then polish it and roll out improvements. Afraid to sell a cupcake because it is not a cake and the client will wrinkle their nose in displeasure? Then this article is for you.
Let's move from the pastry shop to the open space of an IT company and think about whether an MVP can become hell for a perfectionist, what fears push clients into endless development, and how to deal with them so you do not painfully regret a budget wasted for nothing.
Fear No. 1. The product will be low quality and damage the reputation
The concept of MVP is closely tied to Agile philosophy
Clients sometimes think that if a product is built quickly and without a clear technical specification, it means it was built with sloppy code and hacks.
In that case, it is no surprise that they want to play it safe, prepare a detailed specification for a long time, and avoid rushing. "We did not build our reputation for twenty years just to ruin it in three months."
, as major brands say when they want digital transformation but are wary of MVP.
Is the fear justified or not?
My opinion is no
Not all end users will even realize that the MVP contains only part of the possible functionality. Unfortunately, clients often forget that quality depends greatly on them as well.
Weak teams on the client side pose a huge risk when they do not want to work in an agile way and instead work the old-fashioned way, for example by spending a whole year writing the specification in minute detail.
My experience says that most consumers rate the quality of a product with an MVP higher than without one.
Market feedback comes faster (launching an MVP takes about three months on average).
The product is constantly evolving and improving to meet customer requirements, which they communicate through feedback.
The result is high-quality, convenient software built for specific client needs.
How do you deal with it?
First of all, assemble a team inside your company that is capable of making decisions.
They must be ready to sacrifice part of the functionality and make a real cupcake, not a huge cake.
No excessive perfectionism, just pragmatism.
The team needs to understand which features are enough for the MVP and which ones can be left out.
If you are very afraid of bad feedback about an MVP, you should first release it to a small, most loyal audience, friends and family, or a few clients who will be easy to agree with on a pilot launch (in our experience, most agree).
Example 1: developing the checkout page for an e-commerce product. One IT product had the following story.
It was impossible to add a full payment form on the checkout page, and the MVP had to be launched urgently.
The developers were able to offer four ways to work around the problem without reducing quality. Online payments are an interesting case in general.
Sometimes it seems that the inability to pay without going to the bank's website is a major problem that can cause some sales to be lost.
But the opinion of the target audience may surprise you: some customers do not trust this format and prefer to be redirected from the site to the bank's page, which they trust more.
The absence of extra functionality does not always mean low quality.
If your site has a product that the customer needs urgently, that is the main value of your MVP, and the customer will not care about the minor details.
Example 2: developing a B2B portal. An IT company built an MVP for a wholesale supplier's B2B portal and began collecting feedback from real users, retailers who were loyal enough to agree to testing. It turned out that dealers chose products and grouped them into batches in a completely different way from what the client had imagined.
The developers made changes to the MVP, and after release the portal received a high NPS from users (net promoter score). In this case, both the team and the client felt very clearly how many losses an MVP helps avoid and how important it is to get fast feedback on the product. Example 3: creating a year-long specification
One department of our regular client asked us to do the scope for a fixed price. They said the requirements were clear, the functionality was simple, they would draw the mockups themselves, and we just had to build it.
It took a whole year (!) to compile the specification for the "clear" requirements and sign the contract for them, because the client has a job beyond approving the specification, and reading a large document is difficult and time-consuming: while one part is being discussed, another is forgotten, and after some time previously written parts need to be edited, and so on.
In the end, after two months of development, one of the business stakeholders left, and the "clear and simple" requirements became so complex after clarification that even the stakeholder began to lose track of the calculation method they had proposed.
Fear No. 2. Uncertain development budget
For a business, it is important to plan the budget as accurately as possible, and we as a contractor fully understand that.
Is the fear justified or not?
From a budget planning perspective, the classic project approach may seem more profitable and simpler than Agile. You sign one document with a perfect specification for twelve million and wait for a clear result. But it is impossible to create a perfect specification: it simply does not exist. Development with a specification and without Agile is more expensive for the following reasons.
Too many risks are built into the specification, along with unnecessary features. In a classic project approach, the client tries to include a lot of extra, unnecessary items in the specification as a buffer against risk. They think: "I won't be able to change the specification later, so it's better to build in a reserve now." That is how a project becomes truly expensive: the "reserve" usually includes a large number of unnecessary, unclear features that are impossible or difficult to implement. For example, the client demands functionality that in real life does not work the way it does in their imagination.
This will only become clear when the product is tested by one of the departments, which was not considered necessary to involve in writing the specification. The project launch will have to be postponed. Long cycles of business analysis, approvals, and budget revisions are guaranteed. The other extreme is when the specification contains overly vague wording, often deliberately, so that some department can avoid responsibility. In Agile, a fixed team works on the project at a fixed cost.
You can, and should, negotiate with this team; in fact, each sprint begins with an agreement on what value will be delivered to the client at the end of the sprint. The client can spend any budget in a deliberate way, with the freedom to adjust and change priorities and drop unnecessary features in favor of necessary ones.
The client produces revisions at the very last moment. Do you think a detailed specification will save the project from changes and the related costs? Experience shows that clients ask for 99% of changes at the very final stage, that is, during acceptance. It is very hard to imagine the finished functionality in advance, so any project, no matter how detailed the specification, will require fixes. Which means there will be additional budget approval cycles.
There is no question of any savings, and approving such a contract is inconvenient too, because the functionality can be polished endlessly.
Accepting a project by specification is extremely difficult. Imagine you spend time writing the specification and approving it with departments, or your employees do, it does not matter. The contractor estimates the scope and starts work. Then they deliver the work in large chunks, which you then have to test in equally large chunks.
For a complex development project, at least four months will pass from the start: in that time, someone may quit, something may change in the business, and your own vision of the ideal may become completely different. As a result, after several months you receive a request to test all the functionality, but it is not even certain that you still remember how it is supposed to work. Accepting such projects is hell for the client. Signing acceptance documents is scary, in case something was overlooked.
Not signing is bad too: until the acceptance document for a large amount of work is signed, the client may refuse to implement new functionality. How much time does it take to test even two months of a development team's work? A lot. Agile uses short cycles (a sprint lasts 1-2 weeks), so acceptance takes little time, you provide feedback quickly, and the changes are put into production very quickly, where users also start giving feedback.
The result is not visible
If you evaluate the result through ROI (return on investment), an MVP is beneficial because it brings profit earlier. If the product is fundamentally unprofitable or you made a mistake in your initial hypotheses, an MVP will help you realize that quickly and adjust accordingly. The benefit will be reduced losses.
How do you deal with it?
With an agile methodology and an MVP, you get rid of a large number of unnecessary approvals. The team works on the project for as long as needed; monthly costs are transparent and depend on the team size; you define new features for development and accept results in small iterations. After four months, nobody will tell you that the developers built something completely different from what was expected, and as the project manager you will not have to be responsible for inaccuracies in
Specification. Developers will be interested not in "building functionality from a checklist"
, but to build a useful product.
Example: the losses caused by unjustified perfectionism
One team we know spent a year building an online store! A year, and that is still not all!
The project has not gone live yet, but it has already gone through three redesigns simply because the client wants to perfect it. And ideas of perfection change regularly, with changes in company leadership, fashion, weather, politics, and so on. And you know, that does not make anyone happy.
Because endless development is not profitable for either the client or the contractor.
Millions of rubles have been spent, but there have been no sales yet. It is unknown whether this project will pay off.
With MVP development, market reaction would already be visible after three months
In the end, the project did launch, but after launch and once all departments started working seriously on the issues of specific orders (marketing, logistics, IT), the concept had to be changed, along with the design and many technical details.
Is the fear justified or not?
Agile development methods were not invented yesterday.
The term MVP itself appeared around 2001, but it can be said that its foundations lay in the history of scientific management, lean manufacturing, and continuous small-step improvements (Toyota, the 1960s).
Many companies work with MVPs now, including large businesses that have been on the market for a very long time.
Notable examples: Dodo Pizza, Dropbox, Uber, Airbnb, Yandex
In software development, you will not find a single successful, dynamic company that works with rigid methodologies.
Assess where AI can deliver impact in your process
How do you deal with it?
Get to know MVP better
Recommended reading: theory: Jennifer Greene, Andrew Stellman, "Learning Agile: Understanding Scrum, XP, Lean, and Kanban";
Eric Ries. "The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses"
; from practice: a chapter from the Dodo Book on this topic.
Example: the variety of MVP projects
What is encouraging is that agile methods in development are clearly becoming more popular. MVPs are being built both for e-commerce products, where the main challenge is heavy site load (which is actually easy to handle, because with an MVP you just need to control traffic by limiting the budget and collect web analytics), and for products with fewer users but unique technical solutions.
An MVP example for a computer vision and neural network project: first we train the software to recognize X types of paper with 60% accuracy, then in each sprint we add new samples of documents, signatures, and stamps and increase the quality score. An MVP can be created for any unique task!
Is the fear justified or not?
A client may think: "Startups work in conditions of uncertainty, so they need an MVP. But I have been in business for many years and I know exactly what I want from developers. I need very simple software. This button should be here, and this field should look like this. Why do I need an MVP?"
Simplicity here is an illusion
Not only startups but also large businesses, with 10, 20 years or more of experience, always face uncertainty when developing software. First, the market situation and marketing trends change very quickly, and they are hard to keep up with.
End users' behavior changes even faster, because every second they gain new experience from other companies.
This can be called external uncertainty
Second, there is internal uncertainty on the client's side: the more people are involved in decision-making, the harder it is for them to agree on exactly how the product should work.
A simple example: the client thinks the raw material approval form for the warehouse is very simple, because their employees do it manually every day.
But with automation, something previously blurred from view comes to light: it turns out that, based on the original invoice number, the operator must determine the batch number, and the input of raw material quantity will be requested based on knowledge that was not accounted for in software development and was never digitized.
The client was sure the task was simple and well-defined!
How do you deal with it?
Assess the external and internal sources of uncertainty around your business. Recall how long it takes to approve important documents in your company. And how many mistakes have to be corrected in the process. Estimate the value of lost time in money over a year.
Example: the illusion of clarity
-
A small company focused on B2B clients ordered software for internal use using rigid methodologies.
-
At first glance, it seems like a simple product for a small number of users.
-
The company has been on the market for a long time, and all employees have more than 10 years of business experience. Contract approval took a year.
-
When the contractors took on the task and clarified the field dependency requirements, they discussed each step for so long that it became clear each of the four people in the department understood the project differently.
-
Moreover, they did not know their own business processes.
-
And when you automate business processes, you cannot automate chaos. You cannot digitize a rule for assigning responsibility like: "Petya usually did it, but now let Vasya do it, I think he is free right now."
-
A clear algorithm is needed, and a large number of questions arise about the system. The organization was far from the startup stage, but that did not help it avoid internal sources of uncertainty.
Is the fear justified or not?
Before each sprint, a management decision must be made about what is important to implement in the next sprint (usually in software development a sprint lasts 1-2 weeks, and in mechanical engineering 2-3 months; the key is rhythm!). This is hard if your company does not have a strong manager, a leader who can clearly set goals for the next two weeks. Or when there are too many decision-makers in the company and they cannot agree.
How do you deal with it?
Develop your managers. Study INVEST (or SMART) and Impact Mapping: a task description method that allows you to think through a task as deeply as possible from the standpoint of user value, and a methodology in which a specific task maps to improving specific metrics.
In serious IT companies, in addition to developers, there is also a project manager who knows INVEST and Impact Mapping and helps the client arrive at the right wording, though of course not without involvement from the client's management.
Example: how an MVP solves the problem of painful approvals
You can launch a trial version without lengthy approvals and add to it and improve it in every sprint. Making improvement decisions in small steps is not easy, but it is usually simpler than approving a large project all at once. Adjacent departments no longer blame each other for missing something; instead, they discuss a concrete plan for the next two weeks.
Conclusion
So, to summarize: an MVP is a way to connect with reality that helps you get feedback faster and adapt to the needs of system users. Agile methodologies benefit everyone, the client, the contractor, and the end user, because they make business management more deliberate. We hope this article has helped dispel at least some of the fears surrounding MVP.