Tag: CRM integration

How to Turn Pendo Adoption Signals Into Revenue Growth

Your Pendo dashboard can be green while revenue stays flat. Guide clicks, tour completions, and first-time feature use show that something happened inside the product. They do not tell you whether a customer reached value, formed a durable habit, renewed, or became ready to expand.

A Pendo-led growth motion works only when you connect product behavior to a commercial decision. You need a traceable path from an eligible user, to a valuable behavior, to an account-level change, to an owned go-to-market action, and finally to a revenue outcome. This is how to build that path without mistaking activity for impact.

Build the revenue path before you build the guide

Do not begin with a broad goal such as increase adoption. Begin with a decision someone needs to make. Which trial accounts deserve sales attention? Which new customers need onboarding help? Which established accounts show credible retention risk? Which accounts are approaching an expansion conversation?

For one target segment, write the path in this order:

Commercial outcome: the CRM result you ultimately care about, such as trial conversion, renewal, or expansion.
Eligible cohort: the users or accounts that could reasonably produce that outcome. Exclude employees, test accounts, ineligible plans, and anyone who has already completed the journey.
Value event: the action that represents meaningful progress in the customer’s job, not merely a page view or button click.
Activation milestone: the point at which the user has completed enough of the workflow to experience initial value.
Durable behavior: the repeat usage, adoption depth, collaboration, or seat activity that separates discovery from an established habit.
Commercial trigger: the combination of behaviors that should create a sales, marketing, or customer-success action.
Owner and response: the person responsible, the next action, and the condition that closes or suppresses the signal.

A generic trial journey might move from connecting data, to completing a core workflow, to returning and repeating it, to inviting colleagues, and then to meeting a defined sales-ready condition. The exact events will differ by product. The discipline is to explain why each event is evidence of customer value and why the final signal should change a commercial decision.

Time-to-value, feature adoption depth, active usage, and completed trial milestones can help identify purchase readiness. But each metric needs product-specific qualification. Weekly activity is useful only when the workflow naturally recurs weekly. Seat growth is meaningful only when additional users participate in the valuable workflow. A feature click is rarely sufficient evidence on its own.

Start with one or two high-impact lifecycle plays. Trying to instrument onboarding, conversion, retention, and expansion at once usually leaves every definition open to debate. A narrow pilot forces the team to settle the difficult questions before multiplying them.

Turn those decisions into a data contract shared by product, growth, RevOps, sales, and customer success. Record the event name, qualifying properties, user and account identifiers, time rule, exclusions, CRM destination, accountable owner, and consent requirements. Define whether an event can occur more than once, how merged identities behave, and what happens when the same person belongs to multiple accounts. Privacy-by-design matters here because behavioral data becomes more sensitive when combined with contact and account context.

Freeze the definitions for the duration of the pilot. If the activation milestone or eligible population changes after results appear, you no longer have a stable comparison. Log the change as a new version and evaluate it separately.

Use in-app guidance as a targeted intervention

Pendo guides are the intervention layer, not the strategy. Their job is to remove a specific obstacle between the eligible user and the next value event. If you cannot name the obstacle and the desired behavior, the guide is likely to become an announcement that generates attention without changing adoption.

Create a short intervention brief before building anything:

Audience: the role, lifecycle stage, account state, and relevant prior behavior.
Entry condition: the event or state that makes the message useful now.
Friction: the missing knowledge, unclear choice, or incomplete prerequisite preventing progress.
Next action: one observable behavior the user can complete.
Success event: the downstream product event that counts as progress.
Exit condition: the event that permanently stops the guide for that journey.
Fallback: help content, support, or human outreach for users who cannot complete the action.

Match the format to the problem. Use a tooltip when a specific control needs context. Use a short product tour when the user must understand a sequence. Use a banner for broad awareness when an immediate workflow is not required. A modal demands attention, so reserve it for information that justifies interrupting the user.

Behavioral targeting and progressive disclosure help keep guidance relevant. Show the smallest useful instruction at the decision point, then offer deeper help only when the user requests it or reaches the next step. Suppress the experience as soon as the success event occurs. Repeatedly explaining a completed task trains users to dismiss future messages.

Test outcome-first copy, placement, calls to action, and guide format, but choose the experiment’s primary outcome outside the guide. A click-through rate can diagnose whether the message earned attention. It cannot establish that the user completed the valuable workflow.

Define the eligible population before exposure, assign treatment consistently, and select a follow-up window that matches the workflow’s natural cadence. Randomize at the user level when the intervention affects an individual task. Randomize at the account level when colleagues share the experience or one user’s behavior can influence another’s. Otherwise, treatment can leak into the control group.

Pendo Predict can be used to rank segments by likelihood to convert, expand, or churn. Treat that score as a targeting and prioritization input, not as causal proof. Comparing a high-likelihood group with a low-likelihood group will mostly reveal that the groups were different before the intervention. To learn whether the intervention worked, compare similar eligible users or accounts with and without it.

Turn product signals into owned revenue actions

A behavioral signal creates no commercial value while it sits in an analytics dashboard. Connecting Pendo behavior with HubSpot contact and account context makes the signal available inside the workflow where sales, marketing, and customer-success decisions already happen.

The routing design should answer four questions: What happened? Why does it matter? Who owns the response? When should the signal be ignored or closed?

Commercial decision	Qualifying product evidence	Owned action	Suppression rule
Trial conversion	Activation milestone completed, meaningful feature depth, or a short product-specific time-to-value	Route the recent behaviors and account context to the sales owner for tailored discovery	Exclude internal, test, expired, or already-converted accounts; do not qualify on a guide click alone
Onboarding recovery	A prerequisite remains incomplete or progress stalls before the value event	Coordinate the next lifecycle message, contextual guide, or customer-success task	Stop the journey immediately after milestone completion or confirmed ineligibility
Retention protection	Use of a core workflow declines relative to the account’s relevant baseline	Ask customer success to verify the context before choosing outreach, training, or an in-app intervention	Do not label the account as churn risk until role changes, expected inactivity, and other context have been checked
Expansion qualification	Seat usage grows, more users complete the valuable workflow, or premium capabilities receive meaningful use	Ask the account owner to validate the need, entitlement, and buying context before opening an expansion motion	Suppress duplicate alerts and activity caused by testing, administration, or temporary access

Send the evidence behind a signal, not just a label such as hot account or churn risk. The receiving record should include the user and account, triggering behaviors, event timestamps, comparison baseline where relevant, cohort or model version, recommended next action, owner, and current status. If a predictive score is involved, include the behaviors that make the score actionable.

My rule is simple: if a signal does not change a named person’s next decision, it should not be synchronized yet. Sending every event to the CRM creates noise, duplicate outreach, and mistrust. Send the smallest set of behavioral fields that supports a real decision, then add fields only when an owner can explain how they will use them.

The same discipline applies to coordinated journeys. An email, chat message, sales task, and in-app guide should not all fire independently from the same behavior. Give the journey one state model so that completing the action in any channel suppresses the remaining prompts. The customer should experience one coherent response, not the internal boundaries between tools.

Measure incremental lift, not dashboard activity

Measurement should follow the same chain as the strategy. Keep each stage visible so you can find where performance broke rather than collapsing the journey into a single adoption score.

Reach: exposed eligible users divided by all eligible users. This reveals targeting or delivery problems.
Guide response: users taking the guide’s intended action divided by exposed users. This evaluates the prompt, not the business result.
Activation: eligible users completing the defined milestone divided by the eligible population.
Sustained adoption: initial adopters who repeat the valuable workflow during the predeclared follow-up window divided by all initial adopters.
Account progression: eligible accounts reaching the defined health, collaboration, usage-depth, or sales-ready condition.
GTM response: routed signals that receive the intended owned action, including a documented disposition.
Commercial outcome: the relevant CRM result, such as conversion, renewal, or completed expansion, measured at the same entity level as the purchase decision.

The entity level matters. Guides are often experienced by users, while renewals and expansions happen at the account level. Aggregate user behavior before joining it to an account outcome, and avoid treating multiple exposures inside one account as multiple commercial opportunities.

Separate influence from incrementality. An influenced account encountered a guide or met a Pendo cohort definition before a commercial outcome. That sequence can support diagnosis and attribution, but it does not establish that the intervention caused the outcome. Incremental impact is the additional result produced compared with what similar eligible accounts would have done without the intervention.

Use a randomized holdout when the product experience and sample allow it. Declare the primary outcome, minimum effect worth detecting, assignment unit, follow-up window, and stopping rule before launch. Do not stop when an early fluctuation looks favorable. If randomization is impractical, use a staged rollout or a carefully matched comparison cohort, control for concurrent campaigns, and describe the result as directional rather than causal.

Keep campaign identifiers, guide versions, cohort versions, and event timestamps in the joined dataset. Without them, a launch email, sales outreach, pricing change, and in-app guide can all receive credit for the same outcome. Joining usage cohorts, feedback, lifecycle activity, and pipeline context is useful precisely because it lets you inspect the whole path rather than award credit to the most visible touchpoint.

At each review, ask where the chain changed. Did the intervention increase activation? Did activation become repeated use? Did account behavior cross the commercial threshold? Did the routed owner respond? Did the CRM outcome move against a credible comparison? Scale only when the evidence survives that sequence. If guide engagement rises but the next product event does not, fix the intervention. If product behavior changes but the commercial result does not, revisit the signal definition or GTM response.

Key takeaways

Choose a revenue decision before choosing a Pendo guide, segment, or dashboard.
Define activation as a meaningful value event and distinguish it from discovery, clicks, and first use.
Use Predict scores to prioritize attention, then use a valid comparison to measure whether the intervention caused lift.
Route only signals that include evidence, an owner, a next action, and a suppression condition.
Optimize for sustained behavior and account progression; use guide engagement as a diagnostic metric.
Pilot one or two lifecycle plays, stabilize the data contract, and expand only after the full path works.

For your next rollout, select one commercial question and write its behavioral path before opening the guide builder. Confirm the eligible cohort, success event, control, CRM owner, and exit condition. When every owner can explain the chain in the same terms, Pendo becomes more than an adoption tool: it becomes part of a measurable revenue operating system.

References

January 3, 2026

Activation to Win-Back: A Practical Retention System

Your acquisition dashboard can look healthy while the product underneath it is quietly shrinking. Signups rise, campaigns perform, and new accounts appear every day, yet too few users reach value, return for it, or recover after they drift away.

If that is the problem in front of you, do not launch another generic onboarding project or win-back email. Build one lifecycle system that can tell you which users have not found value, which users are receiving it repeatedly, which users are losing momentum, and what action should move each group forward.

Build the lifecycle around value, not visits

Activation, retention, and reactivation are not three independent growth programs. They are transitions between states in the same user journey:

A new user arrives with a job to complete.
The user activates by experiencing a meaningful result for the first time.
The user becomes retained by repeating that result at a cadence appropriate to the job.
The user becomes at risk when the behaviors associated with that result weaken.
The user becomes dormant when meaningful use stops.
The user is reactivated only when meaningful use resumes.

This sequence matters because a login proves almost nothing. A person can log in, fail to recover their workflow, and leave more frustrated than before. Counting that visit as a win inflates campaign performance while hiding the product problem.

Write operational definitions for every state

Your definitions must be precise enough that analytics, product, lifecycle marketing, support, and customer success classify the same account the same way. Write them before debating tactics:

New and unactivated: eligible for the core use case but has not completed the activation event within its defined window.
Activated: completed the event that represents a first successful outcome, not merely a setup step.
Retained: repeated a meaningful behavior at the expected product cadence.
At risk: still active, but frequency, depth, milestone completion, or another leading behavior has declined.
Dormant: no longer meets the meaningful-use cadence for its segment.
Reactivated: returned from dormancy, completed a meaningful outcome again, and showed evidence that usage could continue.

Do not use one dormancy window for every product or segment. A product used for a daily workflow and one used for a periodic job should not declare users lost on the same schedule. Start from the natural frequency of the job, then define the point at which a missed cycle represents real disengagement.

Put five measures on one scorecard

A useful lifecycle scorecard answers five different questions. Blending them into a generic active-user total removes the diagnostic value.

Activation rate: What share of eligible new users reaches the value event within the activation window?
Time to value: How long does it take those users to get there, and where does the slowest part of the distribution stall?
Retention: What share repeats meaningful use at the expected cadence? Day 1, Day 7, Day 30, and weekly engaged usage are useful only where they fit the product’s usage pattern.
Risk incidence: What share of currently engaged users crosses a defined behavioral-risk threshold?
Reactivation rate: What share of eligible dormant users returns to meaningful value, rather than merely opening a message or logging in?

Break each measure down by first-seen cohort, use case, plan, activation depth, and other segments that change the journey. A blended average can rise because the mix of users changed even when no individual experience improved.

Fix activation before asking users to return

Activation is the first credible proof that your product delivered what the user came for. Depending on the product, that might be sending a first campaign, completing an integrated workflow, or producing another finished result. It is not account creation, a page view, an invitation sent without acceptance, or a button click that leaves the underlying job unfinished.

A clear activation event gives you a causal hypothesis to investigate: users who reach this result should be more likely to return because they have experienced the core value proposition. The relationship still needs validation through cohort analysis of activation and later retention; naming an event does not make it predictive.

Define activation in five passes

Choose the user’s primary job. If the product serves several distinct jobs, define activation for each use-case segment rather than forcing one event across the entire product.
Name the earliest event that proves the job produced a result. Prefer a completed outcome over an action that only begins the process.
Add the properties that distinguish success from an attempt. A workflow started, failed, or abandoned should not look identical to one completed successfully.
Set a time window based on how soon a qualified user should reasonably experience value. This turns activation into a rate and time-to-value measure rather than a lifetime count.
Compare later retention for users who activated and those who did not, within comparable cohorts. Repeat the check by segment. If the event does not separate later behavior, it is probably a weak proxy.

For a product with a naturally weekly job, a 7% day-7 return rate can serve as a pragmatic launch checkpoint. Treat it as a signal to investigate, not a universal law. Product cadence, audience, maturity, and the event used to define a return all affect the curve. Crossing the line does not prove product-market fit, and missing it does not tell you which part of the journey failed.

Remove the friction that blocks the value event

Once the event is defined, inspect the path immediately before it. Start with the three largest sources of activation friction, not every imperfection in onboarding.

If an empty account makes the product incomprehensible, use sample data, templates, or a pre-built starting point that lets the user see the intended workflow.
If setup requires unnecessary decisions, remove non-essential fields and provide defaults that can be changed later.
If users know what they want but cannot find the next action, place a contextual tooltip or in-app guide at that decision point. A full product tour is rarely a substitute for local clarity.
If users complete setup but still do not reach value, shorten the distance between configuration and the first finished outcome. Setup completion should not become a comforting proxy for success.
If one segment activates while another stalls, change the path or promise for the struggling segment rather than adding more instructions for everyone.

Measure both activation rate and time to value. A change can leave the overall activation rate flat while helping qualified users succeed much sooner, or raise the rate by attracting low-intent completions that do not retain. The two measures reveal different failure modes.

Before an A/B test, define the minimum detectable effect: the smallest improvement large enough to justify the change and worth designing the experiment to detect. Name one primary metric, the evaluation window, and guardrails such as downstream retention or support demand. Otherwise, a small movement in tutorial completion can be mistaken for meaningful product progress.

Read retention as a diagnosis, not a score

Retention tells you whether value is repeatable. The number alone does not tell you why users leave. To get that answer, inspect the curve by cohort and connect the drop to a stage in the journey: signup, onboarding, first value, repeated use, or the paywall.

The shape of the behavior gives you a starting hypothesis:

A sharp drop before first value usually points to qualification, expectation, onboarding, or setup friction.
Strong activation followed by weak repeat use suggests the activation event is not predictive enough, the value is primarily one-time, or the next reason to return is unclear.
A drop concentrated around a paywall calls for a pricing and packaging review, not another tooltip.
Healthy individual use with weak account-level expansion may mean collaboration, permissions, or adjacent workflows are difficult to adopt.
A problem concentrated in one use case or plan should be solved in that segment before you change the default journey for everyone.

Run the retention diagnosis in a fixed order

Create first-seen cohorts so users who entered during different product and go-to-market conditions are not blended together.
Measure return through a meaningful event or engaged-use definition, not any session.
Split the curve by activation status. If activated users retain substantially better, focus on moving more qualified users to activation. If both groups decline similarly, inspect the value proposition and repeat-use loop.
Split by use case, plan, and activation depth. Activation is often graduated: completing one basic outcome is different from connecting the product deeply enough to make it part of an ongoing workflow.
Inspect what changed before disengagement: frequency, session depth, missed milestones, unfinished workflows, or loss of collaboration. Pair the behavioral pattern with focused customer discovery so the team does not confuse correlation with cause.

This sequence prevents a common prioritization error. If activation is the main leak, adding a new engagement feature gives most new users one more thing they will never reach. If already-activated users stop after a successful first use, making signup shorter will not create a reason to return.

Match the intervention to the leak

For onboarding abandonment, remove work, clarify the next decision, and preserve progress so the user can resume.
For slow time to value, use templates, sample data, and smart defaults to make the result visible sooner.
For weak repeat use, surface the next valuable action in the context created by the first success. Do not send users back to a generic dashboard and expect them to reconstruct the journey.
For pricing friction, connect the paid boundary to value already experienced. More reminders will not repair packaging that appears before the product earns trust.
For shallow account adoption, make collaboration and permissions support the job instead of adding administrative burden.

Expansion belongs after the core journey holds. Prompts for adjacent features, collaboration, or upgrades can compound a healthy use case, but they also distract users who have not completed the primary job. Sequence the experience around the user’s progress, not the number of features available.

Require experiments to prove downstream value

Write every retention hypothesis in an auditable form: Among [cohort] experiencing [friction], [change] should improve [meaningful behavior] by at least [minimum detectable effect] within [window], without harming [guardrails].

A click, message open, tour completion, or session start can help explain the path, but none should be the final success metric. Tie the experiment to activation, repeated meaningful use, feature-adoption depth, or another behavior with a defensible relationship to retained value. Use holdout groups for lifecycle interventions when possible so ordinary returns are not credited to the campaign.

Design win-back around the reason momentum stopped

Dormant users can be an efficient growth audience because they already have product context, historical behavior, and some degree of familiarity. That advantage is only useful when the return path matches what happened before they left. A generic message about what is new asks the user to solve the diagnosis for you.

Segment by the last successful use case, activation depth, plan, and observed friction. Three cohorts provide a practical starting structure for targeted win-back programs:

Cohort	Behavioral trigger	Return path	Definition of a win
Stalled onboarding	A required milestone was started but not completed, or the user never reached the activation event.	Resume from saved progress, remove the known blocker, and use a contextual guide for the next necessary action.	The user completes the activation outcome within the chosen window and begins the next relevant action.
Lapsed power user	Historically deep or frequent use declines relative to that user’s established pattern.	Restore the previous workflow. Mention a new capability only when it directly improves the use case the user already valued.	The user completes a meaningful core action again and resumes the expected usage cadence.
Trial expired after partial success	The trial ended after some useful activity, but activation depth or value realization remained incomplete.	Return the user to saved work, clarify the remaining path to value, and align any offer with actual usage rather than applying an automatic discount.	The user reaches meaningful value again, followed by the intended conversion or continued-use behavior.

Make the campaign continue the product journey

Trigger from behavior, not a broad calendar blast. Dormancy should reflect a missed value cadence or a clear decline from an established pattern.
Reference the last relevant outcome or unresolved job. The message should answer why returning is useful now.
Deep-link to the exact workflow, saved state, or next action. Sending everyone to the home screen recreates the friction that contributed to the lapse.
Remove one blocker at a time. A single relevant call to action is easier to evaluate than a digest of features, offers, and educational content.
Coordinate email, in-app messaging, CRM tasks, and human outreach from the same lifecycle state. Once a user advances, exit that user from the old sequence immediately.
Preserve trust with transparent messaging, appropriate use of behavioral data, and easy opt-outs. Reactivation should restore value, not manufacture pressure.

Be careful with discounts. A price-sensitive cohort may respond to a usage-based offer or a limited boost tied to value realization, but discounting every dormant account hides whether price caused the lapse. It can also reward waiting instead of adoption. Test the offer against a non-discount return path and judge both on retained value, not immediate conversion alone.

Measure incremental reactivation

The primary unit of win-back is not the recovered login. Define a meaningful reactivation event, a window for completing it, and the follow-on behavior that indicates restored momentum. Then compare eligible users who received the intervention with a holdout group.

Reactivation lift: the difference in meaningful reactivation between the treated cohort and its holdout.
Time to restored value: the elapsed time from intervention to the completed reactivation event.
Adoption depth: whether users merely repeated one action or rebuilt the workflow associated with continued use.
Near-term retention: whether reactivated users continue at the expected cadence after the initial return.
Expansion signals: whether renewed usage produces qualified movement toward deeper adoption or an appropriate upgrade.
Guardrails: opt-outs, support demand, campaign fatigue, and any decline in healthy cohorts accidentally exposed to the program.

A weak result is still useful when it changes the roadmap. If stalled users repeatedly fail at the same setup step, fix the step. If power users lapse after a workflow becomes cumbersome, remove that friction. If an offer brings users back only until the offer ends, the campaign has exposed a value or packaging problem rather than solved retention.

Use one operating rhythm for the full lifecycle

Activation, retention, and win-back should appear in the same product review. A weekly review can stay compact if it answers five questions:

Which first-seen and use-case cohorts moved between lifecycle states?
Where is the largest current loss of qualified users?
What did the active experiment change, including its guardrails and minimum detectable effect?
Which win-back segment produced incremental restored value rather than ordinary returns?
Which recurring friction belongs on the product roadmap instead of in another message?

The answers create clear decision rules. If activation is weak, repair first value before buying more traffic. If activation improves but later retention does not, challenge the activation proxy or the repeat-value loop. If one segment retains well while another collapses, protect the healthy path and solve the segment-specific problem. If win-back increases logins without meaningful use, stop celebrating the campaign metric and repair the return experience.

Key takeaways

Define activation as a completed user outcome within a clear window, then verify that it predicts later retention.
Use a 7% day-7 return rate only as a checkpoint for products with an appropriate weekly cadence, not as a universal standard.
Diagnose retention by cohort, activation status, use case, plan, and activation depth before choosing an intervention.
Match onboarding, engagement, pricing, and collaboration changes to the specific stage where value breaks down.
Segment win-back by prior behavior and cause of dormancy, then return the user to the exact workflow that can restore value.
Measure reactivation against a holdout using meaningful product outcomes, near-term retention, and trust guardrails.

Start with one use-case segment. Write its activation event, activation window, retained-use cadence, risk signal, dormancy rule, and reactivation event on a single page. Instrument the missing transitions, find the largest leak, and commit to one measurable intervention. Once that path reliably carries users from first value to repeated value, acquisition and win-back can amplify something worth scaling.

References

December 3, 2025

How to Turn Unified Product Analytics Into a Growth System

You are probably not short of dashboards. You are short of a trusted answer when acquisition, onboarding, sales, and retention compete for the next investment.

If product analytics says activation improved while the CRM shows no pipeline movement and support sees rising friction, another dashboard will not settle the issue. A unified approach gives you a traceable path from customer behavior to business outcome, then builds a decision cadence around it. The fastest way to get there is to prove that path on one consequential growth decision before consolidating the rest of the stack.

Key takeaways

Unify a decision before you unify every tool. Choose a customer journey where conflicting data is delaying a roadmap, budget, or go-to-market decision.
Build a metric spine, not a metric pile. Connect a North Star to leading indicators, guardrails, and diagnostic metrics so each measure has a clear job.
Treat tracking as a data contract. Event names, identity rules, eligibility criteria, exclusions, and CRM mappings must be explicit before a dashboard can be trusted.
Make every insight end in an action. A change in the data should lead to a decision, investigation, experiment, product change, or deliberate choice to do nothing.
Consolidate tools after the growth loop works. Preserve historical data and downstream dependencies before retiring anything that cannot be recreated.

Start with the decision that keeps getting delayed

Analytics unification often begins as a migration project: inventory the tools, compare capabilities, choose a destination, and move the dashboards. That sequence can produce a cleaner stack without producing a better decision.

Start with the disagreement that is consuming leadership attention. It might be whether to put the next growth investment into acquisition quality, first value, repeated value, or re-engagement. It might be whether a launch generated meaningful adoption or merely initial curiosity. Write that decision down before anyone discusses vendors or dashboard layouts.

A useful decision brief contains:

The decision: the actual choice that someone has authority to make.
The owner: the person who will change a priority, budget, workflow, or customer experience when the evidence changes.
The eligible population: the users or accounts included in the analysis, plus explicit exclusions such as employees, test accounts, or customers who could not encounter the experience.
The customer outcome: the behavior that represents receiving value, not merely viewing a page or clicking a control.
The business outcome: the pipeline, retention, expansion, or cost consequence expected to follow.
The observation window: how long the behavior needs to mature before the result is interpretable.
The required evidence: the product, attribution, CRM, support, and qualitative signals needed to make the choice.

Then select one customer journey that exposes the problem end to end. For a product-led motion, that could run from acquisition source to signup, first value, repeated value, retained use, and a relevant CRM or support outcome. In a business-to-business product, preserve both the individual user and account views. A highly engaged user inside an otherwise inactive account tells a different story from broad adoption across the account.

A practical unification boundary links product usage, marketing attribution, sales pipeline, and customer support signals around that journey. You are unified enough when every team can trace the same eligible account through the path, calculate the same metric from the same definition, and understand which action the result should change.

Use a simple acceptance test. Can a product manager identify the accounts that reached first value but did not return? Can growth compare acquisition channels using retained value rather than signups alone? Can sales see the relevant product behavior without inventing a second definition of activation? Can support connect recurring friction to the affected journey stage? Can a leader move from the headline outcome to the underlying cohort without asking for a manual spreadsheet reconciliation?

If the answer is no, adding more executive charts will hide the gap rather than close it.

Do not confuse a single source of truth with a single operational database. Marketing automation, product telemetry, CRM, billing, and support systems can continue serving different jobs. The requirement is that governed definitions, identity mappings, and business logic produce the same answer wherever the decision is made.

This is also why tool consolidation should not come first. Canceling an analytics product before documenting exports, historical definitions, scheduled reports, downstream integrations, and access requirements can remove baselines you cannot recreate. Establish the replacement path and validate the decision workflow before retiring the old one.

Build a metric spine from customer value backward

My rule is simple: if a metric cannot change a decision, diagnose a result, or protect against harm, it does not belong in the primary growth view.

A unified growth strategy needs a small metric hierarchy. The North Star expresses recurring customer value. Leading indicators show whether customers are moving toward that value. Guardrails reveal an unacceptable tradeoff. Diagnostic metrics help you locate the mechanism when the outcome changes.

Metric layer	Question it answers	Typical evidence	Decision it supports
North Star	Are target customers receiving recurring product value?	Completion or consumption of the core value exchange at the appropriate user or account level	Strategy, investment, and portfolio allocation
Leading indicator	Are customers progressing toward recurring value?	Activation milestone, meaningful setup, repeated use, or adoption across the relevant account	Onboarding, lifecycle messaging, and product intervention
Guardrail	What must not deteriorate while the primary metric improves?	Errors, support friction, cancellation behavior, poor-quality pipeline, or another protected outcome	Whether to ship, stop, narrow, or revise a change
Diagnostic	Where and for whom did the result change?	Journey step, cohort, channel, plan, account type, role, or product surface	Investigation and targeted response

The North Star should describe value delivered through the product, not simply a number that appears in an executive report. Revenue and pipeline still matter, but they often arrive after the behaviors the product team can change. Your metric spine should show the path between those behaviors and the later business result.

For every metric, create a contract containing:

The metric name, owner, and business question.
The unit of analysis: user, account, workspace, transaction, or another relevant entity.
The eligible population and entry condition.
The exact value event or state transition.
The numerator and denominator when the metric is a rate.
The observation window, time-zone rule, and cohort boundary.
Exclusions for internal activity, test data, bots, deleted entities, and known instrumentation gaps.
The identity-join logic across anonymous use, authenticated use, accounts, and CRM records.
The system of record, expected freshness, and treatment of late-arriving data.
Known limitations and the date or condition that should trigger a definition review.

An activation definition, for example, should be expressible without interpretation: eligible new accounts that complete the agreed value event within the agreed observation window, divided by all eligible new accounts. The event, eligibility rule, account definition, and window should be references to governed fields, not blanks that each function fills differently.

Next, draw the causal logic you intend to test. Acquisition quality affects who enters the journey. Activation reflects whether those customers reach initial value. Engagement reflects whether value repeats. Retention indicates whether the relationship persists. Pipeline, conversion, expansion, or service cost connects that product behavior to the business.

Do not label a behavior as a leading indicator because it occurs early. Validate whether cohorts that perform it are associated with stronger later outcomes. Retention analysis, trustworthy instrumentation, and a small set of outcome-linked metrics provide the evidence for that relationship. Even then, association is not causation. Treat the relationship as a prioritization signal until an experiment or other credible design tests the mechanism.

This hierarchy also prevents an output from masquerading as an objective. Shipping a redesigned onboarding flow is an output. Improving the proportion of eligible accounts that reach verified first value is an outcome. The roadmap item is a proposed intervention; the metric is how you decide whether it worked.

Make shared data trustworthy before making it self-serve

Self-serve analytics magnifies whatever sits underneath it. With clean definitions, it reduces queueing and lets teams answer follow-up questions while the decision is still live. With inconsistent events and identity rules, it distributes contradictory answers faster.

Use an event taxonomy people can read

Choose a naming grammar and enforce it. A pattern such as object_action makes events easier to scan: account_created, integration_connected, or report_exported. The exact grammar matters less than using it consistently.

Keep mutable dimensions in properties rather than multiplying event names. Do not create separate events for the same export action on different plans, roles, or product surfaces. Use one event with governed properties for plan, role, surface, and other relevant context. Otherwise every dashboard must reconstruct a fragmented behavior before it can analyze it.

Each event definition should specify the trigger, actor, object, required properties, data types, allowed values, expected firing behavior, exclusions, owner, and versioning rule. Include a plain-language sentence explaining what happened in the customer’s world. If that sentence is ambiguous, the event will be ambiguous too.

Resolve identity at the level where value occurs

A user identifier is not enough when the buying, adopting, and renewing entity is an account. Define how an anonymous visitor becomes an authenticated user, how that user belongs to an account, and how the account maps to the corresponding CRM company and relevant pipeline object.

Decide what happens when accounts merge, users change companies, an administrator owns several workspaces, CRM records are duplicated, or ownership changes. Preserve historical truth when mutable fields change. If the current sales owner overwrites the owner attached to an earlier event, a historical pipeline analysis may silently answer the wrong question.

A closed-loop join should let you answer questions such as:

Which acquisition segments bring accounts that reach and repeat product value, rather than merely registering?
Which product behaviors occur before a meaningful pipeline transition?
Which support themes are concentrated among accounts that fail to activate or retain?
Which customer roles adopt the product, and whether that adoption spreads across the account?
Whether a launch changed sustained behavior for its target cohort, not just initial exposure?

These questions are the practical payoff of connecting the product data layer to CRM and lifecycle signals. They turn attribution from a handoff report into a view of the whole value path.

Put quality, governance, and privacy in the release path

Instrumentation is part of the product. Review it with the change that creates the behavior, not as a cleanup task after launch. A tracking plan that never reaches engineering acceptance criteria is documentation, not control.

Use this release checklist for events that affect a growth metric:

The event fires on the defined positive path and does not fire on the relevant negative path.
Required properties arrive with the expected types and governed values.
Retries, refreshes, and repeated actions do not create unintended duplicates.
Anonymous-to-authenticated identity stitching preserves the journey.
User-to-account and account-to-CRM mappings follow the documented rules.
Internal, test, and automated activity is identifiable and excluded where required.
Version changes and backfills are documented so historical comparisons remain interpretable.
The dashboard calculation reconciles with the approved metric contract for a defined cohort.
Freshness and quality failures create a visible warning with a named owner.

Bad data should fail visibly. A dashboard carrying a freshness or quality warning is safer than a polished chart that silently stopped receiving valid events.

Apply privacy-by-design at the same point. Record why each property is needed, minimize personal data, restrict access by purpose, define retention and deletion behavior, and make consent requirements part of the collection design. Moving unnecessary sensitive fields into a unified platform increases exposure without improving the decision.

Once the journey is trustworthy, audit the tool stack by job rather than feature list. For each tool, record the decision it supports, owner, active consumers, system-of-record responsibility, integrations, scheduled outputs, export options, historical retention, access controls, overlapping capabilities, and switching cost.

Retire a tool only after the replacement reproduces the governed metric, downstream dependencies have moved, required exports are preserved, and the accountable owners accept the new workflow. Deleting historical analytics can erase baselines that cannot be reconstructed. Archive them safely when contractual, privacy, and retention requirements allow it.

Turn analytics into a repeatable growth operating cadence

A unified dashboard is an interface. The growth system is the behavior around it. Every material signal should move through the same sequence: detect, diagnose, decide, intervene, and learn.

Detect: identify a meaningful change in an outcome, leading indicator, guardrail, or data-quality measure.
Diagnose: segment by cohort, journey stage, account type, channel, role, or product surface. Use support evidence and customer discovery to distinguish measurement artifacts from genuine friction.
Decide: name the constraint, the decision owner, the proposed action, the expected metric movement, and the condition for revisiting the choice.
Intervene: run an experiment, change the experience, adjust targeting, revise lifecycle communication, enable a customer-facing team, or deliberately leave the product unchanged.
Learn: record the result, update the metric or journey model when necessary, and feed the learning into discovery, roadmap planning, positioning, and enablement.

Match data freshness to actionability. Immediate data is valuable when someone can respond immediately, such as to broken instrumentation or a sudden onboarding failure. A retention outcome still needs its cohort to mature. Labeling an incomplete cohort as real time does not make its conclusion ready.

The recurring growth review should not be a tour of every dashboard. Use an agenda built around decisions:

Which decision changed since the previous review?
Did any data-quality issue invalidate the current interpretation?
Where is the largest observed constraint in the selected journey?
Which segment is driving the change, and which segment is masking it?
What did the active experiments or interventions teach you?
What will change in the roadmap, product experience, go-to-market motion, or support workflow?
Which assumption remains untested?

Keep a decision log beside the analytics. For each consequential choice, capture the question, metric version, cohort, evidence considered, action, owner, expected outcome, guardrails, and revisit condition. This protects the organization from retrofitting a convenient story after the result appears. It also turns past decisions into reusable institutional knowledge.

Use experiments to test mechanisms, not to decorate launches

A useful hypothesis names the cohort, change, primary outcome, mechanism, and guardrails: for the target cohort, changing this part of the experience should improve this outcome because it removes or strengthens this specific behavior, without harming these protected measures.

Before an A/B test begins, define eligibility, assignment unit, primary metric, guardrails, minimum detectable effect, data-quality checks, and the decision rule. The minimum detectable effect and success criteria belong in the experiment design, not in the interpretation after results arrive.

The minimum detectable effect is the smallest difference worth reliably distinguishing for the decision in front of you. It is not the lift the team hopes to report. If the available traffic cannot support the sensitivity the decision requires, narrow the question, choose a more observable leading indicator with a validated connection to the outcome, use a staged rollout, or accept that the evidence will be directional. Do not lower the bar after seeing the result.

Not every change needs an A/B test. Foundational infrastructure, mandatory compliance work, and experiences with insufficient eligible traffic may require other evaluation methods. Be explicit about the weaker causal confidence of before-and-after comparisons, and combine them with cohort analysis, instrumentation checks, support evidence, and customer discovery.

Close the loop with product discovery and go-to-market teams

Behavioral data is strong at showing what happened, where the journey changed, and which cohorts differ. Customer conversations and support evidence help explain why. Use the combination to update the opportunity being pursued, not merely the solution already selected.

The value measured in the product should also match the value promised in the market. If positioning emphasizes a customer outcome while the growth model rewards shallow activity unrelated to it, marketing, sales, product, and customer success will optimize different realities.

For each launch, state the target cohort, customer problem, intended behavior change, primary metric, guardrails, and evidence customer-facing teams should observe. Product tours, in-app guidance, sales enablement, and lifecycle messages can then reinforce the same path to value rather than creating disconnected adoption campaigns.

Pick the growth decision currently consuming the most meeting time. Write its decision brief, choose the customer journey that exposes it, and hold the executive dashboard until the identity rules and metric contract are clear. When the team can move from signal to action without reconciling competing spreadsheets, extend the pattern to the next journey. That is the point at which unified analytics becomes strategy infrastructure rather than reporting overhead.

References

December 3, 2025

Own Your AI: 4 Essential Roles to Supercharge Support and Prevent Performance Drift by 2026

AI doesn’t fail because the model is bad, it fails because ownership is missing.

When someone truly owns your AI, everything changes. Resolution and automation rates climb, the system self-improves, and the customer experience transforms in ways a dashboard alone will never show you.

This is part three of our five-part series on customer service planning for 2026. We’ll be sharing all five editions on our blog and on LinkedIn.

If you’d rather have them emailed to you directly as they’re published, drop your details here.

Last week, we introduced the four roles that make AI actually work in a support organization. These roles are already showing up inside the teams who are scaling AI the fastest, and this week, we get closer to the ground.

Here’s what these roles look like in practice — what they do, how they work, and why your AI performance will inevitably drift without them.

AI operations lead — owns AI performance, every day. I think of this person as the air-traffic controller for our AI Agent. I treat the AI as a living system that needs ongoing supervision, evaluation, and tuning. This role is accountable for what leaders care about most: quality, reliability, and continuous improvement.

The AI ops lead sees the whole picture: conversation quality, missing knowledge, flawed assumptions, unexpected failures, new opportunities for automation, and the subtle signals that the system is beginning to drift. In practice, that vigilance is the difference between steady gains and slow decline.

Day-to-day, here’s what I expect from this role.

1. Reviews AI conversations and surfaces performance patterns. The AI ops lead monitors the AI Agent’s behavior — the tone shift after a product launch, a sudden dip in resolution for a specific intent, or conversation clusters revealing new customer behavior. They scan for anomalies, trends, and early warnings, with an emphasis on what’s happening right now, not last week. Without this intentional ownership, I’ve watched a 2% dip turn into a 10% drop in days.

2. Prioritizes fixes and improvements. Once patterns emerge, they triage fixes like a product team handles bugs. Missing or incorrect content? They route it to the knowledge manager. Behavioral issues? They adjust guidance and guardrails. Action or system issues? They partner with the automation specialist. This connective tissue turns individual fixes into compounding improvements.

3. Defines and maintains AI guardrails. Leaders everywhere worry about AI doing things it shouldn’t. This role answers that fear by establishing clarification logic, escalation rules, “never answer” policies, and safety boundaries. The goal is predictable behavior that protects customer trust — an essential pillar of any AI Strategy and AI risk management practice.

4. Aligns reporting with leadership. The AI ops lead reports on resolution rate, CX Score, CSAT, automation coverage, and hours saved — making the economic impact visible. That visibility is a foundational step in any credible customer support ai strategy.

Why this role exists now. AI systems are dynamic and require constant tuning. A small dip in quality quickly becomes an operational issue, and no existing role naturally owns that. When someone does, teams feel the benefit almost immediately.

Knowledge manager — builds and maintains the structured knowledge AI depends on. I hear the same thing from leaders again and again: AI is only as good as the content you give it. This role is rapidly evolving from classic knowledge management into knowledge strategy — part content designer, part systems thinker, part information architect. Their job is to build the knowledge scaffolding that lets AI answer accurately, consistently, and safely.

Here’s how the knowledge manager creates leverage.

1. Writes, maintains, and improves support knowledge — continuously. After every product change, they update articles, remove duplication, resolve contradictions, and pay down “knowledge debt” that quietly erodes accuracy. The upkeep is shaped by AI performance; when patterns expose gaps, they fix the source.

2. Structures knowledge for AI, not for browsing. Traditional help centers are for humans skimming pages. AI needs clean intent signals, crisp formatting, and clearly structured language. The knowledge manager designs that structure as intentionally as the content itself.

3. Works hand-in-hand with AI ops. Many performance issues stem from missing or unclear knowledge. When the AI ops lead surfaces recurring misunderstandings or low-resolution categories, the knowledge manager resolves the root cause at the source.

4. Ensures accuracy and compliance at scale. As AI handles more sensitive situations, the knowledge manager safeguards correctness, currency, and compliance — critical for data governance and regulatory alignment.

5. Develops a cross-functional knowledge strategy. The role creates a canonical, cross-functional source of truth that product, engineering, product marketing, go-to-market, and support (AI and human) can all rely on.

Why this role exists now. This is one of the highest-leverage positions in an AI-first support org. Teams like Rocket Money and Anthropic are hiring knowledge managers because AI accuracy depends on the quality of knowledge feeding it. Without this role, resolution rate caps out early and never climbs.

Conversation designer — designs how the AI speaks, clarifies, and interacts. AI isn’t just a tool customers use; it’s a representative they interact with. Tone, clarity, pacing, and conversational structure matter, especially in voice. Every word affects perceived expertise, trustworthiness, and brand. The conversation designer ensures the AI feels human-friendly without pretending to be human — the sweet spot that builds trust without misleading customers.

In my experience, staffing conversation design early accelerates results. It changes not only how we tune AI, but how we understand the end-to-end customer experience.

Here’s what great conversation design looks like.

1. Shapes the AI’s tone, voice, and communication style. This role refines phrasing, tunes politeness, adjusts how confusion is handled, and shapes micro-interactions that determine whether customers feel cared for or dismissed. On voice channels, natural cadence is make-or-break.

2. Designs flows for high-value conversations. They design how the AI clarifies intent, branches, communicates uncertainty, verifies details, escalates, hands off, and returns to the main thread without feeling mechanical — treating customer experience as a product with language as the interface.

3. Translates procedures and complex workflows into natural language and logic. As AI runs structured procedures and actions, this role becomes a conversational system architect, translating SOPs into conditional logic with exceptions and fallbacks. For example, in Intercom, our conversation designer uses Simulations to run simulated conversations to see where the AI Agent gets confused, over-confident, or awkward, and refine flows until the interaction feels effortless end-to-end.

4. Ensures transitions to humans feel smooth and respectful. Handoffs should provide clear context to the human agent and maintain continuity so customers never feel dropped.

Why this role exists now. As AI becomes the primary interface, conversation design directly influences trust, brand perception, and operational outcomes. It’s a core competency for any Generative AI and LLMs for product managers program.

Support automation specialist — builds the backend actions that allow AI to do real work. If the conversation designer shapes expression, this role shapes capability. They transform AI from an answering machine into an outcome engine by bridging AI and the systems it must safely and deterministically act on.

Support teams increasingly expect AI to do what a human would do: refund a charge, adjust a subscription, verify an identity, update an account setting, or pull relevant data. That expectation creates a new technical role at the edge of support, ops, and engineering.

What I rely on this specialist to deliver.

1. Creates and maintains backend workflows the AI executes. This includes building and maintaining: Fin Tasks. Fin Procedures with embedded steps. Action flows that call internal and external APIs. Automations that span billing systems, user identity layers, CRM objects, subscription entitlements, refund tools, and more. They ensure the AI can act compliantly and predictably — the playbooks that turn intent into action.

2. Owns the integrations required for advanced automation. Many problems require data elsewhere — billing platforms, internal databases, systems of record. The specialist ensures the AI can retrieve, validate, and use that information safely, often partnering closely on CRM integration and internal services.

3. Partners closely with product and engineering. Some workflows require new endpoints, permission layers, safety gates, or deterministic fallbacks. This role drives those changes across the stack.

4. Ensures reliability and safety at every step. Guardrails, validation logic, exception handling, safe execution paths — all are essential. They confirm that the AI has access to the correct data, the action matches policy, edge cases are accounted for, risky flows have deterministic constraints, and every action is auditable and reversible.

Why this role exists now. Customers don’t want answers, they want outcomes. AI can now deliver those outcomes, but only with the right backend scaffolding. This role modernizes operational architecture and unlocks end-to-end automation.

How these roles work together — the new operating loop. These roles aren’t silos; they’re interdependent parts of one system. The AI ops lead identifies patterns and performance gaps. The knowledge manager resolves inaccuracies or missing content. The conversation designer improves clarity, tone, and flow. The automation specialist expands the system’s ability to take action. Each improvement compounds the next, moving you from early automation to transformational resolution rates through continuous refinement.

This loop is what separates teams that plateau early from teams that scale AI into a reliable, high-performing system — the essence of a durable AI Strategy.

How to get started (even if you can’t hire all four roles today). Most teams phase into this model: assign partial ownership, formalize responsibilities, then specialize as AI volume grows. Here’s the progression I recommend.

Phase 1: Assign ownership. Give each role’s core responsibilities to someone who can devote five to 10 hours weekly. Early on, support ops, enablement, senior ICs, and technically inclined teammates can anchor the work.

Phase 2: Formalize the responsibilities. As AI resolves more queries, optimization becomes core operational work. Formalizing ownership prevents performance drift and knowledge debt.

Phase 3: Specialize and hire. Once AI handles 50–70% of incoming volume, these responsibilities become full-time roles. Investing in specialization becomes essential infrastructure for the next scale stage.

The bottom line. AI changes the shape of your support team. These four roles — AI operations lead, knowledge manager, conversation designer, and support automation specialist — form the backbone of the AI-first support organization. They bring order to a constantly changing environment and enable AI to deliver the outcomes leaders and customers expect heading into 2026.

Next week, we’ll continue the 2026 planning series with a deep dive into org design models for AI-first support teams — how to structure people, workflows, and accountability in a world where AI resolves most conversations before a human ever sees them.

To follow along with the series and have each new edition emailed to you directly, drop your details here.

Inspired by this post on The Intercom Blog.

December 2, 2025

How to Build Marketing Analytics That Measures Revenue

You are probably not short of marketing data. The harder problem appears when a budget decision is due: campaign reports show conversions, the CRM shows pipeline, product analytics shows activation, and finance shows revenue. Every number can be locally correct while the business still cannot explain which investment created durable growth.

If you need to decide where the next dollar or product sprint should go, do not start by choosing a more elaborate attribution model. Build a measurement chain that follows an eligible customer from a consented marketing touch to product value, commercial outcomes, retention, and expansion. Then match each decision to the kind of evidence it actually requires.

Start with the revenue decision, not the dashboard

A dashboard becomes useful only when someone can name the decision it is meant to change. “Improve marketing performance” is not a decision. Reallocating campaign spend, changing an audience, fixing trial onboarding, revising lifecycle messaging, or testing a pricing signal are decisions.

Before requesting another report, write a short measurement brief with these fields:

Decision: What will you start, stop, scale, or change?
Eligible population: Which users or accounts could have received the intervention?
Primary outcome: Which business result determines the decision?
Leading indicator: Which earlier behavior should move if the mechanism is working?
Guardrails: Which important outcome must not deteriorate while the primary metric improves?
Observation window: How long must the customer journey remain visible before the result is interpretable?
Evidence standard: Do you need descriptive reporting, diagnosis, a causal estimate, or an economic forecast?
Decision rule: What result would cause each available action?

Set those fields before looking at the result. If the outcome, segment, or success threshold changes after the data arrives, the analysis has become a story fitted to the answer.

Separate four questions that dashboards often blur

What happened? Descriptive reporting counts touches, sign-ups, opportunities, revenue events, and retained customers.
Where did the journey weaken? Diagnostic analysis examines segments, cohorts, funnel transitions, time-to-value, and behavior preceding the change.
Did marketing cause the change? Causal analysis asks what would have happened to an equivalent eligible population without the intervention.
Was the change economically worthwhile? Revenue analysis adds acquisition cost, customer value, payback, retention, and expansion to the observed lift.

These questions can use some of the same data, but they do not have interchangeable answers. An attribution report can distribute credit for observed revenue without estimating incremental revenue. An experiment can estimate lift without proving that the lift will repay its cost. A conversion increase can be real while customer quality and retention decline.

Connect every marketing touch to a customer value journey

Channel dashboards split one customer into several records: an ad click, a web visitor, a trial user, an account in the CRM, and a commercial outcome. Revenue measurement starts by reconnecting those records without pretending that every join is reliable.

A practical journey model contains the following stages:

Acquisition: Record the eligible campaign, audience, creative, source, and consent state.
Identity: Define how an anonymous visitor becomes a known user and how users map to an account. In B2B products, a user identifier alone cannot represent a buying group or an account-level revenue event.
Activation: Capture the first observable behavior that indicates the customer has received meaningful product value.
Engagement: Measure whether the customer repeats the valuable behavior, uses it more deeply, or adopts the critical workflow around it.
Commercial progression: Join the account to clearly defined CRM stages and the authoritative commercial outcome.
Retention and expansion: Observe whether the acquired cohort continues receiving value and whether its usage produces credible expansion signals.

Putting campaign performance, product behavior, and CRM pipeline into one journey changes the management question. Instead of asking which channel deserves all the credit, you can ask where each acquired cohort reached value, stalled, converted, retained, or expanded.

A unified platform does not create this chain merely by ingesting every table. You still need a canonical user and account identity, consistent timestamps, stable campaign identifiers, documented CRM stages, and explicit ownership of every event. A silent identity merge can make the journey look complete while assigning one customer’s behavior or revenue to another. Preserve the raw identifiers, record the join method, and make uncertain matches visible rather than forcing them into a clean-looking funnel.

For each event used in revenue analysis, document its business meaning, trigger, actor, account mapping, source system, required properties, consent treatment, owner, and version history. Event names are not definitions. Two teams can emit an event called activated while measuring entirely different customer behaviors.

Instrument value moments instead of feature clicks

A feature click proves that an interface element was used. It does not prove that the customer solved the problem they came to solve. Define activation around a completed value-producing behavior, then measure time-to-value, depth of use, and signals associated with expansion.

Describe the customer outcome in plain language before naming an event.
Identify the smallest observable behavior that credibly represents that outcome.
Instrument completion, not merely entry into the workflow.
Measure how long eligible users take to reach the event and whether they repeat or deepen the behavior.
Compare later conversion and retention for cohorts that reach the value moment and cohorts that do not.
Treat that comparison as diagnostic evidence until an experiment tests whether moving the value moment changes the later outcome.

That last distinction matters. A behavior associated with retention may simply identify customers who were already more motivated. It is still a valuable signal for diagnosis and segmentation, but correlation does not turn it into a causal lever.

Build a driver tree from realized revenue back to controllable inputs

Revenue is an outcome, not an operating lever. A driver tree makes the path to that outcome explicit. It also prevents marketing, product, sales, and finance from optimizing different definitions of success.

Start with the commercial outcome your finance function recognizes. Branch it into new-customer revenue, retained revenue, and expansion where those distinctions fit your business. Then work backward through the behaviors and transitions that teams can influence:

Acquisition quality: Eligible demand reaches the intended customer profile and enters a measurable journey.
Activation: Acquired users or accounts reach the defined value moment.
Conversion: Activated customers progress to the relevant commercial outcome.
Retention: Cohorts continue performing the valuable behavior and remain commercially active.
Expansion: Usage depth, account participation, or repeated value creates a credible reason to grow the relationship.
Efficiency: Customer acquisition cost, lifetime value assumptions, and payback remain acceptable for the decision being considered.

Do not collapse the tree into a single blended conversion rate. Read it by acquisition cohort, customer segment, route to market, and other distinctions that could change the mechanism. A campaign can generate inexpensive trials yet perform poorly on activation. Another can create fewer trials but stronger retention and expansion. The top-of-funnel view favors the first campaign; the revenue journey may favor the second.

Metric	Decision it can inform	Definition that must be locked
Campaign-attributed revenue	Consistent reporting and allocation	Attribution rule, eligible touches, identity logic, and observation window
Activation	Audience quality and onboarding priorities	Value event, eligible population, unit of analysis, and observation window
Retention	Customer quality and durable growth	Starting cohort, retained behavior or commercial state, and comparison period
Customer acquisition cost	Acquisition efficiency	Included costs and the definition of an acquired customer
Lifetime value and payback	Whether and how aggressively to scale	Value horizon, cost boundary, retention assumptions, and treatment of expansion

Finance should remain the owner of authoritative commercial definitions. Marketing analytics can connect those outcomes to customer journeys, but it should not quietly substitute attributed pipeline, bookings, billing, collections, and recognized revenue for one another. If the decision uses money, state exactly which commercial event the number represents.

Assign every driver a definition, owner, system of record, refresh expectation, and decision it supports. If a metric has no owner or cannot alter a decision, it is probably dashboard inventory rather than a management instrument.

Keep attribution in its lane and use experiments for incrementality

Attribution is a rule for distributing credit among recorded touches. It is useful when the business needs a consistent reporting convention, campaign history, or a shared way to discuss observed journeys. It does not create the missing counterfactual: what the same eligible customers would have done without the marketing intervention.

Choose the method from the question:

Use attribution to describe how observed revenue is assigned across recorded touchpoints.
Use funnel and cohort analysis to locate friction and generate hypotheses about the mechanism.
Use randomized experiments when you need a defensible estimate of incremental impact and randomization is feasible.
Use customer acquisition cost, lifetime value, and payback to decide whether the measured impact is economically attractive.

Do not make an attribution disagreement carry more meaning than it has. Different attribution rules can produce different answers from the same customer journey because they distribute credit differently. That disagreement does not tell you which touch caused the revenue. If the decision depends on causality, the next step is better experimental design, not another credit-allocation rule.

Define the minimum detectable effect before an A/B test begins

The minimum detectable effect is the smallest effect your test is designed to detect with its chosen statistical setup. It should come from the business decision: the smallest improvement that would justify the intervention after considering cost, risk, and downstream quality. It should not be selected merely because a smaller number sounds impressive.

A credible test plan records the hypothesis, eligibility rule, randomization unit, primary outcome, guardrails, minimum detectable effect, exposure logic, measurement window, and analysis plan before results are inspected. A/B testing with explicit MDE discipline and cohort-based retention analysis keeps teams focused on decision-relevant effects instead of test volume.

Match the randomization unit to the way the intervention spreads. If people within the same account influence one another or share the commercial outcome, randomizing individual users can contaminate the comparison. Consider the account as the unit when the treatment, customer value, or revenue event operates at account level.

Do not stop the analysis at the easiest conversion event when the decision depends on durable revenue. A message can increase sign-ups while bringing in users who never activate. An onboarding change can improve activation while harming a later guardrail. Follow the cohort far enough to observe the outcome named in the measurement brief.

When randomization is not feasible, label the evidence as observational. Record plausible alternative explanations, look for consistent signals across campaign exposure, product behavior, CRM progression, and cohort outcomes, and make the resulting decision more reversible. Honest uncertainty is more useful than a precise causal claim the design cannot support.

Turn revenue measurement into an operating cadence

The work is not complete when a dashboard ships. Measurement becomes operational when the same definitions guide budget choices, product experiments, lifecycle changes, and executive reviews.

Use each decision review to answer a fixed sequence of questions:

Which business outcome changed, and for which eligible cohort?
Which branch of the driver tree explains the movement?
Where in the customer journey did behavior diverge?
Is the evidence descriptive, diagnostic, causal, or economic?
What decision follows, who owns it, and what evidence would reverse it?
Which instrumentation or definition gap weakened confidence in the answer?

Ownership should follow the underlying data-generating process. Marketing owns campaign taxonomy, spend, audiences, and creative metadata. Product owns value events, activation, and engagement definitions. Sales and revenue operations own CRM stage fidelity and account mapping. Data teams own transformation logic, quality tests, and the semantic layer. Finance owns the commercial definitions used for authoritative revenue decisions.

Treat governance as part of growth infrastructure. Consented data, privacy-by-design, documented schemas, and clear metric definitions make analysis more dependable and executive decisions easier to defend. Do not stitch identities beyond the permission and purpose under which the data was collected. The safe alternative is an explicit gap in the journey, with its effect on the analysis documented.

Use generative AI as an analyst, not a measurement authority

Generative AI can accelerate query drafting, anomaly discovery, segment exploration, and the first pass at possible drivers. It cannot repair an ambiguous activation event, an unreliable identity join, or a CRM stage that teams use inconsistently. It also cannot turn observational data into causal evidence by explaining it fluently.

Require every AI-generated finding to show the metric definition, filters, eligible population, time window, comparison, underlying query or transformation, and evidence class. Validate the denominator and join logic before acting. Keep causal conclusions behind the same experimental and statistical standards you would require from a human analyst.

The leverage comes from combining fast exploration with a strong taxonomy and disciplined validation. Without those foundations, AI produces a faster version of the same disagreement that fragmented dashboards created.

Key takeaways

Start every analytics request with the decision, eligible population, outcome, evidence standard, and decision rule.
Connect campaigns to account identity, product value, CRM progression, revenue, retention, and expansion.
Use a revenue driver tree to expose which controllable behavior connects marketing activity to durable growth.
Keep attribution for consistent credit allocation; use experiments when the decision requires incremental impact.
Define value moments, event contracts, commercial outcomes, and MDE before inspecting results.
Let AI accelerate exploration, but require transparent definitions, queries, joins, and human validation.

Begin with the next disputed budget or roadmap decision. Write its measurement brief, then trace one eligible cohort from a consented first touch through product value, CRM progression, and the authoritative commercial outcome. Wherever that chain breaks is the next item for your analytics backlog.

Once the same journey can be reproduced without manual interpretation, add more channels and automate more analysis. That is the point at which marketing analytics stops being a reporting layer and becomes a revenue management system.

References

Amplitude – Marketing Analytics in 2026: Bold, Data-Driven Predictions to Outperform Your Market

November 25, 2025

The Product Playbook: Measuring Agent Performance with Pendo and Agent Analytics to Drive ROI

I treat agent performance analytics as a strategic product lever, not a back-office metric. When I combine Pendo’s product signals with Agent Analytics from our support systems, I get a unified view of where users struggle, how agents intervene, and which in-app experiences accelerate resolution. That visibility lets my team drive product-led growth and improve customer experience while lowering support costs.

Increase revenue, cut costs, and reduce risk with Pendo’s Software Experience Management platform. Optimize the entire software experience to drive adoption and improve engagement.

In practice, I build a clear scorecard that blends both product and support KPIs: first response time, resolution rate, first contact resolution, CSAT, containment/deflection rate, average handle time, ticket volume per active account, onboarding completion, user activation, and time-to-value. This balanced view ensures we reward not just speed, but durable outcomes that reduce repeat contacts and improve retention.

To make the data actionable, we connect our CRM integration, ticketing events, and Pendo product analytics in a unified analytics platform. That gives me cohort-level clarity—who needed help, what they were doing before opening a ticket, how agents responded, and whether users stayed engaged afterward. With clean instrumentation and consistent taxonomies, Agent Analytics becomes a reliable operating system for both product and support leadership.

I then use in-app guides, tooltips, and product tours to proactively address the top friction points that drive ticket volume. Through A/B testing, we compare cohorts exposed to guided workflows versus control groups, measuring deflection, faster task completion, and downstream conversion. When a guide meaningfully reduces tickets for a given workflow, we promote it from experiment to standard onboarding, and we feed those learnings back into our roadmap.

The real unlock comes from tying outcomes to business impact. I track how improvements in resolution quality and self-serve adoption influence expansion revenue, support cost per account, and risk signals like churn propensity. Retention analysis helps us validate whether reduced friction and better agent coaching translate into sustained engagement and healthier accounts.

Operationally, Agent Analytics helps me coach teams with precision. I spotlight high-performing behaviors, identify knowledge gaps, and standardize winning playbooks directly in the product via in-app guidance. This approach empowers agents, shortens onboarding for new hires, and keeps our best practices current as the product evolves.

None of this works without trust. We apply privacy-by-design principles and strong data governance, ensuring that analytics, coaching, and automation respect user consent and data minimization standards. With that foundation, we can scale confidently—experiment faster, learn from every interaction, and continuously improve the software experience.

If you’re getting started, begin by baselining your agent and product KPIs, ship one high-impact guide to deflect a top ticket driver, and review results weekly. Within a quarter, you’ll have a repeatable loop: diagnose friction, test an in-app solution, measure deflection and satisfaction, and reinvest the gains into the next set of improvements.

Inspired by this post on Pendo – Best Practices.

November 4, 2025
3 Hidden Hurdles Blocking Effective AI Agents—and How I Turn Them into Business Wins

AI agents promise leverage at scale, yet too many proofs of concept stall before they create measurable value. Over the past several launches, I’ve seen the same patterns repeat across IT and operations. The mandate is clear: “Discover three key challenges IT and ops teams face when building and managing AI agents that drive real business wins.” Here’s how I frame the work, where teams get stuck, and the playbook I use to move from demo to durable outcomes.

Hurdle 1: fragmented data and weak data governance. Agentic AI is only as strong as the data it can reliably access. In most organizations, knowledge is scattered across CRMs, ticketing tools, wikis, and data lakes—each with different schemas, permissions, and freshness guarantees. Without privacy-by-design and consistent access patterns, agents hallucinate, miss context, or violate policies. This isn’t a model problem—it’s an information architecture problem.

My approach starts with an integration-first mindset: anchor the agent to authoritative systems via CRM integration, unify retrieval across knowledge sources, and enforce role-based access at query time. I pair this with data contracts, lineage, and content freshness SLAs so the agent never acts on stale or restricted information. A unified analytics platform and strong data governance let me monitor coverage, drift, and security posture as the knowledge footprint grows.

Hurdle 2: reliability, observability, and AI risk management. Even well-fed agents can behave unpredictably without tight control loops. Teams often lack Agent Analytics, standardized evals, and guardrails to catch prompt injection, tool abuse, or subtle regressions. The result is fragile behavior that erodes trust with IT, security, and front-line operators.

I build a reliability stack that looks a lot like SRE for agentic AI: scenario-based evaluations before release, production tracing of every step and tool call, red-teaming for threat detection and response, and policy enforcement at runtime. Hallucination mitigation, input validation, and fallbacks (including human-in-the-loop) are non-negotiable. We track latency, cost, accuracy, and safety incidents in one Agent Analytics view so we can ship confidently and iterate quickly.

Hurdle 3: workflow integration and organizational adoption. The best agent can still fail if it can’t take action in real systems or if change management is an afterthought. Agents must fit the way people actually work—permission models, SLAs, audit trails, and existing approval paths—instead of creating shadow processes that confuse teams.

I integrate agents directly into systems of record and daily tools—ticketing, CRM, knowledge bases—so outcomes are auditable and reversible. I define clear RACI, rollout guardrails, and metrics in product roadmapping and sprint planning (e.g., first-contact resolution, time-to-resolution, deflection, cost per task). We ship narrowly scoped capabilities first, pair them with in-app guides and product tours, and expand privileges as confidence and KPIs improve. This is product management leadership, not just prompt engineering.

In practice, the pattern is consistent. For customer support, we anchored the agent to the CRM, knowledge base, and incident runbooks with strict access controls, then layered policy checks for regulated data. With unified analytics, we measured precision/recall of suggested actions, tracked cost and latency, and flagged risky prompts. The result: higher accuracy, cleaner handoffs, and faster time-to-value without sacrificing compliance.

If your agents aren’t delivering, start here: fix the data plane, instrument the control plane, and design for real workflows. Do this well and you’ll move beyond flashy demos to durable productivity gains and competitive differentiation—while keeping security, governance, and stakeholders on your side.

Inspired by this post on Pendo – Perspectives.

October 25, 2025
Unlock Customer Gold: Securely Access Intercom Data in ChatGPT to Align Every Team

I see customer conversations as a goldmine for every team—yet too often, they’re trapped inside the support platform. That silo makes it harder to make confident, customer-first decisions across product, sales, marketing, and leadership. I’ve felt that pain firsthand, which is why this update matters.

From today, the new Intercom connector for ChatGPT changes this. Intercom customers can now allow all teams to securely access conversations, tickets, and user data directly inside ChatGPT. Without having to switch tools, you can now get all the context you need to put the customer first across every area of your business.

Here’s how I approach it in practice: when frontline insights are accessible in the same workspace where I ideate, plan, and write, my team moves faster with more conviction. It’s the difference between guessing at customer needs and grounding decisions in real conversations.

How to connect Intercom to ChatGPT

Connecting Intercom to ChatGPT is easy:

1. In ChatGPT, open Settings → Connectors.

2. Search for “Intercom” and select it.

3. Sign in with your Intercom account to approve the secure connection.

(The connector is read-only and respects your existing Intercom permissions, so people only see what they already have access to. See more about security and setup details here.)

Once you’re in, you can start exploring your customer data using prompts written in natural language, like:

“Help me prepare for a meeting with customer X by updating me on outstanding issues raised in the last four weeks.”

“Find positive Intercom conversations mentioning our new feature Y, and add customer quotes to my campaign brief in Drive.”

“Build a list of the most common feature requests based on customer inquiries.”

What this unlocks

Connecting Intercom to ChatGPT makes customer feedback available across the company in a usable way. In my own workflow, this turns previously buried signals into actionable inputs for roadmaps, messaging, and enablement—without hopping between tools.

Support tickets contain direct information about what’s breaking, what’s confusing, and what people actually need. Normally, that information stays siloed in the support team. When I can query those conversations in plain language, I get immediate clarity on friction points and opportunities, and I can share that context with cross-functional partners in minutes.

When anyone can query it in plain language, it becomes useful for decision-making across the board. Teams stop working at cross-purposes because they’re looking at different parts of the picture. Now, product can see what’s actually frustrating users. Sales can understand common objections. Marketing can use the language customers actually use. Leadership can spot trends as they’re happening.

My recommendation: establish a lightweight ritual around this data. For example, build a weekly highlights digest sourced from Intercom conversations and review it in your product sync or go-to-market standups. It’s a simple way to align stakeholders and keep customer reality front and center.

We’ll be adding more connectors soon so you can access Intercom data in other AI tools your team already uses.

Inspired by this post on The Intercom Blog.

October 25, 2025
Build the Cake, Then the Frosting: 3 Elements of a High‑Performing AI Strategy That Wins

Over the past few years leading product at HighLevel, I’ve watched too many teams rush to demo flashy agents before they’ve built a reliable foundation. The metaphor I use in every AI roadmap review still hits home: “Think of AI readiness as a three-layer cake. Most companies are trying to build the fancy frosting (the agent interface) without bothering to bake the actual cake underneath.” If we want durable impact, we have to bake first, frost later.

When I design an AI Strategy, I anchor on three elements that map directly to that cake: a data and instrumentation foundation, a governance and risk layer, and finally the agent experience itself. This sequence isn’t theory—it’s how we de-risk delivery, accelerate product-market fit, and create competitive differentiation without compromising trust.

Layer 1 — Data and instrumentation: The base of the cake is clean, well-instrumented data flowing through a unified analytics platform. I start with a clear event schema, rigorous data quality checks, and tight CRM integration so we can connect outcomes to users, accounts, and journeys. Privacy-by-design is nonnegotiable: we minimize PII, define retention, and ensure consent flows are explicit. With this in place, gen ai features have the context they need—retrieval works, grounding holds, and feedback loops from production inform continuous improvement.

On top of that, I build measurement in from day one: activation, retention, task success, latency, and satisfaction. Every AI interaction is observable. We run A/B testing with a well-defined minimum detectable effect, pair quant with qualitative review, and feed human-in-the-loop judgments back into ranking and prompt libraries. This is how we avoid “demo-ware” and deliver real, repeatable value.

Layer 2 — Governance and risk: Before scaling, I formalize AI risk management and data governance. That includes model evaluation against safety and quality thresholds, red-teaming for jailbreaks, and threat detection and response for prompt injection and data exfiltration. We establish policy for model and provider selection, versioning, and rollback; we log prompts, responses, and decisions for auditability; and we define escalation paths when the system is unsure. These controls don’t slow us down—they create the confidence needed for faster iteration and board management alignment.

I also align legal, security, and product early on a taxonomy of risks—bias, hallucinations, privacy, IP leakage—so we can write tests and guardrails once and reuse them across features. The result is fewer surprises in customer pilots and a far smoother path through enterprise procurement.

Layer 3 — The agent experience: Only now do we invest in the frosting—the agent interface and workflows. Here I focus on clear jobs-to-be-done, crisp UX writing, and transparent system behavior. We design agentic AI flows that show reasoning steps when helpful, ask for clarification when confidence is low, and gracefully hand off to humans in customer support scenarios. Product tours, in-app guides, and tooltips reduce the learning curve and accelerate user activation.

Crucially, we measure the interface, not just the model. Agent Analytics tracks intents, tool use, fallbacks, and user corrections so we can tune prompts, tools, and policies. This closes the loop from experience back to data and governance, and it directly informs product roadmapping and sprint planning. When the cake is baked this way, go-to-market becomes easier: we can prove ROI with hard numbers, fine-tune pricing, and scale adoption with product-led growth tactics.

If your AI roadmap feels stuck, start with an honest readiness audit against these three elements. Shore up instrumentation and data pipelines, codify governance, then refine the agent interface with real user telemetry. Bake first. Frost last. That’s how we ship AI that customers trust—and keep winning after the first demo high fades.

Inspired by this post on Pendo – Best Practices.

October 25, 2025
WTF is MCP? The powerful protocol giving enterprise AI agents real-world autonomy

I get asked this constantly by boards, CIOs, and product teams: WTF is MCP, and why does it matter for enterprise AI? Here’s my straightforward take from the trenches of rolling out agentic AI across complex, regulated environments—and why it changes how we design, govern, and scale autonomous capabilities.

“Model Control Protocol gives your AI agents arms and legs to go do stuff with your data.” That framing resonates because it’s both simple and accurate. MCP turns passive “chatbots” into active agents that can safely take action within defined guardrails.

In practice, MCP is the connective tissue between models and the tools, systems, and workflows we trust. It standardizes how agents request permissions, execute tasks, and report outcomes—so enterprises can move from demos to durable operations. The benefit isn’t just autonomy; it’s autonomy with accountability, aligned to our AI Strategy and data governance obligations.

When I pilot agentic AI in production, I start with a narrow scope: which systems the agent touches (for example, CRM integration via HubSpot), what actions it can take (read, write, or propose), and what evidence it must log (inputs, outputs, and approvals). That discipline keeps us compliant with privacy-by-design while unlocking real business impact.

Great MCP use cases emerge where read-write actions compress time-to-value. Think: pulling Amplitude analytics cohorts to personalize outreach, auto-generating Pendo in-app guides based on feature adoption, or triggering customer support workflows with predefined playbooks. Each action is observable, reversible, and measured—because in the enterprise, repeatability beats novelty.

From a product management leadership perspective, I treat MCP-enabled agents like any other product surface. We define clear outcomes, not outputs: success rate per task, mean time to resolution, quality score, and safety incidents. We validate uplift with A/B testing and a minimum detectable effect (MDE) before scaling. Then we feed results into an Agent Analytics dashboard, just as we would for product-led growth funnels.

Governance is where MCP earns trust. I enforce least privilege, time-boxed credentials, environment isolation, and tamper-evident audit logs. Every tool call is tied to a business purpose, owner, and SLA. We integrate with existing threat detection and response processes so cybersecurity teams see the same telemetry they’re used to—no shadow AI, no surprises.

There’s also an adoption playbook that works: start with a contained domain, ship a sandboxed agent, require human-in-the-loop approvals, then progressively relax controls as accuracy and alignment improve. Document the boundaries in plain language, and instrument everything from day one. This is how we de-risk AI risk management while accelerating impact.

The most exciting shift is cultural: teams move from asking “Can the model do this?” to “What outcomes should the agent own—and what guardrails make that safe?” That mindset unlocks empowered product teams, clearer ownership, and faster iteration. MCP is simply the operational backbone that lets those choices stick.

If you’re evaluating where to start, pick one workflow with high frequency, clear rules, and measurable outcomes. Wire it to MCP with tight scopes, ship it to a friendly cohort, and learn aggressively. Autonomy isn’t the end goal—reliable, governed value is. MCP just makes that scalable.

Inspired by this post on Pendo – Best Practices.

October 25, 2025
4 Proven Ways GTM Teams Drive Explosive Growth with Pendo’s HubSpot Integration

In my role leading product management, I’ve learned that the most reliable path to product-led growth is aligning product signals with the systems our go-to-market teams use every day. That’s exactly where Pendo’s HubSpot integration shines—by merging behavioral insights with CRM context so sales, marketing, customer success, and product move in lockstep.

See how customer behavioral data can help sales, marketing, customer success, and product teams create a better, more engaging customer experience.

First, I use the integration to create a single source of truth that blends in-app behavior with account and contact data. When product usage, feature adoption, and intent signals flow into HubSpot, lead scoring becomes smarter, pipeline quality improves, and our go-to-market strategy gets more precise. Reps prioritize the right accounts, marketing tunes messaging to demonstrated needs, and we operate as a unified analytics platform instead of scattered tools.

Second, I activate lifecycle journeys directly from HubSpot using in-app guides and product tours. By targeting experiences based on CRM stage or persona, onboarding accelerates, trial conversion increases, and time-to-value drops. The ability to personalize onboarding without engineering work gives marketing and customer success a powerful lever to deliver exactly the right guidance at the right moment.

Third, I orchestrate customer success playbooks that reduce churn and expand revenue. Health scoring improves when retention analysis is informed by real product usage, not just survey sentiment. When usage dips below a threshold, HubSpot workflows trigger save-plays; when product engagement surges, we operationalize expansion motions across self-serve upgrades and account-based upsell. The result is a tighter feedback loop between product adoption and revenue outcomes.

Fourth, I close the loop between sales, product, and marketing to refine product positioning and roadmap priorities. Signals from Pendo in HubSpot highlight which features correlate with win rates and renewals, so we double down on the value proposition that actually converts. Those same insights inform targeted campaigns, sharper messaging, and a continuous learning cycle across GTM and product teams.

To make this work in practice, I start with clear event taxonomies, privacy-by-design data governance, and tightly scoped use cases that we can measure within a quarter. We iterate with small A/B tests, compare outcomes to baselines, and socialize wins across sales, marketing, and customer success to build momentum. The integration becomes more than a data pipe—it’s an operating system for coordinated growth.

When product signals meet CRM workflows, teams stop guessing and start executing with confidence. That’s the power of Pendo’s HubSpot integration: it operationalizes product-led growth across the entire customer journey, from first touch to expansion.

Inspired by this post on Pendo – Best Practices.

October 25, 2025