Prime Gaming

Tools that grew separately

Technical Account Managers (TAMs) handled everything for game developers. Creating an offer meant moving between three internal tools that had each been built for a different part of the process, at different times, by different teams, plus Jira, Confluence, and Amazon's internal ads products depending on what you were doing.

It wasn't scalable and it meant a developer who wanted to publish something had to go through a person to do it.

I ran research with both groups: four TAMs, and four AAA game developers. Getting time with developers was the hard part. The team was protective of those relationships, and I got the interviews because a few partners we had good relationships with were willing to talk to us. I paired that with a service blueprint and information architecture exercise, which turned out to matter more than I expected.

Building for the internal team first

The plan I proposed was to design for game developers directly. That didn't happen, and I understand why.

The operations lead and the TAM team were concerned about the developer relationship. These were partnerships built over years, and putting an unfinished self-serve tool in front of a developer carried a lot of risk. The head of product wanted us to dogfood internally first, which is a reasonable way to de-risk the new product.

So we built for TAMs first.

Games, items, and offers

The first version organized everything the way the TAM team thought about it: a Game, the Items inside it, and the Offers that made those items available. That's an accurate model of the data, and TAMs could navigate it because they had built their mental model around the tools it came from.

In usability testing, three of four participants couldn't explain how the three objects related to each other. They understood each screen. They couldn't tell you what they were doing or how they connected.

The Games screen, showing a selected game and the offers live to customers

Items and offers, on a separate screen

One listing instead of three objects

I proposed collapsing Games, Items, and Offers into a single Listing that walked a developer through publishing step by step. The three objects still existed underneath, they just weren't how the user navigated.

This took some convincing. It meant reworking a structure we had already built and tested, and it moved us away from the model the internal team was comfortable with. But the research is what made the change clear.

Step one: pick the Game the listing belongs to

Step two: add the Item being offered

Step three: set when the Availability starts and ends

Publishing still ran through the Prime Gaming team. A developer submitted a listing and it went to review before going live, typically within a couple of business hours. That was the answer to the operations team's concern: developers got to publish without waiting on a person to build it for them, and the relationship stayed protected because nothing reached customers unreviewed.

The review step, where the Prime Gaming team approved or rejected a submitted listing

Seeing the whole lifecycle

The other thing research surfaced was duplicate offers. TAMs and developers were recreating offers they had already made, either because they couldn't find the original or because it had an end date that couldn't be changed after the fact.

Nothing in the tools showed when an item was live, when it expired, or what state it was in. And the items and offers weren't editable. So I designed a lifecycle view that made all of it visible in one place.

After it shipped, duplicate offer creation went down.

Horizon: Inverse Polarity

In-game content

Team

Apex Legends

Game

Apex Legends

Start

21 January, 2021
7:00PM (PST)

End

24 February, 2021
6:59AM (PST)

Draft

Listing details

The card showing the different lifecycle states: draft, review, publishing, live

Measuring the old process against the new one

Offer creation took 20% less time, measured against the service blueprint. A Product Manager on the team and I worked together walking through the flow and quantifying time per step across the existing offer creation process. We then did the same for the new one and compared them.

I have used that method on nearly every project since. It is the clearest way I have found to make process improvements legible to the entire team.

Looking back

Optimizing for the internal team first cost us more than it saved. The TAM team's mental model went straight into the product, and it took a round of testing and a redesign to get it back out. I understood the operations team's concern about the developer relationship, and I still think we could have protected that relationship while talking to developers earlier. I've brought this thinking into my more recent projects, working closely with the people who work directly with customers to gain their trust and show how the research benefits them and their contacts.

I also learned to treat an accurate data model and a usable interface as separate problems. The Games, Items, and Offers structure was correct. It was just never something a developer needed to hold in their head.

Where it stands

The Listing work was rolled into a self-serve Free Games with Prime launch after I left, but Prime Gaming's partner business now sits under Luna. The standalone initiative I worked on was folded in rather than continued.

The Listing idea came back though. Five years later at Tatari I made almost the same argument about ad groups and campaigns: keep the structure the system needs in the backend, and give the user one object and a guided path through it.