What I built hacking in Seattle

At last week's NBCU hackathon, the Advengers assembled to build something cool.  

Our criteria for "cool": both technically ambitious and highly impactful.

This post is about what we built and why we built it.

You can see the presentation/demo from the hackathon here.  Should have a better demo next week.

What did we build?

We built adHarmony, a second screen¹ app for advertising.  

While you watch TV, the app listens for advertisements.  When the app hears an ad, it asks you what you think of it and gives you options like "learn more" and "skip the ad". Simple.

Why would anyone ever download this app?

DISCLAIMER: This opinion is based on my loose understanding of other humans and stuff I've read.

People want the app because...

• they like to earn rewards for something they do anyway
• they hate sitting through irrelevant ads, and sometimes they can skip them
• the feedback they provide improves the future ads they see
• The user experience is unobtrusive and fun (addictive)

More about the user experience

AdHarmony sits idle in the background while the viewer watches TV and goofs off on their phone.  If the user wants to engage, great!  If they don't want to engage, they just ignore the push notification.

The variable reward system makes the app fun and a little addictive.  Only some ads can be skipped/give bonuses, making it exciting to swipe ads.  We modeled the design after the principals taught by Nir Eyal in his book about building habit-forming apps.

AdHarmony's experience follows Nir Eyal's habit-forming cycle

What's the point?

When adHarmony hears an advertisement, the TV publisher knows who watched the ad. Really, that's it.  Not razzled? Let me explain.

adHarmony Information Flow

The TV advertising industry has this problem: it's hard to keep track of who is watching ads across devices that TV is watched on.  Sure, it's always been annoying to track, but it's gotten much trickier as people watch TV on everything: tablets, connected devices, etc.

Ok...so why is that a problem?  It's a problem because of how TV advertising is sold: on an audience guarantee.  Audience guarantees mean the advertiser only pays for the ad when it gets seen by the demographic they bought. If the wrong person watched the ad, no one gets paid.

Bear with me...

If you lost me there, that's ok.  Here's the point...


When you see an ad that doesn't apply to you, you're not the only one to find it annoying.

1. You don't want to see it because it's not applicable
2. The advertiser doesn't care that you saw it because you'll never buy it
3. The publisher doesn't want you to see because they don't get paid

Doesn't that drive you crazy?  The ads that are MOST annoying don't benefit anyone!  It's just a huge waste of time and money, like serving a steak to a vegan.  AdHarmony helps that happen less.

Therein lies the rub

So, that's the rub: we built something to help users see fewer ads they don't like, publishers make more money from their content, and advertisers get a higher ROI.


Stay tuned for next week's exciting conclusion where we look under the hood at how it works.  Spoiler: dark magic.

---

1 What is a second screen app?

A second screen app is something you play around with on your iphone/tablet while you watch TV. 

Say you're watching "America's Got Talent" on TV.  You might download the app: America's got Tablets™ on your ipad to read more about the performers, vote along with the show, or share clips you like on Twitter and Facebook.  (Yes, I just made that up, but you get the gist.)

What I learned Hacking in Seattle

What I learned Hacking in Seattle

I’m currently on a plane back to NYC after a whirlwind trip to Seattle for the Comcast/NBCu Hackathon. Yesterday, to a room full of hackers and NBC execs, I debuted a working iOS app that can unify measurement across all screens by listening to a video ad play on any device.  Spoiler: we lost the competition.

discover a new relationship with advertising

In another message, I’ll follow up all about what we built and how we built it.  In this post I wanted to write down my lessons learned from this Hackathon while the paint is still wet.

Know your Hackathon goals

A hackathon is a game with a goal.  However, like all games with crummy prizes, getting first place is only one way to “win”.  From the start, my team defined success as building something ambitious with the potential to improve video advertising (and learn along the way).

We didn’t win, but we still celebrated Saturday night as champions because we achieved what we set out to do.

Advengers, Assemble!

I achieved my personal hackathon goals as well:

1. Build something that could change the TV advertising industry (check)
2. Eat fish (check!!) 
3. Make friends and have fun (check and check!)

Argue vehemently. Commit completely.

Building something in 24 hours requires total alignment.  Anyone working on functionality that does not support the goal is wasted work, and we have very little leeway for waste.  Alignment is impossible without agreement on the goal.  

The wireframe that sparked our controversy!

At the starting bell, we began by setting aside 30 minutes to argue about what we were building.  This was heated, critical, and probably the most productive 30 minutes of the competition.  In half an hour we agreed to a common vision and each felt heard and valued. 

Simple! 

After agreeing on what to build, thinking about how to build it came much easier. We were done with tech design in no time because we all saw the same target.

Scheduling: Divide Tasks, then Sync Constantly

Before I begin talking about scheduling…

For those of you who haven’t coded before, building an app is pretty easy:

1. Build the parts of the app
2. Combine those parts

…not unlike building an Ikea bookshelf! (For those of you who haven’t built an Ikea bookshelf, you’re missing out!)

A hackathon is all about constraints: time, people, and skills.  There isn't a lot of slack for anyone to be idle or to work on something that ultimately gets thrown away.  

Before we began coding anything, we started with a goal and a tech design.  Blindly dividing and conquering would lead to trouble because tasks have dependencies on each other’s, and a person's unique skill can quickly become a bottleneck if they're working on the wrong thing. 

• To start, we took inventory of our known bottlenecks and made a rough list of all the tasks we needed to do.  If two people were working on things that talked to each other, that integration was flagged as a separate task from the beginning.  
• Then, we doled out the most critical functionality that didn't have dependencies and could be completed by the fewest people.  
• Once we had assigned a first set of tasks, we continually checked in every 30-60 minutes as a team to run mini-scrums.  During these check-ins we would review progress, update our list, attack any new issues as a team, and hold ourselves accountable for delivering against our own timelines.  This let us ensure dependencies finished before subsequent tasks began and sometimes abandon functionality before we had over-invested.

The presentation IS the deliverable

It’s embarrassing how long this took me to grasp: the goal of a hackathon is to present something, not build something.  Frankly, I don’t think it clicked for me until after they named the winner.  Even during other teams’ demos, our team was still whispering about how an effective presenter with a great idea had a week technical undercarriage.

At the end of the day, I liked our presentation, and I’m incredibly proud of our sweet tech.  But if we could do it over, I would have thrown another coat of paint on the demo.  Lesson learned.