Dogfooding is the practice of using your own products as a way to uncover potential issues and/or improvement areas for them. While it is not a new practice, there has been some recent controversy with it, especially with what has happened at DoorDash that made news when it announced it would require all of its employees — including engineers (gasp!) — to deliver food once a month. The program is an expansion of an initiative to get employees regularly testing its products. It was expanded to include three options for employees to test out the business each month. They’re referring to it as: WeDash, WeSupport and WeMerchant. WeDash is the overall program which includes “dashing,” executing actual deliveries. WeSupport entails employees shadowing a customer experience agent, and WeMerchant, which is the newest addition, entails employees shadowing merchants to better observe logistics and the experience of fulfilling orders. DoorDash encourages its employees who are going out to deliver food or shadow merchants to team up with a couple colleagues to do the job.

The goal is for DoorDash salaried employees, including the CEO, to gain a better understanding of the product and troubleshoot any observed issues that arise. The program is strongly encouraged and employees log the time into Workday to keep track.

The goal is that by letting all employees at all levels in a company really experience and use the products directly, they will be better positioned to understand what is lacking and how things can be improved in ways that using proxies like surveys, metrics tracking or written feedback simply can’t convey.

Part of the problem at DoorDash arose from the fact that the company decided to put engineers in the front-lines delivering value to customers directly (by doing deliveries) at a much higher rate than the value that they were supposed to bring thanks to their much more specialized skillset (writing software). This caused some controversy online as some people felt like the value was being misplaced in the company’s engineers by not leveraging them properly.

However, in a sense, this is actually a good idea for several reasons:

• engineers get a better feel for their own product and how it affects the end-users, both riders and customers;
• proxies like metrics tracking, feedback trickled down to developers from Product Owners or surveys will never be able to showcase the full hands-on experience the product conveys;
• people actually experiencing the real-time feedback are the best ones equipped to handle it;

Let’s expand a little bit on each of these points and see a way that this feedback could be implemented in practice for achieving the best results.

Engineers need to experience what they have built

Very often engineers are never really confronted with the reality of using the product(s) that they build. We can build and expand the same product over a span of several years without ever really using it and consuming it as an end-user will. This introduces a lot of bias over time as we don’t experience the way that all the technical decisions and features we are building organically affect the product over time: without seeing it working all together, it’s impossible to form a coherent picture and it can be very hard to see the “forest for the trees” without a certain level of emotional detachment.

By allowing engineers to use the product as if they were a customer, incredibly valuable feedback can be gathered that can drive the product forward with more intent and purpose than any other decision-making factors could.

Proxies, metrics, feedback, automated tests are not enough

It’s customary for many (all?) product companies to take a data-driven approach to product development: usually there is metrics tracking and usage tracking embedded in the tools we serve to our clients so that we can gauge interest and feedback: “this dashboard was being heavily used after launch but, three weeks later, it took such a dip that it’s now barely used. What happened, how can we improve?”. These types of questions, while useful to measure things like retention rates for features, interest and engagement, usually miss a critical point which is exactly how or why the customers are using that specific dashboard in a specific way, how are they getting the value they need out of the feature, are they even using it correctly and as we in the product teams had envisioned it?

All these proxies and third-aprty gathered metrics can’t answer these questions, and, it usually takes hearing it directly from the people using the product or, even better, using it yourself to fully understand. Without stepping into the end-users shoes, anything else will be at best a guess or a derivation from existing numbers that can lead to the wrong outcomes.

Let the people who use it be empowered to fix the problems

The main idea behind having your engineers consuming the product themselves as end-users is that often times, the feedback that clients can give only comes from a convenience perspective or it comes with the biases of people who can’t fully understand the technical implications of the feedback. And, while the customer feedback is the most important thing you can receive, because the customer is the final end-user who is a domain expert and will pay for the product, it is also valuable to expose engineers to this feedback and then let them use the product. By combining the joint efforts of technical people directly involved in the product development with the end-users who know what is best for the product in terms of the domain and how it can best be used, you will be in the best possible position to move the product forward in a meaningful way for everyone involved.

Conclusion and how to do it right

It’s extremely important to practice dogfooding as a product company - the insights gained when everyone has been exposed to your product and what is being built can be the leverage that is needed for the product to gain extra traction or to really achieve that competitive edge over the competition.

Dogfooding comes with its own set of challenges and there’s an expense obviously to putting your employees out in the field. Take the case of a software developer, for example. Developers are highly compensated for a very specialized skill set that’s in high demand. So what you’re doing when you take them off of their software development role and put them out in the field, you’re paying someone at the software developer’s rate to go out and deliver your frontline service to your employees.

The trick is finding the right frequency for employees to test the product, whether that be weekly, monthly or annually. Even with the high cost to productivity, allowing software developers to get that firsthand experience with how their software is actually being used by customers will broaden their horizons and make the rest of the work more enjoyable and productive.