Design-Driven PLG

Chapter One: Growing Up Together

Aug 25, 2026

A changelog is a record of what a product has become. Most teams treat it as an obligation, and that instinct is understandable, because the work of shipping is exhausting and the record feels like paperwork at the end of it. The change goes out, a line gets added, and the team moves on to whatever is next. Nothing about the process asks anyone to feel something.

Yet the changelog is one of the few surfaces where a company reveals its trajectory, and trajectory is precisely what people are evaluating when they decide whether to commit.

Choosing a product is an investment. Teams are not only asking what a tool does today; they are asking what it will do in a year, whether it will still be maintained, and whether the choice will look sound to the people who approved it. Very little of that can be answered by a feature list. A sustained record of meaningful work shipping answers it without anyone having to make a promise, which makes the changelog the most credible forward-looking claim a company can make.

That signal does different work depending on who is reading it. For prospects, a steady cadence of shipped improvements demonstrates that the product is alive and moving in a direction worth joining. For existing users, each update becomes a reason to return that has nothing to do with a task at hand, which is engagement the team never had to manufacture. And for the champion inside an organization who is trying to get the product approved, the changelog is ammunition, because the argument they need to make internally is almost always about momentum rather than features.

Every update as a moment to be celebrated

Figma and Linear both understood this, though at different scales. Config operates as the annual expression of it, where a room of people discover together what the product is becoming and leave having experienced the change rather than read about it. Linear runs the weekly version, publishing a changelog that reads as though someone is narrating the product’s growth instead of logging it. The mechanism is identical at both sizes: rather than telling people what changed, you let them watch the thing get better.

The gap between these two examples is also where most teams stop reading, assuming that this kind of work requires a team and a budget they do not have. It does not. The practice has degrees, and the useful discipline is matching the degree to the significance of the change.

The four levels

Level one: communicate it better.

The same changelog, written with more care. Describe what improved rather than what was added, because “comments load instantly now” carries more meaning than “performance improvements.” This costs nothing but attention, and it separates you from almost everyone.

Linear’s changelog is designed with the craft of a high quality product experience. The value of each change is clearly communicated, supported by images and video.

Level two: build content from it.

The change becomes a post, an article, a screencast, or a piece explaining the reasoning behind the decision. The work is already done. This level is simply a refusal to let it disappear into a release note.

Linear using video and design assets paired with a post thread to introduce a new feature to create product engagement

Level three: run a session around it.

A webinar, a live walkthrough, or open office hours. The change stops being something people read alone and becomes something they experience together, and the conversation around it becomes part of the update.

Figma and Vercel both run this consistently, and two decisions make it work. The first is that the sessions are archived and published, so a single hour of live production becomes a permanent asset that keeps earning attention long after the release it was built around. The second is that the sessions are not really about the product. They lead with what people are trying to do, and the release is how they do it. That framing is what lets one session serve two audiences at once, pulling in people who have never used the product while giving existing users a reason to show up.

Both also produce this content with partners and community members rather than alone, which lowers the cost of making it and borrows credibility the company could not manufacture internally. The expertise is already out there. The work is inviting it in.

Figma and Vercel run recurring webinars themed around recent releases, archived on their sites for later viewing. Sessions lead with what people want to build, not the feature list, and are frequently produced with partners and community members.

Level four: build an event around it.

Reserved for changes substantial enough to carry a room. This is what Config is, and most teams will reach this level once a year at most. Many never will, and that is a reasonable outcome rather than a failure.

Config is built around new product announcements and major updates, but it never confines itself to them, and the surrounding program speaks to what Figma’s audience cares about independently of the product. That combination is the whole trick. The event sits at the intersection of what the company needs to communicate and what the audience already wants, so the announcements arrive inside something people were going to attend anyway.

Figma did not invent this. Dreamforce is arguably the original version, and Salesforce established the template of the conference as a product moment long before anyone called it PLG. What Figma refined was the temperature. Ten thousand people crossing the world to sit in a room and hear B2B software updates should read as absurd, and the fact that it does not is the strongest available evidence for what this mechanism produces when the underlying relationship is real.

The discipline is in the matching. A level-four treatment applied to a minor fix reads as desperate and erodes trust in everything that follows, while a level-one treatment applied to something that genuinely changes how the product works squanders a moment that will not return. Significant changes are rare enough that spending them carelessly is expensive.

Where design comes in

Everything above is design work, though almost none of it appears in a design team’s remit. The first move is narrative. Every change has a reason it exists and a reason it matters, and the job is to write that down in a way that is both informative and worth reading. Most release notes fail at this not because the writer lacks skill but because nobody framed it as a writing problem in the first place.

The second move is a shift in standard. The content that lives outside the product deserves the same care the product gets. A changelog entry, a launch video, a webinar, a conference session: these are not afterthoughts to be handled once the real work is done, they are first-class experiences and they behave like the product in every way that matters to the person receiving them. Nearly everything else follows from adopting that posture.

The third move is recognizing that live sessions and events are experience design, which is a discipline designers already understand. Pacing, attention, what a person feels at the start and what they leave with. These are the same questions a designer asks about a flow. The skills transfer almost completely. They are simply not pointed in this direction, because nobody has told the design team that the conference is theirs to shape.

What this actually requires is copywriting, visual design, storytelling, and event production. Few teams are strong in all four, and that is a normal condition rather than a disqualifying one. The tooling available now closes most of those gaps at a level that would have required a specialist a few years ago. The constraint is rarely capability, and a team that is not attempting any of this is leaving growth on the table that no amount of additional headcount will recover.

What emerges from working this way is a shift in how the team relates to its own roadmap. The release schedule stops being an internal planning document and becomes the raw material for a continuous, credible argument about where the product is going. Most teams already have everything they need for this. They are simply not publishing it.

What’s easy to miss is that almost every company doing this well is B2B. Figma, Linear, Vercel, Notion. None of them sell to consumers, and all of them generate the kind of attention around a release that people normally associate with consumer products. The difference is not the market. It is that they treat a product update as something worth being present for, and consumer companies have always understood that instinct while enterprise software mostly forgot it.

The shift this produces is larger than the changelog itself. A company whose updates are opaque gives nobody any reason to pay attention, so nobody does, and every release lands in silence. A company that works this way ends up with users watching what ships, forming opinions about the direction, and cheering when something they wanted arrives. That audience is built out of transparency rather than budget, which is why it is available to teams of almost any size.

Chapter Two, Brand Universe, is next. It covers 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. You will get an email when it goes live, so there is nothing to keep track of.

In the meantime, if something here raised a question about your own product, or you are trying to work out what this would look like inside your organization, reply to the email that brought you here and tell me where you are stuck. I read every one, and I answer the ones I can be useful on.