To MVP or Not MVP?
It may be the question, but the answer is almost always to MVP (Minimum Viable Product). This three-letter acronym has been seared into startup founders’ brains since the early 2010s when Eric Ries popularised it in his best-selling book, The Lean Startup.
“The Lean Startup” guides startups and tech companies to develop sustainable business models through continuous rapid prototyping and customer feedback. The book emphasises the “build-measure-learn” feedback loop, urging startups to create an MVP quickly, test it in the real world, and use validated learning to make informed decisions. This method helps startups avoid wasting resources on unwanted features and pivot effectively when necessary to achieve rapid growth in a competitive market.
The premise is simple: before committing major resources to build what you think is the perfect product, break it down to the smallest possible product that delivers some value to test your hypothesis that your customers need it and will pay for it.
The best depiction of a good MVP is one that compares the iterative development of a car, where stages 1 through 5 don’t provide the user any value, versus starting with a skateboard, evolving to a scooter, then a bike, and eventually ending up with a motor vehicle. In the latter scenario, each stage of the product provides the core value of transporting the rider from one destination to another, albeit with less luxury.
The Birth of Drive Yello
I am, and always have been, a big advocate of the MVP philosophy. I certainly applied it when starting up Drive Yello. Here’s the quick version of how Drive Yello came to be. My friend Johnny Timbs owned a couple of Crust franchises before Uber Eats and similar services existed. One Friday night, a couple of his delivery drivers called in sick. He had to find someone to fill the shift or do the deliveries himself.
Ding—light bulb moment. ‘Why isn’t there a marketplace of drivers where restaurants and cafes can find and book a driver on short notice (or in advance) to do deliveries for them?’
Excited to test this idea, I bought the domain driveyello.com that night and began clarifying what hypothesis I needed to test:
Hospitality businesses are willing to book random contractors to do their deliveries, and there are people interested in being those random contractors (remember, this was pre-any delivery businesses launching in Australia). I also needed to know if the problem was sizeable or just a few pizza stores.
To test this hypothesis, I whipped up a simple job board in WordPress using plugins, downloaded some images off the internet, changed the colour to yellow, and voila—the site was live within a weekend. I then posted some ads on Facebook, spent a few hundred dollars on advertising, and bingo—we had a true MVP test in play.
Initial Validation
Day 1 was quiet. On day 2, we saw about 10 couriers sign up. By Day 3, we had about 30 couriers and 4 or 5 merchants. By the end of the week, we had around 150 couriers and 30 restaurants signed up and ready to go. This proved the demand for the service and the supply willing to do the work. Drive Yello was validated as a workable idea, attracting and convincing seed investors of its potential.
Continued MVPs
Since that light bulb moment almost 10 years ago, we have continued to create mini MVPs to validate ideas and adapt to a changing market:
MVP 1 - Shift Booking:
Backstory: Success with the WordPress MVP led to the development of shift bookings and courier tracking, focusing on pizza stores.
Hypothesis: The hospitality industry wanted an easy way to book and pay for couriers for shifts.
Result: Validated. It has proven very popular with both sides of the market, with thousands of couriers and hundreds of restaurants signing up.
MVP 2 - SaaS Platform:
Backstory: During this period, there were no platform delivery companies, so most hospitality venues hired their own couriers for deliveries. It was assumed these venues would want to manage this process as efficiently and transparently as possible. This assumption proved correct and was a key factor in landing our first flagship client, McDonald’s, which used its own couriers and branded cars.
Hypothesis: Hospitality wanted technology to manage, track, and book couriers for venues with their own couriers.
Result: Partially Validated. Consumers loved tracking technology, but venues didn’t see the need to track their own drivers without POS integration. A fragmented POS industry made this a difficult friction point to remove.I'm not sure it solved a big enough problem for the restaurants. They seemed to be happy using physical calendars and didn't really think they needed to track their own drivers
MVP 3 - Couriers On Demand (ASAP):
Backstory: As Uber Eats entered the Australian market, it began to normalise the use of technology for on-demand courier services. The market was evolving, and so did we. At the time, Menulog was generating restaurant orders but wasn’t handling the deliveries. They needed a partner like Drive Yello to compete with Uber Eats.
Hypothesis: Hospitality venues wanted to book couriers on demand to deliver their orders.
Result: This hypothesis was validated extensively. This was the point when our product and business began to take off. We became Menulog’s delivery partner to help them compete with new entrants like Uber Eats. This MVP adapted quickly to market demand, unprecedented for our business. While the product market fit was excellent, product polish let us down slightly as the integration with Menulog’s platform wasn’t as smooth as an all-in-one solution.
MVP 4 - Couriers Booked in Advance:
Backstory: The Menulog partnership was a resounding success, making up 80% of our business. Unfortunately, it was so successful that Menulog decided to take over the delivery themselves. This was a major hit to our business, and if it weren’t for our investors’ support, we might not have survived. We needed to diversify away from fast food delivery, and observing the trend of increased grocery delivery overseas, we decided to target major grocery retailers — to enter our Woolworths era.
Hypothesis: Retailers and their customers wanted to schedule their deliveries, not just get them delivered ASAP.
Validation: Upon releasing our scheduled job feature, it quickly became as popular as our ASAP orders. This feature was critical to helping manage demand during COVID lockdowns.
It has proven to be a great addition to our platform, allowing us to offer one of the most diverse delivery solutions in the space. - Shift, SAAS, ASAP & Scheduled deliveries
When MVPs Can Go Wrong
While MVPs are often hailed as the best way to test and validate new ideas, they can sometimes miss the mark. The most common issue arises when an MVP doesn’t offer enough value. A product that fails to meet a basic level of functionality and usefulness won’t attract or retain users. Additionally, if the features developed don’t address a real demand, the MVP won’t provide a true test of the market.
Not a True MVP
One common pitfall is when the MVP isn’t a true MVP and fails to offer any real value. A common depiction of an MVP when a car is the ultimate product is to either build a bike as your MVP or a car with only three wheels. The latter is a vehicle, but it’s not functional or appealing. An MVP that doesn’t meet basic user needs or lacks core functionality won’t attract or retain users.
Features Not Meeting Demand
Another issue is when the features developed don’t address actual demand. Being too focused on one feature without providing a little more generic value may produce inaccurate results. This is like opening a restaurant that serves only one dish that no one really wants. People may want to eat out regularly but not a fan of the dish on offer. If the MVP doesn’t provide a true test of the market’s interest, it won’t yield useful feedback.
Poor Marketing and Onboarding
Marketing and a positive onboarding experience are as critical as the product itself. A poorly marketed MVP is like hosting a party without sending invitations—no one will show up. This is not a true test of product market fit. Similarly, if the UX is not intuitive or the onboarding experience is confusing, users will abandon it quickly. These are often overlooked as reasons for an MVP's failure, and good products are abandoned for the wrong reasons.
Market, Competitors, and User Expectations
The success of an MVP also heavily depends on the market, competitors, and user expectations. If you are releasing an MVP into a competitive market with established high user expectations, your MVP must meet or exceed these expectations to stand a chance. This has more to do with product polish than the features available in the product.
Importance of Product Polish
While MVPs are meant to be minimal, they shouldn’t be sloppy. An MVP should have a level of product polish to be appealing and functional. If the product feels too unfinished, users might not give it a fair chance.
Always MVP
The Drive Yello MVPs weren’t fully functional on day one but evolved as the need for the feature was validated and specific needs from customers were truly understood. MVPs need time to be tested and their success assessed with an understanding of the elements that can undermine them. With today’s emphasis on speed to market and product-market fit validations, the days of building the ultimate product before you release it are gone. Users are used to jumping onto a platform early, watching it evolve, and almost expect it today. It’s critical to get that mix right:
