Dogfooding: Why SaaS Teams Should Use Their Own Product

Does the term ‘dogfooding’ make you think of testing a software product you’re developing on your own employees, before it goes to market? If you don’t make that connection, it’s understandable.

What is dogfooding?

Software engineers adopted the term to describe acting as your own customer during software development. The label stayed in use, and today in the SaaS era, dogfooding is relevant and valuable. Here at Frontegg, we’ve used dogfooding since our company’s inception, and never regretted it. The practice of dogfooding has paid steady dividends, helping to strengthen our product and company.

Dogfooding provides test users—your own business—months before early beta and reference customers. At Frontegg, dogfooding has been an important aspect of our shift-left practices, and our experience might provide helpful lessons. Below, we give seven good reasons to dogfood, plus some practical Do & Don’t advice based on how dogfooding has worked here at Frontegg. 

How does dogfooding work?

Our founding team, along with other colleagues and me, had leveraged dogfooding before Frontegg. We understood its advantages, and were already sold on it. We made it part of our approach to business. That would be true even if we were in a different industry.

If we ran a clothing store, our team would wear the actual merchandise and provide feedback.  At Frontegg, to build the best software product possible, we set out to optimize our use of dogfooding. We knew that getting it right would improve the results and make for happier customers. 

For starters, Frontegg closely resembles many of our customers; like them, we deliver a SaaS product. We treat Frontegg as we treat all other customers. That’s baked into our company culture.

Users within Frontegg see exactly what any customer sees, and use the same integration and features. To ensure this, we invested resources to separate the customer side of the Frontegg platform from the infrastructure side. Our internal users have no back door to look behind the UI and see the Frontegg code, so they have the same experience as real customers. 

Pretty quickly, most Frontegg departments become active users, including Product Marketing, Sales and Customer Success. Our employees deliver a consistent daily flow of feedback about the product, via a dedicated Slack channel where everyone can chime in. 

7 reasons you should dogfood

Engineering and product companies in particular can take advantage of dogfooding. Here are seven reasons that support your business case for the practice:

1. Catch and fix issues early. Intercept issues before they become problems in a sales demo, or create problems for your customers in actual production usage. This improves the quality of your product, and in the end will reduce customer complaints. For example, at Frontegg we use our Entitlements Engine to handle subscription plans and permissions enforcement for our own products. By continually validating its performance, we are confident the Engine provides our customers with the secure user permissions they need.
   
2. Get direct feedback ASAP. Dogfooding is the earliest feedback on product performance we can get from actual users. It’s very beneficial in identifying areas for improvement, and helps confirm or tune our prioritization of features and functionality.
   
   In one instance, Frontegg decided to facelift the important Roles and Permissions component in our platform after internal users recommended improvements.  We validated their opinion with alpha customers, then decided on this major move. In our view, it was best to handle it prior to the public release of our first version.
   
3. Understand your product better. By listening to users, we learn more about the features, functionality, and limitations of the solution we built, at a deep level. It also ensures the product meets the needs of target users. Dogfood-stage users can even discover unanticipated benefits. For example, Frontegg’s sales team uses the new Entitlements Engine to grant customers access to premium features.
   
4. Instill a company-wide discipline of product ownership. Frontegg, like other software vendors focused on excellence, considers an internal culture of quality to be essential. Dogfooding is a powerful complement to this key building block. When our employees use and rely on the products and tools they sell and support, their ownership and personal commitment go up to new levels.
   
5. Test real-world scenarios: Dogfooding surfaces issues that only reveal themselves with “real users” – this boosts reliability in both normal and outlier situations. For example,  we internally deployed the different security features delivered in our flagship commercial solution. We rely on these critical functions in our own day-to-day operations, so they are continually validated and evaluated in real life. 
   
6. Save time and resources: Early catch-and-fix of bugs with dogfooding does more than accelerate go-to-market. It saves Frontegg both time and money, and boosts our efficiency. Dogfooding is a strong element of shift-left practices.
   
7. Gain a competitive edge: Companies that dogfood end up with better products—and they usually get to the product launch faster. For instance, at Frontegg and organizations where our teams worked previously, we have seen ongoing awareness of product features and performance lead to accurate product improvements and faster launch readiness.

Some precautions to consider

There are several considerations to keep in mind when analyzing the findings that your dogfood contributors—internal users—share with you. 

• Single-customer perspective. At Frontegg, we take our own feedback with a grain of salt. Our internal feedback carries weight, but we humbly accept that it is the viewpoint of just one customer (us).
  
• Unique class of users. In one respect, Frontegg is an outlier customer for the Frontegg platform, like other software development companies are for their own products. This is because we have watched the solution evolve, and some of us know every feature. In a sense, our users might know too much. Having used multiple versions, they could overrate features that address specific Frontegg needs, but are less relevant to most customers.
  
• Bias and blind spots.  Without question, our internal users are familiar with our product and could miss usability gaps that would frustrate new customers. Our employees might easily skip around a workflow obstacle, not realizing it would frustrate a first-time user. This explains why we rely on them exclusively to evaluate the UI, and of course we complement them with outsiders. 

Internal users might not recognize how important a specific capability is for the broader target market. At Frontegg, we have an advantage; we are developers, and our target customers are developers. We closely resemble our real-world customers.

But what if your customer is not like you? If your product serves healthcare companies, focus on how they–not you–would use the system. Strong opinions from your employees could unintentionally nudge the product to match your internal use cases, rather than healthcare firms. 

Dogfooding is not a fit for every organization. It might not make sense for your company if you develop software to operate oil rigs, unless you have internal users who actually are rig operators. 

In this kind of situation, software developers can collaborate with a strong design partner to get end-user perspective. In early stages of product development, the design partner comes closer to being an internal user than any alternative. 

Conclusion 

I should point out that dogfooding is a continuous, ongoing evaluation of your software, not a one-time event. We regularly reevaluate, adapt, and align the Frontegg roadmap—frequently using feedback from our users.

We encourage feedback, but dogfooding is not always obligatory. Some features may not be important enough outside Frontegg for us to insist on feedback. The goal is to deliver the best software, not to be champion dogfooders. 

Carried out properly, dogfooding leads to happier customers, better products, reduced costs, and fewer development risks. Our team finds it fits in naturally with modern approaches to SaaS development that include continuous delivery and early testing. Like most software developers, we are eager for fast feedback, not just by synthetic testing, but from a real customer. And often the most available, candid, and committed real customer that you can access is YOU.