Op-Ed: What We Learned Launching An App and Finding Product/Market Fit

Here's an inside look at our first-hand experience launching an app and applying the validated learning principle.

Prev2 of 2Next
Use your ← → (arrow) keys to browse

First of all, feedback from non-paying users is different from that of paying users. So don’t be misguided during the early stages of product development. You can learn more about product pricing principles in this awesome article by Intercom.

Secondly, we’ve already noticed other developers packing tools with useless features, endless pivoting — and even worse — products launched only for the team to realize that users simply don’t need them. Obviously, we didn’t want to go through any of that.

Besides, as a lean startup, we couldn’t afford to waste a fortune on building dozens of app versions to test the concept. Instead, we chose to use thorough and detailed analytical data to learn what our customers really needed.

We needed to quickly understand what our paying users liked and disliked. Was the main app concept popular with paying users? What features did they use the most (and the least)? How did they behave while browsing the app?

So for our first analytics option, we considered KISSmetrics (which we’d already used for a prior consulting project). But when we checked the pricing, our mood was swayed. At the time, they offered a starter package for $150 per month. (I don’t know about you, but for our newly born startup it was a heck of a sum to take out of pocket monthly).

In search of more startup budget friendly alternatives, we decided to start small and try Google Event Tracking. It has its limitations, but it is free and worth trying. Unlike general Google Analytics, Event Tracking requires a bit more effort (i.e., writing custom code, etc.) Search Engine Land share a nice Event Tracking 101 article, to help familiarize you with the basics.

First, we created a Google Spreadsheet to list all metrics (events) we wanted to track. Our initial list included 60 events, but we decided to test the most important ones first and see how the whole thing worked. The entire process from brainstorming to  integration took 22 hours.

Since setup, we’ve received tons of helpful customer behavior data. After examining the results, we learned the features and functionality we thought would be useful are, in fact, underrated by customers.

Don’t get me wrong! We didn’t quickly depreciate functionality right after viewing the new stats. Every time we think about removing a feature, we make a list of people who have ever used it and send a letter with a detailed explanations asking for feedback.

Thanks to the priceless data we receive, we have an opportunity to understand what app features are actually used and what should be reconsidered. We can then make deliberated decisions based on actual numbers instead of intuition. Besides, stats act as a perfect foundation for prioritizing tasks for every update. As I see it, having first-hand knowledge of customer behavior is the most important criterion for success. Google Event Tracking was a real help here.


Supporting and Validating New Ideas

Ultimately, I learned that nothing beats data. It’s funny to watch how, at first, a feature seems extremely vital yet after finally removing it, you realize the app feels much better without it. Besides, it helps to remind yourself that every product feature should be supported and tested.

No matter how strong your gut feeling is, I highly recommend using actual stats to analyzing your product and learn more about your customers. Then you can truly improve what is important and get rid of what is useless.

This articles has been edited and condensed.


Mike Kulakov is the Founder and CEO of Everhour, a startup offering a time tracking and reporting solution for data driven teams. Connect with @everhour on Twitter.

Prev2 of 2Next
Use your ← → (arrow) keys to browse

© YFS Magazine. All Rights Reserved. Copying prohibited. All material is protected by U.S. and international copyright laws. Unauthorized reproduction or distribution of this material is prohibited. Sharing of this material under Attribution-NonCommercial-NoDerivatives 4.0 International terms, listed here, is permitted.


In this article