We love food at Plain. Our co-founders love food so much that they, in fact, cook the whole team a multi-course dinner at the end of every year. For most of us, human food takes priority – with dog food coming a close second.

One thing to note in relation to dogfooding, is that not all products are equal in terms of your ability to do it. For example, in non consumer tech – it can be hard to get your hands on your product on a daily basis. Luckily, we don’t have this problem at Plain. Everyone on the team needs to provide support to our customers. We’re doubly lucky as the way we work is reflected in our customers – we’re a technical B2B team, that’s product obsessed.

Nonetheless, dogfooding doesn't come for free. You have to think of dogfooding as an active thing you promote within a company, both culturally and through process.

Over the years, we’ve built a solid workflow for ourselves on how we dog food at Plain. Here are some insights into how we approach dogfooding, and why we find it so impactful for our customers.

How we approach dogfooding at Plain

Providing great support to our customers is P0

The first step in effective dogfooding, is making sure that everyone at Plain knows the ins and outs of the product. During every new hire’s second week, they’re assigned to our internal support rota. This gets them up to speed with our key features, and common pain points experienced by our customers. After this, every week different team members take over support making sure that we are constantly hands-on in the product with real support cases.

By having a team that knows the product inside and out, we’ve essentially built a team that can jump into new features with an understanding of how our users would want to utilize it to spot bugs and suggest workflow improvements proactively.

We’ve created a solid feedback loop with our engineers

Dogfooding is pointless if feedback and suggestions are easily lost. When we find an issue while dogfooding, the finder adds it to our triage queue in Linear – these issues are then discussed at the next weekly planning meeting (we do them every Monday). If the bug is quickly treat-able, we’ll ship a fix as it comes up or in our weekly gardening sessions that take place every Friday. If the issue is, in fact, an indicator that the feature needs more work, we’ll move to a separate team in Linear we use to keep track of feedback and requests, ensuring that it doesn’t fall off our radar. As all linear issues are linked to the relevant support requests, when there is movement, Plain then helpfully reminds us of which customers we can announce the launch to.

To be good at dogfooding, we’ve got to do it consistently

As with most foods, poor consistency in dogfooding will leave a bad taste in the mouths of our users. It’s not something you can dip in and out of if you truly want to build the best version of your product. Our weekly support rota here already does a lot of the heavy lifting ensuring the whole team uses Plain regularly. In addition to sharing support, when we’re shipping a new feature or improvement we swarm as a team on a feature and all try it out together. This helps everyone get hands-on and make sure that new changes are socialized well as well as drawing up a nit list of small improvements and stuff we want to ship before marking a project as done. For example, recently having shipped discussions we’re now as a team making extra-heavy usage of them straight in #engineer in order to put them through their paces - even if perhaps is a bit more disruptive.

We eat “real” dog food

Often, it can be tempting to try your product in mock scenarios or in a dev environment and then think you know what it’s like. This is just simply not true. Take Plain for example, if you have 20 minutes of quiet time and try to send some emails and slack messages and resolve some threads in a staging environment, you are going to be more perceptive, relaxed and focused on the experience than you ever will be in real life. When you are trying to get some engineering work over the line and have team meetings and then that’s when an urgent support request comes in. That’s where you can experience what it’s like to actually be on the line for support.

Dogfooding which is ‘testing’ doesn’t count. That’s testing and it’s valuable too but it’s very, very different. Testing is much better at spotting rare and hard to foresee bugs, but is much less good at giving you the true feel of a product.

Dog food can be API usage too

There is often a very clear divide in quality between a company's core-product and their API developer experience. This makes sense as you normally have a lot of eyes-on time with the core product but not as an ‘external’ user of your API. In Plain this is less pronounced as we build Plain with the same API we make available to our customers. That said, when we use our own API we are doing so in a mature codebase with lots of helpers and custom utilities to make things easier. This is not our customer’s experience using Plain.

For this reason, we build examples for common uses-cases our customers have as stand-alone micro apps. Examples we’ve recently built are a webhook handler to push SLA breaches into Pagerduty, an Attio integration which syncs customers or a webhook handler which automatically sets the priority of a thread based on specific attributes of a thread. Building little integrations and apps like this makes it much easier for us to spot funky gaps in our APIs, documentation or general developer experience. It’s also great because it gives us a repository of code examples we can share with customers.

Why it’s so impactful for us

Dogfooding has become an integral part of how we build Plain

We approach dogfooding as a given, rather than an afterthought. If we launch a new feature one week, we know we’re dogfooding and making any necessary fixes in our gardening sessions the following. By having teammates with fresh eyes jump in to test new features, we almost always find areas for improvement – whether it’s something in the feature itself, or how we talk about the feature to new customers and in our docs.

It shapes everything we build and how we talk about Plain

Great product knowledge among our entire team – including our non-technical teammates – is essential for knowing how to speak about Plain. Dogfooding helps us find opportunities for us to document how to use our features a bit better, and to talk about them in a clearer way. For example, if someone on our sales team jumps in to test a new discussions feature, they might spot a gap in how we’re educating our users about them. During demos, our sales team can then lean on their own personal experience of using the product to share insights and make sure we’re all talking about Plain in a consistent, clear way. It also builds an incredible sense of ownership among non-technical members of the team.

But, it’s not perfect

One thing we’re increasingly feeling as we grow and onboard bigger support teams, is that their usage of Plain in terms of sheer volume far outstrips ours – meaning they sometimes catch bugs that we’d not accounted for, because we couldn’t. We're increasingly seeing gaps in our own testing and dogfooding to do with scale. This is, of course, the best problem we could have as a team, and one that we’re ecstatic to continue solving for by onboarding more and more customers.