Making Venmonopoly

One of my fond memories of growing up in Puerto Rico, strangely enough, revolves around a six day game of Monopoly my family played during the candle lit aftermath of hurricane George. Without electricity, or any of the usual 90's distractions, what were we to do but spend evenings screaming at one another over fictional rent payments? Each turn was a grand deal making opportunity: we wanted to knock each other out of the game, of course, but doing so too soon would end the fun.

I was recently thinking about that jewel from my past when, from the comfort of a fully powered house, I wondered, what if Monopoly was also powered? What if it had an easier way of tracking player payments or score? Could it be better? Now, my usual projects are proprietary adventures - the sort I can't discuss due to non-disclosure agreements. Because of this, I'd been looking for a simple idea I could build in the open to demonstrate the lean startup, cost saving principles I use to create new products. This became that idea... what follows is my journey in making Venmonopoly - an app for streamlining paper cash payments in Monopoly.

Lean Startup Principles

Before diving in, here's a quick refresher. The aim of lean startup principles - as articulated by Erik Ries, is to quickly and cheaply iterate ones way to making profitable products. A lot of this boils down to running experiments that test for what customers really want through what he calls the Build, Measure, Learn loop. In it, we:

Build an adequate version of our product or idea.
Measure it's ability to satisfy our customer.
Learn how this version of the product or idea can be changed to directly improve it for our customer.
Repeat this process while paying close attention to our overall product-market fit. If the fit isn't there then we change (Pivot) our design.

For the purpose of this article, we'll cycle through three iterations of this loop. In our first iteration, we'll look at products built by others to learn what we can from the existing market. In the second pass, we'll apply what we learned to design and partially validate our own app. In our third and final pass for the article, we will channel all of the customer feedback we learned into making and launching an actual app. Let's go!

Iteration 1: Pre-existing builds

As one may have expected, a few products have already tried to "power" Monopoly. Here are five of them:

In summary, there are electronic banking versions, as well as a few apps out there that either recreate the game entirely or serve as companion products to the physical board game.

Iteration 1: Measure & Learn

Next, I found over 200 customer reviews for these products and grouped them by value proposition. What I found was that a majority of customers valued ease of use, aesthetics, and how well the product preserved the feel of the original game.

A note on data quality: There are a few issues related to product review analysis. For one, reviews tend to skew very positive or very negative since it's often the love or hate of a product that motivates someone to write down their feelings in the first place. In that sense, reviews are extreme as well as minority opinions. Of course, there is also the issue of fake reviews. None of this is to say we can't learn from these but, rather, we should view them for what they are - imperfect information.

With that in mind, here's how those value props stack up:

Let's unpack the most prevalent ones:

Ease of use: This value presented in a number of ways. For example, players of Monopoly Ultimate Banking expressed a lot of confusion around the order they were supposed to swipe fake credit cards in order to facilitate a transaction. Monopoly Voice Banking players couldn't get the device to recognize verbal commands. Still others really enjoyed the speed of sending payments via an app.
Aesthetics: Players really like their game to look good. They tend to bristle at game pieces made of "cheap" plastic or an app interface that's geometrically too simple, colorless or missing white space.
Preserved classic feel: A recurring complaint was that several of these electronic products forced different rules or changed the aesthetics of the game to the point of making it too different from what a customer grew up playing.

Rumblings in game board forums also surfaced parental frustration with how these electronic versions spoil the educational aspect that holding and counting money, fake as it is, has for children.

I have grouped these product reviews by their value proposition here below (this looks best on desktop):

Iteration 2: Sketch the idea

At this 2nd iteration, we have a lot of assumptions about what our customers want. To start building a prototype, even when the cost to do so is cheap thanks to tools like Bubble or Webflow, would be a costly mistake. That's because it's even cheaper to hand draw a rudimentary version of our idea to ask potential customers about it. A mentor of mine put it this way:

The simpler these initial designs are, the more likely you are to get honest feedback. People tend be nice so the moment they see a polished design, something they know you've spent a lot of effort making, they'll be more likely to compliment than to criticize at the risk of hurting your feelings.

So keep it simple.

As for Venmonopoly's initial sketches, the stakes are low and the customer familiar enough (this product is partially for me, after all) that I jumped straight to crude digital mockups for a money transfer app. Here's the very first:

A vision is born

I kept iterating the design until it included an answer for each major value proposition discovered in our first pass of the Build, Measure, Learn loop. For example, the above became a two panel interface like this:

Payment Flow

This design tries to address eight value propositions:

Users can plainly see their balance.
It preserves a classic Monopoly feel: Instead of having a traditional dial pad as one sees on a phone or calculator app, I opted to recreate buttons in the form of classic Monopoly money which are pressed to "ring-up" the amount a player sends or requests from another.
Retains an educational aspect: Making the dial buttons look and behave like money requires players to do the mental math they would to transact physical bills. In this way, younger players can still improve on arithmetic while gaining exposure to something equally educational: digital finance.
Is available across multiple phones.
Supports up to 8 players (rather than the maximum of 4 found in other products).
Has ample whitespace to accommodate longer player first names without truncation.
Allows players to customize their avatar color.
Is pretty to look at.

Here are a few other screenshots:

Iteration 2: Measure & Learn

Design in hand, I asked friends and family for feedback. They said the design was Fun and Looks good. From an app discovery point of view, they suggested to make this product available in an app store rather than distributed as a web app since it would be easier for them to find. There was also a desire for "Pass & Play"... which is a way for a family to use the app without needing a phone for each player (especially younger ones). Look at us, we're learning!

Iteration 3: Build a usable alpha version

At this point in our journey, we've seen what customers like and dislike about electronic Monopoly games. We've also heard real prospective customers tell us what they think about our imaginary product. Since my goal in making this app (for now) is less to sell it, and more to document the Build, Measure, Learn loop, I found it appropriate to dive right into making a functional prototype here in iteration 3. That's my choice but...

In practice, creating a functional prototype at this stage is premature. We've only engaged customers once! And while friends and family can be a gut check for initial ideas, they're often not a good proxy of our ideal customer. This is the moment to validate assumptions by talking to at least 20 qualified customers. Twenty because if you can find that many folks who value the same propositions, then there's a decent chance you're working on the right problem. Of course, the opposite is also true. So to find these early adopters, I like to follow Rocket Reach founder Amit Shanbhag's playbook:

Make a simple webpage with two things: Your value proposition, and a “sign up” button. E.g. “Yoga on demand, for $12/month subscription — sign up below”. When they sign up, tell them they're in a waiting list, and they would receive an invite when the product is ready. I also like to share a Calendly link so they can schedule a customer discovery meeting with me.
Bring users to the landing page with Google Ads. Setting up and paying for a targeted one month long ad campaign takes a lot less effort than cold calling over the same period. Doing this also allows us to test signup rates for different ideas simultaneously.

This way we don't have to build an actual product — just a landing page. And we can cheaply discard or pivot away from products few people are interested in.

Back to our app - if it's not validated, then why build it? Well... I also wanted to make a public demonstration of Bubble. I've received a lot of push back from traditional software developers about using low-code tools because of a belief that no real Internet product can be built on something that wasn't hand-coded at great expense. To that claim, I am pleased to introduce the world to Venmonopoly, a Bubble app built in 4 weeks:

App summary

Landing page is simple and to the point:

Starting a new game is easy:

Payments are made in seconds:

Succumbing to bankruptcy is sad but cute:

Advertisements aim to be useful but unintrusive:

An unexpected find: Monopoly's Universal Basic Income

I realized that endgame performance cannot be calculated without considering income from the Bank. It turns out there are two substantial bank related transfers without which Monopoly doesn't exist:

The initial, no questions asked $1,500 deposit every player gets at the start of a game.
Subsequent $200 deposits every time a player passes go (even if they previously went to jail).

I find it interesting that a game from 1901, made to illustrate the tyranny of unbridled capitalism would include, in its core, a form of universal basic income. We are unable to start playing the game without a handout. And it is by these handouts that we come to build houses, hotels and thriving rental businesses. Curious.

Iteration 3: Measure & Learn

I have launched Venmonopoly in open alpha for this 3rd round of feedback. This means it's good enough for playing with Monopoly but un-validated enough that I want to hear how it can be improved. It has some issues but nothing I've seen ruin a game. In this state, it doesn't:

Have Pass-and-Play functionality.
Allow you to self bankrupt. Instead an opponent must first request more funds than you own in order to present the opportunity for bankruptcy.
Display lifetime stats. Instead it only shows previous game stats.

You can check it out and leave a review at venmonopoly.com

At this point, I do want to share that there were a few things I really wanted to build but intentionally left out of version 1:

A tournament mode for making it easy for anyone to connect with other Monopoly players to play for fun or wagers.
A token shop where people can create and order custom 3d printed gameboard tokens they can play with.
A crypto mode where players can raise the stakes by placing real money transactions on something like the Stellar network.

No customer has asked for these but I think these value propositions create something new and exciting for the gaming community. On the other hand, maybe no one actually cares. It's a lot cheaper to defer implementation until justified by customers. For my part, Venmonopoly users can easily signal interest in the tournaments feature by wait-listing it in the menu tab.

Starting up, Lean.

So that's three cycles through the Build, Measure, Learn loop. I suppose, in truth, it's more like 2 and 2/3rd cycles... But that's okay, the salient point is there's a systematic way of discovering and creating products people want to use. By making inexpensive mockups, prototypes and tests, one can more quickly validate or invalidate critical assumptions than if we were to just build it all without constant feedback. The confirmations we're after do not come from a group of detached office managers, but from the real world people we seek to serve.

Our path is as Kevin Kelly, the founding editor of Wired magazine, once told us:

To make something good, just do it. To make something great, just re-do it, re-do it, re-do it. The secret to making fine things is in remaking them.

Now go and make something fine! And remember, I'm available for hire Get in touch here.