Introduction: Why Design-Driven PLG, Why Now

Everyone is building faster. Almost nobody is building growth.

Everyone is racing to build faster with AI. For design teams that usually means producing design faster, which is the least interesting thing you could do with the capacity.

The better question is what you do with the time it frees. Shipping faster is not a moat when your competitor ships just as fast. What holds is a community of people who genuinely care about the product and the team behind it, and that is the one thing you cannot generate in a sprint.

The tools distracting you are the tools that make it possible

The same tools pulling everyone’s attention toward output are the ones that make growth work accessible. Community-driven PLG runs on writing, visual design, video, storytelling, and production. Those used to require specialists most teams could not justify hiring. They do not anymore. While it is tempting to assume that businesses well-known for PLG like Figma, Notion, Slack, Canva and many others had something you do not, they were doing this long before they had the scale to pay for it. The work they did the hard way is now considerably easier to replicate than it looks.

What is missing is not capability, it is the playbook.

Experiencing the playbook from the outside and within

I started using Figma in 2016, during the open beta. At that point the company had no team in Japan, no Japanese marketing, and no localized product. Nobody sold it to me. I found it, it was better, and I spent the next few years convincing my own team to switch and then convincing other teams across the market to do the same. In 2019 I ran the first Figma community event in Tokyo, three years before Figma had anyone in this country. Eventually I became one of the first people they hired here, employee number three, and the first advocate in APAC.

Experiencing Figma's community driven PLG firsthand attending the original Config

None of that was an accident on my part or a lucky break on theirs. Everything I did, I was able to do because the product was built to let me do it. I could try it without asking anyone. I could learn it without a rep. I could show it to my team, and then to other teams, and every one of them could get to the same place I had without the company being involved at all. Figma’s sales and marketing eventually arrived in Japan and found a market that its design had already built.

What the title obscures is where the role actually sat. Designer Advocate reported into marketing, which in APAC meant being a designer embedded in a growth marketing team, carrying a growth mandate and measured the way marketing gets measured. I was not studying this from a design org and writing it up afterward. By 2025 that team had become the highest performing marketing team at Figma, and APAC has consistently been the fastest growing region in the business.

That vantage point is why this playbook takes the shape it does. Sitting inside a growth function while thinking like a designer meant the levers the team reached for, the events, the content, the community programs, the launches, all read to me as design decisions that happened to be filed under marketing. None of what follows is assembled from the outside. It is the approach I ran, with the results attached.

The design-driven PLG

That is the whole argument in one story, and it is why I keep finding it strange that product-led growth gets filed under marketing.

Product-led growth is a go-to-market strategy where the product itself drives acquisition, activation, retention, and expansion. Instead of routing every prospect through an outbound sales process, people discover the product, try it, and get value from it before they ever speak to someone in sales.

That definition is accurate, and it hides the interesting part. It describes an outcome without naming any of the work. Something still has to do the discovering, the convincing, and the expanding.

I also want to be precise about which part of this I am claiming, because plenty of PLG is not especially interesting. Marketing can run a free tier. Marketing can drive self-serve signups. That version works, and it is not what I am talking about.

The flavor worth studying is the one that produces fans. Not users who convert, but people who follow every step of a company’s journey, who care about the team behind the product, and who talk about a piece of business software the way people talk about things they love. B2B with the affect of a consumer brand. That is the part a sales motion cannot manufacture and a marketing budget cannot buy, and nearly every mechanism that creates it is a design decision.

My own story is not an outlier. It is what this looks like when it works, and it is happening right now around products like Linear, Vercel, Clay and Granola, neither of which is a design tool and neither of which bought its way to the audience it has. What is strange is how few companies have decided to build for it on purpose. This playbook is about how you get there.

A community is the one advantage that cannot be replicated in a sprint. It compounds in a direction no budget reaches, because your users end up selling the product for you in places you did not know existed.

The economics follow from there rather than leading. A sales-led motion is expensive to run and limited in how far it can reach, particularly in markets where a company has no presence and no efficient way to build one. Expansion revenue, which sits at the center of PLG, is the most efficient revenue available to any business, because it costs less to grow revenue from existing customers than to win new ones. But the reason to do this is not that it is cheaper. It is that it produces something a competitor cannot buy their way past.

It’s more achievable than you think

Before the chapters, one thing worth saying plainly. Everything I am about to describe looks, from the outside, like work that requires a large team and a budget to match. That impression is the single biggest reason most teams never attempt any of it. It is also wrong. These are mechanisms, they break down into pieces small enough to start on a Monday, and the version of each one that a team of three can run is worth considerably more than the version nobody runs at all.

Who this is for

This playbook is written for people who work close to the product and to the market, and who are looking for new avenues of growth. Some are trained designers and many are not, which matters less than you would expect, because what is useful here is not craft but a way of seeing what design can do once it is pointed at growth rather than at output. If you have ever suspected that design could be doing more for the business than it currently is without being able to say precisely how, this was written with you in mind.

What you should be able to do by the end is look at your own product and recognize where growth is already sitting unused. Beyond that, readers tend to want one of two things from a piece like this. Some want to know whether the idea is real before committing anything further to it, and for them the argument and the examples do most of the work. Others already believe it and want to know what to do on Monday, which is why each mechanism is broken into degrees, with the smallest usable version sitting alongside the ambitious one.

Yet it would be dishonest to present this as a complete account of product-led growth. There are four mechanisms here, and they are the ones that did the most work in the case I watched closely rather than a survey of everything available. Plenty of PLG sits outside them, and much of it is covered well elsewhere. What these four share is that each is a design decision first and a growth outcome second, which is the part that usually goes unexamined.

The four mechanisms

Over the next few weeks I am going to work through the four that did most of the work, one at a time.

Growing up together. How the way a company communicates what it ships turns a changelog into a reason for people to pay attention.

Brand universe. Why the products people love have a personality rather than a tone of voice, and what gets built around the product to make that true.

Self-serve everything. How removing the moments where someone has to ask permission lets your most motivated users move at the speed they actually want to.

Community flywheel. How users become the people who sell your product, and what has to exist before they can.

Each one is a design problem. None of them requires the team you think it requires.