Run a thought experiment with us: Think of some of your favorite software products that you use regularly.
Maybe it’s Figma. Airtable. Notion. Bubble.
Would your opinion of those products change if you found out that the company's teams didn’t use their products internally?
We certainly think so. If Notion used Google Docs for their company's Wiki instead of Notion, that'd be a bit suspicious. If Figma employees didn’t even use Figma for their own design needs, their marketing would feel unconvincing.
Enter: dogfooding.
What is Dogfooding?
“Dogfooding” refers to the practice of using your own company’s product internally, and it’s commonly used in the software and technology industries.
Surprisingly, though, the term didn’t originate in tech. Instead, it originated with, well … dog food.
In the late 1970’s, popular television commercials for Alpo dog food featured spokesperson Lorne Greene claiming that he fed Alpo to his own dogs. In time, the phrase “eating your own dogfood” became a metaphor for using the products you were promoting.
The jump to the technology world came soon after, when then-President of Apple Michael Scott sent a memo banning typewriters in their offices in favor of their newest product, the “Apple II-Apple Writer Systems.”
Microsoft was similarly aggressive in using its own products, and since then, the idea of dogfooding has become associated with technology development.
But enough history lessons — let’s take a look at what dogfooding looks like today, why it matters, and how to integrate it into your own product testing and development processes.
How can a company use dogfooding to its advantage?
Creating strong marketing is just one benefit of dogfooding. Done well, dogfooding as a practice can help a company significantly improve its product — if it’s not done superficially. This is not the same as Coca-Cola banning Pepsi products in the office, or a clothing store requiring its employees to only wear its brand.
Instead, teams who dogfood effectively increase internal usage of their product to speed up beta testing and generate significant internal feedback on the product. This allows you to iterate faster and more effectively, and quickly make your product better.
It’s not always practical for every company to use its own product, but there are plenty of areas where dogfooding can still create meaningful advantages, especially within tech. Here are two real-life situations of dogfooding that you can steal or take inspiration from for dogfooding your company’s products.
1. Dogfooding your own website
For many tech companies, dogfooding your own website is a great place to start. We do this here at Bubble: Everything on our website but the editor is built on Bubble. This puts our internal team of Bubble Developers in the perfect position to test, iterate, and request new features.Early in Bubble’s development, we knew that we wanted to give people the freedom and ability to build multi-page web apps and match the design quality of more limited but “landing page”-centric website builders like Wix or Squarespace. Building our own web app on our platform acted as a “forcing function” to make sure we had all the features and functionality available to make our website competitive with other platforms.
Bubble’s website is one of the larger and more complex apps we’ve created at Bubble using our own platform. By building it on Bubble, we can iterate faster on new features and pages, as well as empower our own developers to build our site without writing code.
A perfect example of this is the Ideaboard, a page on Bubble’s main website where users can submit, upvote, and discuss ideas for product improvements. VP of Product (and one of the original creators of the Ideaboard) Allen Yang says the concept isn’t unique to Bubble, but the team built it themselves because “it’s a perfect use case for Bubble!” In fact, the first version came together in just a few days. This was a huge plus, says Allen, because it shows “how much Bubble helps you develop ideas very quickly.” The initial capabilities were fairly basic: users could submit and upvote ideas and Bubble team members could moderate submissions.
Today, Allen says that the Ideaboard is a great source for feedback and ideas for the Product team as they work through what to prioritize on the roadmap. And the fact that it’s built on Bubble gives the team a ton of flexibility they might not have if they’d used a different service to build it.
“[We] set up our own moderation system tailored to the content and to the needs of our community,” explains Allen. “We can start simple and evolve as needs change… You can imagine different new ways we could integrate the Ideaboard more deeply into other parts of the product experience to make it even smoother for our users.”
Want to learn more about how we do it? Check out our internal developers’ masterclass on How Bubble Builds Bubble for Scale.
2. Dogfooding products as custom internal tools
For many tech companies, using your own product as part of your own internal tech stack is the easiest and most effective way to dogfood. For example:
- Clickup should use Clickup for their own internal project management
- Uber employees should regularly use Uber to get to and from the office
- Slack should use Slack for their internal messaging system
…and so on, all the way back to Apple using their own word-processing system instead of typewriters.
At Bubble, we use several internal tools built on our own platform. Because the Bubble site is hosted on Bubble, our non-developer team needed an easy way to make updates to sites like the employee directory, Showcase page, or support articles in an easy-to-manage, central location. Enter: Bubble’s internal Content Admin tool.
Building the tool on Bubble was a “no-brainer,” according to Bubble Developer Maria Posa. The Content Admin lets Bubble employees “safely manipulate some data in our app by providing a simpler interface and safety guardrails.” Because it’s built on Bubble, it also incorporates some more complex logic when CRUD (Create, Read, Update, and Delete) functionality isn’t enough.
The Content Admin covers a huge range of, well, content. On the simpler side, the People team has a page that allows them to add, edit, and delete employee records as part of the onboarding process.
On the more complex side, the Marketing team can edit announcement banners to display important info about upcoming events and feature releases. “But it also automates logic like publishing in the future, showing the banner on specific pages, and allowing users to dismiss it a certain number of times,” adds Maria.
Your entire product may not make sense to use internally — but it’s likely that there are features of it that your team could be using regularly for testing and feedback.
For example, a company like Loom may not want to replace all of their meetings with Loom videos. But, they could (and do!) use Loom features in interesting ways throughout their workflows, such as using Loom to record explainers for their blog or managing sales outreach with custom Loom messages. Implementing a variety of use cases for your product internally first gives you a stronger understanding of your product’s functionality and a clear way to test for potential inconsistencies.
The bottom line
Starting a dogfooding program with your own products has so many benefits:
- Identifying and removing dependency issues
- Creating a more stable version of your product for customers
- Gaining clarity on the needs and goals of your target audience
- Making faster improvements on bugs and other product issues
- Stronger support for your product among internal teams and your organization generally
- More consistent internal quality assurance, since you’ll be using your own product day-in and day-out, and not just waiting on bug reports from users
While it isn’t the answer to every problem in software development, “eating your own dog food” is essential for tech companies that want to iterate quickly and build better products faster. It’s why we’re so committed to building our own website, applications, and products on Bubble.
We’re convinced that no-code tools can be as powerful and customizable as coded solutions. Using them ourselves has allowed us to develop the world we want to see — and that includes a world where makers of all abilities can create tools, apps, and online marketplaces without a single line of code.
No-code makes it easier to design and develop products, and it also makes it easier to dogfood them yourself. Curious how no-code can help you strengthen your product or dogfood your tools for faster, better software work?
