Me.me is a meme search engine dedicated to optimizing meme content and making it accessible across multiple platforms. The company originally started in 2014 as a mobile app called Light. Jim Hefner, the CTO describes that app as twitter meets snapchat. Jim says the idea was that people take more photos than they share. So this app allowed them to share more pictures on a public stream and each picture would disappear after an hour. Jim’s two fellow co-founders were looking for an engineer to build their idea out and take it to the app store. Jim became that guy.
Knowing When and Why You’re Build Isn’t Making the Cut
Jim and his co-founders were very metric driven from the beginning. They were big on using analytics. When looking at the stats, their growth curves and usage curves were not compelling.The problem with the app, Light, was an empty room issue. Because photos disappeared after an hour, when users logged in, there would often be little to no content to view. So they spent a lot of time trying to turn that poor growth curve into an okay one by incorporating feature development. They added things like tags, photo filters, location recognition, and even as a last ditch effort during the World Cup, a feature that allowed you to display the running score over your photo. It quickly became a vicious cycle of chasing modest improvements when really they had much larger structural problems.
They created a cut out and sticker feature as a final push called Doublie. It was initially developed as an add-on, but they soon realized that Doublie was its own separate product. It was an app that encouraged people to take more photos and share more often. When they realized this feature was its own app, they then shifted development entirely.
Creating these add-ons for Light involved working on the code base that already existed. But for Doublie, Jim was using a lot of shared libraries. So Doublie became a 75% tear down and rebuild. Doublie ended up getting a write-up in Business Insider and TechCrunch, which generated an influx of traffic. But it still wasn’t enough.
A Great Core Mechanic Creates a Promising Build
You’re always trying to create a baseline for yourself, it’s a constant battle with a rebuild. The core mechanics are the hardest thing to change because it’s the heart of the product that you’ve built. If that core mechanic is not compelling enough on it’s own, then there is no amount of window dressing that is going to fix your more fundamental issues. Jim and his team were getting a lot of installs with Light and Doublie, but it unfortunately didn’t translate to daily active users. This was an indication that there was something fundamentally broken with both apps. This lead Jim and his co-founders to writing a bunch of tutorials. What they found was that the feature set was on the lighter side for both apps. They also realized that they actually used the apps less and less themselves. There wasn’t a definitive reason as to why these apps should be for everyday use. They were more novelty apps.
You’ve Built A Good Product, But Aren’t Getting the Numbers
After Light and Doublie, Jim and his team were at a bit of a crossroads needing to get more numbers. So the three of them started working on independent projects, trying to get MVP’s out the door in a matter of a few days. They would see how many users would take advantage of each app.
One piece of advice that Jim offers is to not pay to have users over time just to boost your numbers. But initially, paying to have a small set of users like Facebook, can be a good thing to get people testing the app. “You can spend $50-$100 and get hundreds of users testing the app out” Jim states. From there, you can improve the app as other users catch word.
Numbers Are Your Best Friend
The numbers show everything. Look at the numbers and let them convince you. With Doublie, Jim and his team even looked into using usertesting.com to get deep insight into what specific aspects of the app people were confused by. It’s all useful information, but if you’re on a budget, it’s not necessary. The biggest thing to have is an analytics framework in the app or on your site. Jim has been pretty happy with google analytics for web. Segment has become his go to for mobile. But he does know that if your growth curve is flat or down then there’s a very serious problem. That’s what it comes down to.
Compelling Aspects of Apps
The biggest aspect people gravitate to is polish. One of the hardest things to do is make the app feel good. Incorporating animation or click actions that feel nice is challenging. Apps that are built natively tend to achieve this much easier. For Doublie, Jim and the other engineer created a navigation feature in the form of a wheel. It allowed them to display a large amount of content very quickly with just a single click. It looked nice and created a smooth experience on that app.
Best Practices to Avoid a Teardown
After building five apps, Jim and his team have learned more about what works and what does not. They are much quicker to discard things these days. If aspects of an app don’t work, they just cut them out. On the flip side, writing code just to be throw away code is almost always problematic. It’s about finding that balance between letting go of attachment to your work and keeping what is needed and what works. It’s about building the most basic aspect that you are convinced will at least work and then building upon that and upgrading as needed.
The best thing to do when you have an idea is to come up with an MVP and then test some aspect of it. For example, if you want to test how often the app is shared then you need to come up with a viable reason to get people to share it. Then run a test case to see how well it performs on that metric in the real world. Early on, Jim and his team had a range of different app ideas. It would be a serious amount of work for a four person team to build out an MVP multiple times. So they came up with a test where they would ask people at career fairs, on the street, or other public areas to take a survey. The survey would show a bunch of features associated with an app. And the feedback Jim and his team were looking for was if after the survey people asked what the app was or where they could get it. Whichever MVP garnered the most interest, that’s the one they would build.
To see the lifetime value of an app, it’s best to look at the timespans. Over at least 30 days, you want to see what percentage of people are coming back everyday and even multiple times a day. The higher the percentage, the much more compelling the product most likely is.
It’s also helpful to start with a basic idea and not overshoot what you think the app needs. Me.me started out of a baseline idea. Jim built out an MVP with the intention of being as automated as possible since they are a small team. They basically started fetching memes automatically, parsing them, and making them searchable. Just the index of the meme content itself proved to be very powerful. Me.me was getting indexed by google. More and more people were using google to search for the memes. Soon enough, the growth curve of this application was the exact opposite of the other apps they had created before. The growth has been sustainable since the start.
The backend of me.me is kept as automated as possible. For instance, the app automatically fetches and discovers new meme sources. It also uses computer vision and a variety of other techniques on the photos. It’s also beneficial having a search box on the site that allows users to search through the vast amount of this content. Finally, human curating and editing are augmented with auto-generated tags.
Overall, tearing down can be a painful process. But excitement for the new project helps bridge that pain significantly. Trying to not get too emotionally invested in a project, going in with a balanced mindset and knowledge that not everything works all the time is the best approach to take.