Designing before the product exists

Shipped in

·

2022 – 2023

My role

·

Product strategy, brand design, design system, naming

Team

·

CEO + CTO + Myself + Product manager

Four of us left Apple in late 2022 to start something new. A CEO, a CTO, a product product manager, and me. No product, no engineers, no name. Just a shared conviction that we wanted to build something fast, for real users, without a corporate calendar telling us when to ship.

The impact

Led the naming process that produced Metica

Designed Metica's founding identity and led two subsequent rebrands

Design system built from scratch in 2022, still in production 3+ years later with no structural rebuild required

Starting with problems, not ideas

We had history. My founders had sold their previous company, Datatiger, to Apple in 2017, partly on the strength of a product that worked well and a team that moved fast. I was part of that team. After four years inside Apple, scaling that product and helping launch Arcade, TV+, and Fitness+, we knew what we were good at and we knew what we missed about working small.

The first thing we did was not brainstorm product ideas. We mapped problems. Specifically: which problems were real, which were large enough to build a business around, and which sat inside a space we genuinely understood. We put everything on a whiteboard and grouped it by area. Generative AI for game assets came up early, campaign visual generation too. Both felt possible. Neither felt like ours.

What kept surfacing was the space we had the most direct experience with: in-app purchasing behaviour in free-to-play mobile games. Personalising those purchases, making them respond intelligently to context rather than firing the same offer at every player, was a problem nobody had solved cleanly. We had familiarity with the underlying technology from Apple, contextual bandits, on-device ML, privacy-first personalisation. The whiteboard exercise didn't give us the answer, but it cleared enough noise that we could see it.


Naming as a constraint problem

At some point between the whiteboard sessions and the first customer conversations, we needed a name. Everyone had ideas. I ran it as a structured exercise rather than a creative discussion, because creative discussions about names tend to produce either the loudest person's favourite or a compromise that nobody loves.

The constraints were concrete. Short .com domains were either gone or priced beyond what we could justify, so six characters was our floor. The name needed to be pronounceable by customers across English, Korean, Vietnamese, and South-East Asian markets, a lesson we had learned the hard way from Datatiger and from Comufy, the founders' first company, which most people could not say correctly on a first attempt. Trademark risk was real: operating in tech with a name too close to an existing player's, even phonetically, is an invitation to a legal claim that kills momentum. And we had a budget cap of around $10K for domain acquisition.



I ran the workshop, gathered ideas from the team, scored each against the criteria, and cut anything that failed on more than one. Metica cleared them all. Memorable, short, pronounceable in any language we cared about, available as a trademark in the US and EU, and affordable to register. We moved on.

Going to a customer before we had a product

In April 2023, five months in, we flew to Germany to run a design sprint with a gaming publisher we already had a relationship with. We had no product to show them. The sprint wasn't a sales call dressed up as a workshop. It was a proper three-day session: problem framing, sketching, dot-voting, rough prototyping, the kind of thing that used to require getting twenty people in a room before Miro made it easier to do it badly from home.



The question we were testing was whether intelligent IAPs, specifically offers that adapted in real time based on player behaviour, felt like a real and urgent problem to the people who managed them. The prototype we built during the sprint was rough. It was never going to ship. But the conversations around it confirmed that we were pointing at something real, that publishers were losing meaningful revenue to static offer logic, and that nobody had given them a tool to fix it.

We flew back with conviction rather than a spec. That was the point.

Building the right infrastructure before the product

While the product idea was still being tested, two other threads were running in parallel. The first was brand. We needed something to put on investor decks, something that looked considered without committing to a direction we might have to abandon. I designed a temporary brand: logo, typography, colour palette. It was never meant to last, and it didn't. When we later worked with a brand designer to build a proper identity, most of it changed. But having something real to present gave the company weight in rooms where perception matters.



The second was the design system. Starting from zero is a rare opportunity, and I didn't want to waste it. No legacy components, no inherited inconsistencies, no token structure somebody else had bodged together under time pressure. I built it properly: components, tokens, a structure flexible enough to absorb a rebrand mid-journey, which is exactly what happened when the visual identity shifted later on. The system survived that without breaking. (More on that in the Planning a design system that can scale)

By the time we hired our first engineer, the product had a name, a validated hypothesis, a brand that worked on paper, and a design system ready to build on. Six months.