Blog

Posted on

Deep Customer Knowledge: The PM’s Field Guide to Knowing Your User Better Than They Know Themselves

Deep customer knowledge is the single most important skill in product management — and the most commonly faked. I say that as someone who once inherited 18 user research studies spanning 13 years and still nearly made the wrong product decision because of it.

Here’s what happened. A usability test asked 5 users to try the Hebrew/Greek word study tools. Zero out of 5 said they’d use them. The researcher’s recommendation: deprioritize original language features. But the behavioral data told a completely different story. The reverse interlinear — the exact tool those 5 users dismissed — was the single most-used resource among paying subscribers. The feature driving the most revenue was the one the research said nobody wanted.

That’s the gap between having customer data and having deep customer knowledge. In my post on 25 PM Skills for 2026, I listed deep customer knowledge as skill #1. Here’s the full picture.

What Deep Customer Knowledge Actually Is

Deep customer knowledge isn’t reading your NPS score. It isn’t scanning the top 10 support tickets. It isn’t even running a survey.

It’s the ability to predict what your customers will do — not just what they’ll say — in situations you haven’t tested yet.

Marty Cagan puts it directly: the product manager needs to be the “acknowledged expert on the customer.” Not the research team. Not the data analyst. The PM. Deep knowledge of their issues, pains, desires, how they think, how they work, and how they decide to buy. Without it, you’re just guessing.

Most PMs can rattle off their user personas. They can tell you the average age, the top feature requests, the churn rate. That’s customer data. It’s necessary. It’s not sufficient.

Deep customer knowledge is the specific, surprising detail that changes how you build — knowing that 27% of your churn is involuntary (credit card failures, not dissatisfaction), and that the user who doesn’t renew isn’t unhappy, they just forgot your product existed for three weeks. One number goes in a report. The other rewrites your retention roadmap.

Three Ways PMs Fail at Deep Customer Knowledge

Failure mode 1: Outsourcing understanding. You hire a research firm, they run a study, hand you a deck. You read the executive summary, quote two stats in your next planning meeting, and call yourself customer-obsessed. The deck goes in a folder. The understanding stays surface-level.

Failure mode 2: Confusing asking with knowing. Surveys tell you what people say they want. Behavioral data tells you what they actually do. These diverge constantly. The Hebrew/Greek example is the poster child — five users in a room said “no thanks.” Fifty thousand subscribers in the wild said “this is why I pay.”

Failure mode 3: Building knowledge once. Your customer isn’t static. The median age of one subscriber base I tracked increased by 2 full years in just 3 years (58 to 60). The same persona document from 2019 would actively mislead you in 2026. The most dangerous sentence in product management: “We already know our customers — we’ve been in this market for years.” Tenure creates confidence. Confidence stops you from looking.

The Knowledge Stack: Five Layers of Customer Understanding

I think about customer knowledge as a stack. Five layers, each harder to get but more valuable than the last.

Layer 1: Demographics. Who they are — age, location, role, income. You get this from surveys and analytics. Almost every PM has this. It tells you very little about what to build.

Layer 2: Behavior. What they do — feature usage, session patterns, search queries, purchase triggers. You get this from analytics and instrumented data. Most PMs have some of this. It tells you what’s working but not why.

Layer 3: Motivation. Why they do it — the job they’re hiring your product for. You get this from interviews and contextual inquiry. Teresa Torres calls this the “opportunity space” — the unmet needs, pain points, and desires that drive behavior. Her framework in Continuous Discovery Habits insists on weekly interviews where you collect stories, not opinions.

Layer 4: Context. What surrounds the decision — their constraints, their alternatives, their emotional state when they open your product. You get this from spending time with users in their actual environment. Rob Fitzpatrick’s The Mom Test is the best guide here.

Layer 5: Contradictions. Where what they say and what they do diverge. You get this by holding Layers 2, 3, and 4 in tension. This is where the real product insights live. The feature nobody asks for but everybody uses. The problem they describe incorrectly but feel intensely.

Most PMs operate at Layers 1–2. The best PMs live at Layers 3–5.

What It Looks Like in Practice

When I walked into a new role with those 18 research studies going back to 2012, instead of reading executive summaries, I indexed every finding — 35 discrete, citable insights with evidence levels and source documents. Within a week, I could trace any claim about our users back to the specific study, sample size, and date.

What emerged wasn’t in any single study. It was in the pattern across all of them. The #1 cancel reason for 7 straight years was “I didn’t use it” — not “too expensive,” not “missing features.” Just didn’t use it. Forty to 56% of non-subscribers didn’t know the premium tier existed. The growth problem wasn’t conversion. It was awareness. The user base was aging, but the most convertible non-subscriber segment was 25–39 year olds.

None of these were secrets. They were all documented. But nobody had held them in tension before. The research existed. The deep customer knowledge didn’t — until someone synthesized it.

How to Build This Skill (Starting This Week)

Week 1: Build your Knowledge Stack audit. For your product right now, what do you know at each layer? Write it down. Most PMs discover they’re strong at Layers 1–2 and almost empty at Layers 3–5.

Week 2: Read the raw data, not the summary. Pull the last 3 customer research reports. Don’t read the executive summaries. Read the verbatims — the actual words customers used. The patterns you spot in raw language are different from the patterns a researcher highlighted.

Week 3: Start a contradiction log. Every time you find a gap between what users say and what they do, write it down. Over a month, you’ll have 5–10 entries. Each one is a potential product insight.

Week 4: Talk to one customer who left. Not a satisfaction survey — a conversation. Ask them to walk you through the last week before they canceled. The story will tell you more than the rating ever could.

The PMs who build the best products aren’t the ones with the most customer data. They’re the ones who can tell you where the data contradicts itself — and what that contradiction means. That’s the skill. That’s what separates customer-informed from customer-obsessed.

Your Turn: Apply This Today

Deep customer knowledge isn’t built in one session — it’s built through consistent practice. Start here:

  • Book one customer visit this month — not a Zoom, a visit. Go to where your user actually uses your product. Watch them in their environment. You will learn something in the first five minutes that no survey could surface.
  • Create a “customer reality file.” Start a running document (not a Confluence page no one reads — a doc you actually open weekly) capturing direct quotes, observed behaviors, and surprising context from every customer interaction.
  • Interview a churned user before your next roadmap session. Ask one question: “What were you hoping we’d become that we never did?” Their answer will reorganize your priorities faster than any NPS report.
  • Spend two hours in your support queue. Read the last 50 support tickets without filtering by category. Look for the emotion in the language — frustration, confusion, apology. That’s your product’s actual reputation.
  • Map the user’s day, not just your product’s workflow. Draw a timeline of a typical user’s workday. Mark where your product shows up. Notice what surrounds it — what did they do before, and what do they need to do immediately after?
  • Challenge your next assumption in the open. In your next sprint planning or roadmap review, say out loud: “I believe [user assumption] — here’s what would have to be true for me to be wrong.” Invite pushback. Build the habit of treating assumptions as hypotheses.

Need help building a customer research system that actually informs product decisions? I work with product teams at ministry organizations and faith-tech companies. Let’s talk.

Posted on

What Should Be Free? The Framework I Use to Draw the Paywall Line

I made the wrong paywall call once. We gated a feature that a significant portion of our free users relied on daily — not because the revenue math demanded it, but because “premium users should get more.” Six weeks later, support tickets had doubled, free-to-paid conversion had flatlined, and we’d punished the most engaged segment of our user base. We reversed the decision. It cost us three months and a lot of trust.

The freemium paywall framework I use today came out of that mistake. Here’s how I think about what should be free — and why getting this wrong kills mission-driven products faster than anything else.

The Wrong Question Behind Most Paywall Decisions

Most freemium decisions start from the wrong end. The instinct is reasonable: if you’re building a paid tier, paying users should get more. But when that logic drives every decision, you end up asking “what should go behind the paywall?” instead of “what must stay free?”

That inversion matters more than it sounds. When you start from the free side, you’re forced to defend every gate. When you start from the paid side, you’re incentivized to move things behind walls because it feels like value creation. In my experience, it usually isn’t.

The freemium products that last built genuinely useful free tiers first, then built paid tiers that made useful things faster, deeper, or scalable. The free tier wasn’t a demo. It was a product. If your free tier is deliberately limited to drive upgrades, you’re not running a freemium model — you’re running a time-limited trial. Those are different businesses, and they attract different users with different expectations.

Two Jobs, One Product

The framework starts with a question that sounds simple and isn’t: what job is the user trying to do?

In most digital products — especially mission-driven ones — at least two distinct user jobs show up at the same front door. The personal user and the professional. The student and the practitioner. The occasional reader and the daily power user. These aren’t tiers of the same job. They’re different jobs entirely.

Conflating them into a single pricing decision produces a product that serves neither well — and a paywall that frustrates the users most likely to become your strongest advocates.

Once you’ve mapped the jobs clearly, the paywall question becomes cleaner. For each feature, you’re really asking: does this serve the user who can’t pay, the user who won’t pay, or the user who pays because the tool is genuinely worth it?

Can’t pay: Gate this, and you’ve excluded someone with no alternative. If your product serves a global audience, this is a mission failure disguised as a pricing decision. Won’t pay: Gate this, and you’ll generate complaints with minimal conversions. The feature isn’t their tipping point. Pays because the tool is worth it: Gate this correctly and you have a sustainable model.

The Four Paywall Tests

For every feature — new or existing — I run four tests in order. The order matters.

Test 1: Access. Does gating this feature prevent someone from doing the core job they came here to do? If yes, it stays free. Not “probably free” — free, as a hard constraint. A product that charges for its core value has confused its business model with its purpose.

Test 2: Job. Is the primary user of this feature a personal user or a professional? Personal = free. Professional = paid. Students are a gray zone — check your analytics to see who actually uses it week over week. The data is almost always less ambiguous than the internal debate.

Test 3: Majority World. Would someone with limited income — a volunteer, a practitioner in a lower-income country, a student without institutional backing — need this feature to accomplish meaningful work? If yes, it belongs in the free tier or needs a genuine no-cost path. Scholarship programs, geographic pricing, and educator access are all legitimate answers. “We’ll figure that out later” is not.

Test 4: Revenue sufficiency. Is there a paying segment large enough and motivated enough that this feature can sustain itself economically? A feature behind a paywall that generates no conversions is worse than a free feature. It signals to free users that you’re extracting value while delivering no business result. As OpenView’s SaaS benchmarks consistently show, freemium-to-paid conversion depends heavily on the perceived value gap — not the friction gap.

The Ideology Under the Framework

The four tests are pragmatic. But there’s an ideology underneath them that determines how you handle the hard cases — and in mission-driven products, most hard decisions are edge cases.

The ideology I work from: subscribers are mission partners, not just customers.

When a professional user pays for a tool, they’re making it possible for others who can’t pay to access something valuable. That framing only holds if the free tier is genuinely good. If the free tier is deliberately weak to force upgrades, you’re not distributing access — you’re withholding it and calling it generosity.

This connects directly to how I think about subscription products for ministry — the paywall philosophy and the subscription model are two sides of the same decision. Get one wrong and you’ve undermined both.

Where AI Makes This Harder

Every product team is about to face a version of the same question: where does AI land in the framework?

The professional-tools category is relatively clear. AI features that accelerate professional workflows — research assistants, document generation, structured analysis — belong in paid tiers. The value is concrete, the willingness to pay is real.

The personal-use category is harder. An AI that helps someone understand a difficult concept or access something they couldn’t reach before — is that a professional tool, or is it closer to a core access feature? If you gate it, you’ve made a decision. That decision might be right for the business. It might not be right for the mission. Those aren’t the same thing, and pretending they always align is how you end up making the wrong call at the edge cases.

The products that age well are the ones that answered that question from the mission side first and built the revenue model around the answer.

The Clarity You Owe Your Users

The mistake I described at the start wasn’t really a pricing mistake. It was a clarity mistake. We hadn’t named what we believed about our users, so we defaulted to what we thought premium users deserved instead of what free users needed.

The framework above doesn’t eliminate that tension. It makes it visible. When you can map the jobs, run the four tests, and state the ideology out loud in a room with your team, you at least know what tradeoff you’re making.

Your Turn: Apply This Today

Walk your current or next paywall decision through this framework before your next pricing review:

  • Categorize every feature as acquisition or retention. Go through your feature list and sort each into: “this brings users in” vs. “this keeps users coming back.” Acquisition features belong in free. Retention features belong in paid.
  • Identify your “aha moment” and protect it. What is the single experience that converts a skeptic into a believer in your product? Make sure every user reaches it before they hit a paywall. If the aha is behind a gate, you’re metering the wrong thing.
  • Map your mission-critical users. Who are the users whose engagement creates value for everyone else — contributors, creators, community members? Consider whether paywalling them is worth the cost to the overall ecosystem.
  • Run a “free tier audit.” List everything currently free. For each item, ask: is this generating acquisition or just giving away margin? Remove or gate anything that isn’t actively driving new user acquisition or ecosystem health.
  • Test your paywall message before your paywall decision. Show users a description of your paid tier before you build it. Does the value proposition make them lean in or shrug? If they shrug, you haven’t found the right gate yet.
  • Set a paywall conversion benchmark. Decide in advance what free-to-paid conversion rate would validate your model. Build toward that number. If you hit 6 months without reaching it, revisit what’s behind the gate.

Navigating freemium strategy, pricing philosophy, or subscription model design? These are decisions I’ve made across multiple faith-tech products. Let’s think through it together.

Posted on

The Sermon Library Problem: What Chegg’s Collapse Taught Me About AI and Product-Market Fit

I run a product that helps pastors prepare sermons. We have 245,000+ sermons in our library, decades of content, and a subscription model that’s worked for years. Pastors come to SermonCentral when they’re stuck, when they need inspiration, when Sunday is three days away and the blank page is winning.

And for the first time in my career, I’m looking at that model and asking: Is our product-market fit about to evaporate?

The Treadmill You Don’t See Moving

Reforge published a piece that hit me like a gut punch. The core argument: product-market fit is a treadmill, not a destination. The bar for what customers consider “good enough” is always rising, and AI just cranked the speed to a sprint.

Here’s the part that stuck with me: unlike previous tech shifts that unfolded over years, AI causes the PMF threshold to spike exponentially, giving incumbent solutions no time to adapt before losing relevance.

Mobile took a decade to reshape industries. Cloud computing gave companies 5–7 years to migrate. AI? The examples are already piling up.

Chegg lost 87.5% of its valuation. Stack Overflow saw traffic crater. These were category leaders with massive content libraries and loyal user bases.

Sound familiar?

The Chegg Parallel Is Uncomfortably Close

Let me lay this out plainly.

Chegg’s model: a massive library of human-created study content, monetized through subscriptions, behind a paywall. Students paid because they couldn’t get the answers anywhere else. Then ChatGPT showed up. Suddenly, students could get comparable answers, for free, instantly, with no subscription required.

Now replace “students” with “pastors” and “study content” with “sermon outlines.” Replace “ChatGPT” with SermonAI, Sermon Snap, or honestly just ChatGPT itself with a decent prompt.

The structural vulnerability is identical: a content library behind a paywall, AI that generates comparable output for free, and a “good enough” bar that resets overnight.

I talk to pastors every week. More of them are experimenting with AI tools for sermon prep. Most are cautious about it — but it solves their immediate problem: “I’m stuck and Sunday is coming.”

The Real Strategic Question

Here’s where most product leaders get it wrong. The knee-jerk reaction is: “We’ll just bolt AI onto our existing product.” Slap a chatbot on the homepage. Add an AI summary feature. Ship it fast.

That misses the deeper question: is your product the platform people use AI through, or the platform that AI makes redundant?

If you’re a content library and you add AI search, you’re still a content library. You’ve made the existing model slightly better, but the customer’s mental model hasn’t changed. They’re still coming to you for content, and AI is still generating that content for free elsewhere.

The real pivot is harder. It means rethinking what your product actually is.

For SermonCentral, the strategic move is “AI-powered sermon prep workspace where our library is an input, not the product.” The library becomes training data, context, theological grounding — the thing that makes our AI better than generic ChatGPT. The product becomes the workflow.

Three Questions Every SaaS Leader Should Be Asking Right Now

If you run a content-library or knowledge-base product — and honestly, this applies to most subscription SaaS — here’s the framework I’m using:

1. Can AI generate a “good enough” version of your core deliverable? Be brutally honest. Can AI give my customer something that clears their bar? For many use cases, 70% quality delivered instantly beats 95% quality behind a paywall. If the answer is yes, your paywall is losing its teeth.

2. What does your product offer that AI alone cannot? This is where you find your moat — or discover you don’t have one. For SermonCentral, it’s community validation (knowing 10,000 other pastors used this sermon), exegetical depth that’s been peer-reviewed, denominational fit, and sermon series planning that accounts for the liturgical calendar. These are things a generic AI doesn’t know to consider. Your version of this list is your survival strategy.

3. Are your current users already using AI tools alongside your product? If you don’t know, find out this week. A simple exit survey question, an onboarding poll, a one-question email. If even 15–20% of your users are experimenting with AI alternatives, the adaptation window is already closing.

The Window Is Smaller Than You Think

With previous technology shifts — mobile, cloud, social — companies had years to adapt. You could see the wave coming, form a committee, hire a consultant, run a pilot, iterate for a few quarters, and still catch up.

AI doesn’t work like that. The window slams shut before you recognize the threat severity. Chegg didn’t see a slow decline and choose not to respond. They saw a cliff, and by the time they recognized it, they were already falling.

The work we’re doing right now at SermonCentral — instrumenting whether our users are using AI sermon tools, prototyping AI-augmented workflows that use our library as an input rather than competing with free generation, rethinking activation so that a new user’s first 48 hours deliver something AI alone cannot — is existential work.

What’s Actually Scarce

The companies who survive this shift will be the ones who rebuilt their products around the assumption that AI-generated content is free and abundant — and then found the thing that’s scarce.

For church tech, what’s scarce is trust. Theological accuracy. Community wisdom. The peace of mind that comes from knowing your sermon was shaped by a tradition, not just generated by a machine.

Those things have real value. But only if we build products that deliver them in ways a pastor can feel on a Tuesday night when Sunday is looming.

The treadmill is speeding up. Time to change direction before it throws you off.

Your Turn: Apply This Today

Use these questions to pressure-test whether your product is the next Chegg — or the one that replaces it:

  • Name the task your product completes. Write it in one sentence from the user’s perspective: “When I need to ______, I use ______.” If AI can now complete that task in 30 seconds, your moat is eroding. Be honest.
  • Run the “AI substitute” test. Have someone on your team try to accomplish your product’s core job-to-be-done using only ChatGPT or Claude. Document exactly where the AI falls short. That gap is your defensible surface.
  • Map your unique data assets. What does your product know that a general-purpose AI cannot access? User history, community content, proprietary datasets? If the answer is “nothing,” that’s your most urgent product risk.
  • Identify your highest-engagement users and interview three of them. Ask them directly: “Have you tried using AI tools for what you use us for? What happened?” Their answer will tell you more than any dashboard.
  • Rewrite your product’s value proposition for the AI era. Your old version assumed AI wasn’t available. Rewrite it assuming users have access to powerful AI. What do you still uniquely offer? That’s your actual pitch.
  • Set a 90-day “substitution risk review.” Put a recurring calendar item to evaluate how much of your product’s core workflow can now be replicated by AI. Treat it as a competitive threat review, not a tech curiosity.

Is your SaaS product facing a similar AI-driven PMF threat? I help product leaders think through competitive positioning and strategic pivots in the age of AI. Let’s talk.

View all posts