Blog

Posted on

The Activation Problem: Why Your Onboarding Isn’t Broken, Your Value Proposition Is

Three years ago, I sat in a product review watching our head of growth celebrate a 70% onboarding completion rate. The slides were beautiful. The funnel charts were clean. And then someone asked the question nobody wanted to answer: “If 70% complete onboarding, why are only 12% still active at day 30?”

We had a great onboarding flow. Users could set it up in under five minutes. The tooltips were helpful. The empty states were friendly. And none of it mattered — because we had never solved the activation problem.

Onboarding Completion Is a Vanity Metric

The activation problem is one of the most expensive and most misdiagnosed challenges in product management. Teams pour engineering cycles into onboarding redesigns, empty state copy, welcome email sequences — all while the real issue sits upstream: the user hasn’t experienced the core value of the product yet. They may never experience it at all.

Activation, properly defined, is the moment a user first experiences the value that made them sign up in the first place. Not the moment they complete registration. Not the moment they finish the tutorial. The moment the product does something for them that they couldn’t easily do without it.

When activation rates are low, most product teams fix the wrong thing. They shorten the onboarding flow. They add progress bars. They A/B test CTA copy. These tweaks occasionally produce small lifts — which is dangerous, because a 3% improvement in a broken funnel is still a broken funnel.

The Real Activation Problem: You Haven’t Defined Your “Aha Moment”

Before you can fix activation, you have to be ruthlessly precise about what activation actually means for your product. What is the specific action — measurable, observable, time-bound — that correlates with a user becoming retained? Not a proxy. Not a feeling. A behavior.

This is harder than it sounds. I’ve worked with teams who genuinely couldn’t answer this question in a room of fifteen people. They had intuitions. They had opinions. What they didn’t have was data tying a specific first-week behavior to 90-day retention. Until you have that, you’re optimizing in the dark.

Facebook famously identified “7 friends in 10 days” as their activation threshold. Slack’s was sending 2,000 messages as a team. Dropbox’s was adding a file to a synced folder. Notice that none of these are onboarding steps. They’re all value moments — the thing the product is actually for.

Your activation metric is the answer to this question: What does a user have to do, in their first week, that almost guarantees they’ll still be using the product in 90 days? If you can’t answer that with a specific behavior and a correlation coefficient, you don’t have an onboarding problem. You have a value proposition problem.

Why Product Leaders Confuse the Two

Onboarding is visible and controllable. You can A/B test it. You can sprint on it. You can show progress. Value proposition clarity is neither visible nor fast — it requires honest conversations about who your product is actually for and what job it truly does for them. Those conversations are uncomfortable, especially in organizations where the product already shipped.

There’s also an attribution problem. When a team tightens onboarding and activation improves slightly, it’s easy to conclude that the onboarding work caused the improvement. Often the reality is more complicated: the users who activate despite mediocre onboarding are the ones whose need was acute enough to push through friction. You improved completion. You didn’t change who your product is actually for.

I’ve come to think of this as the difference between removing friction and delivering value. Onboarding optimization removes friction. Only your core product can deliver value. If the value isn’t there yet — or if the wrong users are being attracted into the funnel — no amount of onboarding refinement will save your activation rate.

How to Diagnose Which Problem You Actually Have

Start with a cohort analysis, not a funnel. Pull users who activated (whatever you currently consider activation) versus those who didn’t. Look at what they did differently in their first 48 hours. What features did retained users touch? What questions did they ask support? What search terms brought them in? What job titles are most represented among your 90-day retained users?

If you find that retained users clustered around a specific feature or use case that your onboarding doesn’t prioritize — you have an onboarding problem. Fix the path to value.

If you find that retained users look fundamentally different from your average new signup — different industry, different role, different use case — you have a positioning problem. Your marketing is attracting users your product can’t serve well. No onboarding fix will close that gap.

If retained users don’t cluster around anything predictable — if they’re scattered and seemingly random — you may have a product-market fit problem. And in that case, the most valuable thing you can do isn’t optimize onboarding. It’s go talk to your retained users and find out why they stayed.

Your Turn: Apply This Today

Whether you lead a team of three or thirty, here are the diagnostic steps to determine whether you have an onboarding problem or a value proposition problem — and what to do about it:

  • Define your activation moment precisely. Write one sentence: “A user has activated when they [specific behavior] within [time window].” If your team can’t agree on this sentence, that’s your first problem to solve — not the onboarding flow.
  • Pull a cohort comparison. Look at users who hit your activation metric versus those who didn’t. What did activated users do in their first 48 hours that non-activated users skipped? Let the data surface the pattern before you assume an answer.
  • Check the ICP match of retained users. Map your 90-day retained users against your stated ideal customer profile. If your best users don’t look like the users your marketing attracts, you have a targeting problem upstream of activation.
  • Audit what onboarding is actually teaching. Walk your own onboarding as a new user. Does each step directly accelerate arrival at your activation moment? Cut anything that doesn’t. Add steps for anything that does.
  • Interview five churned users. Ask them one question: “What would have had to be true for you to still be using this today?” Their answers will tell you more about your value proposition than any funnel chart will.
  • Set a 30-day activation target and report it weekly. Activation rate should be a team-level metric, not a growth-team-only metric. When product, design, and engineering all see it weekly, the right conversations start happening faster.

If you’re working through related challenges in product strategy, you might find these posts useful: The Product Roadmap Isn’t the Strategy explores why execution clarity doesn’t substitute for strategic direction, and Your AI Product Has a Trust Problem Before It Has a Performance Problem addresses the credibility gap that kills adoption before users ever experience value.

Struggling with activation rates or trying to figure out why retention isn’t moving despite clean onboarding? I consult with product leaders on exactly these kinds of diagnostic challenges — from defining the right activation metric to restructuring positioning for the right audience. Let’s talk.

Posted on

What Nobody Tells You About Product-Led Growth in Faith Tech

Product-led growth has become the dominant go-to-market playbook for B2B software. Let the product do the selling. Freemium drives acquisition. Self-serve onboarding reduces sales cost. Expansion revenue follows natural usage. The model works extremely well — in markets where users have discretionary time, personal tech comfort, and the organizational freedom to adopt tools on their own.

Faith tech is not that market. And the teams that have tried to apply the PLG playbook to churches, ministries, and faith-based organizations have learned some expensive lessons about what makes this market different. I’ve been in this space — building digital products for Sermons4Kids and SermonCentral, serving hundreds of thousands of ministry leaders — and the lessons from those attempts have fundamentally changed how I think about growth in faith-based contexts.

Why the Standard PLG Playbook Doesn’t Transfer

PLG assumes a user who can make adoption decisions independently. In most church and ministry contexts, this assumption breaks immediately. The person who would use a curriculum platform daily is a volunteer children’s ministry director who has roughly seven minutes to prep and no budget authority. The person who controls the budget is a pastor or board member who will never use the product directly. The person who influences technology decisions in the congregation may be an IT volunteer who serves one Sunday a month.

This multi-stakeholder structure — where the user, the buyer, and the influencer are almost never the same person — means that the classic PLG motion of “user falls in love with product, user expands usage, user becomes internal champion who drives purchase” doesn’t work. The user can fall in love with the product and have zero ability to generate a purchase. The buyer can approve a purchase for a product they’ve never touched. The influencer can kill a deal based on concerns that have nothing to do with product quality.

Standard PLG metrics — activation rate, time-to-value, viral coefficient — measure the wrong things in this context. The bottleneck in faith tech adoption isn’t activation. It’s trust between the product and the organizational decision-maker who will never be a power user.

What Trust Means in Ministry Contexts

Ministry organizations run on a different trust architecture than corporate buyers. A mid-market B2B buyer evaluating software is assessing: does this solve the problem, is the price justified, and what does implementation look like? A church or ministry evaluating a platform is assessing all of those things plus: do we trust this organization with our people?

That last question is not a minor addition. Ministry organizations are deeply responsible for the spiritual and relational wellbeing of the communities they serve. They’re not just buying a productivity tool — they’re choosing a technology partner that will touch their congregation’s formation, communications, or discipleship. The stakes of a bad fit are perceived as higher than a bad software choice in a corporate context. The evaluation process reflects that.

In practice, this means that community signals matter more than product signals in faith tech adoption decisions. “Our denomination uses this” carries more weight than “this has 4.8 stars on G2.” “I heard about it at the pastors’ conference” moves faster than any inbound funnel. Trust flows through relationship networks, not through product-led virality. The distribution model that actually works in this market looks more like word-of-mouth in a high-trust community than like a self-serve freemium funnel.

The Metrics That Actually Matter

The metrics I’ve found most predictive in faith tech are not the standard PLG metrics. They are:

Volunteer completion rate. Not administrator completion, not pastor usage — the metric that predicts retention in most faith tech products is whether the volunteers who rely on the product can complete their core task without failure or confusion. Volunteers have the lowest tolerance for friction and the highest likelihood of abandoning a tool that makes their service harder. If volunteers stop using it, administrators switch platforms.

Community recommendation rate. How often do your users recommend the product in contexts you’re not involved in — small group leader networks, denominational meetings, online ministry forums? This is the faith tech equivalent of the viral coefficient, but it operates on a much slower, higher-trust basis. One strong recommendation from a respected ministry leader is worth more than a hundred self-serve trials.

Mission alignment signal. The organizations that pay premium prices in faith tech do so because they believe the product advances their mission, not just because it’s functionally superior. Tracking whether your users articulate a mission connection — in support conversations, in community forums, in reviews — tells you whether your positioning is landing at the level that drives willingness to pay.

What Faith Tech Growth Actually Looks Like

The growth motion that works in faith tech is closer to community-led growth than product-led growth. The product still has to work — a platform that fails volunteers will never earn the community recommendation that drives adoption in this market. But great product quality is the floor, not the ceiling. The ceiling is community trust.

This means investing in community infrastructure that PLG playbooks typically skip: presence at denominational conferences, partnerships with seminary programs, engagement in the online forums where ministry leaders actually talk to each other. These are slow, relationship-dependent channels that don’t scale the same way a self-serve freemium funnel does. They also don’t turn off when the budget cycle changes, because they’re built into how the community thinks about the product.

The teams that have built durable products in this space — and I’ve watched several attempts — are the ones that understood the trust architecture of their market and built their growth motion around it, rather than applying a playbook from a different market and wondering why the numbers didn’t work. The FaithTech community’s research on technology adoption in ministry contexts is the most useful public resource I’ve found for teams trying to understand this market’s distinct dynamics.

Your Turn: Apply This Today

If you’re building for faith-based organizations — or any high-trust, mission-driven market — here’s how to adapt your growth thinking:

  • Map your actual decision-making chain. For your target organization, identify: who uses the product daily, who controls the budget, and who influences the decision. Are they the same person? Almost never in ministry contexts. Design your acquisition, activation, and expansion motions for each role separately — not for an idealized single-user who does all three.
  • Reframe your freemium strategy around trust-building, not feature gating. In faith tech, free tiers work best when they demonstrate mission alignment and build organizational trust — not when they gate features to drive upgrade. Ask: what free experience would make a ministry leader trust us enough to bring us to their board? Design toward that, not toward the feature paywall.
  • Instrument volunteer completion rate separately from administrator metrics. If you’re not tracking whether the front-line volunteers who use your product daily can complete their core workflow successfully, you’re missing your most important retention leading indicator in ministry-facing products. Add it to your weekly review.
  • Build your community presence before you need it for growth. Attend the conferences, engage in the forums, build relationships with denominational leaders before you’re asking them to recommend your product. Community-led growth in high-trust markets requires relational investment that can’t be turned on urgently. Start now.
  • Measure mission alignment explicitly. Add one question to your onboarding or check-in flow: “How does this platform support what your ministry is trying to accomplish?” The answers will tell you whether your positioning is landing at the mission level — and they’ll give you the language to communicate that positioning to buyers who’ve never used the product.
  • Design your onboarding for the volunteer, not the administrator. In most faith tech products, the product review is done by an administrator and the daily experience belongs to a volunteer. Build your onboarding and help content for the least technical, most time-pressured user in the chain — the volunteer who has seven minutes on Sunday morning. If they succeed, the administrator renews.

The trust dynamics in faith tech connect to broader themes about designing for time-constrained users — what children’s ministry taught me about product simplicity goes deep on what the seven-minute volunteer experience reveals. And why faith tech is becoming a real category covers the market-level opportunity behind these dynamics.

Building or investing in faith tech and trying to figure out a growth model that actually works in ministry contexts? I consult with digital ministry organizations and faith tech teams on product strategy, growth model design, and building for the unique trust architecture of the faith-based market. Let’s talk.

Posted on

Your AI Product Has a Trust Problem Before It Has a Performance Problem

Every AI product team I’ve worked with or advised has spent significant time on the performance problem: how accurate is the model, how fast does it respond, how well does it handle edge cases? These are legitimate engineering concerns. But I’ve watched technically impressive AI products fail in the market for a reason that none of those metrics capture: users didn’t trust them.

Trust is the prerequisite for adoption. And trust in AI products breaks in ways that are categorically different from trust in traditional software — faster, harder to repair, and with a long tail of behavioral effects that don’t show up in your engagement dashboard.

How AI Trust Breaks Differently

When traditional software fails, users understand the failure. A button doesn’t work. A page doesn’t load. The app crashes. These failures are frustrating, but they’re legible — users know what happened and can calibrate their expectations accordingly.

When AI fails, users often don’t know what happened. The AI gave a confident-sounding answer that turned out to be wrong. The recommendation seemed personalized but was clearly off. The summary missed something important and presented the gap with the same authority as the accurate content. Users can’t distinguish between the AI being right and the AI sounding right. That illegibility is what makes AI trust failures so destructive.

A single high-visibility AI error can undo months of accurate performance. Users who’ve been trusting the AI unconsciously — accepting its outputs without verification, integrating them into their workflows — suddenly question every prior output. The trust collapse is retroactive. And it’s much harder to rebuild trust after an AI failure than after a traditional software failure, because the user’s underlying question — “how do I know when to trust this?” — doesn’t have a clean answer.

The Trust Gap Product Teams Miss

Most product teams measure trust indirectly — through engagement, retention, NPS. These metrics capture trust effects, but they lag the trust event by weeks or months. By the time your NPS drops, the trust damage was done several product cycles ago.

The trust gap I see most consistently is between what users expect the AI to know and what it actually knows. Users quickly form a mental model of what the AI understands about them — their context, their history, their preferences. When the AI behaves in a way that violates that mental model, trust breaks. Not because the AI was necessarily wrong, but because it revealed that its understanding of the user is shallower than the user assumed.

This is a design problem as much as an engineering problem. The AI’s communication of its own uncertainty — what it knows, what it’s inferring, what it’s guessing — is as important to trust as the accuracy of the output itself. Products that communicate their AI’s confidence level clearly allow users to calibrate appropriately. Products that present all AI outputs with equal confidence train users to either overtrust everything or distrust everything. Neither is the outcome you want.

Building Trust Before You Build Performance

The framing shift that changes how you build AI products: trust is a design requirement, not a performance outcome. You don’t earn trust by making the AI more accurate and hope trust follows. You design for trust explicitly — and then let performance maintain it.

What designing for trust looks like in practice:

Transparency about what the AI can and can’t do. Set user expectations at the point of first contact, not after the first failure. Users who understand the AI’s capabilities and limitations before they rely on it calibrate their trust appropriately. Users who discover limitations through failure recalibrate toward distrust.

Visible confidence signals in the UI. When the AI is highly confident, say so — implicitly through clean, direct output. When the AI is uncertain, signal that too — through hedged language, source attribution, or explicit “I’m not sure about this” framing. Users who can see confidence levels can trust appropriately rather than uniformly.

Recoverable failures. Design for the moment when the AI is wrong. How does the user know? How do they correct it? What does recovery cost them? AI products where errors are hard to detect and expensive to fix train users to verify everything, which eliminates the productivity benefit. AI products with visible, cheap error recovery build the confidence for users to rely on the AI without constant verification.

Consistent, predictable behavior. Trust requires predictability. An AI that behaves differently on similar inputs — even if both outputs are acceptable — trains users toward unpredictability anxiety. They start over-supervising the AI because they don’t know when to trust it. Consistency in behavior, tone, and output style is trust infrastructure. Google’s People + AI Research guidebook on AI interaction design is the best public resource I’ve found on trust-centered AI design principles.

The Trust Measurement Problem

If you’re not measuring trust directly, you’re flying blind on your most important AI product metric. Engagement and retention are trust effects. They tell you that trust is breaking down after it’s already happened. You want leading indicators.

The leading indicators I track: AI override rate (how often users edit or reject AI outputs, separated from how often they accept without modification), re-query rate (how often users immediately follow an AI output with a corrective or clarifying query), and qualitative signals from support tickets about AI confusion or error. These don’t replace engagement metrics — they explain them, and they surface trust issues early enough to do something about them before they show up in churn.

Your Turn: Apply This Today

Build trust into your AI product development process before the first failure forces you to repair it:

  • Audit your AI product for confidence signaling. Walk through your product as a new user. Can you tell when the AI is highly confident vs. uncertain? If all outputs look the same, you’re training users to either overtrust or uniformly distrust. Add confidence signals before the next major release.
  • Map your AI failure modes and their recovery cost. For each AI feature, ask: when this is wrong, how does the user know? How expensive is the correction? The higher the recovery cost, the more supervision users will apply — and the lower the actual productivity benefit. Design cheap recovery paths into every high-consequence AI feature.
  • Add AI override rate to your product metrics dashboard. Instrument how often users accept AI outputs without modification vs. edit, override, or immediately re-query. Track it weekly. If the override rate is near zero, users may be overtrusting. If it’s very high, users don’t trust the AI enough to rely on it. Calibrated override rates (somewhere in between) indicate healthy trust.
  • Conduct a “first failure” user research session. Recruit users who have experienced a visible AI error in your product. Interview them about what happened to their trust and usage behavior after the failure. The pattern in their responses will tell you whether your product’s trust recovery design is working or broken.
  • Write your AI product’s “trust contract” with users. One paragraph: what your AI knows, what it can do reliably, what it can’t do reliably, and how to tell the difference. Share it in your onboarding. Users who understand the trust contract calibrate appropriately. Users left to discover it through failure don’t.
  • Run a “trust stress test” before every major AI feature launch. Deliberately trigger AI failures in a testing session with representative users. Observe their reactions. How long does it take them to recover trust? Do they change their behavior after the failure? If the trust damage is severe or persistent, redesign the failure experience before launch.

The trust problem is closely connected to the cognitive load dimension — Kahneman’s System 1 automation paradox explains why users overtrust confident-sounding AI outputs, and the Solomon test for AI decision-making addresses when human judgment needs to stay in the loop regardless of AI confidence.

Building an AI product and noticing that trust is the bottleneck more than performance? I consult with product teams on AI trust design, confidence signaling, and building the user research processes that surface trust problems before they become retention problems. Let’s talk.

View all posts