August 8, 2014 - No Comments!

If you can’t solve it on paper, you’ll never solve it with software.

People love computing power. And why wouldn’t we? Computers solve a lot of problems for us — every day. In fact, smart phones, apps and search engines do so much for us, it’s easy to take this information processing for granted.

Did you know?

  • Every two minutes, we take as many photos as all of humanity took during the 1800s.
  • There is more processing power in a TI-83 calculator than in the computer than landed Apollo 11 on the moon.
  • Most devices advertised in this 1991 Radio Shack ad exist today as one single smart phone.

I know, I know. Your minds are blown.

See? Computers do a lot of things we used to do for ourselves. But that doesn’t necessarily mean that investing hundreds of thousands of dollars in tech will solve a problem that you can’t even solve on paper.

For the sake of argument, let’s just say you are the type of person that uses a TI-83 to calculate the simplest math problems. Now, let’s see how good your calculator is at solving word problems. Shall we?

A man, who charges his clients $125 per hour, buys a TI-83 calculator at a store for $90. He spends four hours reading the manual before he is comfortable enough to enter a math equation (2+2=?). What is the difference between the man with the TI-83 and a third grader with a $.50 No 2 pencil and a $.25 piece of notebook paper if they arrive at the same result?

Ok, so now that I have half of you busy solving that problem, let’s talk a bit about what I mean by “paper.” Paper is a term I like to use when I’m trying to avoid the “minimum viable product” buzzword. It’s what product developers would call, “MVP” (extra points for anyone thinking of Yadier Molina every time they hear this acronym) and it should define the easiest thing you can build or do in order to solve a problem.

How do you know when you’ve expended just enough effort to solve a problem? What’s the threshold? How do you know you’re ready to prove viability? Good questions, people.

First, let’s examine an example — it’s a problem one of my clients is trying to solve. Then let’s talk about employing two different models for how to evolve the scope of a solution to this problem over time.

The problem

My client produces large tournament events twice a year with thousands of people in competition with each other. They provide a playing field for competitors. They invite vendors to sell sporting equipment. They staff professional referees to moderate the events. And they even utilize a proprietary tournament bracket system to help tournament competitors answer two fundamental questions:

  1. Where and when am I playing my next match?
  2. How am I ranked in comparison to other competitors?

In my first visit to the tournament floor, I found — just like all of the tournament competitors — answers to the aforementioned questions are not easy to come by. They require a player to walk around the edge of the massive convention area and wait in huddled masses of confused players, reading oversized paper sheets, to locate their position in an unconventionally designed tournament bracket. Thankfully, the bracket system comes with the follwing easy-to-read instructions, so just about anyone can way-find quickly (sarcasm):

1*U7_dHsHgc2pdRxSa1F1RZw

APA’s Bracketology: How to Read Modified Single Elimination Format Brackets

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.”
— E. F. Schumacher

Upon shadowing some players through this process, our product design team wondered how we could best answer those two questions with the added convenience of a reference tool… right in their pockets.

The dry cake solution

cake-filling-icing-2

You TI-83 folks are all probably screaming, “Yeah! iPhone/Android apps! Sweet!” Heck, you might even be onto something. Solving the way-finding problems with software follows a “dry cake” approach that many organizations use to plan out new products and experiences. They start with a basic and uninteresting product — like plain dry cake. Then, as their resources expand, they add new features such as icing or filling.

Heck, it makes sense to build a native app from an operational perspective. Think of all those smartphones that are in peoples’ hands these days just waiting for on-demand tournament bracket information!

But there are problems with this model from both the customer’s viewpoint and from a competitive perspective. Cake with no filling or icing is just about as appealing as software, that can’t get the internet access it requires to operate correctly. It just so happens that the internet infrastructure at large events in 2014 Las Vegas sucks. And even access were available, the software could fail due to a myriad of untestable technical glitches, over-taxation of the server infrastructure, or (god forbid) isn’t accessible because not everyone has access to a smartphone device.

The cupcake solution

cupcake-cake-wedding-cake-2

A better model for planning new experiences is the “cupcake” approach. Start with something small, but very desirable. It has all the appeal of a complete cake — icing and filling, etc. — but its production costs are much lower. People want a complete product, and they’ll pay for it.

Below, you will see the tiny morsel we’ve offered, as a taste-test to twenty lucky players. We call it the “Tourney Journey.” It’s shows of the possible games one might play at the tournament, what round they are in at any given point, and what prize money they’re in store for (if they make it that far). It’s sort of like a choose-your-own-adventure game.

1*umlLST5LUwDsOMcWOyCJ7Q

One day, we’ll probably bake the wedding cake and build an app. But for now, we’re trying to get as many “paper cupcakes” into people’s pockets as we can.

Leave a Reply