Most launches move fast—especially when you’re a small PMM team. You’re juggling timelines, writing copy, coordinating with teams—just getting everything out the door is a win.

So even though we always send both in-app messages and emails, they’ve usually been planned separately. A quick pass to make sure we’re not repeating ourselves, maybe. But an actual connected strategy across both is not something we’ve nailed.

That’s what we wanted to change with the Workflows launch.

We used Workflows to launch Workflows—testing how well we could guide users through the setup experience with coordinated, behavior-based messages across in-app and email.

Here’s how we made the two channels work together:

Step 1: Map what needs to happen 

Before setting up any messages, we mapped the steps a user needs to take to get started with Workflows. At a high level, it looked something like this:

→ Learn about Workflows
→ Create a Workflow
→ Configure a domain
→ Verify a sender
→ Test
→ Publish

Then we layered on:

• What a user needs at each step (inspiration, instructions, etc.)
• Points of friction
• Existing resources that could help
• Events we needed to track
• Open questions

It looked like a mess of post-its, but seeing everything laid out made it easier to get started.

Step 2: Automate the right messages at the right time

Once we had the map, we started building. Some messages were must-haves, like:

• A feature announcement (personalized based on whether the user had opted into the beta).

Then, we added behavior-based nudges:

• If someone got the announcement but didn’t build a Workflow, they got a follow-up.
• If someone published their first Workflow, they got a celebratory message and encouragement to keep going.
• If someone came back through email, in-app picked up the thread—offering help on each page.

Here's a peek at what it looked like when email pulled users into the product, where an in-app message was ready to carry it forward:

And a glimpse behind the scenes of how our messages came together in Workflows.

Step 3: Show the full experience

Once everything was built, we dropped it all back into Miro. That helped us make sure the messaging lined up—and helped us share the plan internally.

Teams want to know:

• What will users see in the product?
• What message will they get via email?
• What does the full experience look like?

Miro made it easy to show—not just tell. Here's our (cleaned up) template if you'd like somewhere to start from.

It’s not revolutionary, but any momentum is good momentum. And we learned a lot for next time, including:

• Start small—it’s easy to overcomplicate things
• Build one Workflow at a time (and one email or push notification at a time)
• Track every event along the journey from the start
• If something doesn’t work, it’s easy to unpublish and adjust

This was just the first phase. We created what we could within the time we had. Now we’re working on longer-term adoption workflows—nudges tied to usage patterns and key post-launch moments.

If you’re also thinking about how to better connect your channels, here’s our Miro board template.