Launching features people notice

Software teams now ship faster than their users can keep up. A feature that took a quarter to build can go out in a changelog line on a Tuesday afternoon and never be heard of again. The product gets better every month, and the way it looks, launches and explains itself stays where it was a year ago. This guide is about closing that gap: how to take what the team built and launch it so the people it's for notice, understand and use it.

01Why do good features go unnoticed?

Because they're launched the way they were built. The team spent weeks inside the feature, so the launch describes it from the inside: its name, what it does, how it works. That's accurate, and it's invisible to the people it's for, who weren't in the room and don't think in the team's vocabulary.

Three patterns cause most of it:

• The launch describes the feature, not the change. "New: automatic reminders" tells users something exists. It doesn't tell them why they should care, or when.
• The launch has no proof. A claim without a screen, a record or a user's words asks for trust the product hasn't earned yet.
• The launch lives in one place. A blog post or a changelog entry that nobody visits. The users who'd benefit most are in the product, in their inbox or in a group chat, not on your site.

None of this is a design problem you can fix with better visuals. It's a sequence problem: the launch starts at the wrong point in the story. Our old website had the same problem, and we tore it down in public.

02What makes a feature noticeable?

A feature becomes noticeable as it climbs four rungs, which is the framework we call Feature-to-Moment:

1. Feature: what it is, in the team's words. Accurate, and nearly always invisible.
2. Benefit: what it does for the person using it. Better, and still abstract: "saves time" could describe anything.
3. The moment it matters: the specific point in someone's day when the benefit lands. The task, the pressure, the second before it would have gone wrong.
4. Proof: something the audience can see that makes the moment believable.

Most launches stop on the first or second rung. The ones people remember lead with the third and back it with the fourth. The difference isn't polish; it's which rung the launch starts from.

03How do you find the moment a feature matters?

Not in a brainstorm. The moment already exists in your users' day; you have to find it before you write a word of the launch.

• Start from the problem the feature was built for. Every feature was a response to something: a support ticket, a request, a workaround you saw. Go back to it. That's where the moment lives.
• Find the last time it went wrong. Ask users about the most recent time the problem hit them: what they were doing, what happened next, what it cost. The answers name the moment far better than a persona document.
• Look for the pressure. A moment matters when something is at stake: a customer waiting, money in dispute, a deadline. If there's no pressure, there's no moment, and the feature might be one to launch quietly.
• Check it with the people who use it. Describe the moment to a few users. If they recognise it straight away, you've found it. If they have to think, keep looking.

Some features have no moment. They're maintenance, polish or groundwork for something later. That's fine: not every feature deserves a launch, and pretending otherwise teaches users to ignore the ones that do.

04How do you write the one sentence?

Every launch rests on one sentence that names the moment. Write it before anything else, and don't start the kit until the team agrees on it. A shape that works:

For [who], when [the moment], [the product] now [does what], so [what changes for them].

"For salon owners, when an artist disputes last week's commission, apprn now shows the service, its code and its time, so the answer is on screen instead of in an argument." It's long, and it's specific, which is the point. Short versions come later, cut from this one, for the clip and the posts.

Test the sentence in two ways. Read it to someone who uses the product: if they say "that happens to me", it works. Then take out the product's name and read it again: if it could describe a competitor's feature, the moment isn't specific enough yet. A sentence that fails either test will produce a launch that fails the same way, only more expensively.

The sentence also settles arguments later. When someone wants to add a second message to the email or a new section to the clip, the question is whether it serves the sentence. If it doesn't, it waits for another launch.

05How should the launch tell it?

In five beats, in this order, which is the Narrative Spine:

1. Problem: one specific person, one thing that goes wrong for them today.
2. Stakes: what it costs if nothing changes.
3. Product moment: the moment the product changes the outcome, shown, not described.
4. Proof: why they should believe it will happen for them.
5. Ask: one next step, the right size for this audience.

The same spine runs a twenty-second clip, an email, a launch page and a demo. Only the length of each beat changes. The product arrives third, as the answer to something the audience already cares about, which is exactly what a feature-first launch gets wrong.

Two rules keep it honest. One moment per launch: ten features shown quickly are remembered as none. And one ask: two asks split attention, and none wastes the story.

06What counts as proof?

Proof is whatever lets the audience check the claim for themselves. In order of strength:

• The real product, on screen. Real screens, real data shapes, the real flow. A mock-up that looks better than the product is a promise you'll have to keep.
• The record. If the feature produces something (a log, a receipt, a result), show it. Records are proof because they exist whether or not anyone is watching.
• A user's own words. With permission, and quoted, not paraphrased into marketing.
• A number, with its source. Only one you actually hold, labelled by where it comes from. A borrowed or invented number undoes the whole launch the moment someone checks it.

Label every example by where it comes from: your product, a customer (with permission), or an illustration. It costs nothing, and it's the difference between a launch that builds trust and one that spends it.

07What should a launch ship with?

Write the story once, then package it for every place your users already are. A launch kit usually holds:

• The moment, in one sentence, agreed before anything else is made. Every asset repeats it.
• A short product clip showing the moment on real screens, short enough to watch without sound.
• An in-product announcement, shown to the users who'll hit the moment, at the point they'd hit it.
• An email to existing users, built on the same five beats.
• A launch page or changelog entry that can be read without scripts, with the moment in its opening lines.
• Posts for the channels you actually use, cut from the same clip and copy.
• An update to the help docs, so the people who search for it find the same words.

The existing users come first. They're the people most likely to hit the moment this week, and the people most likely to tell someone else. A launch that reaches new audiences before existing users has the order backwards.

08What's different about launching an AI feature?

Everything above applies, plus three things that AI features make harder.

• Show the answer, and the limits. An AI feature produces different outputs for different inputs, so a single perfect demo overstates it. Show a real case, and say plainly what it doesn't do. Users forgive limits they were told about; they don't forgive discovering them.
• Show what happens when it's unsure. The moment that builds trust in an AI feature is often the one where it hands over to a person, asks a question or declines to guess. If the product does that well, show it. It's proof of judgement, and it's rarer than a clever answer.
• Lead with the moment, not the model. Nobody's day changes because a feature uses a particular model. It changes because a task got easier at a specific moment. Mention the model, if at all, below the fold, for the people who ask.

There's a harder question underneath: whether the feature needed AI at all. If the Remove-the-AI Test says rules would have done most of the job, the launch shouldn't pretend otherwise. "It just works" is a better story than "it's powered by AI" when the first is true and the second isn't the point.

09How do AI tools describe your launch?

More and more people ask an AI assistant what a product does before they visit its site. The assistant answers from what it can read: your pages, your docs, and what others write about you. If your launch lives in a video and a social post, the assistant can't see it, and it will describe your product as it was before the launch.

That's the problem Machine Legibility addresses. For a launch, it means four things:

• One description. The feature and the moment worded the same way on the launch page, in the docs and in the product.
• Crawlable content. The launch page and changelog readable without scripts, with the moment in the opening lines.
• Structured documentation. Help docs with clear headings and the questions users actually ask, answered directly.
• Genuine mentions. Users and partners writing about it in their own words, which you can encourage but never manufacture.

None of this guarantees an AI tool will mention you. It makes sure that when it does, it describes the product you actually shipped.

10How do you launch every month without a crunch?

By treating launches as a system rather than a scramble. Teams that ship monthly and launch monthly usually have three things in place:

• A named owner and an approval path. One person decides what gets launched and signs off the kit. Without an owner, every launch becomes a committee, and committees keep every feature and cut every deadline. It's the governance layer of Brand OS Layers.
• A kit that's the same every month. The same formats, the same sizes, the same order of work. The content changes; the system doesn't.
• A cut-off before the build finishes. The moment is decided while the feature is still being built, so the launch kit is ready when the feature is. Starting the launch after the release is how launches arrive two weeks late.

The rhythm matters more than any single launch. A product that launches something useful every month teaches its users to pay attention. A product that launches in bursts teaches them the opposite.

11How do you know a launch worked?

Not by views. A launch worked if the people it was for started using the feature at the moment it matters. Decide the measure before the launch, and read it from the product, not from the social posts:

• Adoption by existing users: how many of the users who hit the moment used the feature there.
• The moment, repeated back: users describing the feature in words close to the launch's one sentence, in support threads, calls and reviews.
• Questions that stop: the support questions the feature was meant to answer going quiet.

Set your own bar for each, from where you are today. A borrowed benchmark from someone else's product tells you very little about yours.

Then read the result before the next launch, not after the quarter. If adoption was low among the users who hit the moment, the moment was wrong, or the launch never reached them where they'd hit it. If users repeated a different sentence from the one you wrote, listen: they've told you the moment they actually care about, and the next launch should lead with it.

12What are the most common launch mistakes?

• Launching the roadmap instead of the product. "Coming soon" posts spend attention on things users can't use yet. Launch what's live; mention what's next in a line.
• Launching several features at once. A release with five features is a changelog. Pick the one with the strongest moment and launch that; list the rest.
• Making the launch prettier than the product. A launch clip built from mock-ups sets an expectation the first real session breaks.
• Forgetting the people who have to support it. The support team should see the kit before users do, so the first questions get the same answers as the launch.
• Measuring the launch instead of the feature. Views and likes tell you how the launch travelled, not whether anyone's day changed.

Each of these is a sequence mistake more than a craft mistake, which is good news: they're fixed by deciding things in the right order, not by hiring a bigger team.

13Worked example: the code at the chair

Own venture apprn is our agentic salon management venture, in a live test with real salons. Its spine is one verified event: an artist can only start a service by entering a one-time code sent to the customer with that booking. Here's how that feature climbs the four rungs, and how we'd launch it.

On the Narrative Spine, the launch runs: an owner and their best artist disagree about last week's commission (problem); the argument costs the owner the artist, or the artist their trust (stakes); the owner opens the record and both see the same service, code and time (product moment); the record is the screen itself, not a claim about it (proof); for salon owners, one ask: try it in your salon. The story never says "one-time code" until the third beat, and by then the audience knows why it matters.

What we don't do in that launch is claim results the live test hasn't produced. The go or no-go decision is made against kill criteria set before the test, and a launch that got ahead of them would be making, in public, the mistake the whole method exists to catch.

14The launch checklist

Before any feature launch goes out, check it against this list:

1. The moment it matters, in one sentence a user would recognise.
2. The four rungs written down: feature, benefit, moment, proof.
3. The story on five beats, with one moment and one ask.
4. Proof people can check, each piece labelled by where it comes from.
5. The kit: clip, in-product announcement, email, launch page, posts and docs, all repeating the same sentence.
6. Existing users reached first, at the point they'd hit the moment.
7. The launch page and docs readable without scripts, worded the same as the product.
8. A named owner who signed it off.
9. The measure decided before launch, read from the product.

15Questions teams ask about launches