Photo by Design Wala on Unsplash
It’s a truism of all cloud SaaS companies that we should run our businesses on our own technology. After all, if this technology is so valuable and innovative that customers with dozens of existing vendors, tools and processes need to adopt the new offering, shouldn’t the startup use it internally as well? It also seems obvious that a new company should reality check the value it’s claiming to provide to the industry by seeing it first-hand, and that any major gaps should ideally be experienced first by the home team rather than inflicting these on customers.
Sometimes it’s easier said than done.
It can be surprising how difficult this sometimes turns out to be for new companies.
When the technical and product teams focus on the ideal customer profile and likely user, it’s not always the case that these match the startup’s internal situation. Very often, the intended user is really part of a larger team that interacts with other teams in a complex set of processes and relationships, and the realistic environment that the new product will face is far larger and more diverse than anything a startup would have internally. This makes it difficult to apply the new technology in a meaningful way and can also make the value proposition less obvious.
For example, if a major claim of the innovation is to simplify complex, manual or legacy processes, or to reduce wasteful spending through optimization, these benefits may be less obvious in a smaller/newer company environment. As a result, the “eat your own dogfood” claim may be just a marketing slogan without real meaning.
And then there’s the other truism to consider: the cobbler’s children often have no shoes. When a startup is running fast and focused on building innovation – with a small team that prioritizes the core value of a new product and customer engagement over any internal efforts – it’s easy to push off eating your own dogfood for another day. Ironically, if there are challenges in using the product internally, these may not be seen as the highest priority to fix or improve, vs. the urgent customer-facing ones that are tied to adoption and revenue. It’s always easy to say, “Well, customers haven’t seen these issues yet, so it’s probably ok for now.”
But, in fact, this is at the heart of the innovation process.
No one cares more about your product than the team that built it. You’re always challenging yourself:
Is it really easy to use?
Does it work reliably
Where are the hidden “gotchas”?
But for a breakthrough new product, this isn’t enough.
As your earliest design partners start testing the product in their environments, it’s equally important to consider how you will use it internally as well. This is not just about testing for bugs or functionality as you build your software development processes. It’s about becoming the user in every way possible and seeing the product through their eyes and daily jobs.
The world can look quite different from this viewpoint. Using the product internally raises the bar higher than responding to customer feedback or watching them during usability testing. It gives you a direct, visceral reaction to your own product:
Does it delight you as a user?
Would you use it on a daily basis?
Does it make your job easier?
Does it provide value that’s beyond other products you’re currently using?
Even if your company is not a perfect match with your ICP and your employees are not the typical users, you can still learn a great deal. For example:
- Do a job that your customer would do, from end to end, and see whether the product made your work easier/better.
- Show someone else in your company (who’s less familiar with the product) an output from the product and ask if this was helpful and understandable.
- Think of what you’d want your product to do next if you were a paying customer and considering a renewal.
At Causely, we decided early on that a high priority was to run “Causely on Causely.” Since we are developing our own SaaS application (which of course is not nearly as complex or mature as our customers’ application environments, but still has many of the same potential cloud-native problems and failure scenarios), we also need to troubleshoot when things go wrong. So we wanted to make sure that Causely would automatically identify our own emerging issues, root cause them correctly, remediate them faster and prevent end-user impact. We judge our progress based on whether WE would find this compelling and validate the claims we are making to customers, such as enabling them to have healthier, more resilient applications without human troubleshooting.
As a team, this requires us to discuss our own experiences as a customer and makes it easier to imagine the experiences of larger, inter-connected teams of users running massive applications at scale. Eating our own dogfood helps us improve the product so it’s easier to use, more understandable and reliable. And it has laid the foundation for how we will develop and operate our own applications as we scale. Of course eating your own dogfood is not a substitute for all other required approaches to testing and improving the product, but it’s a critical element in a startup’s development that should be hard-wired into company culture.
I would love to hear about other founders’ dog-fooding experiences and what’s worked well (or not) as you build your products. Please share!
Related resources
- Read the blog: Don’t forget these 3 things when starting a cloud venture
- See Causely in action: Request a demo