Foodable
Role
Product Designer, Product Strategy
Summary
I revisit the MVP after a year of sunsetting Foodable. I decope and reimagine product offering and strategy.
What is Foodable?
Foodable is a startup and passion project a couple of peers and I started towards the end of our undergrad.
Being an undergrad, we understood what it was like feeding ourselves.
We also understood there was a lot of food waste at the end of the day, whether from our campus Starbucks or the local sandwich spot.
The problem is not unfamiliar...
44%
of University of California students are food insecure
30%
of restaurant industry revenue was lost due to the pandemic
10%
of global emissions are due to food waste
What’s the value here?
Students still want to eat good food (the dorm food can get boring). Students may not have that much to spend. Local restaurants and food places would prefer to not trash inventory. If they could, they would sell it. And we’re doing our part in being more sustainable.
Sounds like a win-win to us.
But how?
In the little free time we had after our 9-5’s, we met every other day to scope features, to define our value prop, to MVP the MVP.
The solution is simple
input excess meals into our database any time before closing
displays and notifies users of new available meals on the app
pick up meals, saving them money and saving the planet, one meal at a time
What we considered our consumer-facing MVP
I prioritized and tackled the consumer-facing experience because it was the most important for a successful product. We would figure out how it would work on our end after defining our core customer’s journey.
Browsing and viewing a food item.
Checking out a food item and payment method.
Keeping track of order and ease of confirmation for pick up.
Running into the same hurdle over and over and over again...
A mobile app left too much space for other liabilities we should not and could not be responsible for.
Such as: hosting and storing payment information, storing location data, and the accompanying debate of whether or not to store data locally.
Two years later, I had a shower thought (revelation):
The payment was by far the most difficult part to develop, yet it was unnecessary.
We should simply ask that the customer pays the restaurant directly when they pick up their meal. This leaves little payment liability on our part, and both restaurants and customer interact the same way they’ve always interacted.
The solution is even more simple
input excess meals into our database any time before closing
texts users the availability of food items of the day
claim via text, receive confirmation via text, and pay at pick up
Foodable reimagined
This solves our overengineering, allows us to learn manual processes before building tools for it, and still affords the same product offering to customers and restaurants.
Retro
Making something complicated is simple, and making something simple is complicated.
We were very ambitious in the first iteration, and while that is a good thing, learning when to decope is equally as important. The ultimate goal is to deliver the value prop -- how you do it is less important, so get scrappy.
After learning this, I was able to revisit and reimagine a more feasible scope and put my concept to designs.
(✿◡‿◡)
Thanks for reading. If you’re interested more about my role and time at Foodable, reach me at my email.