Or: How we use Gleap to build Gleap. In my last blog post I gave you a brief introduction into the practice of dogfooding in software testing, and promised you insights into how we dogfood. At Gleap we like to keep our promises so here goes. In this post we’re going to take a deep dive into how we use Gleap to build Gleap.
If done the right way, dogfooding can be immensely helpful to improve one’s own product. We believe that the practice of alpha testing or dogfooding is highly cost and time efficient, we consider it a reality check, and we speak from experience when we say that it is very humbling. The benefits of dogfooding can best be illustrated using a prominent example showcasing what happens if you don’t dogfood.
Let’s have a look at Facebook’s Android problems. Most of Facebook’s team were iPhone users, which led to the fact that Facebook’s Android app was mostly unattended to and used to look awful. The management at Facebook gave out a corporate directive for some of its employees to replace their iPhones with Android phones. Their employees then had to deal with the problems of the Android app daily and eventually fixed it.
At Gleap we focus on one thing, and one thing only: making developers’ lives easier by helping them fix bugs real fast with standardized bug reports. Gleap was developed by developers for developers. This means that our internal use case and the intended purpose of our tool are the exact same. We therefore figured that Gleap is a perfect fit for dogfooding.
To get the most valuable feedback when dogfooding, it is important that you distribute your software, be it an app, a website or any other tool, to testers that come as close to your target market as possible. So, if you don’t have any use for your product internally, dogfooding might not be as insightful or it might not make any sense at all.
Once you’ve decided whether using the practice of dogfooding is a good fit for your case, the next step is to figure out in which phase of the development lifecycle to introduce it. Generally speaking, there are 3 common phases in which dogfooding your product makes total sense.
Since we consider Gleap such an amazing fit for dogfooding, we follow the premise of continuous testing. The software agency we run permanently uses Gleap in their work with customers, allowing us to get both insights from clients and developers as users. Additionally, our Gleap developers dogfood Gleap every time we release new features.
Our number one priority is to keep gleap simple. We do that by focusing on the essential and making it fast and easy to use. In this area we generated three main learnings while dogfooding. First, documentation is key. The more straight forward the documentation, the easier for Gleap users to integrate and customize our tool. Second, onboarding has to be quick and easy, yet safe. Dogfooding our onboarding process showed us two major results: we need to introduce Google sign-in and we need to make reporting a user’s first bug easier as well as more intuitive. So we implemented those features. Finally, we learned that keeping the Gleap dashboard real simple and rather focusing on good integrations was our way to go. After all, we’re not a project management tool.
Keeping Gleap simple also entails keeping our pricing fair by preventing bloated plans. Dogfooding Gleap, we found that it would be amazing to have agency plans. In other words to allow users to add multiple projects to their plan without having to upgrade. We then went and adapted our pricing models accordingly.
Dogfooding is always a good idea if you want your product to be and most of all to remain cutting edge. Along the way, we’ve learned that dogfooding does however only really work if, and only if, your own employees in this case acting as testers make sure that they keep track of all their bug reports and feature requests in an organized place and manner. Bug reports and feature requests will be the main kinds of information you’ll get out of dogfooding. Obviously, we used Gleap to manage the whole process.