I work at a digital agency. I’ve been working at digital agencies for the past decade. It’s given me the opportunity to work on a wide variety of projects, as well as work with a diverse group of clients. I’ve done mobile, ecommerce, m-commerce, marketing sites, responsive sites, touchscreen kiosks, iPhone apps, Android apps. Agency life affords me the certainty that the next project will always be something different. And that held true in the summer of 2013 when I was asked to lead the UX on a very atypical agency project.
My agency had committed to developing it’s own social media app. The agency was dedicating staff and resources — significant resources — to build this app. There was real commitment. We were establishing a startup within the agency.
Why was the agency doing this? The concept was the result of an internal discussion: “What is the future of marketing?” For the purposes of this post, I won’t delve into this question; it’s a fraught, complicated question, and one that never really interested me. It is enough to say that the agency was genuinely dedicated to building a sustainable digital product.
A lot of hard work, long nights, stress, and sweat went into building this app, which we launched in March 2014. Below are some of the key things I learned from this experience.
Agencies are not by nature optimized for product development work
This hard-learned lesson was a shock to me. For a number of years I thought agencies should branch out and develop a core product development capability. My logic went like this: agencies possess the full range of skills needed to build anything; we quite literally build whatever a client can imagine. We’re steeped in industry best practices, understand the digital landscape, and are up to date on the latest and greatest trends in the space. All an agency needed to do was to select a couple winning ideas to develop and grow. This would lead to new revenue streams for the agency, as well as add to their prestige (“hey — look at this cool thing we built”).
But agencies are optimized for working with and for a client; not leading the way on a concept. When a client comes to an agency, usually they have a clearly defined idea of what they want/need (and for those of us in agency life, we all remember painfully the clients who came to us without a defined idea of what they want). Agencies are most effective at solving for that need; we work best with defined requirments. As much as agency people bristle at the restraint clients put on us, that restraint — and direction — is key to reaching the finish line. The client focuses an agency on solving a specific business-driven problem. This focus and drive was initially missing with our app. We all had a general idea of what we wanted to build, but we struggled at times to define it concisely and consistently. It was in the details where the purpose of the app would shift; often based on the problem we were tackling at the time. Maintaining a consistent, concise, and specific definition of what the app is was probably one of the toughest challenges we faced.
Actually, failure is an option… and a necessary part of the process
The first build of our app technically worked, but it wasn’t as engaging as we had imagined it would be. The second build improved from the first, but it was still lacking. The third build followed a similar pattern: slight improvement, but not “it.” And again with the fourth build. Now for anyone in product development, this is an obvious lesson. Failure leads to an improved product. But for us, it was extremely frustrating. We did not understand this at the time and we struggled with this reality. Criticism cropped up among our group, aimed at each other. This was misplaced. Instead of focusing on people, the criticism should have been directed at the app. To understand: what worked, what didn’t work, and why. An honest evaluation of our work was necessary.
Agencies don’t consider failure. We just don’t allow for it. Clients hire us to do a job and so we cannot countenance failure as a possible outcome. Brands don’t hire agencies that fail before getting it right. And so failing is not in an agency’s culture. And this is a realization that took a long while for our team to understand and accept. We truly believed when we started out that building our app would be like every project we’d done for our clients to date: we’d do the research, we’d design, we’d iterate, we’d build, we’d launch, and we’d succeed. We did not see failure as an opportunity to improve our product, but rather a failure of ourselves.
Faster is better than perfect
Agencies are perfectionists (see above about failing). When something is not quite right in a design, the designer will work well into the night — and morning — to get it right. This dedication to perfection is not asked or expected, it just is. Every designer, copywriter, developer, or strategist I’ve worked with at an agency has this ethos. Our names go on the work and we have an immense amount of pride tied up in that.
But perfection takes time and time applies a terrible friction to product development. Failure is important. Or more accurately, iteration — trial and error — is important to developing an enjoyable, useful, quality product. That a bunch of talented people can lock themselves in a room for a couple of months designing, crafting, coding and at the end of that time releasing a finished product is a myth. One we believed in.
Having a prototype in users’ hands is most important. It helps the team to understand what it is that they have and how to adjust. It allows them to test and gather feedback. This feedback is the most important input one needs in product development. We would start to get this — valuable, actionable insights — but our design process consumed too much time. We kept debating which features needed to be included rather than focusing on getting our app out there to test and learn what features users actually wanted. If we had shortened our launch cycles we would have gathered more feedback earlier. This is a very key lesson that took us a while to understand.
Product developments brings higher highs and lower lows
I grew quite passionate about what we were building. Any and all free time I had I devoted to the work — sketching, designing, refining, during the morning commute to work, during the evening commute home, after my wife and child went to bed, weekends. There was a stretch when I was needed on a big client project and so was assigned full time to that work. Rather than let go of our product, I just worked even longer days. Any moment sitting meant my laptop was open in front of me, doing work (my wife did not enjoy this time). Our app meant so much to me that I needed to stay connected to the work. I was personally invested and felt responsible for it. Each milestone was celebrated. I still have the email confirmation from Apple confirming our submission to the App Store. I intend to have it framed.
I poured this glass of Macallan 18 year scotch after our app was submitted
But such highs bring comparable lows. I would lose a discussion over a particular feature or design and feel dejected. I would stew on the decision the rest of the day, sometimes keeping me up when I tried to sleep. It wasn’t that I was always right (I like to think I was right most of the time, but realize how foolish that notion really is). Sometimes the alternative option proved to be obviously better, or that both options were equally effective. Still, losing these battles bothered me more than on typical client projects. In those cases the product belonged to the client — not me. Here was the first time that the product belonged to me. It was personal and so it affected me more.
Our startup wasn’t really a startup
It may have resembled a startup and we certainly thought of ourselves as one, but I believe that the reality of a startup is very different. For one, a startup isn’t paying our salaries (or to be specific, we have salaries). We work for a large, well-established company. We are very well funded. The company’s future is not tied to the success of our app, nor is my job. This takes what I imagine would be very real concerns and significant sources of stress that are typical of startup life out of the equation. That security is important to me, important to everyone on the team.
No doubt some of the challenges we encountered as we developed our app were relatable to a startup experience. We were plotting a course not traveled. We had to learn things painfully that seem obvious in retrospect. But on a certain level, our startup experience is somewhat artificial, or at least insulated. I imagine in real startup culture, success and failure carry much higher stakes. Also, when it’s time to walk away from our product, the cost will be borne by the Agency, not its employees.
(and I want to state how truly grateful I am that my agency afforded us this opportunity)
Conclusion
These are the key lessons I learned while working at a startup within my agency. While you might theoretically be developing the same thing — an app for a client or an app for your startup — the experience can be very different. Here, we’re learning from our foray into product development and figuring out how we can amend our processes. There are many real positives and negatives that are inherent to product development (the same can be said for agency work as well). On the whole, I’ve really enjoyed our startup journey.
I’ve recently had to transition back onto an important client project (two constants of agency life: (1) you don’t get to choose what you work on; (2) client work ALWAYS comes first). This has unfortunately taken me away from day-to-day operations of our startup. I hope I get back to it again, back to our product development enterprise, or perhaps down the road find an opportunity with the right startup. This has been a great experience.
Want to talk Product Development, Startups, or Agencies? Let’s connect on twitter.
