Home / Developer console

from product to process (and back).

When I joined Pley as Lead Product Designer, the company had recently raised its Series A and was looking to scale.

Problem

Getting a game from signed contract to first paying player took seven months or more.

Approach

Prototyped the launch process in Notion, then built the product to accommodate collaboration.

Outcome

Launches dropped to around two months, with the console one of several changes.

We'd demonstrated that mobile games could be brought to the web successfully, but those launches required considerable hands-on work. Getting a game from a signed contract to its first paying player could take seven months or more, which was difficult to reconcile with our ambition to become a self-service platform.

We had SDKs, a developer console, and a growing number of capabilities intended to make launching games easier. Much of the product work focused on improving those tools. Conversations with customers made me question whether we understood where the delays were coming from.

Pley sold its platform to game publishers, although the people responsible for implementing it were usually someone else.

Game developers had to port the game, integrate our SDKs, and adapt their development processes to the web. Many were experienced mobile developers but had limited web experience.

User acquisition teams had to figure out how to attract players in a browser, where the practices they knew from mobile didn't always apply.

The publisher had commercial expectations, but the work was distributed across developers, marketers, consultants, and sometimes several different companies.

A game couldn't launch until these groups had completed their respective tasks, and we hadn't done much to help them coordinate that work. Our product was primarily a collection of technical capabilities that people were expected to learn and configure.

I worked with one of our product managers to understand where the time was going. Each launch we'd done so far had been different. We spoke with developers and customers to find the problems and blockers that kept coming up across those launches, then worked backward from a successful launch. We wanted to understand what needed to happen, who was responsible, and which activities depended on others being completed.

Some of the delays were technical. Others came from people not knowing what to do next, who was responsible, or what was blocking progress.

We created a shared launch program in Notion that outlined the process, assigned responsibilities, and made dependencies visible.

I focused particularly on the commercial side, including acquisition and web assets, while the PM covered much of the game-porting and SDK integration work.

Introducing project management felt somewhat contradictory to what we were trying to accomplish. We wanted to reduce the manual work involved in launching a game, and here we were creating another process that required coordination and follow-ups.

The Notion program worked well, though, and gave us a much clearer picture of the work. Developers still needed to learn unfamiliar tools, marketers still needed to prepare campaigns, and publishers still needed to coordinate everyone involved. We could improve the software without necessarily reducing those dependencies.

Meanwhile, our developer console was becoming increasingly complicated. We'd added capabilities as the platform evolved. Each feature made sense individually, but together they created a conventional SaaS application with pages, settings, and workflows that developers had to learn.

Many of those developers hadn't chosen to use Pley themselves. Their publisher had made that decision, and they were now expected to learn a new product while completing an unfamiliar technical task.

The console's structure increasingly seemed at odds with what developers needed. They generally wanted to get their game working on the web, and navigating our application was an additional task on top of the integration itself.

The Notion program had shown that presenting the work as a series of steps, with clear responsibilities and dependencies, helped people understand what was expected of them. I wanted to apply some of that thinking to the console.

I redesigned a few capability pages as interactive documentation, combining the instructions with the controls needed to complete the work.

A checklist in the sidebar showed which capabilities had been integrated and which remained. Developers could see their progress and move between the instructions and configuration without having to navigate separate sections of the console.

We began with a few pages rather than redesigning the entire console. The early response was encouraging. Developers appeared to find what they needed more easily, and we could observe teams working on game ports using the redesigned pages. We continued developing the approach and brought more of the launch process into the product.

We incorporated the collaboration we'd established in Notion into the console itself. A broader launch guide showed the work required to get a game live, with pages that could be assigned to different people. Publishers, developers, and acquisition teams could see what needed to happen and who was responsible.

I'd previously thought about self-service as making it possible for a customer to sign in, configure the technology, and launch independently.

That was a poor description of how our customers worked. We were dealing with several groups, often across different companies, who still needed to coordinate even if the technology became easier to use. We wanted the product to help them manage that work without Pley having to coordinate every step.

The launch program and redesigned console helped establish a more deliberate process around getting games live.

Over time, we reduced the launch process from seven months or more to around two months. Several things contributed, including clearer responsibilities, changes to how we worked with customers, and improvements to the product. I can't separate the effect of the console redesign from those broader changes.

The work changed how we approached the console. The shipped version organized the console around the process of launching a game, with technical capabilities and collaboration tools available where people needed them.

Pley had grown quickly, and we were caught up in the organization we were trying to build. We spent less time stepping back to identify the problems customers were actually facing.

That began to change as people moved across roles. I started out leading the design team, but as a generalist I soon moved into developer relations and customer success, and joined commercial calls. Working across those roles helped us build better feedback loops in an organization that had grown too quickly.

At a company still looking for product-market fit, no job is beneath a product designer or product manager. You need to sit alongside users and customers and do the unglamorous work with them, or for them. That's how you learn what motivates them, what takes time, where the friction is, and where your product can help.

If I started again, I'd spend more time with those people from the beginning and question how the product was organized sooner.

We'd spent a lot of time designing the developer console as a conventional SaaS application. That approach made sense when looking at the individual capabilities we were building, but it was less useful for developers who had been asked by their publisher to integrate an unfamiliar platform.

I would have started by mapping the complete launch process with customers, then used that work to decide what belonged in the console and how it should be presented.