Agile In Action: How We Built Appian Portals

I got into playing Wordle in December 2021, like many others around the world. The daily word game had me hooked. 

I was also focused at work on building Appian Portals for our launch in March of 2022. At its simplest, Portals allows applications made through the Appian platform to be publicly available. 

To really test the new features, therefore, we needed to make something public - internal testing wasn't going to realistically replicate the usage pattern for an app that can be used by anyone, anywhere in the world. I got the idea to create Pordl, a version of Wordle using Appian. Our thinking was to put some real world stress on Appian Portals to experiment and learn all we can about how to make it better. And doing it with a game was a way to get broad participation.

I’m John Rogers, Manager of Product Management at Appian. After being here for more than eight years, I've seen how we lead with agility as a company. I’ve also personally been a part of so many projects that lead with agility at its core. The growth of the Appian Portals product team was one of them. The project required a lot of creative testing (yes even with a word game!), and iterating our planned approach as we discovered new customer needs. 

If you dropped in once per month throughout the past year, there would likely be at least one major feature or plan that changed each time you checked in on Portals. That’s how we work — we’re agile and adaptable to change.

Appian Portals lets Appian customers use low-code tools to create public, dynamically scalable UIs for their external users — think of insurance quotes, surveys, onboarding, and more. 

Full transparency: games are not our sweet spot. Appian is mainly used to build applications that help improve efficiencies and workflows within businesses. But in order to go live with a successful project we have to test features, and what better way than making a word game that’s already so popular?

I am proud to say that I built the game myself. I’m not a technical developer but the great thing about our product is that you don’t need to be an expert to create apps in Appian. The team latched onto it and within a day of releasing Pordl, we'd already pinpointed multiple bugs in Appian Portals (two performance issues, a functional error, and several good enhancement ideas were just the start). It was a fun way to test, because it didn’t feel like we were asking people to do us a favor, they were just excited to play the game. 

Appian employees and people in our greater community enjoyed trying it out, which put the eyes on it that we needed. We wanted people to poke holes in it and ask questions in order to continue to improve it. 

We got questions like: 

• Why is this so slow to load? 
• What if we made the share button a different format? 
• How can we make the user interface more similar to Wordle? 

Our team was on top of making the changes our audience wanted to see, and this gave us even more ideas on how to make Appian Portals better. Ultimately, we had hundreds of players around the world play almost 9,000 games of Pordl. This was thousands of hours of realistic testing — and needless to say, it would have been far beyond the capacity of my team to do this much testing purely internally!

This is one example of “dogfooding” at Appian, where we use our own product to help us internally and test how it will work for our customers. In the real world, apps often don’t behave the way we think they will, so the more testing the better. 

The ability to create public apps through Appian has been highly requested for years - before Appian Portals, the only way to use an Appian app was to have a user account and log in. But the approach technologically on how to allow public access and have the greatest impact for customers was unclear. 

So we started the Portals project with what we call a discovery pod, or a “discopod.” It’s when we get a small group of people together to explore the hard technical questions to see if something is possible. 

We didn’t just move 15 engineers on the project right away. Before we do a large development investment, we want to ensure we've got an approach and scope of functionality that our partners and customers agree is valuable and addresses their needs. Our discovery pod first wanted to understand how it would work, asking how quickly can we move with this and what does it take to get something real that our customers can test?

The disco pod found an approach that was easier than folks thought it would be. We discovered that a recent initiative to improve our offline capabilities for mobile apps had given us a new and exciting option for the technical foundation of a public app capability. That’s when we decided to move to the next stage - testing the beta prototype with customers, getting their feedback, and using that to determine how much internal time and resources to dedicate towards building Portals.

We have a very active Appian Community with customers who were excited about Portals and keen to help us figure it out. We partnered with the Customer Success team and found Appian developers at multiple customers and partners who wanted to be part of it. We were clear with this beta program that Portals was in very early stages, and we expected some areas not to work, or not to work the way they needed it to — that’s what we needed their feedback on! 

The beta program was highly successful, and while there were plenty of bug reports and suggestions from our beta testers, there were no foundational challenges to our approach - in fact, our beta testers were much more open to a release with fewer features than we'd been thinking were necessary.

Throughout the process, we were open to change. Every week, we’d ask ourselves: 

• What did we learn this week? 
• What surprised us? 
• How can we apply this to the project? 

For the Portals launch in March 2022, we wanted to ensure we were including the features customers said they couldn’t live without. If it wasn’t super valuable for customers, we added it later to the product roadmap. This really represented our agile way of working where we prioritized moving quickly and iterating along the way. 

We’re still learning the best ways to run beta programs, but found this was a great way to get our Appian community involved early on and help us make it the best it can be. Providing early access to Portals to selected customers when it was 20% built was a new way for us to test. We were upfront that we hadn’t worked out the kinks yet and were still missing major features, and it was valuable having customer input at such an early stage that we could easily change our priorities based on their feedback. Feedback on a feature that was 90% built would have been much more painful and disruptive to incorporate.

My favorite kind of hard problem is the "platform thinking" that working at Appian requires — you can’t just think of one kind of app or set of users, because our customers are using Appian across many industries. The Appian platform is software that helps others build software, and that creates a lot of new and complex challenges in our work. 

With every feature we build, we need to think through it and test it in a really comprehensive nature so it helps customers who have so many different use cases. Appian is used to build apps for customers working in insurance, pharmaceuticals, government, transportation and more. It forces you to think about product development in a much broader way.

This means that working on the product team at Appian requires a lot of adapting, asking questions, and change, which makes for exciting work. It can even mean jumping on a word game trend, that sparks an idea, that creates an experiment that helps us test something in a new way.