In 1988 an email titled “Eating our own Dogfood” was sent by Paul Maritz, manager at Microsoft to his colleague Brian Valentine.
Valentine’s was a test manager and as people may guess, the email was encouraging the internal use of their own product. (View Highlight)
Since then the term is used more widely in jest by tech companies creating new products that in many cases solve problems they face themselves, to promote testing and validating what they are building.
Although it may sound obvious to test something you’re building by using it yourself, the philosophy ranges wider than testing your end-product, and can be the difference between good and great products. (View Highlight)
The obvious lessons of “eating your own dogfood” or using your own product are still valuable and worth mentioning.
Whether a tool or product is intended to be consumer facing, for other businesses or to be used internally, using them as an engineer/product owner/designer are valuable for bug testing and exploring the user experience. (View Highlight)
When testing your own product it is normal to be blind to obvious drawbacks by being naturally familiarised with the system you are working on . It is still a good initial step before more rigorous testing with people not accustomed to what you are building.
When I worked in a 5-person team launching a consumer hardware product with an accompanying app, we would test our application by running it with each of our phones.
These simple tests let us efficiently test if new features would work across different smartphone operating systems and phone models. (View Highlight)
For more in-depth testing we would use our product in ways that were less contained and would let us experience our application breaking. While our application was running we would test by:
• Running other apps in the background
• Quitting the app on our phones
• Turning off Bluetooth on our phones
Although these tests would verify that our technology worked with more obscure scenarios, - “eating our own dogfood” also included testing our application for its intended use (which in our case was for assisted mindfulness activities). (View Highlight)
To act as your user is not always to act as your customer, as your customer is only one user.
If you are building a consumer product, your end product is not the only product or system you can test. (View Highlight)
Will Shu, the founder of Deliveroo (UK food delivery app) has said that he still carries out deliveries to test the companies app.
Despite Deliveroo being a consumer facing product, he is testing the user experience for people working for Deliveroo who use the app for carrying out deliveries. (View Highlight)
Shu mentions how as well as testing the app’s functionality and reliability, he arrives at restaurants to pick the food up, and occasionally experiences restaurant staff being rude to him.
Although carrying out deliveries helps Shu test the technology the team use on a daily basis, he is also given a unique insight to the day-to-day experiences they face. (View Highlight)
In scenarios where it is not possible to directly test what you are building it is important to get as strong of an insight as possible.
When working at Siemens Magnet Technology as a Process Engineering Intern, all of my projects were aimed at making the manufacturing process safer or leaner. (View Highlight)
As Adam Grant writes in his book “Give and Take”, good long-term relationships and generosity should not be valued for their transactional benefits, but they will always result in strong team culture. (View Highlight)
Being focused on product development can run the risk of beingisolated from how the end user will use their application.
Testing devices while acting as the end-consumer gives everyone involved in development an idea of what and why they are building their technology.
In all hardware projects I have been a part of having to assemble, solder and setup devices in-house has been valuable when working on longer-term manufacturing plans and has inspired design changes. (View Highlight)
