Why Transition to a Subscription Model?

One of the larger themes that you’ll hear in ad tech circles today focuses around transparency. With the abundance of ad tech players regularly added to a brands’ media plan, understanding exactly where your ad budget is going is nearly impossible. Managed service is a business model where a company uses internal resources (e.g. client services or ad operations) to manage a campaign for their clients, taking a margin on top of the cost of their media buy. While managed service is a great way to introduce an advertiser to a new technology, it doesn’t allow for much transparency for the advertiser. This lack of insight more recently lead brands into a lets do it ourselves approach, where they rather train their internal teams to use a smaller set of ad tech platforms instead of maintaining a bevy of managed service vendors.

This shift in advertiser sophistication brought me to Spongecell to lead product development for their Self-Service initiative. Like many other ad tech companies, Spongecell started as a managed service vendor focusing on high impact rich media units. By the end of 2014, the advertising industry’s focus on vendor transparency, end-user experience, page load speeds, and the migration to HTML5, prompted Spongecell to change their philosophy and catch up to the rapidly evolving market. The thought was that providing client’s with a great user experience when using our tool, while proving the performance benefits of Dynamic Creative Optimization (DCO) , we could make a subscription model work.

What Were Our Biggest Challenges?

One of the biggest challenges we had to overcome was from our internal teams. Early on, through user research, surveys and client interviews, we were able to validate that majority of our clients really wanted a self-service tool. Getting clients to provide feedback and test out our prototypes was fairly easy, however, getting the overall company onboard with the journey was very challenging.

As a startup, there will always be major challenges during organizational transitions. While our team members were excited about the idea of self-service, there was a distinct fear of the unknown. Additionally, since Spongecell had been managed-service focused, the front-end for the platform had not been maintained properly, leading to a bad user experiences and a lot of technical debt.

Understanding this challenge, we were determined to make our transition as inclusive as possible. Lead by our Director of UX, our nimble product team began conducting user sessions with internal production and operations teams to better understand how they leveraged the platform. With a full production and ad operations team at our disposal we were able to uncover ways to enhance their current workflow while building for the future. Not only focusing on qualitative feedback, we were able to analyze the number of extraneous hours production and operations spent working on monotonous tasks (e.g. rebuilding the same creative for the various IAB ad sizes). Quickly we discovered a huge amount of wasted time spent due to our outdated and unintuitive UI.

What Were We Building?

Lets take a quick step back to understand what our DCO platform allows clients to do:

Spongecell provides clients with the ability to personalize ad units at scale across desktop & mobile display, in-app, and in-stream video channels. We do this by leveraging 1st party, 3rd party, browser and partner data integrations to pull actionable information about each user that we serve an ad to. In addition to leveraging data points like location, weather and audience data for creative decisioning, we also leverage auto-optimization algorithms to help improve performance on creatives that are targeted to the same audiences. We have a dynamic studio that clients can use to build out ad units and link creative elements to their dynamic variations. Variations can be leveraged on the individual asset level (e.g. show the male model image vs the female model image) or the creative template level (e.g. show the summer ad unit vs the winter ad unit).

Now that you understand what a DCO platform does, let’s take a look into who our main users were. Per my description above, you can essentially break our platform down into five main components.

• Asset Management: Where users can upload variations of the individual elements that will be decisioned on within the ad unit (e.g. male image, female image, unisex image etc…)
• Creatives Templates: Where users can build their creatives within a studio (think photoshop) and manage their assets
• Template Variations: Where users can add their variations of creatives that will be optimized(e.g. winter ad unit vs summer ad unit)
• Trafficking / Tagging: Where users can pull their final Javascript tags and setup third-party tracking
• Reporting: Where users can determine whether or not our technology is providing value

After identifying these main functions or jobs that people used our platform to complete, we were able to focus on four main personas that mapped back to our end users. Brand lead, creative lead, media lead, and analytics lead. The brand lead would essentially be the final decision maker and the person that we focused on as our primary end user. These personas allowed us to rethink the overall structure of our platform and tailor each component to their needs.

What We Launched?

In conjunction with rebuilding our dynamic studio, our team leveraged the personas we had built to redesign our platform workflow. We broke it down to four key platform sections

• Campaign Dashboard: General campaign information, access to reporting and user management

• Concepts: Creative concept management and access to dynamic studio where users can link to their asset variations

• Strategies: Manage decisioning of creative templates variations amongst a set of ad tags

• Flights: Manage media partners, third-party tracking, and access to ad tags

What we learned?

The most valuable part of this journey was the key learnings along the way. One of my favorite attributes of product management is that its a continuous journey or learning and iterating, regardless of industry or vertical. Below are some of the key learnings I internalized through my time helping build Spongecell.

• Product management is not about YOU: I used to have this idea that a product manager’s job was to make decisions. While product managers do make many decisions, these decisions are made based off of a vast amount of data and feedback from users, team members, and competitors. Making a concerted effort to remove my bias when working on a new products has helped me become a better product manager
• Build-Measure-Learn: Data-Driven Product Development doesn’t have to mean analyzing data points from thousands or millions of users. Leveraging qualitative data from a small group of users could be extremely valuable as well, as long as you are continuously measuring throughout your development cycle and spreading the learnings within your team. Set goals, experiment and validate your assumptions.
• Simplify your offering: Managed service thrived for so many years because ad tech was implicitly complicated. Our designs and interactions were benchmarked on how easy it was for customers to use our tools. Our best successes as a team were when we were able to simplify the many complicated nuances of running a dynamic creative ad campaign.
• Focus on the ‘WHY’, let the experts focus on the ‘HOW’: Luckily for Spongecell, I didn’t actually have to build or design anything during my tenure. Sometimes I get the itch to voice my opinion on architectural design or UX choices, but I had to learn that we have experts on our team that are better equipped to make these decisions. Something I did do was question certain decisions to help provide valuable discussions around why we were building things. Majority of the success of our self-service launch has to go to our amazing UX and engineering teams.
• Process first, instinct second: One of my favorite podcasts is How I Built This hosted by Guy Raz. The one question that Guy asks all his guests is how much of their success is attributed to luck versus skill. I think about this question a lot when I see myself leaning towards my instinct instead of data or our prioritization framework to make decisions. Luck, similar to instinct, is not really tangible. However, generally following an operational process that has previously yielded valuable results should work more times than not. While I have built better product instinct over the years, I’ve found that relying on our process first is the best approach.

Spongecell is now a part of Flashtalking as the two companies merged last winter. Though I no longer work at the company, I would like to think that our self-service transition played a large part in their eventual exit.