Ask Me Anything: DOGFOODING--best practices, pitfalls, and personal stories

[Christine P. Dela Rosa]

Drop your questions between now and Tuesday, 14 September EST, when our experts respond to the questions on this page.

Featured Atlassian responders:

• Nick Muldoon - Co-CEO - Easy Agile
• Paul Slade - Head of Engineering, Experience Platform
• Swati Raju - Senior Manager, Engineering
• Agnes Ro - Senior Manager, Engineering
• Marshall Walker Lee - 'Work Check’ podcast debater & Team Lead, Learning Experience
• Shannon Winter - ‘Work Check’ podcast debater & Corporate Brand Lead

As heard on the "Work Check" podcast, dogfooding is a practice where companies use their own products or services in their day-to-day work. It's a way to better understand what their customers go through, to inform the product development process.

Listen to the podcast episode (on Apple Podcasts or wherever you download your podcasts) to learn more, and when you're done, come back and ask follow-up questions on this page. Or, ask us anything about dogfooding in general...all questions are welcome!

Then on September 14 EST, join the debaters from the podcast to answer questions submitted or upvote the questions you want to see answered. 

[Daniel Ebers · Accepted solution]

Seeing the positive aspects of dogfooding I'd love to hear who should make the decision in a company to use a dogfooding approach vs. using a different tool-set.

Or in other words: could there be clashing interests depending on the individual's role to use a dogfooding approach vs. not to do it?

[sladey]

Daniel, in my view the product development team should make the call to institute dogfooding. They need to control the process to get the most value for the "paying customers". That is not the whole story though. If there are internal users of said product then at the very least they should have a feedback mechanism to flag to the product team when the dogfood process is impacting productivity. The idea then is to moderate the internal teams using the latest and greatest version of the product, removing the most impacted teams from the "experimental cohort".

Using a different tool-set is slightly different story. In my experience it is the responsibility of the product team that owns the "equivalent product" to the alternate tool being used in other teams to gather "competitive intelligence" from the teams using the alternate tools. We have situations in Atlassian where there is a mix of Atlassian product and competitor use - we try and learn as much as we can from these situations.

In general there is a willingness to slightly reduce the productivity gains from a fit for purpose tool choice in order to get more feedback on the products we build.

[John Funk · Accepted solution]

What type of tool would you create internally right now (one that you don't already use) that you would turn into dogfood for your company? 

[shannyshan]

Super interesting question, @John Funk! I don't have a net-new product idea off the top of my head, BUT your question made me think of Point A, Atlassian's program for bringing new products to life. We have a handful of products under the Point A umbrella right now, and we're internally dogfooding all of them (either at the team, department, or company level) just as we would with our more established products. 

Team Central is a great example of a relatively new Beta product that we're dogfooding or project goals & status reporting. It's for sure beneficial for the Team Central product team to source internal Atlassian feedback alongside beta customer feedback as they work to make the tool better and better, but I think the value of dogfooding expands far beyond product management. For instance, I'm part of our Brand team, and by dogfooding products like Team Central, I'm able to work on brand strategy and brand positioning/messaging in a much more authentic way.

[John Funk]

Ah, yes! Point A is a great example if you are actually using those products internally.  :-)

[Monique Barreto · Accepted solution]

I like the taste test concept around dogfooding. A chef doesn't serve a meal without tasting it first. But, does your whole company have to fully adopt a product to be dogfooding, or is it enough to test it for a short period of time? Especially for some teams that might not easily integrate certain tools.

[sladey]

You are right Monique.  As I said above we have tooling that allows us to target dogfooding efforts.  Often compliance is a reason that dogfooding is not appropriate.  This is definitely something to check with your legal and risk teams.

[nina_schmidt · Accepted solution]

Reverse dogfooding would be interesting - does Atlassian use some Non-Atlassian Tools and if, why? 

Somehow related to @Daniel Ebers question

[Bill Sheboy]

Thanks, @nina_schmidt  That was what I was hinting at with "mitigate around the gaps" in my question.  :^)

[sladey]

Nina, this is sometimes called "cat fooding".  The best example in Atlassian's past is the usage of Trello across several teams in Atlassian.  I know that feedback from such teams was keenly sought by the Jira team.

There have been times when we have been unintentionally dogfooding.  We used PagerDuty before we acquired Opsgenie.  The migration to Opsgenie was one of the most intensive periods of feedback for the Opsgenie team !   It significantly moved the product forward for customers like Atlassian. 

[Agnes]

Personally I think its important to regularly "cat food" and check out what other companies are doing, even if it is for a short period of time. Whilst we do rely a bit on Product Managers to help bring this information back into the teams, similarly to getting engineers to understand our customers better by dogfooding, there’s no better way to really see first hand how other products are advancing by using their tools 🙂

[shannyshan]

+1 to all the above! 🐱 I'd also add that I think catfooding (and dogfooding for that matter) should be iterative, longer-term endeavors, rather than one and done experiments. That's not to say that a quick poke around a competitive product can't be useful, but I think the real juicy insight comes over time as you become more familiar with a product and it's features, you try out new updates as they rollout, etc. - essentially, you see what it's like to have that product as a part of your life. And as Paul highlighted re: dogfooding, there should be a way to capture feedback when you're catfooding (ideally in a place that's visible to others like an open Confluence page or Trello board), so interesting insights don't stay trapped in your head. 

[Bill Sheboy · Accepted solution]

Greetings, community!  My question is:

When "dogfooding" with Atlassian products, how often do you find your teams:

• changing how they work to match what Jira is capable of supporting
• versus maintaining how they work and trying to mitigate around the gaps
• versus trying to influence product decision-makers in other/better directions?

[sladey]

Great question Bill.

I would say the majority of teams do NOT want to change their processes and workflows.  This is hardly surprising.   In this regard the Atlassian teams are just like any other customer team so we are deliberate about change management for such teams.   It is true that internal Atlassian teams are encouraged to adopt new features and capabilities but is rare that we force them to (unless we are doing a forced migration and then Atlassian teams go earlier to test the migration process itself).

There are feedback mechanisms for internal teams to contact the product decision makers.  Our teams are not shy of providing in depth feedback on how new features are working for them :)

[Agnes]

Dogfooding is powerful as teams will ultimately find gaps and annoyances with the product. We often find that during our ShipIt (hackathons) or innovation weeks, the engineers will try to tackle these gaps themselves, often involving Product and Design in their projects. Some successful projects have resulted in getting proper roadmap time and shipping, examples that just come to mind include the dot dialog for quick shortcuts in Jira, Confluence page layouts, find and replace in the editor.

[Bill Sheboy]

Thanks for your thoughts, @sladey 

Please note I was not stating teams are forced to change, and rather that they may choose to abandon/alter their working norms when a tool cannot support them as it may be more cumbersome to use multiple tools to continue those norms.  I was instead asking the frequency of this symptom when Atlassian teams use "dogfooding".

For examples of this for customers, please consider some of the common practices for teams using the Scrum Framework or the Kanban Method, and then check community posts to read about frustrations, often leading people to just "do what Jira supports" or to investigate marketplace addon apps at additional costs.

Thank you for helping the community!

[Margareta Buruian · Accepted solution]

How are the criteria for how or what to dogfood out of any given product cycle determined? Is there input from anyone outside of the product team for example? 

[sladey]

In Atlassian the most common setup is that internal teams either use products running in non-production environments OR they are part of a canary cohort OR they get enrolled in experiments.

In the non-production environment scenario it is very difficult to "escape" the dogfooding world.   Typically the development teams who use the product to build the product (thankfully a common situation at Atlassian) use this kind of dogfooding.

Being part of the canary cohort is typical for product instances that get a lot of continuous usage.  These ensures they are useful canaries and discovery issues quickly and the rollout can be halted and rolled back. At Atlassian our company wide instances of Jira and Confluence operate as canaries.

Finally, experiments are used for very targeted testing.  This is common when you allow internal teams to "enrol" in a new feature.   Also we have many innovation projects happening within Atlassian and the developers of those projects want to see how those projects stand up to real-world usage.  They find internal teams that are willing to explore the project and use the experimentation framework to allow them to dogfood the project. 

[Swati Raju]

Craig, on the question of what criteria we use for what to dogfood and how to do it, it depends entirely on the feature being rolled out. I work on Confluence Cloud and in some cases, a feature may benefit from several months of internal dogfooding where the development team can validate and course correct their assumptions. (In that regard, at Atlassian, we are really lucky that our products lend themselves to extensive usage in our day to day work life, and dogfooding becomes an incredibly valuable means to get feedback).

There are also cases, where dogfooding internally has limited value. For example, building features for onboarding new customer may offer little value from internal dogfooding. In such scenarios, where internal dogfooding doesn't provide great feedback, using A/B testing or incremental rollouts directly to users has been very helpful.