By Aaron Bach
Four Winds Interactive

It all started with an art museum.

About two years ago, our CEO, David Levin, stood at my desk and looked at a custom sign build I had created for the Denver Art Museum (a local client of ours and one that, incidentally, our new building backs up to). The build featured some exciting, compelling functionality: sign-to-sign wayfinding, exhibit promotions and dynamic pricing. As I demoed it to David, he said something that would fundamentally alter the course of FWI: “We should be promoting this application to every single museum in the country.”

Initially, I didn’t catch the weight of his comment. After all, promoting our best work – meeting room signs, flight boards, virtual concierges, etc. – to entire industries was something we did every day. David wasn’t talking about that. He wasn’t implying that we ought to create a “Custom Museum Application Statement of Work” for every museum in the country.

Rather, his vision was something far greater: we ought to sell this exact application (along with a way to customize key aspects) to every museum in the country. This was a radical notion. It scared me. To date, our software platform had been focused on custom digital signage and content management. We had always done things a certain way, and this wasn’t it. How could we possibly accomplish this? Could the software even do it? What did this mean for FWI long term? Who would manage a program like this?

So, like any careful, measured, responsible technology leader, I thought about all this in the span of three seconds, swallowed my concerns, and boldly proclaimed, “Let’s do it.” At the same time, I remember thinking, “Aaron, don’t you dare regret this.”

Fast forward. After a year of “working group” status, we launched FWI’s Application Development program in January of 2015. And now, as we near the end of our first official year in operation, I want to reflect on some of the big things we, as a team, have learned along the way.

Forming a Development Team

The construction of a competent software team is never easy. In our case, however, we had a unique challenge: for the first 9.5 years of FWI’s history, our Sign Developers had gotten used to building one-off digital signs. SOWs would come in, meetings would be held, and they would begin building. When a particular project was complete, they’d move on. We gave little thought to previous sign builds because there were so many to focus on in front of us.

Task one on our plate was to expand. Principally, this meant that our developers had to change their ways of thinking. It turned out to be a hard transition.

When you begin to build any software for a one-use scenario, you naturally go down the most direct path: you build it to work for that environment and you pay little attention to anything else. That wouldn’t fly with our group. Ours was a harder job: we had to design applications that would work for anyone. They had to configurable; they had to be skinnable; they had to combine our best practices with the flexibility that “app users” came to expect. In short, our developers had to be a lot smarter about how they built things.

To accommodate this change, we decided to pursue a strategy that would allow it to occur. Early on, we adapted Agile Scrum as our development methodology. Although it provided several tactical benefits, one, in particular, stood out to me: it didn’t require that we “get it right” immediately. We could try things; we could iterate quickly; we could collect feedback and rapidly adjust. I believe we flourished more quickly because we didn’t demand that our “end-all-be-all” product be on the shelves on Day 1.

Now, a year later, our team is performing at a level I didn’t imagine was possible. We are operating on all cylinders, so to speak. The lesson learned? Perfection, although a wonderful thing to strive for, can crush anything that’s trying to change.

Pivoting a Platform

Traditionally, Content Manager focused on just that: content management. Although it might have carried other responsibilities over the years, “application development” wasn’t high on that list. Given that our client base was used to this product, we faced a unique challenge. How were we supposed to roll out a brand new paradigm using the same tools as before?

In the early days of AppDev, we created “sort-of” applications. We took our best sign builds, exported them as .ds files (a proprietary format for Content Manager), and stuck them on a shared network drive. The thinking went like this: “When we need to implement another meeting room/virtual concierge/etc., we’ll go to our shared drive and grab the one we’ve already made!”

At the time, we thought this was revolutionary; in retrospect, it suffered from some core problems. Principle among these was ease-of-use: “configuration” of these applications meant opening up an Excel spreadsheet, editing a bunch of values, saving it somewhere, then deploying a version of our .ds file that pointed at that Excel spreadsheet. Clean? Useful? Intuitive? Not even close.

So, we did something bold: we went back to our leadership team and said, “Content Manager needs to have the ability to produce and consume real apps.” We outlined our needs: easy-to-configure, not overwhelming, documented, and more. We wanted a distant cousin to an iOS or Android app architecture and we needed it to live within our ecosystem.

I’ll never forget the email I got from David one morning in late 2013: all it said was “FYI :-).” Below, I saw an email exchange with our CTO. “Apps as entities” within Content Manager was something that he’d been thinking about for a while. More importantly, he really liked the idea. Right before my eyes, the dream was coming true: Content Manager was going to be enhanced to build the real, reusable applications that we so strongly desired.

What lesson did we learn? Be bold and go after something big. Had we constrained ourselves by the old way of doing things, we might never have progressed past the “working group” stage. By going for the “big ask,” we catapulted ourselves to a new level and began to inspire all of FWI to orient towards it.

Building an App Store

Around the same time that development began on Content Manager, I had a sidebar discussion with our Core Product Director about where we were going to house the apps that we planned to create. Our shared network drive was obviously no good: we needed something that was customer-facing. We tossed around several ideas; then came another pivotal statement in our group’s formation: “You know, what we really need is an app store.”

I was elated at the thought. There was only one problem: I had no clue how to build, maintain, and run an app store.

I did the first thing I could think of: I Googled “how to build an app store” and searched. Not surprisingly, this approach didn’t yield much; most literature (if you could call it that) on the subject focused on technology, infrastructure requirements, user authentication, etc. We knew all this. What we didn’t know was how to run a store as a business. How do you charge for each app? What do you charge? How do you collect feedback? How do you choose what apps to feature on the store’s homepage? On and on it went. I remember dreaming about speaking to executives from Apple and Google on their stores. All I heard back was gobbledygook.

So, in a truly agile fashion, we winged it. We came up with a basic UI, we wrote down a few processes around its maintenance, and started communicating the idea of the “FWI Store” to our internal teams. Within a few short weeks, our Sales, Legal, and Accounting teams had come up with mechanisms to incorporate the Store into our agreements and SOWs. We started to pitch it to selective clients (and only a few at a time). As time passed, we expanded the Store more and more. Before we knew it, a mature app store was up and running.

Where’s the proof, you ask? Last week, in five days’ time, we had 112,000 logins to the FWI Store. Not bad for a concept that got its start through a sidebar conversation and some furious Googling.

The lesson? Don’t immediately think about replicating the successful model of a distantly-related “cousin organization.” In retrospect, we didn’t need to deduce how Apple and Google operate their stores; our intention was never to be Apple or Google. In pursuing our own revolution, we found a sense of the unknown and, more importantly, our ability to overcome it.

The Road Ahead That’s Year One of FWI’s App

Dev Department and the FWI Store. I can barely believe the road that we’ve taken. Our baby has grown up and is starting to flourish.

The most exciting part? Even though I know the tactical nature of what we’ll try to accomplish in Year Two and beyond, I have little insight into how the journey will look. There’s uncertainty in the unknown. There will be challenges, difficulties, and long days ahead. We may face complete revolution a time or two more before this is all said and done.

You know what, though? I’m thrilled. Our group is pursuing something special and they’re doing it in a powerful way. When I think of all the places we could be, I realize that the only place I want to be is right here.

This column was reprinted with permission from Four Winds Interactive and originally appeared here and here.