The power of MVP
Much has been written about minimum viable products (MVP). I doubt I can add new insights, but I can share my perspective from an experience with one client.
A minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.
Let me set the scene. The client was a leading European real estate company—though the domain matters little here. The product team envisioned a complex product to sell to their customers. To gauge user acceptance, we ran multiple A/B tests to find the most successful approach. The product was straightforward to implement, but deciding which users should see what was another story. We had to account for user location, search location, last visit, and more. The number of variables was large, so we ran the tests for nearly half a year to gather meaningful data.
This kind of experiment requires proper metrics, so we measured everything. Once the test finished, the data analysis team did their job—and the results disappointed us. They fell far short of expectations. Yet one small part of the product resonated strongly with users, and a month later the product team built a new product around it.
Now the real story begins. The new product lacked the complex rules of the previous one: no location logic, no visit history, no search patterns. Customers would get a special section on the page to showcase their products and share it as they liked. Since the user-facing part already existed from the previous test, it was time to make it real and start selling.
We held a meeting to define the architecture and implementation plan. Two engineering teams, the head of technology, and the product owner—about 14 people in virtual rooms across countries—discussed the best approach and estimated completion. Someone pointed out that since customers had to purchase the product, we'd need to involve the commerce team. The products team would create a new microservice, and the website team would consume and process that data to enable the product for each customer.
Complexity piled up again. Initial estimates put delivery at three months minimum—probably more, given coordination across engineering, marketing, and design. Listening to these discussions, I asked the product owner: "How will you sell this product in the short term?" The answer unlocked an easier path. Initially, a small sales team would contact only the most important customers. After that, they'd evaluate which other customers might be interested.
With this information, I proposed an unorthodox approach. Instead of building the complex system, coordinating multiple teams, and blocking the launch until everything was done—why not hardcode customer IDs? A few lines of logic, and we're done. Each time the product sold, someone would email the team, and we'd add the ID in minutes. This solution doesn't scale, but it wasn't meant to. Since sales would be handled manually at first, we could control the pace of customer acquisition.
Everyone received the proposal well. We could start selling earlier and relieve pressure on the engineering teams. Within one week we had the product in place and sold to the first customer. Over the following months, the teams worked at a relaxed pace on the final implementation—one that would eliminate manual steps.
That's the story. Here's what I learned:
- Keep the implementation as simple as possible. You'll reach the market earlier and may relax some deadlines along the way.
- Involve engineering teams early in product definition. Different perspectives surface better solutions.
- Share the full project vision with engineers, not just their piece. Context shapes better architecture.
In conclusion: I'll keep practicing what I consider one of the most important traits in a developer—laziness. That instinct drives me to find the simplest, fastest way to solve a problem.