Product-Led Growth skill 10 of 13

In-App Messaging SKILL.md

The In-App Messaging skill makes Claude, Codex or another AI agent plan product messages that guide rather than interrupt. It inventories messages, chooses formats for announcements, tips, nudges, surveys, upgrade prompts, service notices and help, targets by behaviour, sets priority and frequency rules, writes short copy, coordinates with email, gives messaging one owner and calendar and measures outcomes.

in-app-messaging/SKILL.md, version 1.0.0, 1,527 words.

In-app messages reach users while they're using the product: announcements of new features, tips at the right moment, nudges towards key actions, surveys, upgrade prompts, maintenance notices and help. Used well, they guide users towards value without leaving the product. Used badly, they become a stream of pop-ups that interrupt work, get dismissed without reading and train users to ignore every message. As more teams gain access to in-app messaging tools, coordination becomes as important as copy.

This skill plans in-app messaging programmes: message types, targeting and triggers, frequency and priority rules, copy, coordination with email and other channels, governance across teams, surveys and feedback, and measurement.

Operating principles

  1. Context beats broadcast. Messages tied to what the user is doing outperform announcements to everyone.
  2. Fewer, better messages. Each message should earn the interruption.
  3. One owner, one calendar. Coordinate messages across product, marketing, success and sales.
  4. Match the format to the urgency. Banners, tooltips, modals and inboxes suit different needs.
  5. Measure the outcome, not the view. Did the user take the action that matters?

Message types and formats

TypeFormatExample
Feature announcementInbox item, small banner, modal for major launches"Scheduled reports are here"
Contextual tipTooltip or hotspotSuggest a shortcut when the user repeats an action
Action nudgeChecklist item, slideout"Connect your calendar to see availability"
SurveyNPS or one-question survey"How easy was setting up your first report?"
Upgrade promptContextual paywall or bannerAt limits or premium features
Service noticeTop bannerMaintenance or incident updates
HelpHelp widget, chat, resource centreSearchable help in context

When to use, and when not to

Use it when launching features, guiding users to key actions, collecting feedback, coordinating messages across teams and reducing reliance on email for product guidance.

Don't use it for email or SMS lifecycle programmes (the CRM and Lifecycle skills) or website pop-ups for visitors (the CRO popups-onsite-messaging skill).

Inputs to ask for, in one message

  1. In-app messaging tool and current messages.
  2. Product events available for targeting.
  3. User segments (role, plan, lifecycle stage, activity).
  4. Upcoming launches and campaigns.
  5. Which teams send messages today.
  6. Engagement and outcome data for past messages.

Raw SKILL.md file

.md

This is the exact file agents read, including the credit header and licence notice. Save it as in-app-messaging/SKILL.md.

---
name: in-app-messaging
description: "Plan in-app messaging that guides rather than interrupts: announcements, contextual tips, action nudges, surveys, upgrade prompts, service notices and help, behavioural targeting and triggers, priority and frequency rules, short copy, coordination with email, one owner and calendar, retirement of stale messages and outcome metrics. Use whenever someone asks about in-app messages, product announcements, tooltips, in-app surveys or NPS, too many pop-ups in the product, coordinating in-app and email messages or governance for product messaging."
license: CC-BY-4.0
metadata:
  author: Afeez Adebayo
  author_url: https://afeezadebayo.com
  author_linkedin: https://www.linkedin.com/in/afeez-adebayo/
  author_x: https://x.com/za_icon
  source: https://afeezadebayo.com/skills-md/marketing/product-led-growth/in-app-messaging/
  category: marketing
  subcategory: product-led-growth
  version: "1.0.0"
  created: "2026-10-10"
  updated: "2026-10-10"
---

# In-App Messaging

In-app messages reach users while they're using the product: announcements of new features, tips at the right moment, nudges towards key actions, surveys, upgrade prompts, maintenance notices and help. Used well, they guide users towards value without leaving the product. Used badly, they become a stream of pop-ups that interrupt work, get dismissed without reading and train users to ignore every message. As more teams gain access to in-app messaging tools, coordination becomes as important as copy.

This skill plans in-app messaging programmes: message types, targeting and triggers, frequency and priority rules, copy, coordination with email and other channels, governance across teams, surveys and feedback, and measurement.

## Operating principles
1. **Context beats broadcast.** Messages tied to what the user is doing outperform announcements to everyone.
2. **Fewer, better messages.** Each message should earn the interruption.
3. **One owner, one calendar.** Coordinate messages across product, marketing, success and sales.
4. **Match the format to the urgency.** Banners, tooltips, modals and inboxes suit different needs.
5. **Measure the outcome, not the view.** Did the user take the action that matters?

## Message types and formats
| Type | Format | Example |
|---|---|---|
| Feature announcement | Inbox item, small banner, modal for major launches | "Scheduled reports are here" |
| Contextual tip | Tooltip or hotspot | Suggest a shortcut when the user repeats an action |
| Action nudge | Checklist item, slideout | "Connect your calendar to see availability" |
| Survey | NPS or one-question survey | "How easy was setting up your first report?" |
| Upgrade prompt | Contextual paywall or banner | At limits or premium features |
| Service notice | Top banner | Maintenance or incident updates |
| Help | Help widget, chat, resource centre | Searchable help in context |

## When to use, and when not to
Use it when launching features, guiding users to key actions, collecting feedback, coordinating messages across teams and reducing reliance on email for product guidance.

Don't use it for email or SMS lifecycle programmes (the CRM and Lifecycle skills) or website pop-ups for visitors (the CRO `popups-onsite-messaging` skill).

## Inputs to ask for, in one message
1. In-app messaging tool and current messages.
2. Product events available for targeting.
3. User segments (role, plan, lifecycle stage, activity).
4. Upcoming launches and campaigns.
5. Which teams send messages today.
6. Engagement and outcome data for past messages.

## Workflow

### Step 1. Inventory messages
List all live messages with triggers, audiences, owners and results.

### Step 2. Define goals per message type
Adoption, activation, feedback, upgrades or service information.

### Step 3. Set targeting and triggers
By behaviour (did or didn't do something), plan, role, lifecycle stage and page.

### Step 4. Set priority and frequency rules
Maximum messages per session and per week; priority order when several qualify.

### Step 5. Write the message
Short headline, one benefit, one action, easy dismissal.

### Step 6. Coordinate channels
In-app for guidance during use; email for users who aren't active; avoid sending both for the same thing at once.

### Step 7. Govern
One owner, a shared calendar, review for new message types, retirement of stale messages.

### Step 8. Measure
View, click, dismissal and, most importantly, the target action and downstream retention.

## Priority and frequency rules (example)
- Service notices override everything.
- Then onboarding guidance for new users.
- Then contextual tips and adoption nudges.
- Then announcements and surveys.
- At most one modal per session and two non-blocking messages per day per user.
- No marketing announcements during first-run onboarding.

## Message copy template
```
Headline (5-8 words): what's new or what to do
Body (1-2 sentences): the benefit for this user
Action: one button with a clear verb
Dismiss: visible close or "Not now"
```

## Targeting examples
| Audience | Trigger | Message |
|---|---|---|
| Activated users who haven't connected an integration | Third visit to reports | "Connect your CRM to keep reports up to date automatically." |
| Admins on Team plan | Login after a security feature launch | "New: require SSO for your workspace." |
| Users who completed a key task | Task completion | One-question survey about ease |
| Inactive for 14 days | Next login | "Here's what changed since your last visit." |
| Free users at 80% of a limit | Limit threshold | Limit warning with upgrade option |

## Format guide
| Format | Interruption | Use for |
|---|---|---|
| Tooltip or hotspot | Low | Explaining a feature in context |
| Inbox or resource centre | Very low | Announcements and updates users can browse |
| Slideout | Medium | Nudges and short surveys |
| Banner | Medium | Service notices, account-wide information |
| Modal | High | Major launches for relevant users, critical changes |

## Metrics
| Metric | Why |
|---|---|
| Target action completion | Whether the message worked |
| Click-through and dismissal rate | Relevance and annoyance |
| Messages seen per user per week | Fatigue risk |
| Feature adoption or upgrade lift versus holdout | Real impact |
| Survey response rate and scores | Feedback quality |

## Governance checklist
- Named owner for in-app messaging.
- Shared calendar visible to all teams.
- Templates and copy guidelines.
- Review for new message types and major launches.
- Monthly clean-up of expired or low-performing messages.
- Holdout groups for important nudges.

## Surveys inside the product
Ask one question at a meaningful moment, such as after a first report or a support interaction, rather than random NPS pop-ups. Sample a share of users, limit surveys to one per user per quarter, and close the loop by sharing what changed. Route detractors to success or support quickly.

## Channel coordination
In-app messages reach active users; email reaches people who haven't logged in. Use shared events so a user who completes an action stops receiving both, and never send the same announcement through every channel at once.

## Edge cases and judgement calls
| Situation | What to do |
|---|---|
| Many teams want to message users | Central calendar and approval for new campaigns |
| Major launch | Modal for the relevant segment only, plus inbox and email for others |
| Survey fatigue | Sample users; limit surveys per user per quarter |
| Mobile apps | Shorter messages; respect notification permissions |
| Enterprise customers | Let admins control certain announcements |

## Handoffs to related skills
- Onboarding guidance: `in-product-onboarding`
- Feature adoption: `feature-adoption`
- Upgrade prompts: `in-app-upgrade-prompts`
- Education resources: `product-education`
- Lifecycle emails: the CRM and Lifecycle skills
- Website pop-ups: the CRO `popups-onsite-messaging` skill

## Worked example
A SaaS company let product, marketing and success all send in-app messages, and some users saw four modals in one session. Engagement with messages fell and support complaints rose. The company created a single owner and calendar, set priority and frequency rules, replaced most announcements with an inbox and contextual tips, kept modals for major launches to relevant segments and retired 60% of stale messages. Click-through on remaining messages rose, feature adoption from tips improved and complaints dropped.

## Output format
```
# In-app messaging plan: <product>, <date>
## Inventory and retirement list
## Message types and goals
## Targeting and triggers
## Priority and frequency rules
## Copy guidelines
## Channel coordination and governance
## Metrics
```

## Common mistakes
- Broadcasting every announcement as a modal.
- No frequency limits.
- Several teams messaging without coordination.
- Measuring views instead of actions.
- Stale messages left running for years.

## Questions to ask before you plan
- What should users do differently after each message?
- Who owns in-app messages across teams?
- How many messages does a typical user see per week?

## Self-check before you answer
- Are messages targeted by behaviour and context?
- Are priority and frequency rules set?
- Is there one owner and calendar?
- Are outcomes, not views, measured?

## Further reading
- Intercom on in-app messaging: https://www.intercom.com/blog/

---
Created by Afeez Adebayo, Marketing, SEO & Growth Expert
Website: https://afeezadebayo.com
LinkedIn: https://www.linkedin.com/in/afeez-adebayo/
X: https://x.com/za_icon
Source: https://afeezadebayo.com/skills-md/marketing/product-led-growth/in-app-messaging/

Licence: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). You may copy, share and adapt this skill, including for commercial use, as long as you credit Afeez Adebayo and link to the source URL above. Keep this notice in any copy or adapted version.

Workflow

Step 1. Inventory messages

List all live messages with triggers, audiences, owners and results.

Step 2. Define goals per message type

Adoption, activation, feedback, upgrades or service information.

Step 3. Set targeting and triggers

By behaviour (did or didn't do something), plan, role, lifecycle stage and page.

Step 4. Set priority and frequency rules

Maximum messages per session and per week; priority order when several qualify.

Step 5. Write the message

Short headline, one benefit, one action, easy dismissal.

Step 6. Coordinate channels

In-app for guidance during use; email for users who aren't active; avoid sending both for the same thing at once.

Step 7. Govern

One owner, a shared calendar, review for new message types, retirement of stale messages.

Step 8. Measure

View, click, dismissal and, most importantly, the target action and downstream retention.

Priority and frequency rules (example)

  • Service notices override everything.
  • Then onboarding guidance for new users.
  • Then contextual tips and adoption nudges.
  • Then announcements and surveys.
  • At most one modal per session and two non-blocking messages per day per user.
  • No marketing announcements during first-run onboarding.

Message copy template

Headline (5-8 words): what's new or what to do
Body (1-2 sentences): the benefit for this user
Action: one button with a clear verb
Dismiss: visible close or "Not now"

Targeting examples

AudienceTriggerMessage
Activated users who haven't connected an integrationThird visit to reports"Connect your CRM to keep reports up to date automatically."
Admins on Team planLogin after a security feature launch"New: require SSO for your workspace."
Users who completed a key taskTask completionOne-question survey about ease
Inactive for 14 daysNext login"Here's what changed since your last visit."
Free users at 80% of a limitLimit thresholdLimit warning with upgrade option

Format guide

FormatInterruptionUse for
Tooltip or hotspotLowExplaining a feature in context
Inbox or resource centreVery lowAnnouncements and updates users can browse
SlideoutMediumNudges and short surveys
BannerMediumService notices, account-wide information
ModalHighMajor launches for relevant users, critical changes

Metrics

MetricWhy
Target action completionWhether the message worked
Click-through and dismissal rateRelevance and annoyance
Messages seen per user per weekFatigue risk
Feature adoption or upgrade lift versus holdoutReal impact
Survey response rate and scoresFeedback quality

Governance checklist

  • Named owner for in-app messaging.
  • Shared calendar visible to all teams.
  • Templates and copy guidelines.
  • Review for new message types and major launches.
  • Monthly clean-up of expired or low-performing messages.
  • Holdout groups for important nudges.

Surveys inside the product

Ask one question at a meaningful moment, such as after a first report or a support interaction, rather than random NPS pop-ups. Sample a share of users, limit surveys to one per user per quarter, and close the loop by sharing what changed. Route detractors to success or support quickly.

Channel coordination

In-app messages reach active users; email reaches people who haven't logged in. Use shared events so a user who completes an action stops receiving both, and never send the same announcement through every channel at once.

Edge cases and judgement calls

SituationWhat to do
Many teams want to message usersCentral calendar and approval for new campaigns
Major launchModal for the relevant segment only, plus inbox and email for others
Survey fatigueSample users; limit surveys per user per quarter
Mobile appsShorter messages; respect notification permissions
Enterprise customersLet admins control certain announcements
  • Onboarding guidance: in-product-onboarding
  • Feature adoption: feature-adoption
  • Upgrade prompts: in-app-upgrade-prompts
  • Education resources: product-education
  • Lifecycle emails: the CRM and Lifecycle skills
  • Website pop-ups: the CRO popups-onsite-messaging skill

Worked example

A SaaS company let product, marketing and success all send in-app messages, and some users saw four modals in one session. Engagement with messages fell and support complaints rose. The company created a single owner and calendar, set priority and frequency rules, replaced most announcements with an inbox and contextual tips, kept modals for major launches to relevant segments and retired 60% of stale messages. Click-through on remaining messages rose, feature adoption from tips improved and complaints dropped.

Output format

# In-app messaging plan: <product>, <date>
## Inventory and retirement list
## Message types and goals
## Targeting and triggers
## Priority and frequency rules
## Copy guidelines
## Channel coordination and governance
## Metrics

Common mistakes

  • Broadcasting every announcement as a modal.
  • No frequency limits.
  • Several teams messaging without coordination.
  • Measuring views instead of actions.
  • Stale messages left running for years.

Questions to ask before you plan

  • What should users do differently after each message?
  • Who owns in-app messages across teams?
  • How many messages does a typical user see per week?

Self-check before you answer

  • Are messages targeted by behaviour and context?
  • Are priority and frequency rules set?
  • Is there one owner and calendar?
  • Are outcomes, not views, measured?

Further reading

When to use this skill, and when not to

Use it when launching features, guiding users to key actions, collecting feedback, coordinating messages across teams and reducing reliance on email for product guidance.

In-app messages reach users at the right moment, but without coordination they become a stream of pop-ups that interrupt work and train users to ignore everything. As more teams gain access to messaging tools, governance matters as much as copy.

Don’t use it for email and SMS programmes (use the CRM and Lifecycle skills) or website pop-ups (use the CRO Popups skill).

Example prompts

  • “Users see too many pop-ups. Set rules.”
  • “Plan in-app announcements for our launch.”
  • “Write a contextual tip for our reports feature.”
  • “Set up in-app surveys without annoying people.”
  • “Who should own in-app messaging?”

Example output

The skill returns a fixed structure. A shortened example for an imaginary site:

# In-app messaging plan: example SaaS, 12 October 2026

Before: product, marketing and success all sent messages; some users saw 4 modals a session
New: one owner and calendar; priority and frequency rules; inbox and contextual tips; modals only for major launches to relevant segments; 60% of stale messages retired
Result: higher click-through, better adoption, fewer complaints

Messages are judged on the action users take afterwards, not on views or clicks alone.

What the agent needs from you

The skill asks for the messaging tool and current messages, product events for targeting, user segments, upcoming launches, the teams sending messages and past engagement and outcome data.

How this skill hands off to related skills

Messaging connects to the set: Onboarding, Feature Adoption, Upgrade Prompts and Education, plus the CRM and Lifecycle skills and the CRO Popups skill.

How to run In-App Messaging step by step

  1. Install the skill as in-app-messaging/SKILL.md.
  2. Inventory live messages.
  3. Set goals, targeting and triggers.
  4. Set priority and frequency rules.
  5. Write short, clear copy.
  6. Govern and measure outcomes.

Situations this skill handles

Messaging programmes vary. The skill handles these situations:

SituationWhat the skill does
Many teams messagingCentral calendar and approval
Major launchModal for relevant segment only
Survey fatigueSampling and quarterly limits
Mobile appsShorter messages, permission respect
Enterprise customersAdmin control of announcements
Stale messagesMonthly clean-up

What makes this skill different

Most in-app messaging grows by addition until users tune out. This skill inventories what exists, retires stale messages, targets by behaviour and sets rules for priority and frequency across every team.

It measures whether users actually did the thing each message asked, so only useful messages survive.

Practical tips from real projects

  • Context beats broadcast.
  • Fewer, better messages.
  • One owner, one calendar.
  • Measure the outcome.

A worked example: a SaaS company let product, marketing and success all send in-app messages, and some users saw four modals in one session. Engagement with messages fell and support complaints rose. The company created a single owner and calendar, set priority and frequency rules, replaced most announcements with an inbox and contextual tips, kept modals for major launches to relevant segments and retired 60% of stale messages. Click-through on remaining messages rose, feature adoption from tips improved and complaints dropped.

Message types match formats: feature announcements in an inbox or small banner, with modals only for major launches; contextual tips as tooltips or hotspots when users repeat an action; action nudges as checklist items or slideouts; surveys as single questions; upgrade prompts at limits; service notices as top banners; and help through widgets and resource centres.

Targeting uses behaviour, plan, role, lifecycle stage and page. Activated users who have not connected an integration see a prompt on their third visit to reports; admins see new security features; users who complete a key task get a one-question survey; users returning after two weeks see what changed; free users at 80% of a limit see a warning.

Priority rules put service notices first, then onboarding guidance for new users, then contextual tips and adoption nudges, then announcements and surveys. Frequency rules allow at most one modal per session and two non-blocking messages per day, with no marketing announcements during first-run onboarding.

Copy stays short: a five to eight word headline on what is new or what to do, one or two sentences on the benefit for this user, one button with a clear verb and a visible way to dismiss.

Governance names one owner, keeps a shared calendar visible to all teams, uses templates and copy guidelines, reviews new message types and major launches, cleans up expired or low-performing messages monthly and keeps holdout groups for important nudges.

Surveys ask one question at a meaningful moment, sample a share of users, are limited to one per user per quarter and route detractors to success or support quickly.

Formats differ in how much they interrupt: tooltips and hotspots interrupt little and suit features in context; inboxes and resource centres interrupt even less and suit announcements users browse; slideouts and banners sit in the middle for nudges and notices; and modals interrupt most, so they are kept for major launches and critical changes. In-app messages reach active users while email reaches people who have not logged in, so shared events stop a user who completes an action from receiving both, and announcements never go through every channel at once. Metrics track target action completion, click-through and dismissal rates, messages seen per user per week as a fatigue signal, adoption or upgrade lift against holdouts and survey response rates and scores. Mobile apps use shorter messages and respect notification permissions, and enterprise customers can let admins control certain announcements for their teams.

Stale messages left running for months are the most common cause of fatigue, so the inventory is repeated every month.

Frequently asked questions

Messages shown inside the product, such as announcements, tips, nudges, surveys, upgrade prompts, service notices and help.

A common rule is at most one modal per session and two non-blocking messages per day per user.

Tooltips for features in context, inboxes for announcements, slideouts for nudges and surveys, banners for notices and modals only for major launches.

One named owner with a shared calendar across product, marketing, success and sales.

In-app for active users, email for inactive ones, with shared events so users do not get both for the same thing.

By target action completion and downstream retention, ideally against holdouts.

Changelog

  • 1.0.0, 10 October 2026: first release.

Use, adapt and share this skill under CC BY 4.0: credit Afeez Adebayo and link to this page.