Dogfooding Appian
Appian is a low-code platform that turns your business ideas into enterprise-class applications 20 times faster than via traditional software development. I lead the Appian Engineering team and this article covers why and how we use our software (or “eat our own dog food”) to run and scale our department.
To make this journey fun, my dog Wally (a connoisseur of dogfood) will be our guide. Let’s start by listing the five reasons we dogfood our features before we ship to paying customers.
- Discovery: To deliver great usability as shown below, dogfooding helps us experience our platform’s capabilities from different perspectives: as an “Appian developer” building applications to an “Appian user” using them, dogfooding complements our formal usability testing efforts.
For example, when building a Web Content component to embed external user interfaces within Appian, we made extensive use of dogfooding. We invited people across Appian to leverage an early version of this component for a variety of use cases. They embedded things like Google Maps, which surfaced specific issues that we couldn’t have easily anticipated via our regular software development process. Through dogfooding, we were able to make both the configuration and run-time experience optimal for our customers and the component has been a big hit.
2. Leverage: We strongly benefit from using Appian to run our rapidly expanding department. During my 6 years at Appian, Engineering has grown tenfold. We leverage Appian’s low-code platform to build unique applications for our department to power everything from release tracking to career management and technology selection.
As an example, our team site is shown below and packs all the custom functionality we need to manage our team structure and employee lifecycle.
3. Empathy: Dogfooding increases our customer empathy because we get a chance to experience the Appian platform just as they do. Our Integration Software Development Kit (SDK) benefited a lot from dogfooding. We didn’t just use it arbitrarily; we built actual extensions that we shipped to the Appian App Market. Along the way, we discovered a number of problem areas that gave us paper cuts and eye strain. Dogfooding allowed us to experience these issues as consumers would and surface them more quickly. By the time we released the SDK, we didn’t just have a smoother experience, we had a more powerful and intuitive SDK.
4. Innovation: Working with the product also inspires our engineers. Even if dogfooding targets a feature in development, their exposure to other areas of the product has led to a lot of creative side projects that become some of our most beloved product improvements. In the example below, an engineer dogfooding our Process Modeler struggled to find things in the palette on the left, so they added a search box. Enhancements like this, which can often languish in the backlog, may get expedited as a result and delight customers.
5. Quality: Lastly, dogfooding provides an additional blanket of protection (adding to our comprehensive quality processes) by all employees using our applications to keep a lookout for any regressions. Appian is a complex platform and dogfooding ensures that if we inadvertently break things, we find many of these problems before our customers do.
For example, we were running a large meeting using an Appian application and people reported strange behavior at times. The application was written a while ago but exhibited intermittent problems when used at this meeting. Digging in, we found a bug that was introduced in a recent internal release and were able to correct it before the next public release.
Our team gets so much value out of dogfooding, we do it for almost every feature we build. We have an Appian report for our release backlog (below) where each feature gets a color-coded paw print to show its dogfooding status. The tooltip on the paw print shows where and when the feature will be dogfooded. We added a report filter to show features by dogfooding status and follow-up as needed.
We have simple rules for dogfooding. Besides a few features that can’t be dogfooded for honorable reasons (for example, because we don’t use SAP at Appian, we can’t dogfood our SAP Connector), everything else must be dogfooded someplace within Appian.
Our senior Product Management leaders ensure that the entire platform is dogfooded comprehensively. We treat dogfooding like a quality gate to ensure that every feature is delivering the value and satisfaction it’s designed to before it leaves the Appian factory floor.
When we roll out any new process like dogfooding within Engineering, it can meet some resistance at first. But as we evolve our processes and address peoples’ feedback, we smooth out the rough edges. Months later, we are now using this process fully and effectively.
In addition to the formal dogfooding process outlined above, we also discuss our dogfooding experiences at team retrospectives and Product Management reviews to learn from each other and motivate everyone to partake in this process to build the best low-code platform for our customers.
In the past year, we’ve more than doubled the number of engineers building internal applications with Appian. We hope to do that again this year. Dogfooding is also taking root in other departments — most recently, our Intellectual Property lawyer built an Appian application to manage our patent filing process. Sorry for ending with a lawyer joke…but I hope this article will inspire you to dogfood your product. Woof!