Topic 11 — Go-to-market and launching

Goal: Understand what it takes to release a product to the world successfully.

Lesson 11.1 — The feature nobody used

Maya's team at Lumi spent five weeks building an Excel export. Customers had asked for it for months. It shipped on a Tuesday. By Friday, almost nobody had touched it.

The feature worked perfectly. That wasn't the problem. The problem was that it lived three menus deep, there was no announcement, and the people who'd begged for it had no idea it had arrived. They were still emailing support asking when it was coming.

This is the surprise that catches a lot of new PMs: building the feature is only half the job. Getting it into people's hands so they know it exists and understand why they'd want it is the other half, and it has a name. It's called go-to-market, or GTM for short.

A great feature can still flop when the launch is treated as an afterthought.

Maya had quietly assumed that part was someone else's job. Marketing would handle it. The truth is that how a feature reaches and lands with users is the PM's job too. You can pour months into building something and then leave most of its value on the table by "just turning it on."

Lesson 11.2 — The plan that answers four questions

After the export flop, Priya the designer pulled Maya aside with a simple habit: before anything ships, write down the answers to four questions. That short document is the go-to-market plan.

The four questions are:

• Who is this for, exactly? The target audience.
• What's the message? Why should they care, in one clear sentence?
• How will they find out? The channels: email, in-app notice, social, sales, press.
• Is everyone ready? Do support, sales, and marketing know what's coming?

There's a fifth thing the plan pins down, and it's easy to forget in the excitement of shipping: what success looks like. Which number should move? Maya learned in Topic 9 to name the metric up front. If you don't, you'll launch, feel a vague sense that it went fine, and never actually know whether it worked.

Maya doesn't write all of this alone. The message and positioning are usually led by the Product Marketing Manager (the PMM, from Topic 2). At Lumi that's a colleague who's sharp on how to phrase value so it lands. Maya's lane is product readiness and timing: is the thing actually finished, and is now the right moment? The two of them pulling together is what makes a launch feel deliberate instead of accidental. Coordinating product, message, channels, and team readiness all at once is one of the most visible things a PM does.

Lesson 11.3 — Not every release deserves fireworks

Two things land on Maya's plate the same week: a one-character typo fix on the sign-up screen, and a whole new weekly-budget feature. She catches herself about to give them the same treatment, then stops. A typo fix and a brand-new feature should not be launched the same way.

PMs get this wrong in both directions: throwing a campaign at a tiny tweak, or quietly flipping on a major release that deserved noise. Matching the size of the launch to the size of the change is a real judgment call, and it leans on the risk thinking from Topic 3.

There are three launch types worth knowing:

• Soft launch / rollout — release quietly, often to a small percentage of users first, so you catch problems before everyone sees them.
• Beta — release to a limited group of willing early users who give you feedback before the full launch.
• Full / GA launch — GA stands for "General Availability." Open to everyone, usually with a marketing push for anything big.

So the weekly-budget feature earned a proper GA launch with an email and a blog post, while the sign-up typo got a quiet soft rollout and no campaign at all. Knowing which a given change deserves is part of the instinct you build over time.

Lesson 11.4 — The switch that contains the damage

Picture flipping a big change on for every user at nine in the morning. By nine-fifteen something's broken, and it's broken for all of them at once. Your only move now is a frantic scramble while the support queue fills up.

There's a calmer way, and it runs on a tool called a feature flag. A feature flag is a switch that turns a feature on for some users and off for others without shipping new code. The feature is already deployed and sitting there. The flag just decides who gets to see it.

That switch unlocks a gradual rollout. Instead of going from zero to everyone, you go 1% of users, then 10%, then 50%, then 100%, watching your metrics (Topic 9) at each step. If something breaks at 10%, you've only affected a sliver of people, and you roll back instantly by flipping the flag off. No emergency code, no all-hands panic. You contained the blast radius.

This is the risk management from Topic 3 applied to launch day. You learn as you go instead of betting everything on one big-bang moment. Flags do more, too: they power the A/B tests from Topic 10, and they let you launch to a specific group first, say one country before the rest. For a PM, "let's put it behind a flag and roll it out gradually" is one of the most useful sentences you can say.

Lesson 11.5 — The day after

Launch day feels like an ending. It isn't.

The launch is a milestone, and the most valuable learning shows up right after, when real users meet the thing for the first time. A good PM plans the post-launch before shipping, which closes the lifecycle loop from Topic 3. Four moves:

• Watch the metrics. Did the number you predicted actually move? Any warning signs, like errors, drop-offs, or a wave of complaints?
• Listen. Read the support tickets, the reviews, the user messages. Those first reactions are gold.
• Iterate. Almost nothing is right on the first try. Fix the rough edges, then decide whether to invest more or move on.
• Share the results. Tell the team what happened, the wins and the misses both. Being honest about a miss is what earns the trust that makes your next launch smoother.

The "ship it and move on" instinct throws away exactly the learning that's most worth having. Sam, the senior engineer, respects a PM who comes back a week later with real numbers far more than one who declares victory on launch morning and disappears.

Worked example — The home screen that moved a button

Lumi redesigns its home screen. It's a big one, touching all 2 million users. The reckless move would be to flip it on for everyone at 9am on launch day and hope.

Maya doesn't do that. First she writes a GTM plan. The audience is all users, but messaged warmly as "a faster, cleaner home." There's a one-line value message, three channels (an in-app banner, an email, and a blog post), and support is briefed so they know what's changing before the tickets arrive.

For the release itself she uses a feature flag and rolls out gradually: 1%, then 10%, watching the key metrics. At 10%, engagement is flat, but support tickets suddenly spike. People can't find a button that moved in the redesign. Because only 10% of users are affected, Maya rolls back instantly. The team fixes the discoverability problem, and the rollout resumes, all the way to 100%, this time smoothly.

Then comes the post-launch. Maya watches the metrics for a week, reads the feedback, ships two small fixes, and writes an honest recap for stakeholders that includes the early stumble. Contained risk, real learning, a launch that actually worked.