Project example: Rive feature launches

My role

I led the process from early product context through launch and follow-through.

How the launch process worked

1) Deciding what needed a launch

Not every product update needed the same level of support.

Some were major releases that required a campaign, technical education, in-product messaging, community rollout, and leadership review. Others only needed release notes, a social post, or a smaller customer communication.

I worked across Product, Engineering, Growth, Community, Support, and leadership to understand what was shipping, why it mattered, and how much attention it deserved. From there, I helped define the launch scope, audience, channels, and deliverables.

The goal was to match the effort to the importance of the release without letting meaningful features slip through the cracks or turning every update into a major production.

2) Getting the real story from Product and Engineering

A roadmap rarely arrives as a clear customer narrative.

I met with product and engineering leads to understand:

• How it affected workflows

• Which users it was for

• What problem it solved

• What was technically distinctive

• What limitations or dependencies still existed

• Where users were likely to become confused

I translated that context into a central launch brief the rest of the team could work from.

This was often the point where positioning became clearer, unsupported claims were removed, and internal product language became something customers could actually understand.

3) Building the launch plan

Once the story was clear, I mapped the work required to bring it to market.

Depending on the launch, that could include:

• Announcement blogs

• Technical deep dives

• FAQs

• Release notes

• Email

• Social copy

• Community and Discord posts

• In-product messaging

• Documentation

• Sales or support enablement

• Creative assets

I assigned owners, identified dependencies, established review stages, and built a timeline around the actual product release.

The plan gave every team one place to see what was being made, who was responsible, what information was still missing, and what could block the launch.

4) Establishing one narrative across channels

A launch could not be written separately by every team and still feel coherent.

I created the core messaging foundation: the audience, problem, value proposition, supporting claims, proof points, terminology, and likely objections.

From there, I either wrote the copy myself or helped each owner adapt the narrative for their channel.

The message stayed consistent, but the level of detail and call to action changed. A technical blog needed more depth than a social post (obviously). An in-product message needed to help someone act immediately. A FAQ needed to address uncertainty without repeating the announcement.

5) Coordinating Creative, Product, and channel owners

The copy was only one part of the launch.

I worked with Creative to identify the visuals, demos, screenshots, pull quotes, and product moments that would make the release understandable. I coordinated with Product and Engineering when builds, screenshots, or technical details changed. I also made sure Community, Support, Social, and other channel owners had what they needed before launch day.

A large part of the job was catching the gaps between teams: the missing demo, the outdated screenshot, the unanswered product question, or the asset no one realized another deliverable depended on.

6) Running reviews without losing momentum

Technical launches needed careful review, but too many reviewers could stall the work or blur the message.

I separated different kinds of approval:

• Subject-matter experts verified technical accuracy

• Product confirmed behavior and scope

• Creative reviewed visual execution

• Growth and leadership weighed in on positioning

• I owned structure, clarity, consistency, and final editorial quality

I kept feedback centralized, resolved contradictions, and made sure late product changes were reflected everywhere they needed to be.

7) Managing launch day

Before launch, I confirmed that the product, copy, creative, links, documentation, and distribution plan were aligned.

On launch day, I coordinated publishing across the relevant surfaces and stayed close to Product, Engineering, Community, and Support in case something changed or users encountered confusion.

Because the groundwork had already been done, launch day was usually execution rather than improvisation.

8) Extending the launch beyond the announcement

A launch was not finished when the announcement went live.

I looked for ways to turn the release into ongoing education and adoption: technical follow-ups, documentation improvements, customer stories, examples, tutorials, and future editorial opportunities.

Community and support feedback also helped reveal which parts of the message had landed and which needed clearer explanation.

That made each launch part of a longer product story rather than a single moment in the feed.