A Minimum Viable Beach Bar
What is a Minimum Viable Product? An improvised beach bar on Mallorca can teach you a thing or two about this.
We held next to the main road.
Our goal was to reach a small beach which was lesser known to tourists and promised to be less crowded. A friend had recommended it to us, saying that it was a bit hard to reach but worth it.
Now we found ourselves in the middle of nowhere and looked down a bumpy gravel road. The sun was burning and every move made us sweat.
The road would have brought us nearer to the beach and we wondered if we should take the risk. But looking down that road, we could spot some serious potholes. Otherwise, the road didn’t seem very inviting either. It seemed there was a real risk for a broken axle on our rental car if we weren’t cautious enough. So we decided not to take that risk and walk.
It was a long walk in the heat of the midday sun but we did it.
After a while, we stumbled into a gate. The gate and a walk through uncertain terrain was the last thing between us and the beach. We slipped through the gate and conquered the terrain behind. After around another fifteen minutes we could see the sea. When we finally arrived we had spent almost an hour since we parked the car.
You can imagine we were craving for a chilled drink when we finally reached the spot.
What does a beach bar need?
What would you say is the minimum a beach bar needs?
Perhaps you think about a cottage, chairs, tables. Perhaps, you even think about a refrigerator or other electrical devices. If that is the case, you are thinking too big.
Way too big.
There wasn’t much free space for a cottage on that tiny beach. On top of that: even the tiniest cottage would have destroyed the idyllic scene of the beach. Leaving alone the logistic nightmare.
Two tree trunks, a plywood board on top, and a couple of coolers will do, right?
What does this beach bar teach us?
It could have been by accident. But the people running the bar gave us a practical demonstration of a Minimum Viable Product.
Testing an idea with real customers and the smallest possible amount of effort. That is the essence.
An MVP shares similarity to a prototype. Both share the same purpose: get feedback early in the product cycle. However, a prototype is a preliminary version of what could become a product. It is usually used for internal purposes — to showcase technical feasibility for example. As such it is disposable. Contrary, an MVP is a product but with functionality limited to the bare minimum. It should be enough to assess if it’s valuable for real customers. Furthermore, it should serve as a foundation to build an even more valuable product.
Did the beach bar provide value to real customers?
For us it did.
There is also no doubt that the bar was suitable to gain feedback. After all, the people running it made some money. They sold chilled drinks and pieces of bread topped with tomato salad and Serrano ham. It’s unknown to me if it was suitable to pay their bills. Maybe that wasn’t their plan anyway. It’s possible they wanted to make some extra money while hanging out at the beach. Who knows? In any case, it provided valuable insights if they were looking for it.
And the bread was delicious, too.
What the Minimum Viable Product is all about
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.
(Quote from the Scrum Guide)
Fundamental to Scrum is that we want to ensure regular opportunities for feedback. We do that because we want to deliver value and excite customers with good products. No one wants to deliver something that no one wants. But we also know that we do not know what the customer needs – until we show something to them.
For a new product, the uncertainty about the value it brings is especially high. The Minimum Viable Product is not a Scrum practice per se, but it can be handy for practitioners:
- It helps you find out, what the customer deems valuable.
- It limits the risk of wasted effort to the effort for building a minimal version of the product.
- It’s reducing the time to market if your customers like what they see.
You build a Minimum Viable Product to get feedback from real or potential customers. You do it also to provide value fast.
For that, your first take does not always have to be a full-fledged product. Sometimes a landing page can be enough. It allows you to generate insights about prospective customers and iterate from there. Adding value sprint by sprint.
The hardest part in practice is to define an appropriate scope for an MVP. For that matter I recommend the following approach:
- Think about what you want to figure out with the MVP.
- Think about the required functionality, which would provide value right away.
- Discuss the scope with the Development Team. Do they consider it scoped narrow enough to be part of a single Sprint?
- If the scope is too large: repeat steps 2 and 3 until you have found a set of functionality that does fit into a sprint.
In rare cases, it is not possible to fit the required functionality into one sprint. In these cases aim for as few sprints as possible. Make sure you don’t compromise in the criteria to meet the Definition of Done.
The good thing about the approach: it is useful not only in the initial product stage. Do you want to build a feature that is too large for a sprint? Try coming up with the minimally viable version of this feature.
In Scrum, each Sprint should result in a potentially useful Product Increment. The approach can help you tailor your sprint goal and scope in accordance.
The best of all is, we can practice this: Sprint by Sprint.