Minimum Viable Product
Gamebyrd
The swift transformation of the video-rental industry (R.I.P brick-and-mortar movie rental companies) left a void within the hearts of many gamers. As the market moved towards digital entertainment streaming, the ability to rent anything - from new video games to childhood classics - was lost.
Enter Gamebyrd - an internal project with a simple concept: deliver games, consoles, and accessories to your door as quickly as a pizza.
Two Weeks to Create or Bust
For me, the design methodology for web applications always focuses on getting a working prototype into the user’s hands as quickly as possible. This doesn’t mean cutting corners – it means working efficiently. By receiving feedback from users early and often, I was able to validate assumptions and adjust on the fly. For internal initiatives, I typically allow two weeks to create a working prototype - either an interactive mockup for more complex apps or a deployed alpha version for simpler ones.
I started with the basics. By defining the overarching goal of the project and exploring the customer need, I was able to design around a defined value statement. There was no need to make this complicated – which is why I followed a template, similar to a modified business.
Minimum Viable Product
A product as a collection of features that work together to solve a customer’s problem. It is all about needs vs. wants. What is important to know is what features are completely and totally necessary for the experience. In my process, each user journey is mapped out and features in the app are prioritized accordingly. For Gambyrd, I knew users would need to search, add items to a cart, give payment information, and receive notifications.
All journey maps for minimum viable products are based on the end-user. Yes – I could have applied more dynamic processes like automating the order flow, automatically generating routes, programmatically contacting drivers to deliver games, etc. – but were those pertinent to the preliminary testing of the app? These are the types of scenarios I thought through. Without first validating that this idea was something the user would adopt, I risked spending time and money on things that might not matter. In the end, the needs outweighed the wants.
Where it is Now
Our end product was demoed to a cohort of roughly 25 people with mainly positive feedback. After moving through some personal demonstrations to prospective users, our team ultimately decided to cease development on the app. Between the logistical hurdles and new developments in the retro games space (looking at you NES classic), we decided it wasn’t a product to continue with into the future. But man, did our imaginations have fun with this one.
Additional Information
I'm really passionate about products and entrepreneurship, so if I have an ambitious idea that requires a lot of work, I write a business plan for it before coding anything. This allows me to see how close it is to the projected cost of production, what the runway needs look like, and if it’s viable. Sometimes I'll decide to build the product and put it in people's hands for testing before choosing to continue with it full time.
- Business Plan (has a lot of fun facts about the retro gaming industry if you're into that kinda thing!)
Want more content like this?
Sign up to receive my newsletter, where I feature early access to new products, exciting content, and more!