There are almost too many lessons to count that I learned while working on GORanger. Its rise to over 100,000 monthly active users followed by its rapid downfall taught me a lot about product, marketing, engineering, and even mental health.

Today I'd like to take you through GORanger's history and talk about the most important takeaways that you can use on any project.

So grab your backpack, we're going on a Pokemon product adventure!

Solving pain, literally

GORanger was born because on one sunny Saturday afternoon, I wore the wrong shoes. I had just finished an errand and one of Pokemon GO's many "Community Day" events was about to start. For me, these events often involved 3 hours of brisk walking in downtown Milwaukee with friends.

One of my friends texted me "Dude, where are you? It's about to start." No time to run home and grab my walking shoes like I had planned, I was going to have to do this event in brand new non-broken-in sandals.

Except when I showed up downtown late by about 15 minutes, I was greeted by my friend with a "Whoops, I messed up the timezones again, it doesn't actually start for another 45 minutes."

I walked FOURTEEN MILES in those sandals, my feet hurt so bad. So much so that I decided I was going to make an app that detailed all of the events upcoming and ongoing in Pokemon GO with explicit countdown timers so people knew exactly when events started.

The days of reading the Pokemon GO blog and trying to decipher what geolocation you were in and then converting it to your own timezone were going to be over, all because I wore the wrong shoes.

Solving pain is the absolute most important part of any project.

If you're not solving someones pain, you're not going to be successful. It doesn't have to be foot pain, this is true even for entertainment apps which solve the very real pain of boredom.

And it can't be a "Tylenol level" pain, it has to be something that only a pain reliever as strong as you and your product can solve.

Minimum viable product

You'll hear an MVP called a hundred different names, but no matter what you believe it stands for one thing is true: you shouldn't start with every single feature you can dream up.

What the real definition of an MVP should be is "the bare minimum product that you can create that solves the pain you're trying to solve."

In this case, all I needed was a way for the user to select a Pokemon GO geography (auto detecting based on imaginary geo lines would be too difficult), a way for me to update events in a database, and some countdown timers. Maybe a description of the event so users could determine if they even cared about that specific countdown.

Easy, peasy. I programmed the app up in about a week using the tech stack I knew best at the time, and it took another 3 days for the app to be approved on both iOS and Android. If this idea didn't work out, I was only going to lose 14 days of nights and weekends.

So what's your bare minimum feature set to solve pain? Really question that list, don't overdo it.

Some apps even use something called the "Wizard of Oz Test" before programming, where you manually perform the action for the user. For instance, Uber could have launched an initial version of their service where all they did was call the Taxi company for you in order to determine if the idea would be succesful.

Launch to a community

At the time I launched GORanger, I had already been an active member of the r/PokemonGO community on Reddit (that's important, don't go spamming communities you're not already a part of).

I had also seen other posts where people were complaining about timezones (as developers, we know timezones are hard, mkay). Before I even began programming the app, I made a post where I asked others "What do you look up frequently?".

Now notice, I didn't ask "What features do you want?" I specifically wanted to know what potential users already valued enough (felt enough pain) to want to look up answers.

There were some good ideas in there, and a fair amount of upvotes and replies, so let's continue programming.

On Day 14, I posted my app to r/PokemonGO. Over 2000 upvotes and 500 comments came pouring in!

By solving for a real pain, in a real community (a target demographic that was large enough), my app had already been set up for success in the smallest amount of time possible.

40,000 users in 2 days

"Hey, I love your app!" someone from across the street in Milwaukee's Third Ward yelled through cupped hands in my direction. They had noticed my bright red GORanger T-Shirt.

And while "people in downtown Milwaukee" weren't my target demographic, people in the Third Ward Pokemon GO hotspot between the hours of 1pm and 3pm CST on this Saturday (thanks GORanger!) absolutely were.

The best kind of Marketing isn't paid ads or any other gimmicks, it's creating something so valuable to a very niche group of users that one of them will yell across the street at you to thank you.

This avid Pokemon GO trainer was just one of over 40,000 users that had downloaded and used my application in the two days that followed that Reddit post, causing GORanger to be the #6 trending app on all of Google Play. I rode the high for a few hours as I caught as many shiny Pokemon as I could (in walking shoes that didn't hurt my feet).

Then I got back to work. A launch always feels good, but inevitably not all launch users stick around and become long term users of your product. After a few days the dust settled with around 7000 daily users sticking around.

So how did I get up to 100,000 users? Well, I didn't stop there, I kept making new features that people would yell across the street about and share with their friends.

The "evolution" of new features

(See what I did there?)

While making events and timezones easier to understand for Pokemon GO players was a big pain, there were countless others that the Pokemon GO community felt and yearned to be solved.

What you want to look for in most feature requests is one thing: the underlying pain that the user feels. It's not always what the user asks for that is important, but the pain they feel. It's then up to you as a creative product engineer to solve for that pain in a way that makes the most sense on behalf of the user.

One of the easiest ways to find things like this is to look for pains that people are already solving in less effective ways that you could make much much easier.

In the Pokemon GO community two of the biggest things that were already popular were: Raid Boss infographics (literal images of the best Pokemon to use to beat specific bosses) and Excel Spreadsheets of available Pokemon that you could check off as you caught them.

Every time there was a new raid boss or a new spreadsheet, you had to go find your favorite creator, wait for them to make a post, and then download the image to your phone for later use, which is now somewhere in your Photos app. The same Photos app that gets polluted by your Pokemon GO camera pictures. Great.

Not to mention, both of these things involved a complete lack of customization. What if the infographic author only included the best 6 Pokemon and you only have the 7th? What if the checklist didn't have the specific collection that you were tracking, like my daughers purple shiny collection?

So not only were these pains being solved ineffectively, there was room for new feature development that only something dynamic like an app could provide.

GORanger continued to find and solve pains like these for trainers around the world and ultimately wound up with a robust feature set of things like:

• A central view for all currently active bonuses, so users don't even have to look at each event
• Completely custom checklists, so users can track their unique wants
• A Pokedex that allowed people to look up possible moves before wasting move changing items
• A Player-vs-Player type coverage checker, to see what kinds of Pokemon you might lose to

Notice that I included each specific pain with the feature, because verbalizing what your features do to solve your users pain is one of the most effective marketing tactics.

Some pains (like users not having to look at each event) will actually be caused by your product, but good news, you can fix those too!

Monetization

After a few months of constant feature development and around 100,000 monthly active users, it was time to begin monetizing the application.

I always knew this would be a mostly free consumer app from the get-go, but I did need to make sure that I was getting "paid back" for all the time I was investing into the application. Especially when that time was time taken away from nights and weekends with the family.

While monitization strategy is way too long of a topic to go over in depth in this post, it's common knowledge that one of the usual ways to monetize a free app is with advertising. In this case, I decided to embed Google Ads. With the amount of monthly active users my app had, I began bringing in roughly $1500/m in advertising revenue.

And with most apps that come with ads, the next thing you program is a paid plan to remove Ads from the application. As GORanger required constant effort to add and modify data (as opposed to traditional SaaS which doesn't require timely data entry), I decided that instead of a one-time payment, this would be a monthly $3 charge.

I also included the ability to create an account and backup your checklists to the cloud with the paid plan. The reason I chose that specific thing as a paid feature is that it wasn't as painful or valuable to every single user, so I would be charging people with very specific requirements instead of trying to monetize all free users. This is a great strategy for all freemium apps.

In general, this didn't bring in as much money as advertisements (around $1000/m), but it was definitely a welcomed addition to the feature set for diehard users.

For those doing the math, that's roughly $30,000/year on a side-project. Had the project not met its demise (more on that later), I most likely could have doubled or tripled this number with continued effort.

The great refactor

Ah the thing that us developers dread (love?) the most, a good old fashioned refactor! Or in this case, a complete rebuild from the ground up. The simpler new pains were beginning to dwindle, and it was on to much more complicated problems.

Problems that required me to step back and take a good look at the application and how it was programmed. Now that it had a significant number of users, I didn't want it to be merely "good," I wanted it to be great.

While I knew this rebuild would take me some time, I decided that the best way to do it without making any mistakes (read: not solving pain well enough for my users) would be to build it in public.

Every time I finished a new part of the app I'd post to Twitter/X with a video of the feature in action to see how much feedback it would get or if I needed to make any changes because something was too confusing. I'd even use Twitter polls to solicit feedback live while programming. Here are some examples:

Overall what I really wanted to get out of this refactor was the satisfaction of building something amazing, but only after I had ensured that the project had legs first.

Building something amazing in the first place often leads to an extremely large amount of wasted effort. I've been burned in the past by building something amazing that no one actually wanted.

Life used Tackle, it was Super Effective!

Sadly, this story doesn't have a happy ending...well, it does for me, but not for GORanger. While you probably read a lot of excitement in the above, what I left out is that the entire time I was dealing with intermittent episodes of major depression.

I found myself in the doctors office only a week after launching GORanger crying to the nurse that I felt horrible for no reason at all, in fact, I felt like I "should be happy" given my recent successes.

Ultimately, during a depression episode, I just stopped working on GORanger. Google Play once again removed the app from the store (I was accidentally using the YouTube API incorrectly). COVID hit. And I just didn't have the energy to keep updating the app or even to finish the rebuild. To the community, I apologize, but I had to take care of myself first, I hope you understand.

(If you're suffering from depression, please utilize resources like SAMHSA's National Helpline to receive the help you need.)

For the past 5 years I've gone through various medications and treatments, and I've finally found something that has been working for me. I feel good!

And thus, TripleThreat.dev was born: my first real project since the days that stranger yelled "Love your app!"

In retro ... I wouldn't change anything. I got help when I needed to, and I'm much happier now.

Until next time,