One day you’re building the Minimum Viable Product, and the other day you’re the CEO of an international company, delivering products or services for customers around the world. But what comes in-between?
Zero to hero in a few simple steps
If you’ve read our article on choosing between in-house development and outsourcing (a highly recommended read!), you probably already know our approach to simple and short answers. But worry not, we’ll grasp the concept concisely.
Before we move further, let’s take a look at the idea and rationale behind building an MVP in the first place. Just a brief reminder – the concept of MVP is associated with the lean startup methodology. According to the approach, the startup is an experiment, as a company operating under extreme risk. What causes the risk? The potential biggest strength of the product can be its major weakness – innovativeness. Since the idea is new and original, it can conquer the market. On the other hand, its creator can’t be sure the market will accept it and whether the technology can support the vision, as there’s no reference to previous examples. Thus, entering the market requires verification of a hypothesis, backed by a minimal solution solving the customer’s problem.
I’ve built my MVP, what should I do next?
The Minimum Viable Product stage is just the beginning. The product development process continues, with the customer needs in mind. Agile-powered startups, preparing to conquer the market, beat the following road.
Minimum Marketable Product (MMP) / Minimum Marketable Feature (MMF)
The MMP/MMF stage is just enough to be released into the wild, with the minimum of necessary features to be launched, provided for a customer to recognize any value. This stage enables – just like the MVP – reducing risks, verifying the monetization strategy, analyzing the demand, and accelerating the market release.
Minimum Marketable Feature (MMF)
The product at this stage needs to include must-have features resulting in immediate value to the customer. MMF helps in prioritizing the release of features, enabling the creators to learn from the first item and benefit from the conclusion while building the following elements.
Minimum Marketable Release (MMR)
This stage can consist of several items developed as Minimum Marketable Features and serves the role of shortening time-to-market, reducing the smallest necessary feature set to bring new value to users. MMF can be developed more than once if required, in case the product needs to grow to meet recognized needs.
Minimum Sellable Product (MSP)
During the MSP stage, creators build a product able to win a paying customer. This level of building a product is less about the idea and more about the functionality. The stage imposes cost control, requiring the development to be cost-efficient and not exceed the expected revenue.
Minimum Lovable Product (MLP) / Minimum Awesome Product (MAP)
Quite contrary to MVP, MLP is something the customers not only will accept, but also they’ll really, really like. The idea behind this stage is to not only provide functional features but to make them enjoyable and user-friendly. The MLP release focuses on the crucial features, designed to make users happy with interacting with the product.
But why exactly are we doing this?
Theory aside, building a product requires committing to a process. Actions aimed at a better understanding of market needs, threats, and opportunities are a rescue to people behind the idea itself. Names of particular stages sometimes differ, and the levels themselves have different meanings, confusing creators. While we aim at delivering great, working products, we’re not that attached to definitions. We focus on the MVP assumptions and recognize what it delivers.
The process from the idea to complete solutions, as exemplified by… mowing the lawn, should follow intuitive, logical steps. We don’t start with building a combine harvester from scratch, dedicating years to perfecting the engine. Instead, for starters, we deliver a scythe. In the next step, we design and test a more advanced, yet still handheld, solution, handheld shears. Afterward, the team will create a mechanical lawnmower, a simple drum mower, finally – a power mover. Or even, if that’s the intention of the client and research identified such needs, a gardening tractor, like the one you might remember from David Lynch’s movie, The straight story.
The thing is, we don’t do that at once. While building the product, we collect the emerging ideas for features that won’t make it to the product just now, but certainly are desired in the future. These ideas and suggestions arise at each stage of development, and while not critical to particular levels, add up to the backlog and wait for their time to shine.
Creators sometimes fall into a trap of making the product pixel-perfect, devoting time to polish the elements not crucial at certain stages. To present core functions and benefits, the developed idea needs to be good enough. Not beautiful, but working correctly. What’s the use of a pretty item that doesn’t serve its purpose?
To go beyond just the nice looks, some must-haves are to be taken care of:
Runtime environments reflect physical resources, necessary for project implementation, and contain details of external systems, interacting with the project. It’s the environment where the application is executed, the software and hardware infrastructure enabling the product to work.
The environment should be ready to handle bigger traffic, appropriate to the products’ characteristics. We need to know what kind of workload to expect, as it differs from business to business, e.g. B2C e-commerce experiences peaks around holidays while accounting systems record peaks monthly, quarterly, etc.
Apart from the above aspects, testing and development environments are required, along with the preparation of the version updates process. Each stage of development and managing the working product requires thorough testing. We ensure the created solutions match the requirements, and function within set ranges. Evaluation and verification of the product enable delivering the best quality to end-users, increasing the odds of winning happy customers.
Backup, security, monitoring of processes
This part may not be the first coming to mind when creating a product idea, but once the MVP is ready, we need to allocate resources to secure the functioning product. Simply saying, the project team needs members delegated to service and maintenance, to ensure the smooth and safe functioning of the project. Assigning some workforce to maintain the product’s infrastructure cannot be underestimated, especially when something goes wrong, requiring a rapid response. While building a new project, most certainly, something will go wrong, and we’ll be prepared to step in and save the day.
Customer support, adjusted to present capabilities
Measure up – it doesn’t have to be 24/7 support from Day 1, provided in 7 languages. Still, there needs to be something, e.g. 9-5 English-spoken-only support will be fine, as long as it’s suitable for the number of users at every stage. As we focus on making the product a working solution (not yet making it working and beautiful), we need to ensure the best possible customer experience while interacting with the product at each stage of development.
To know what to expect we need a scenario. Or to be even better prepared for the things to come, 3 scenarios: optimistic, pessimistic, and medium. Building a product/service, we may be pleasantly surprised with its exponential growth, but we need to be prepared for every possibility. After the MVP stage, we take time to consider various aspects of the idea, checking whether it’s suitable for commercialization. Our role is not only to help our customers build their products or services. It’s about looking from a wider perspective and seeing how their clients/ end-users will benefit from the developed solution.
Future development strategy
Staying on track during the project development process requires a document presenting the product’s current place, showing directions on where we are heading, what the next steps are, and functionalities to take care of. A roadmap is created as a part of the strategy, along with the target group needs, competition, and market analysis. As work progresses, the product is refined, its UI is improved, and further functionalities are added. Identified areas for improvement are noted, noticed bugs and irregularities are added to the backlog and taken care of when time and budget allows.
And… that’s it! In a nutshell, this is what should happen after the MVP. While we know it still may sound complex, we’re here to assist you through the journey.
Is there a method to this madness?
MVP seems to be the most popular and well-known stage of product development. (Un)fortunately, that’s just the beginning of the process. Moving past the next stages brings the creators closer to seeing their product conquer the market and winning customers’ hearts and wallets.
But that’s not the full answer to why. 10% of startups fail during the first year, while in subsequent years, 90% of new ideas and products will collapse. The main reason, unsurprisingly, is the misunderstanding of market demands, exceeding 40% of failures. Some may say it’s a matter of luck, but harsh market realities call for more than just a rabbit’s foot and hoping for the best while releasing a brilliant product that…nobody needs nor wants. The product development process aims at building a product in the best way possible, but with as much focus on the user, as on the project. Understanding the market, the customers & their needs, and providing the right features is the path creators of a new product should take, instead of jumping head-first and hoping for the best. While we admit the multitude of stages and their attributes may seem overwhelming at the start of building a new product, innovators aren’t left out alone. Before working out the further steps, consider consulting your idea and benefit from the experience we already have in delivering new products to the market.