Month: May 2026

I was part of a team prototyping onboarding flows for a global Bible engagement app, and we made a mistake I’ve seen repeated dozens of times since. We handed the prompts to our AI tools without telling them what the product was for. The AI did exactly what it was trained to do — it reached for patterns from fitness apps, productivity tools, and habit trackers. Badges. Streaks. Daily login rewards. These were the patterns that worked in consumer contexts with the highest engagement data.

The problem: our users weren’t trying to build a fitness habit. They were people trying to connect with scripture in the ten minutes before work. Or processing a hard diagnosis late at night. Or trying to find something true to hold onto in the middle of a season that wasn’t making sense. The streak counter didn’t just fail to help them — it felt faintly insulting. Our completion rates showed it, and when we talked to users, they told us the same thing in different words: this doesn’t feel like it was built for me.

The fix wasn’t a different AI tool. It was embedding the mission before the AI touched anything. My job, I’ve come to understand, isn’t to build features. It’s to build space — the right kind of space for the right kind of encounter. That framing changes what you put into every prototyping prompt.

Why AI Prototyping Defaults to Someone Else’s Mission

AI prototyping tools are trained on the vast middle of consumer software. They know what engagement looks like in fitness apps, productivity tools, social platforms, and enterprise SaaS. What they don’t know is why a small church prioritizes trust over scale, why a children’s ministry platform needs to work in a seven-minute volunteer prep window, or why a global discipleship app has to honor cultural nuance over raw personalization efficiency.

When you hand a prototyping prompt to an AI without mission context, you get competent, generic output. It passes the “does this look like software” test. It fails the “does this serve our community” test. The difference only becomes visible when you put it in front of real users — by which point you’ve spent significant time and trust going in the wrong direction.

The solution isn’t to avoid AI prototyping. It’s to front-load the mission input so the tool has something specific to work from. Specificity is what separates useful AI output from generic AI output. An AI that knows your non-negotiables produces dramatically better output — not because the model is smarter, but because it has the right filter.

How to Embed Mission DNA Before You Prototype

The practice I’ve landed on is building a mission filter document before starting any AI-assisted prototyping sprint. It doesn’t have to be long — a single page with three things: the specific user you’re serving (not a persona template, but a real description of a real person in your community), the job they’re trying to do in their language, and the non-negotiables that define what this product will and won’t do regardless of what the engagement data suggests.

On the children’s curriculum platform, our mission filter was two sentences: “A harried volunteer with seven minutes to prep a lesson. We make that person feel ready, not overwhelmed.” Every prototype, every AI-generated flow, every feature proposal got filtered through those two sentences. The AI didn’t know them by default — but once we embedded them into our prompts, the output changed. We stopped producing things that looked like apps and started producing things that felt like the product we were trying to build.

The other accelerant is bringing non-technical mission stakeholders — pastors, volunteers, community members — into the prototyping process as co-creators, not just testers. Not because they’ll have great UI ideas. Because they’ll immediately tell you when something feels off. Their instinct for “this doesn’t feel like us” is faster and more reliable than any usability metric I’ve ever run.

What Mission-Informed Prototyping Actually Produces

When you prototype with mission DNA embedded, a few things shift. You stop building features that look good in demos but don’t solve the actual user job. You catch misalignments earlier — before they’re built into production — because the mission filter creates a shared language for “this isn’t right” that anyone on the team can use. And you build trust with your community faster, because what they encounter actually reflects the values the product claims to hold.

That last point matters more in faith-tech than anywhere else I’ve worked. Ministry users have a finely tuned instinct for whether something was built by people who understand their context or built by people who read about it. They know the difference. The mission filter is how you make sure they experience the former.

Your Turn: Apply This Today

Before your next AI prototyping session, use this checklist to make sure your mission is in the room.

• Write your mission filter document before the sprint starts. One page: your specific user described as a real person, the job they’re trying to do in their exact words, and three non-negotiables your product will and won’t do. This goes into every AI prompt.
• Interview one ministry stakeholder this week. Ask them to describe what “success” looks like in their specific context — use their exact language in your next prototype prompt and compare the output to what you’d have gotten without it.
• Audit your last three AI-generated prototypes. For each one, ask: does this reflect your mission non-negotiables, or does it reflect generic consumer app patterns? Name the specific places it went generic.
• Add your mission filter to one prompt this sprint. Take a prompt you’ve used before, add the mission context, and compare the output. The difference will make the case for the practice more effectively than any argument I can make.
• Bring one non-technical mission stakeholder into a prototype review. Give them one question: “Does this feel like us?” Their answer is your fastest mission-alignment check — faster than any usability test.
• Create a shared vocabulary for “off-mission” with your team. Name two or three specific patterns that feel wrong for your community — things that work elsewhere but don’t fit your context. Make them explicit so anyone can call them out without it becoming personal.

For more on building AI strategy that fits faith-tech specifically, read The Complete Guide to AI Product Strategy for Faith-Tech and Ministry Leaders and AI Transformation Isn’t About Tools — It’s About Team Mindset.

Getting AI prototyping right in faith-tech requires upfront investment in mission clarity that most teams skip. I consult with product leaders on building that foundation — and on the AI strategy decisions that depend on it. Let’s talk.

The sermon resource platform I was working on nearly buckled on a Sunday morning in November. A church network shared a link, thousands of pastors hit it at once, and we weren’t ready. The platform slowed. Then timed out for some users. Pastors who depended on it to prep for their services got error messages when they needed the product most — which is the worst possible version of the trust problem in faith-tech. We spent weeks recovering that trust. The failure was entirely predictable. We just hadn’t done the work to predict it.

That experience changed how I think about infrastructure. Before it, infrastructure was something engineers handled and product managers approved budgets for. After it, I understood that infrastructure decisions are product decisions — and that in faith-tech, where your users’ most important moments often hit your platform all at once, the product leader who doesn’t understand their infrastructure breakpoints is one viral campaign away from destroying the trust they spent years building.

AI makes this significantly more urgent. The computational appetite of generative AI features is nothing like serving static content. Personalization, content generation, semantic search, real-time analytics — these features carry cost structures that most faith-tech teams don’t model until the bill arrives. By then, you’re either throttling features or absorbing a cost spike you didn’t plan for. Neither is a good option when your users are a volunteer at 6am on Sunday morning.

The Faith-Tech Infrastructure Problem Is Specifically About Timing

Most SaaS products have relatively predictable load patterns. Faith-tech products have predictable spikes — and the spikes happen at the worst possible times. Sunday morning. Wednesday night. Easter. Christmas. The high-traffic moments are exactly the moments when your users are most dependent on the product working and least forgiving of it failing.

When you add AI features to this dynamic, the cost structure amplifies the timing problem. A generative AI feature that costs $0.02 per request is manageable at normal traffic. At 10x traffic on a Sunday morning, that same feature costs 10x as much — and if you haven’t built cost controls, you’re either overspending or throttling users at the exact moment they need the feature most. The infrastructure decision you deferred becomes a user experience crisis on the day you can least afford one.

The product leadership question isn’t just “can we build this AI feature?” It’s “what does this feature cost when everything goes right, and what does it cost — in money and in trust — when everything goes wrong at the worst possible time?”

Building for Breakpoints Before They Happen

The most useful infrastructure exercise I’ve run with faith-tech teams is a failure scenario workshop. Not “what happens when one service has a brief outage,” but what happens in the scenario that felt unlikely until it didn’t — holiday traffic, a viral campaign, an API provider going down, a cost spike that requires immediate throttling.

Walking through those scenarios in advance surfaces the decisions that need to be made before the moment of pressure. Where do you cache? What degrades gracefully versus what fails completely? What does the user experience look like during a partial outage — a clear message, a fallback, or a silent failure that makes your users think they did something wrong? Those decisions, made calmly in advance, are completely different from the same decisions made at 8am on Easter Sunday.

Good infrastructure planning isn’t about eliminating risk — it’s about knowing your tradeoffs. What have you prioritized, and what have you accepted as a known risk? Knowing the answer to that question before you need it is the difference between a managed failure and a trust crisis. For more on the cost side of this, read AI Costs Are Skyrocketing: How Product Leaders Should Budget for AI Before It Bites Them. For the infrastructure architecture decision, read Cloud vs. Self-Hosting for Faith-Tech: How to Choose Infrastructure That Won’t Break Under Pressure.

Your Turn: Apply This Today

Infrastructure planning for AI features doesn’t require an engineering degree. These are product leadership decisions that prevent Sunday morning failures.

• Map every AI feature’s cost structure. For each AI feature in your product, identify the per-request cost and model what happens to your monthly spend at 2x, 5x, and 10x current usage. Know your cost cliff before you hit it — not after.
• Identify your non-negotiable uptime scenarios. Name the two or three user moments where failure is most costly — Sunday morning prep, a high-traffic campaign, a crisis care feature. These define where your highest infrastructure investment needs to go.
• Run a failure scenario session with your team. Pick your highest-risk scenario and walk through it together: what breaks first, what degrades gracefully, what does the user experience look like during the failure, and what does recovery look like? Do this before you need to.
• Implement one caching strategy this sprint. Identify the AI output in your product most likely to be requested repeatedly and build a simple cache. Measure the cost difference over 30 days.
• Move one non-urgent AI call to async processing. Find a feature where real-time AI response isn’t essential to the user experience and shift it to a batch job. This is usually faster to implement than it sounds.
• Design your degraded-mode user experience now. What does your product look like when an AI feature is unavailable — clear communication, a graceful fallback, no silent failures? Ship that experience before you need it. Your users will respect honesty far more than a broken spinner.

For the broader AI strategy context, read The Complete Guide to AI Product Strategy for Faith-Tech and Ministry Leaders.

Infrastructure failures in faith-tech aren’t just technical problems — they’re trust problems. I consult with faith-tech product leaders on AI infrastructure planning, cost management, and building for the breakpoints before they happen. Let’s talk.

We added a streak counter to a volunteer training app and watched engagement spike for three weeks. Then it cratered. The volunteers who kept their streaks alive weren’t the ones doing the best work — they were the ones gaming the system, checking in without actually engaging. The people doing the real work found the streak counter mildly insulting. One of them told me so directly, which I appreciated.

The problem wasn’t the streak counter specifically. The problem was that we rewarded what was easy to measure instead of what actually mattered. That’s the gamification trap — and it’s everywhere in AI adoption right now. Teams add points, badges, and progress bars because those are the mechanics they know, and they watch engagement metrics go up, and they feel like something is working. What’s actually working is the illusion of progress. The real thing — behavioral change that serves the mission — is often going backward.

What Behavioral Science Actually Says About Motivation

Most gamification frameworks start with B.F. Skinner and stop there. The insight is correct: behaviors that are reinforced become more frequent. But Skinner’s research also showed something product teams tend to ignore — variable reward schedules create compulsive behavior, not meaningful behavior. The mechanics that make slot machines effective are also the mechanics that make gamification feel hollow after the novelty wears off. Three weeks of engagement spike, then a crater. I’ve seen this play out more than once.

The more useful framework for faith-tech AI adoption is Self-Determination Theory — the research showing that people sustain behaviors connected to autonomy, competence, and purpose. External rewards can start a behavior. Intrinsic connection to something that matters is what sustains it. For ministry users, “something that matters” isn’t abstract — it’s the lesson that went well, the conversation that helped, the volunteer who felt prepared instead of overwhelmed. That’s what you’re trying to connect the gamification to. Not logins. Not streaks. The actual thing.

Designing Gamification That Serves the Mission

After the streak counter failure, we rebuilt the engagement system around preparation completion rather than session counts. Instead of a streak for daily logins, a progress indicator for lesson readiness — how many of this week’s materials had been reviewed and marked ready. Instead of a badge for time-in-app, a visible confirmation that the volunteer was prepared for their class.

The difference wasn’t cosmetic. Completion rates climbed. More importantly, volunteers who completed their preparation reported feeling more confident leading their classes — which was the mission outcome we actually cared about. Nobody at a volunteer training debrief says “I really loved the streak counter.” They say “I felt ready.” That’s the outcome worth designing toward.

The design principle I’ve landed on: reward the behavior that reflects the mission outcome, not the behavior that’s easiest to measure. For an AI tool used in pastoral care, don’t gamify messages sent — recognize follow-through, the logged interaction that shows a leader used the tool to connect with someone who needed it. For an AI sermon prep tool, don’t reward time spent — reward preparation completed. The outcome you reward is the outcome you get more of.

Adoption Mechanics vs. Engagement Mechanics

There is a legitimate place for lighter gamification: reducing the friction of trying something new. A first-use celebration, a simple progress indicator, a “you’ve used this five times” acknowledgment — these lower the barrier to initial adoption without creating the compulsive patterns that burn out motivation. I’m not arguing against all gamification. I’m arguing for being deliberate about which kind you’re using and why.

The distinction I use is adoption mechanics versus engagement mechanics. Adoption mechanics help people get over the initial friction of learning something new — appropriate during onboarding and early use. Engagement mechanics that reward sustained use need to be tied to mission outcomes, not usage metrics, or you’ll spend months optimizing for the wrong thing. Most AI adoption failures I’ve seen conflate the two. They run adoption mechanics indefinitely and end up with users who feel perpetually coached into using a tool they already know how to use. That’s patronizing, and people feel it.

For more on the team adoption side of this, read AI Transformation Isn’t About Tools — It’s About Team Mindset and Agency Over Automation: Why AI Won’t Replace the Leaders Who Know How to Use It.

Your Turn: Apply This Today

Use this checklist to audit your current AI adoption gamification and rebuild it around outcomes that actually matter.

• Audit every gamified element in your AI features. List each reward, badge, streak, or progress indicator. For each one, name the specific behavior it’s reinforcing — and whether that behavior reflects your mission or just your engagement metrics.
• Identify your two or three mission-aligned outcome metrics. What are the user behaviors that actually reflect the outcome your product is designed to create? These are what your gamification should reinforce — not logins or time-in-app.
• Remove one shallow gamification element this sprint. Pick the reward mechanism that most obviously optimizes for the wrong behavior and replace it with one tied to a mission outcome. Measure the difference over 30 days.
• Interview three users about what makes the work feel meaningful. Ask what makes them feel capable and purposeful with the tool — not what they enjoy about it. Use their answers to redesign one reinforcement mechanism.
• Separate your adoption mechanics from your engagement mechanics explicitly. Decide which gamification elements are for onboarding and which are for sustained use. Audit each category separately with different criteria.
• Set a 30-day mission behavior review. Check whether mission-aligned behaviors — not just usage metrics — are increasing. Adjust the reinforcement design based on what you find, not what the dashboard makes look good.

For more on building AI adoption that actually sticks, read The Complete Guide to AI Product Strategy for Faith-Tech and Ministry Leaders and Three Guardrails Every Product Leader Needs Before Experimenting with AI.

Getting AI adoption right in faith-tech requires designing for motivation that sustains, not engagement that spikes. I consult with product leaders on building adoption strategies that reflect the mission rather than quietly undermine it. Let’s talk.

Most faith-tech teams get their AI strategy wrong in the same way: they start with the tool. They hear about a new model, a new API, a compelling demo — and they spend months building a feature that either gets ignored by users, erodes trust with the community, or drains a budget that was never designed for the cost structure of generative AI. The problem wasn’t the technology. It was the sequence. They bought answers before they understood the questions.

This guide is the resource I wish had existed when I started advising faith-tech product teams on AI strategy. It covers the full picture: how to define the right problems for AI to solve, how to evaluate tools without getting distracted by demos, how to build the team capacity and governance that make AI adoption stick, and how to measure whether any of it is working. Every section links to deeper dives where I’ve written more extensively on that topic.

I’ve led product at one of the largest digital Bible platforms in the world, built ministry tools used by hundreds of thousands of volunteers, and advised teams navigating the specific pressures of building for faith communities. What you’ll find here is practitioner knowledge, not theory — the kind of framework that holds up when you’re in a leadership meeting and someone asks why you’re spending money on AI.

Part 1: Start With the Problem, Not the Tool

The single most common AI strategy failure I see in faith-tech is treating AI as a solution looking for a problem. Leadership hears that “everyone is doing AI” and tasks the product team with integrating it somewhere. The team picks a feature area that seems feasible, builds something, and ships it to users who were never asking for it.

The antidote is problem-first thinking. Before any discussion of tools or timelines, a useful AI strategy starts with three questions: What are the most painful, repeated problems your users face? Which of those problems currently require human intelligence to solve — and is that the right constraint, or just an artifact of how things have always been done? And where does your organization have data that, if analyzed well, would surface insights you’re currently missing?

In faith-tech specifically, the most tractable AI problems tend to cluster around three areas. First, content personalization at scale — helping ministry leaders, volunteers, or individual users get the right resource for their specific context without requiring manual curation. Second, support and response — handling the high volume of repetitive questions that hit ministry teams and church staff, freeing up human attention for the conversations that actually require it. Third, insight from support data — mining the tickets, emails, and feedback that accumulate in any ministry platform for the signals that should be driving your product roadmap.

That third one is underutilized. Most faith-tech teams I work with are sitting on a goldmine of user signal in their support queues and never reading it systematically. AI makes that analysis tractable at a scale no human team can match. Read more on this in Support Data Isn’t Just Feedback — It’s Your AI Strategy’s Fuel.

Part 2: Evaluate AI Tools Without Getting Distracted by Demos

Every AI vendor has a compelling demo. The demo is optimized to show the best case: clean input, ideal output, happy path from start to finish. Your users will encounter the edge cases. Your team will encounter the integration complexity. Your finance team will encounter the cost structure. None of those show up in the demo.

When evaluating AI tools for a faith-tech product, I use four criteria that cut through the noise.

Problem fit: Does this tool actually solve one of the specific problems you identified in Part 1? Not “could it theoretically help with something in our space” — does it directly address a named user pain point? If you can’t answer yes without hedging, you’re buying on hope, not evidence.

Cost structure at scale: Generative AI has a cost model most product teams don’t fully price in during evaluation. Token costs, API call volume, and the infrastructure required to serve AI features to a large user base can turn a seemingly affordable tool into a budget crisis within weeks of launch. I’ve watched teams burn through a quarterly budget in a month because nobody modeled the usage math. Read the full breakdown in AI Costs Are Skyrocketing: How Product Leaders Should Budget for AI Before It Bites Them.

Data privacy and trust: Faith-tech users share deeply personal data — prayer requests, spiritual struggles, giving records, family information. Any AI tool that ingests that data requires explicit scrutiny about where data goes, how it’s used for model training, and what your users would think if they understood the arrangement. The trust your platform has with its community is your most important asset. It’s also the easiest thing to destroy with one poorly disclosed data practice.

Integration complexity: The gap between “this API can do X” and “X is reliably working in production with our existing stack” is where most AI projects actually die. Evaluate tools against your current infrastructure, your team’s technical capacity, and the maintenance burden of a new dependency — not just against the feature it enables.

AI prototyping tools can help you explore fit quickly before committing to full integration — but most teams use them wrong. They prototype the feature they already planned to build rather than using the prototype to test whether the problem is real. More on this in AI Prototyping Tools Are Solving the Wrong Problem.

Part 3: Build Guardrails Before You Build Features

AI features in faith-tech carry unique risks that secular product teams don’t have to think about as carefully. When your product serves people in moments of spiritual seeking, grief, crisis, or formation, an AI response that’s inaccurate, theologically inconsistent, or simply cold can do real harm — not just produce a bad user experience.

Three guardrails belong in every faith-tech AI strategy before any feature ships.

Theological boundary constraints: Your AI features need explicit boundaries around what they will and won’t say on theologically sensitive topics. This isn’t about making the product less useful — it’s about being honest with users about what they’re interacting with and preventing the product from becoming an unintended theological authority. The guardrail isn’t “never engage religious content.” It’s “be clear about what the AI is and isn’t qualified to do.”

Human escalation paths: Any AI feature that touches user wellbeing, spiritual care, or pastoral context needs a clear path to a human. Not buried in settings — visible, easy, and genuinely warm when the user reaches it. The AI feature is a first response layer. It is not a replacement for the human connection that is, in many cases, the actual product your ministry organization is delivering.

Output review and iteration loops: AI outputs in production will surprise you. Build a review process for surfacing problematic outputs before they become user complaints — and build the feedback loop that gets those examples back into your prompt engineering and model behavior. Shipping and forgetting is how AI features erode trust over time. For a full treatment of how to think about these guardrails, read Three Guardrails Every Product Leader Needs Before Experimenting with AI.

Part 4: Build the Team Mindset for AI Adoption

The most common reason AI features fail in faith-tech isn’t technical. It’s organizational. The team doesn’t understand the goal the feature is supposed to achieve, so they can’t make good decisions about how to build it or how to tell if it’s working. Or the team is trained on how to use the tool but not on why the tool exists in context of the mission. Or leadership made the decision to adopt AI without bringing the team into the problem-framing, so adoption is performative rather than genuine.

Successful AI adoption in faith-tech organizations requires three things before any feature goes into development. First, a single, specific mission outcome that the AI feature is supposed to move — not “improve efficiency,” but something measurable like “reduce the time ministry volunteers spend on lesson prep from 45 minutes to 15 minutes.” Second, a shared understanding across the team of how the feature connects to that outcome. Third, one mission metric — beyond engagement and revenue — that you’ll track to know whether the outcome is being achieved.

I’ve watched teams skip all three and ship AI features that everyone agrees are technically impressive and organizationally meaningless. Read more on the mindset side of AI adoption in AI Transformation Isn’t About Tools — It’s About Team Mindset.

There’s also a deeper question about agency. AI tools create leverage, but leverage amplifies whatever direction the team is already moving. Teams with high agency — people who feel empowered to define problems, challenge assumptions, and own outcomes — use AI to do genuinely new things. Teams without agency use AI to do the same things faster. The limiting factor in most faith-tech AI adoption isn’t the tool. It’s whether the people using the tool have the authority and confidence to actually change things. Read more in Agency Over Automation: Why AI Won’t Replace the Leaders Who Know How to Use It.

Part 5: Manage AI Infrastructure Costs Before They Manage You

AI infrastructure decisions are product leadership decisions. Most faith-tech product leaders have delegated this entirely to engineering, which means they’re surprised when the cost reports come in and they have no framework for evaluating the tradeoffs.

There are four cost levers in AI product infrastructure that every product leader should understand. Model selection — the difference between using a large frontier model and a smaller specialized model can be a 10x cost difference for comparable quality on a narrow task. Caching — many AI features make essentially identical calls repeatedly; caching common outputs eliminates cost without degrading the user experience. Batching and async processing — not every AI feature needs a real-time response; moving non-urgent AI calls to batch processing significantly reduces cost. And rate limiting by user tier — not all users need the same level of AI access, and tiering your AI feature access by subscription level is both a cost management strategy and a product differentiation opportunity.

Beyond usage costs, infrastructure resilience matters differently for faith-tech than for most SaaS. When your platform serves ministry moments — a volunteer prepping a lesson, a congregation during a live service, a leader making a pastoral decision — downtime is not just a business inconvenience. It’s a trust breach with a community that was counting on you. Read more on how to think about this in Cloud vs. Self-Hosting for Faith-Tech: How to Choose Infrastructure That Won’t Break Under Pressure.

Part 6: Measure What Actually Matters

Standard product metrics — daily active users, retention rate, revenue — measure market traction. They don’t measure mission fidelity. A faith-tech product can hit every growth target while systematically moving away from the users it was built for and the outcomes it was designed to create.

Every AI feature in a faith-tech product should have at least one mission metric alongside the standard engagement metrics. What is the human outcome this feature is supposed to produce? Are users experiencing that outcome? How would you know if they weren’t?

For AI features specifically, I track three measurement layers. First, technical performance — is the feature producing accurate, appropriate outputs consistently? Second, user behavior — are users engaging with the feature in the way you expected, and completing the task the feature was designed to help with? Third, mission outcome — is the underlying user problem actually being solved, and is that solution serving the broader purpose of the platform?

The mission metric layer is where most teams drop off. It requires knowing what your product is actually for — a discipline that connects directly to the governance question. Read more in Mission-Aligned Governance: How Faith-Tech Products Stay True to Purpose Under Growth Pressure.

Part 7: Putting It Together — An AI Strategy Framework for Faith-Tech

An AI strategy for a faith-tech product isn’t a list of features. It’s a set of decisions about where AI belongs in your product, what problems it’s solving, how you’ll govern it, and how you’ll know if it’s working. Here’s the one-page version of how I’d structure it.

Problem definition (Week 1–2): Interview your highest-value users and your support team. Identify the top 3 repeated, painful problems that currently require human judgment or manual effort. Rank them by user impact and organizational cost. These are your AI candidates — not the other way around.

Tool evaluation (Week 3–4): For each candidate problem, identify 2–3 tools or approaches. Evaluate on problem fit, cost structure at scale, data privacy, and integration complexity. Build one small prototype against the most promising option — not to validate the feature, but to test whether the problem is real and the tool is the right fit.

Guardrail design (Week 4–5): Before writing a line of production code, document your theological boundary constraints, human escalation path, and output review process. Get these reviewed by someone who understands your community’s trust relationship with the product.

Team alignment (Week 5–6): Write the mission outcome your first AI feature is supposed to achieve. Share it with everyone who will build, market, or support the feature. Get explicit buy-in — not on the feature, but on the outcome. Identify your mission metric and start tracking a baseline.

Pilot and iterate (Month 2–3): Ship to a small segment of users. Track technical performance, user behavior, and mission outcome metric. Review AI outputs weekly for the first month. Adjust based on what you learn — not what you assumed.

Governance integration (Ongoing): Add AI feature performance to your quarterly mission review. Ask whether the feature is still serving who you said it would serve, whether the cost structure is sustainable, and whether user trust is intact. AI strategy isn’t a one-time decision. It’s an ongoing discipline.

Your Turn: Apply This Today

Use this checklist to assess where your AI strategy stands right now and identify your most important next move.

• Name your top three AI-candidate problems. Interview five users and your support team this week. List the most painful, repeated problems where AI could plausibly help. If you can’t name three, you’re not ready for an AI feature — you’re ready for user research.
• Audit your current AI cost exposure. If you’re already running AI features, pull your last 90 days of API costs and model them against 3x and 10x user growth. Know your cost cliff before you hit it.
• Write your guardrails document. One page: what your AI will and won’t say, how users reach a human, and how you’ll review outputs. If you ship an AI feature without this, you’re one bad output away from a community trust crisis.
• Define one mission outcome metric. Pick the AI feature you’re most excited about and write the human outcome it’s supposed to produce in one measurable sentence. If you can’t write it, the feature isn’t ready.
• Schedule your first AI governance review. Block 60 minutes this quarter to evaluate whether your current AI features are serving your mission. Put it on the calendar before you forget.
• Read the supporting posts. Each section of this guide has a deeper-dive post linked. Pick the one that addresses your most pressing current challenge and start there.

Building an AI strategy for a faith-tech product is harder than building one for a secular SaaS — not because the technology is different, but because the stakes are different. Your users bring more of themselves to your product than they bring to most software. That’s a responsibility that deserves more than a rushed feature sprint.

I work with faith-tech product leaders on exactly this: building AI strategy that’s technically sound, financially disciplined, and aligned with the mission that justified building the product in the first place. Let’s talk if that’s a conversation worth having.

Get Weekly Posts on Faith-Tech Product Leadership

I write weekly about AI strategy, product leadership, and building mission-driven technology. If you found this guide useful, send me a quick email at joshua.gray.read [at] gmail [dot] com with “Subscribe” in the subject line — I’ll add you to my list and send new posts directly to your inbox.

No spam. Just the kind of practitioner-to-practitioner writing that helps you do the work better.

A friend once told me I was throwing my life away. I wasn’t buying a house. I wasn’t funding a 401(k). I was living on a missionary stipend in South Africa with my wife and four kids, working out of a laptop. From the outside, it looked irrational. From the inside, I was accumulating something that didn’t show up on a balance sheet — trust, relationships, and a deep understanding of what people actually needed versus what they said they wanted.

I think about that a lot when I look at how faith-tech teams design their freemium models. They’re optimizing for the balance sheet metric — conversion rate, feature adoption, upgrade revenue — and missing the thing that actually drives it. Freemium works in consumer SaaS because users are rational feature-seekers. It breaks in faith-tech because your users aren’t buying features. They’re looking for something closer to what that beginner Bible Gateway user is looking for at 2am: signal in the noise. Peace in a crazy world. You can’t gate that behind a paywall and expect them to upgrade.

The Jobs-to-Be-Done Problem With Freemium

Clayton Christensen’s Jobs-to-be-Done framework asks a deceptively simple question: what job is the user actually hiring your product to do? Not what features they use — what problem they’re trying to solve in their life, and why they’re hiring your product over every other option available to them.

For most faith-tech products, the job isn’t “access content efficiently.” It’s something closer to “help me feel connected to my faith in the 10 minutes I have before work” or “give me the confidence that this message will land on Sunday.” Those jobs have emotional and relational weight that standard freemium design completely ignores. When your free tier delivers partial access to content, you’re not failing to convert users because they don’t want to pay. You’re failing because the free tier never did the job they hired it for. They disengage — not because they’re cheap, but because you never built enough trust for them to care what’s behind the paywall.

What a Value-First Free Tier Actually Looks Like

On the curriculum platform I spent years building, we made a deliberate choice: the free tier had to be genuinely complete for the core job. Our primary user was a volunteer with seven minutes to prep a lesson before their group walked in the door. If the free tier didn’t make that person feel ready — actually ready, not “ready enough if they upgrade” — we had failed before the conversion conversation even started.

Premium added community features, deeper analytics, and customization. But the job — make this volunteer feel prepared and confident — was fully done in free. The result: a free tier that built real trust, and a conversion path that didn’t feel like a bait-and-switch. People upgraded because they believed in the product, not because we’d frustrated them into it.

For AI-powered faith-tech tools, the same principle holds. If your AI helps with sermon prep, let the free version generate a full, usable outline with cultural context and practical application. Then charge for depth, integration, and personalization. But if the free version produces half an outline and stops, you haven’t demonstrated value — you’ve demonstrated that you don’t trust your own product enough to let people experience it.

Why Community and Trust Drive Conversion in Faith-Tech

In most SaaS markets, conversion is driven by feature hunger. Users hit the ceiling of the free tier and upgrade to get more. In faith-tech, conversion is driven by trust and community fit. Users upgrade when they believe the product genuinely understands their mission — when it feels like a partner, not a vendor.

That distinction changes everything about what your free tier needs to accomplish. It’s not just about demonstrating value — it’s about demonstrating that you see your user. You understand what they’re trying to do. You built this for them, specifically, not for the average SaaS conversion funnel. Ministry users have good instincts for when a product is built by someone who understands their context versus when it’s a generic tool with a faith-flavored coat of paint. The free tier is where they make that call.

Your onboarding, your empty states, your error messages, your feature framing — all of it either confirms or undermines that impression. This isn’t a design detail. It’s your conversion strategy.

Your Turn: Apply This Today

Before your next freemium redesign or pricing conversation, use this checklist to diagnose whether your model is actually built for your users.

• Interview five users about the job they hired your product to do. Ask what they were struggling with before they found you, and what “done” looks like for them. Let the answers surprise you — they usually do.
• Audit your free tier against the core job. List every step a free user takes to complete their primary goal. Identify every point where they hit a gate — and ask honestly whether that gate is protecting your business or just frustrating your user.
• Write one sentence describing what the free tier accomplishes. Not what features it includes — what it actually does for the user. If you can’t write that sentence, the free tier isn’t solving a job.
• Test a more complete free experience with 50 users. Roll it out small, track whether engagement beyond the first session improves, and measure trust — not just feature adoption.
• Survey those users on one question: did this feel built for you? Not “did you like the features.” Did the product feel like it understood your context. Adjust based on what they tell you.
• Redefine your conversion goal. Set a metric for trust-driven conversion — not raw upgrade rate. Define what it looks like when someone upgrades because they believe in the product, not because you’ve withheld enough to force the decision.

For more on building product strategy around real user motivation, read AI Costs Are Skyrocketing: How Product Leaders Should Budget for AI Before It Bites Them and What Retention Data Actually Tells You (And What It Doesn’t).

Freemium strategy in faith-tech isn’t a pricing decision — it’s a statement about whether you actually understand your users. I consult with faith-tech product leaders on building conversion paths that are built on trust, not tricks. Let’s talk.

A church tech leader emailed me recently with a question I’ve been getting more often than I expected: “We’ve invested in AI tools — better content pipelines, automated workflows, smarter outreach — but nothing’s actually changed. Why isn’t this working?”

I’ve learned to answer this one directly: you’re solving a technology problem when you have a people problem. The tools aren’t the issue. The missing piece is whether your team has the mindset, the clarity, and the shared understanding of what you’re actually trying to accomplish. Without that, the best AI stack in the world produces expensive activity that doesn’t move anything important.

I’ve watched this play out in faith-tech organizations and at scale in secular SaaS alike. The pattern is the same: leadership gets excited about AI’s potential, rolls out new tools, runs feature training, and waits for results. The results don’t come — not because the tools are bad, but because nobody defined what success looks like or connected the tool to a specific outcome anyone actually cares about. The team learns the features. They don’t change what they do.

Why AI Transformation Stalls at the Mindset Level

The shift I’ve had to make myself — and that I watch other leaders resist — is from thinking of AI as a capability to acquire and thinking of it as a way of working that has to be built. Buying a tool is a transaction. Building a team that knows how to use AI well is an organizational change project. Those require completely different leadership approaches, and conflating them is why most AI transformation efforts produce underwhelming results.

In my experience, the teams that actually shift how they work with AI share three things. First, someone — usually a senior leader — uses the tools personally and talks about what they’re learning. Not just encourages others to adopt. Actually does the work themselves and shares what surprised them. Second, the team has a clear, specific outcome they’re trying to affect — not “improve our content” but “reduce the time our volunteers spend on lesson prep from 45 minutes to 15.” Third, early wins are documented and shared in a way that makes the outcome visible to the whole team, not just the metrics dashboard.

The Mission Connection That Most Teams Skip

In faith-tech, there’s an additional layer that secular product teams don’t have to navigate: the team’s relationship to the mission can either accelerate AI adoption or completely stall it. I’ve seen both.

When AI adoption is framed as efficiency — “this tool will save you two hours a week” — faith-tech teams often disengage quietly. Not because they don’t want to save two hours. But because they didn’t get into ministry technology to optimize workflows. They got into it because they believe the work matters. The efficiency framing doesn’t connect to that.

When AI adoption is framed around the people being served — “this tool means the volunteer who has seven minutes to prep a lesson actually feels ready instead of overwhelmed” — the same team engages completely differently. Same tool. Different frame. The difference is whether you’ve connected the technology to the reason the team shows up.

That connection has to be made explicitly and repeatedly, not assumed. Most AI adoption rollouts assume the mission connection is obvious. It isn’t. You have to make it.

Your Turn: Apply This Today

Before your team’s next AI rollout or adoption push, run through this checklist to make sure you’re solving the real problem.

• Name one specific mission outcome your AI tool should affect. Write it in a single sentence — measurable, time-bound, tied to a real person you serve. No vague language. If you can’t write it, pause the rollout until you can.
• Connect the tool to that outcome explicitly. Document how, specifically, this tool moves the needle on that outcome. Walk through a real scenario with your team before feature training starts.
• Use the tool yourself before you roll it out. Not a demo. Actual use, on actual work, with enough repetition to form an honest opinion about what it does and doesn’t do well. Then share that honestly with your team.
• Run a 30-minute session on the why before any feature training. Walk your team through a specific story about the person the tool is designed to help. Make the mission connection visible before you open the tutorial.
• Track one mission outcome metric for 30 days — not tool usage. Completion rates. Volunteer confidence scores. User engagement depth. Something that reflects what you’re actually trying to change, not just whether people logged in.
• Review progress honestly in your next team meeting. Name what’s not working. Adjust the approach, not just the tool settings. The team needs to see that you’re optimizing for the outcome, not protecting the technology investment.

For more on building AI strategy that actually sticks, read AI Prototyping Tools Are Solving the Wrong Problem and Agency Over Automation: Why AI Won’t Replace the Leaders Who Know How to Use It.

AI adoption is a leadership challenge, not a technology challenge. I consult with product leaders and church tech teams on AI strategy, team alignment, and building the organizational mindset that makes new tools actually work. Let’s talk.

Here’s a number that should give faith-tech product leaders pause: a 2024 Flexera report found that 87% of enterprises use multiple cloud providers — yet most teams treat infrastructure as a set-and-forget decision. You pick AWS or Azure, spin up your stack, and move on to the product work that actually feels interesting.

I’ve watched that assumption collapse in real ministry contexts. A children’s ministry curriculum platform I worked with had its live-stream go down mid-service on Christmas Eve — a cloud provider outage that nobody had a fallback plan for. It wasn’t just a tech failure. It was a trust breach with every family watching at home. The team had optimized for convenience and gotten fragility in return.

Cloud infrastructure feels like the obvious choice: scalable, cost-effective, someone else’s problem. But for mission-driven products — where the audience isn’t just a user base but a community with deep emotional stakes — blind cloud dependence can be a hidden liability. The question isn’t whether to use cloud. It’s how to build infrastructure that doesn’t crack when it matters most.

Cloud Gives You Scale. It Doesn’t Give You Resilience.

Nassim Taleb’s concept of antifragility is useful here. Fragile systems break under stress. Robust systems endure it. Antifragile systems get stronger from it. Most cloud-dependent faith-tech products are fragile — they’re built for normal load, and they shatter when something unexpected hits.

I’ve seen this play out beyond outages. A global discipleship app team I worked with faced a mid-contract pricing hike from their cloud provider that consumed 30% of their annual infrastructure budget overnight. They had no leverage and no alternative. The mission didn’t pause; the scramble to find budget did.

Cloud is excellent for elasticity — handling millions of users during a viral moment, scaling down when traffic drops. But elasticity isn’t the same as resilience. When your product is a lifeline for ministry volunteers with seven-minute windows to prep lessons, you need both.

When Self-Hosting and Hybrid Models Actually Make Sense

Self-hosting carries a bad reputation in most product circles — more overhead, more expertise required, more things to break. That reputation is largely earned. But dismissing it entirely ignores cases where control matters more than convenience.

The discipleship app team I mentioned earlier moved to a hybrid model after the pricing shock. They kept cloud for frontend delivery and user-facing features — where elasticity matters — but self-hosted their user data and core content. They regained control over their most critical assets without abandoning the scalability they needed.

For a children’s ministry curriculum platform, we cached lesson content locally as a fallback. The seven-minute volunteer window couldn’t tolerate a cloud dependency. That cache cost almost nothing to implement and eliminated the single point of failure that had been invisible until Christmas Eve.

The framework I use is simple: identify your product’s non-negotiables — the user experiences that cannot fail — and trace every dependency in that path. Wherever you find a single external point of failure, that’s where you need a fallback strategy, whether that’s a cache, a redundant provider, or a self-hosted component.

Making the Cloud vs. Self-Host Decision

Most teams pick infrastructure based on what the founding engineer knew or what the first CTO preferred. That’s not a strategy; it’s inertia. The right decision framework starts with your mission’s non-negotiables and works backward to infrastructure requirements.

Ask yourself: what does the product need to do when everything goes wrong? If the answer is “stay up and serve users” — and for most faith-tech products it is — then every architectural decision needs to account for failure modes, not just happy-path performance.

Cloud-first makes sense when scale and global reach are primary. Hybrid or self-hosted components make sense when privacy, cost control, or reliability of a specific feature are non-negotiable. Most faith-tech products need both in different parts of their stack.

Your Turn: Apply This Today

Infrastructure decisions feel abstract until something breaks. Use this checklist to pressure-test your setup before that happens.

• Map every cloud dependency. List every external service your product relies on — provider, function, and what breaks if it goes down for an hour.
• Identify your non-negotiables. Name the one or two user experiences your product cannot afford to fail on — these define where you need the most resilience.
• Stress-test one critical path. Simulate a cloud outage on your most-used feature and document what actually breaks versus what you assumed would.
• Calculate your 12-month cost exposure. Factor in potential fee hikes, overage charges, and downtime costs — compare that number to a hybrid option for your highest-risk dependency.
• Build one fallback. Pick your highest single point of failure and implement a simple fallback — a cache, a secondary provider, or a self-hosted component — before next month.
• Write a crisis response plan. Document three steps your team takes if your primary cloud provider goes offline. Make it short enough to execute under pressure.

For more on building product systems that hold up under real-world pressure, read AI Costs Are Skyrocketing: How Product Leaders Should Budget for AI Before It Bites Them and Agency Over Automation: Why AI Won’t Replace the Leaders Who Know How to Use It.

Resilient infrastructure is a product leadership decision, not just an engineering one. I consult with faith-tech product leaders on infrastructure strategy, cost discipline, and building systems that serve your mission when it matters most. Let’s talk.

A product manager at a faith-tech startup asked me after a workshop: “Are AI prototyping tools worth the hype? Should my team jump in?” My answer was direct: they can be genuinely useful — but only if your team has already done the discovery work that tells you who you’re building for and what they actually need. Without that, AI prototyping doesn’t accelerate your work. It accelerates your mistakes.

I’ve watched this play out on a curriculum tool I worked on for children’s ministry volunteers. We had AI tools that could generate wireframes and mockups overnight. The output was slick and fast. What we didn’t have was a clear picture of how volunteers actually used the product — that they were prepping lessons in seven-minute windows, on their phones, while something else was happening in the background. Once we spent time with real users, everything changed. The prototypes we’d built before that conversation were solving for the wrong constraints entirely.

The Discovery Gap That AI Prototyping Can’t Fill

The promise of AI prototyping is speed — faster wireframes, faster iteration, faster path from idea to testable artifact. That promise is real. The problem is that speed only creates value when it’s pointed at the right problem. Teams that skip discovery and reach for prototyping tools first end up with a faster path to the wrong answer.

Teresa Torres’ continuous discovery framework makes this argument precisely: product teams need to be constantly testing assumptions with real users, iterating on outcomes rather than outputs. AI prototyping can accelerate the artifact side of that loop, but it cannot generate the user insight that makes the artifact worth building. That insight only comes from talking to users — and most teams are doing far less of that than they think.

The tell that a team has skipped discovery: their prototype feedback sessions produce surprises. Users don’t understand the flow. The feature solves a problem the team assumed existed but users don’t recognize. The navigation makes sense to the team and nobody else. These aren’t AI prototyping failures — they’re discovery failures that AI prototyping revealed faster than a slower process would have. The tool surfaced the problem. The problem was upstream.

When Speed Becomes a Liability

There’s a specific failure mode I’ve seen in teams that adopt AI prototyping without strengthening their discovery practice first: they ship faster, get feedback faster, and — because they haven’t grounded the feedback in clear user outcomes — misread what the feedback means. They iterate on surface signals rather than structural problems. The prototype improves visually while the underlying user need goes unaddressed.

On a cross-functional team I worked with, we used AI tools to generate a series of mockups for a new feature in rapid succession. The PMs were hitting deadlines. The designers were producing great work. The engineers were ready to build. And the users, when we finally got in front of them, had no idea what the feature was for. We’d built consensus within the team about what to build, but we’d never built consensus with the users about the problem we were solving.

Torres’ framing is useful here: teams that do continuous discovery are constantly checking their assumptions against reality. Teams that don’t are building confidence in a direction without checking whether the direction is right. AI prototyping accelerates confidence-building. It doesn’t check whether the confidence is warranted.

How to Use AI Prototyping Correctly

The right sequence is discovery first, prototyping second. That means before any AI tool generates a single wireframe, the team should be able to answer three questions: Who is the specific user this prototype is for? What decision or task are we trying to make easier for them? What does success look like for that user, in their terms?

When those three questions have answers grounded in actual user conversation — not assumption — AI prototyping becomes a genuine accelerant. You know what to build. You have a clear evaluation criterion. User testing produces signal rather than surprise. The tool is pointed at a real target.

The teams I’ve seen use AI prototyping most effectively treat it as a way to test specific hypotheses faster, not as a way to generate options when direction is unclear. That distinction matters. Options without direction produce more meetings. Hypothesis tests with direction produce learning.

Your Turn: Apply This Today

Before your team runs another AI prototyping session, make sure the discovery foundation is in place. Here’s how:

• Answer the three questions before opening the prototyping tool. Who specifically is this for? What task or decision are we making easier for them? What does success look like in their terms? Write the answers in the meeting doc before anyone opens Figma or any AI design tool. If the team can’t agree on the answers, that’s a discovery gap — not a design problem.
• Schedule user interviews before your next major prototype. Not after — before. Even two 30-minute conversations with real users will surface assumptions you didn’t know you were making. The time cost is real. The cost of prototyping in the wrong direction is higher.
• Run a “who is this for?” check on every active prototype. Look at your current prototyping work and ask: can we name a specific real user whose life this will improve, and can we describe specifically how? Prototypes that can’t pass this check are building team alignment, not user value. Both have their place — but they’re not the same thing.
• Separate exploration prototypes from validation prototypes. Exploration prototypes are for generating team ideas. Validation prototypes are for testing specific user hypotheses. AI tools are excellent for exploration. They’re only useful for validation if the hypothesis is already sharp. Know which mode you’re in before you start.
• Debrief on what you learned from the users, not just what you’ll build next. After every user test, the first question in the debrief should be: what assumption turned out to be wrong? Not “what should we change in the prototype?” — what did we assume that the user didn’t confirm? That learning is the asset. The updated prototype is the output.
• Read one chapter of Torres’ “Continuous Discovery Habits” with your team this month. It’s the clearest articulation I’ve found of what a disciplined discovery practice actually looks like in a product team. Pick one chapter, discuss it in your next team meeting, and identify one habit to adopt. The investment pays back faster than most product tools will.

AI prototyping and discovery are both part of the broader question of how teams stay grounded in user reality as AI capabilities expand. Why Teresa Torres’ Continuous Discovery Cadence Is Breaking Down in the AI Age addresses how the discovery framework itself needs to evolve when AI is part of the solution space. And How AI Prototyping Can Break Silos in Faith-Tech Products covers the team alignment dimension of prototyping that this post focuses on the discovery dimension of.

Trying to build a stronger discovery practice in your product team so your AI investment is pointed at the right problems? I consult with product leaders on user research systems, discovery cadences, and the habits that close the gap between what teams assume and what users actually need. Let’s talk.

The most dangerous moment in any AI product initiative isn’t the launch. It’s the planning session where someone says “let’s just try it and see what happens.” I’ve been in that room. The energy is high, the timeline is short, and constraint feels like the enemy of progress. It isn’t. Constraint is what keeps experimentation from becoming chaos.

I learned this the hard way working on a project for children’s ministry resources. We had the technical capability to use AI to auto-generate lesson plans at scale. The business case was obvious. The engineering was ready. What we hadn’t done was define what harm would look like if we got it wrong — and in a context where volunteers were trusting us with theologically sensitive material, that was the question that mattered most. We paused. We defined the guardrail. We shipped something better because of it.

Why Guardrails Accelerate AI Experimentation, Not Slow It Down

There’s a counterintuitive truth about constraint in product work: the teams that define boundaries before they start experimenting move faster than teams that don’t. Not because they’re more cautious, but because they spend less time relitigating the same decisions. Every time a team without guardrails hits an ambiguous call — “should we use this user data for this?” “is this recommendation too aggressive?” — they stop to debate it. Teams with guardrails already know the answer. The constraint bought them speed.

John Wesley’s Three Simple Rules — Do No Harm, Do Good, Stay in Love with God — were designed as a framework for community life, not product strategy. But I’ve found them to be one of the clearest models I know for scoping AI experimentation in mission-driven organizations, because they’re sequenced by priority and genuinely hard to rationalize around.

Guardrail One: Define What Harm Looks Like Before You Build

“Do No Harm” sounds obvious until you try to specify it. Harm in an AI context is surprisingly easy to overlook because it’s often diffuse, delayed, and hard to attribute. A recommendation engine that prioritizes engagement over depth doesn’t harm anyone in a visible way on day one. Over six months, it reshapes behavior in ways that may run directly against the product’s stated mission. That’s harm. It just doesn’t show up in your sprint metrics.

Defining harm specifically, before you build, forces the conversations that matter. In our children’s ministry project, the harm question surfaced a concern nobody had articulated: what happens when AI-generated content contains a theological error that a volunteer doesn’t catch? That’s a trust problem, not just a content quality problem. We added a human review gate. The product shipped later and was far more trusted by the volunteers who used it.

For your context, harm might be data privacy for members, cultural insensitivity in generated content, algorithmic bias in which users get which experiences, or recommendations that drive the wrong behaviors. The form it takes is specific to your product and your users. Name it explicitly in your feature spec before engineering starts.

Guardrail Two: Measure “Doing Good” Before You Claim It

“Do Good” is the guardrail most product teams think they’ve already cleared. They haven’t — they’ve assumed it. There’s a meaningful difference between “this feature is directionally good for users” and “this feature measurably improves a specific outcome for a specific user in a way we can verify.” The first is a hypothesis. The second is a product decision.

I’ve watched teams deploy AI features in faith-tech contexts — sermon prep tools, discipleship engagement nudges, content recommendation engines — that were built with genuinely good intentions and produced genuinely mixed results. Not because the technology was wrong, but because “doing good” was never defined precisely enough to know whether the feature was achieving it. Usage metrics went up. Whether people’s engagement with faith deepened was never measured. That’s a guardrail that was never set.

Before any AI feature ships, I want a one-sentence definition of what “doing good” means in measurable terms: “Users who engage with this feature will [specific behavior] at [measurable rate] within [time window].” If the team can’t write that sentence, the feature isn’t ready to build.

Guardrail Three: Stay Grounded in the Mission When the Hype Pulls You Away

“Stay in Love with God” — translated for product teams — means staying grounded in the specific mission that justifies the product’s existence, especially when vendor pitches and industry trends are pulling you toward shiny features that have nothing to do with it. This is harder than it sounds in 2026. The AI capability landscape changes fast enough that every quarter there are new things your product “could” do. The question is whether doing them serves the people you’re actually building for.

I’ve been in strategy sessions where the room spent an hour excited about a generative AI capability that had no clear connection to user outcomes. The capability was impressive. The use case was thin. The right move was to say no — not because the technology was bad, but because chasing it would have consumed engineering cycles that belonged to the actual problem the product existed to solve.

This guardrail is a practice, not a policy. It requires someone in the room willing to ask “how does this directly serve our users?” without apologizing for slowing the conversation down. Usually that person is the product leader. Make it a habit.

Your Turn: Apply This Today

Before your next AI feature enters the roadmap, run it through these three guardrails explicitly — not as a checklist to complete, but as questions that need honest answers:

• Define harm for your specific context in writing. For the AI feature currently in planning, name the two or three ways it could harm users if it doesn’t work as intended. Data exposure, bad recommendations, eroded trust, misrepresented information — whatever is relevant. Add this to the feature spec. If you can’t name the harm, you haven’t thought about it carefully enough yet.
• Write the “doing good” sentence before scoping data requirements. “Users who engage with this feature will [behavior] at [rate] within [timeframe].” If your team can’t complete that sentence in one working session, the feature definition isn’t ready. This conversation is cheaper than a sprint of building in the wrong direction.
• Put your mission statement in the room when you make AI prioritization decisions. Literally — write it on the whiteboard or put it in the meeting doc. When a new AI capability comes up, the first question is “how does this serve [mission]?” Features that can’t answer that question belong in a backlog, not the current sprint.
• Say no to one trending AI feature this quarter. Not because it’s bad, but as practice. Find one thing your team has been considering because it’s interesting or because a competitor shipped it, and explicitly decline it because it doesn’t clear your guardrails. Document the decision. This builds the muscle of constraint before you need it for a harder call.
• Run a 30-minute team session this week using the three guardrails. Pick your current highest-priority AI initiative and put it through all three questions as a group. Where do people disagree? That disagreement is useful data about misaligned assumptions that would have surfaced at the worst possible time if you hadn’t surfaced it now.
• Interview three users about what “harm” and “help” look like from their perspective. Your internal definition of both will be incomplete without user input. Ask: “What would this product have to do to lose your trust?” and “What would genuinely change your week for the better?” Their answers will sharpen all three guardrails faster than internal debate will.

The constraint framework connects directly to how you define AI features in the first place. Why Your AI Feature Doesn’t Need More Data — It Needs Better Problem Definition addresses how to scope AI work before you start building. And Agency Isn’t Enough: Why AI-Era Product Teams Need Constraint Over Freedom covers the organizational dynamics that make guardrails hard to maintain under pressure.

Working through how to structure your team’s AI experiments so they stay grounded in mission and user outcomes? I consult with product leaders and ministry innovators on constraint-driven AI strategy, feature scoping, and the organizational habits that keep AI investment pointed at the right problems. Let’s talk.

Last year, I nearly blew a product budget on an AI tool that promised to transform user engagement. I fell for the slick demo, the polished pitch deck, and the assumption that token costs were negligible. Three months in, the monthly AI infrastructure bill had quietly grown to something that required an uncomfortable conversation with finance — and the engagement lift didn’t justify it.

I’m not alone in this. AI cost management has become one of the most common and least-discussed problems in product organizations. Teams scope AI features based on demo performance and initial estimates, then watch costs scale unexpectedly as usage grows. By the time the problem is visible, it’s already a crisis — because it’s now entangled with a shipped feature that users depend on.

Why AI Costs Are Harder to Predict Than Other Infrastructure

Traditional infrastructure costs scale in relatively predictable ways — more users means more compute, and the relationship is roughly linear. AI costs don’t work that way. Token pricing for LLM-based features can vary by orders of magnitude depending on model selection, prompt design, context window usage, and whether you’re doing inference, fine-tuning, or both. A feature that costs $200/month at 1,000 users might cost $40,000/month at 100,000 users — not because of linear scaling, but because of how the feature was architected.

This unpredictability creates a specific trap for product teams: they validate the feature at small scale, ship it, and don’t discover the cost problem until they’re well past the point of easy architectural change. The feature works. Users like it. And it’s quietly becoming the most expensive line item in the infrastructure budget.

In faith-tech and mission-driven organizations especially, where margins are thin and every dollar is tied to a stated mission, this trap is particularly dangerous. The organizations that get this wrong don’t just waste money — they create a credibility problem for AI investment overall, making it harder to fund the next initiative that might actually matter.

The AI Budget Discipline Most Product Teams Skip

The fix is a cost architecture conversation that needs to happen before feature development begins — not after launch. This conversation covers four things: unit economics at scale, model selection tradeoffs, prompt efficiency, and cost monitoring.

Unit economics at scale means estimating the cost per user interaction at 10x and 100x your current scale before you commit to an architecture. If the math doesn’t work at 100x, you either need a different model, a different architecture, or a different feature scope. Finding this out at 1x is cheap. Finding it out at 100x is expensive.

Model selection tradeoffs means being intentional about which model you need for which task. The most capable model is not always the right model. For many product use cases — classification, simple summarization, structured extraction — smaller, cheaper models perform comparably to frontier models at a fraction of the cost. Using GPT-4 class models for tasks that a fine-tuned smaller model could handle is a budget decision masquerading as a technical one.

Prompt efficiency matters because token costs are real. Bloated system prompts, unnecessary context, redundant instructions — these add up at scale. A prompt engineering discipline that optimizes for token efficiency alongside output quality pays dividends as usage grows.

Cost monitoring means treating AI infrastructure costs as a first-class product metric, not just an engineering concern. Product leaders who monitor cost-per-interaction alongside user engagement metrics catch problems early and make better architectural decisions.

Your Turn: Apply This Today

Whether you’re scoping a new AI feature or auditing an existing one, here’s how to build cost discipline into your AI product process:

• Run a cost projection before any AI feature enters development. Estimate the cost per user interaction. Multiply it by your current user base, then by 10x and 100x. If the 100x number is uncomfortable, that’s important information — not a reason to kill the feature, but a reason to make intentional architectural choices now.
• Ask “do we actually need this model?” for every AI implementation. Document the specific capability requirement. Then check whether a cheaper model meets that requirement at acceptable quality. If you haven’t tested a smaller model, you haven’t answered this question.
• Audit your most expensive prompt. Pull the system prompt for your highest-usage AI feature and count the tokens. Look for redundancy, unnecessary context, and instructions that could be simplified. Even a 20% reduction in prompt size compounds significantly at scale.
• Add cost-per-interaction to your product metrics dashboard. It should sit alongside engagement, retention, and error rate. If your team can’t see it, they can’t manage it. Cost visibility changes the conversation about AI feature scope and architecture.
• Set a cost ceiling before launch. Define the maximum acceptable monthly AI infrastructure cost for this feature at your current scale and at 3x scale. Make it explicit in the feature spec. This gives engineering a clear target and surfaces tradeoffs early, when they’re still cheap to resolve.
• Review AI costs quarterly with the same rigor as other infrastructure. AI pricing changes. Model options change. What was the most cost-effective architecture six months ago may not be today. A quarterly review ensures you’re not paying legacy prices for capabilities that have gotten cheaper.

AI budget discipline connects directly to infrastructure strategy. Jensen Huang’s Sovereign AI: Infrastructure Argument for Product Builders covers the build-vs-buy dimension of AI infrastructure decisions. And The Product Leader’s AI Infrastructure Blind Spot addresses the organizational patterns that cause AI infrastructure costs to spiral before anyone catches them.

Managing AI infrastructure costs alongside feature development and trying to make the numbers work? I consult with product leaders on AI strategy, infrastructure decisions, and the budget frameworks that keep AI investment sustainable as products scale. Let’s talk.

I’ve seen AI generate a sermon outline in seconds. I’ve watched it draft a social media calendar in minutes. I’ve used it to analyze engagement data that would have taken a team a week to process manually. And in every one of those cases, the value didn’t come from the AI. It came from a person who knew which problem to point it at, how to evaluate whether the output was any good, and what to do with what it found.

The “AI will replace product managers / pastors / tech leaders” conversation misses the actual dynamic. AI doesn’t replace judgment. It makes judgment more consequential. The leaders who understand this are pulling ahead. The ones waiting to see if they’ll be replaced are falling behind — not to AI, but to the people who learned to work with it.

Automation vs. Augmentation: The Distinction That Matters

The replacement anxiety is driven by a conflation of two very different things: automation and augmentation. Automation replaces a task. Augmentation improves the quality or speed of a decision. Most of what AI does in product and ministry contexts is augmentation, not automation — and augmentation doesn’t reduce the need for the person doing the work. It raises the bar for what that person can accomplish.

When AI drafts a sermon outline, a good pastor isn’t replaced — they now have more time to do the thing AI can’t do: knowing the widow in row three, understanding the weight of what the congregation is carrying this week, and delivering something that actually meets them there. The draft is scaffolding. The sermon is still fully human.

When AI surfaces a pattern in support tickets, a good product manager isn’t replaced — they have faster access to a signal that used to take weeks to surface. The decision about what to do with that signal still requires product judgment, user empathy, and strategic context that no model has. The analysis is faster. The judgment is still theirs.

What AI Actually Replaces

Here’s the honest version: AI does replace some things. It replaces the first draft of documents that don’t require original insight. It replaces basic data aggregation that humans were doing slowly and inconsistently. It replaces repetitive categorization tasks that consumed analyst time without producing analyst thinking. These are real things — and losing them to AI is, on balance, good. They were preventing people from doing their best work.

What AI doesn’t replace: the ability to define which problem is worth solving. The judgment to evaluate whether an AI output is trustworthy in a specific context. The relationships and credibility that make a recommendation worth following. The courage to make a call when the data is ambiguous. The discernment — in ministry contexts especially — to know when the technically correct answer is the wrong pastoral choice.

These are the capabilities that compound with AI rather than competing with it. The more AI handles the mechanical, the more valuable human judgment becomes. Which means the leaders who invest in judgment — in pattern recognition, in mental models, in knowing their users deeply — are the ones whose value increases as AI capabilities improve.

The Trap: Outsourcing Ownership, Not Just Tasks

The real risk isn’t that AI replaces product leaders or ministry leaders. It’s that leaders outsource ownership to AI alongside the tasks. There’s a meaningful difference between “AI drafted this and I refined it” and “AI drafted this and I shipped it.” The first is augmentation. The second is abdication.

I’ve watched this happen in both product organizations and faith-tech teams: leaders hand first drafts to AI and stop interrogating the output. The quality degrades slowly, then quickly. Users notice before leaders do. And when something goes wrong — a feature that misses the user’s actual need, a message that lands badly with the congregation — there’s no accountability structure, because nobody owns the decision.

Agency over automation means staying in the decision loop even when AI is doing the heavy lifting. It means knowing enough about what your AI tools are doing to evaluate their output critically. It means treating AI-assisted work as your work — with your name on it and your judgment applied to it.

Your Turn: Apply This Today

Here’s how to build an “agency over automation” practice that keeps you in the decision loop as AI takes over more of the mechanical work:

• Audit what you’re outsourcing vs. what you’re augmenting. For every AI tool you currently use, ask: am I using this to do my thinking faster, or to avoid thinking? The first is augmentation. The second is a skill you’re letting atrophy. Be honest about which is which.
• Always apply one critical edit to every AI output before it ships. Not to prove you’re involved — to stay in the judgment loop. If you can’t identify something worth changing or adding, the output isn’t being evaluated critically enough. Friction in evaluation is a feature, not a bug.
• Name the judgment call in every AI-assisted decision. “AI surfaced this pattern; I decided to prioritize it because [reason].” This keeps ownership explicit and builds a decision log that’s useful when you need to explain your reasoning later.
• Invest in the capabilities AI doesn’t replace. User empathy. Mental models. Deep domain knowledge. Relationship credibility. These compound with AI rather than competing with it. Wherever you’re currently underinvesting in these, that’s where your development time should go.
• Set one “AI-free” decision this week. Pick a product or strategic question and work through it without prompting a model first. Notice what you know, what you don’t, and where your judgment is weakest. That map is where you need to grow.
• Talk about AI augmentation explicitly with your team. Not as a policy — as a culture conversation. “We use AI to do [tasks] faster. We own the judgment on [decisions]. Here’s the line.” Teams that have this conversation explicitly are more resilient to the drift toward outsourcing that happens when nobody names the boundary.

Agency and ownership in AI contexts are closely related to how you build team culture around AI adoption. Why Agency Trumps Skills for AI-Driven Church Tech Teams covers the ownership dynamic from a team-building angle. And Why AI Decision-Making Needs Human Judgment: The Solomon Test explores where AI judgment breaks down and human judgment becomes non-negotiable.

Thinking through how to keep human judgment at the center of an AI-augmented product or ministry organization? I consult with product leaders and ministry innovators on AI strategy, team culture, and the practices that keep people — not tools — in the decision loop. Let’s talk.

Last month, I sat in a church basement with a tech team lead drowning in AI tools. He had a dozen browser tabs open, each promising to automate something — sermon prep, small group scheduling, follow-up emails. His face was pure frustration. “I can do anything with these,” he said. “But I have no idea what I should do.”

I’ve heard variations of that sentence from product leaders at organizations far beyond church tech. The promise of AI is unbounded capability. The reality is that unbounded capability without constraint produces paralysis, not progress. Giving a team agency over a blank canvas doesn’t produce great work — it produces anxiety. The teams that are actually moving forward with AI aren’t the ones with the most freedom. They’re the ones with the clearest guardrails.

Why Too Much Freedom Is a Product Problem

There’s a well-documented psychological pattern here: when options multiply, decision quality degrades. Barry Schwartz called it the paradox of choice. The same dynamic that makes consumers freeze in front of 47 varieties of salad dressing also makes product teams stall when handed AI capabilities with no defined scope.

I’ve watched product teams spend entire quarters “exploring AI possibilities” — building demos, attending workshops, writing strategy documents — without shipping a single user-facing improvement. The exploration felt productive. The output wasn’t. And the root cause wasn’t lack of skill or motivation. It was the absence of a constraint that forced a decision.

Constraint isn’t the opposite of agency. It’s the container that makes agency useful. A product manager with agency and no constraint is a sculptor with clay and no deadline. A product manager with agency and clear constraint is a sculptor with clay, a deadline, and a specific brief. The second one ships.

Wesley’s Three Rules as a Product Constraint Framework

John Wesley’s Three Simple Rules — Do No Harm, Do Good, Stay in Love with God — were written as a framework for Methodist community life in the 18th century. I’ve found them to be a surprisingly clean model for AI product constraints, particularly because they’re sequenced by priority and genuinely hard to game.

“Do No Harm” maps directly to the first constraint every AI product decision should clear: are we breaking anything? Are we introducing complexity that frustrates users who didn’t ask for it? Are we shipping a feature that serves the roadmap more than it serves the user? The discipline of asking “what harm could this cause?” before shipping has stopped more bad ideas on my teams than any review process.

“Do Good” maps to the second constraint: is there measurable user benefit? Not “this is technically impressive” or “this will differentiate us in demos.” Actual user benefit, with a metric attached. I’ve watched teams get seduced by generative AI for content creation, spend months iterating on algorithms, and launch to crickets — because they never defined what “doing good” for the user actually looked like in this context.

“Stay in Love with God” — secularized, this becomes “stay grounded in mission.” AI hype can pull organizations away from the thing they exist to do. I’ve been in strategy meetings where the room buzzed about “transformative AI roadmaps” while the core problem — equipping the people the product is supposed to serve — got lost. Constraint means refusing to drift with every AI trend, and anchoring back to the specific outcome that justifies the product’s existence.

Constraint as a Design Principle, Not a Limitation

The reframe that helps teams most: constraint isn’t what you can’t do. It’s what you’ve decided to do first. A constraint says “this quarter, we’re only using AI to address user friction in the onboarding flow” — not because other AI applications don’t matter, but because focus produces better outcomes than breadth. You can revisit the other applications next quarter. You can’t revisit the quarter you spent spinning.

Teams that build constraint-first AI strategies share a few common habits: they define their AI investment in terms of specific user outcomes before selecting tools, they set explicit scope boundaries for each AI experiment, and they treat “we should also try X” as a backlog item rather than a current sprint addition. These habits sound bureaucratic until you see what the alternative produces — which is usually a lot of demos and very little improvement in the metrics that matter.

Your Turn: Apply This Today

If your team has been in “AI exploration mode” without clear traction, here’s how to apply constraint thinking and start moving:

• Run every current AI initiative through the “Do No Harm” filter. For each active experiment, ask: who could this hurt, confuse, or frustrate — and are we certain that’s not happening? If you can’t answer that question with evidence, the experiment isn’t ready to ship.
• Define “Do Good” in measurable terms before the next sprint. Write one sentence per AI initiative: “We’ll know this is working when [specific user behavior or metric] changes by [amount] in [timeframe].” Initiatives that can’t complete that sentence don’t belong in the current sprint.
• Do a mission audit on your AI roadmap. List every AI initiative your team is working on. For each one, answer: how does this directly serve the specific outcome that justifies this product’s existence? Items that can’t answer that question are candidates for the backlog, not the sprint.
• Set one explicit scope constraint this quarter. Not a theme — a boundary. “This quarter, AI investment is limited to reducing time-to-value in our onboarding flow.” Decide what’s out of scope and write it down. Teams that know what they’re not doing are faster than teams that can do anything.
• Build a “next quarter” list. Every time someone says “we should also try [AI thing],” add it to a visible next-quarter list rather than the current backlog. This preserves the idea without letting it dilute the current focus. The list becomes a gift to your future self at quarterly planning.
• Review your constraint at the end of each sprint. Ask: did this constraint help us make better decisions, or is it the wrong constraint? Constraints should be reviewed, not assumed. The goal isn’t rigidity — it’s focus. If the constraint is pointing your team at the wrong problem, change it.

Constraint thinking connects directly to how you define AI features in the first place. Why Your AI Feature Doesn’t Need More Data — It Needs Better Problem Definition covers how to scope AI work before you start building. And Three Rules for AI Prompt Design: John Wesley’s Constraint Framework applies the same Wesley framework specifically to prompt engineering discipline.

Working through how to focus your team’s AI investment and stop spinning on exploration without outcomes? I consult with product leaders on AI strategy, constraint frameworks, and the organizational habits that turn AI capability into shipped product impact. Let’s talk.

Two years ago, I was in a cramped church office helping a small tech team work through an inbox overflowing with user complaints about their digital giving platform. One email stopped me cold. A frustrated pastor had written: “I spend more time troubleshooting this than preparing my sermon.”

That line hit harder than any crash report or churn metric ever could. It wasn’t just a complaint — it was a window into exactly how badly the product was failing its core users. In that moment I saw support data for what it really is: not a burden, but the clearest possible signal about where to invest next.

Why Product Teams Treat Support Data as a Chore

Most product teams, especially in resource-constrained organizations, treat support tickets as a lagging indicator to skim at the end of a sprint — or a problem to outsource to the customer success team. I’ve been guilty of this myself. When you’re moving fast, the inbox feels like noise.

But treating support data as noise is one of the most expensive misreads a product team can make. It’s where your most motivated users — the ones who cared enough to write in — tell you exactly what isn’t working, in their own words, without anyone asking them to. You can’t buy that signal. You can only neglect it.

Charlie Munger’s inversion mental model is useful here. Instead of asking “how do we improve the product?” ask the inverse: “What would we have to do to guarantee users keep struggling?” The answer almost always lives in the support inbox. Users are already telling you. The question is whether you’re listening.

Support Data as AI Strategy Fuel

In the AI era, support data has become even more strategically valuable — and even more underused. Here’s why: AI tools are exceptionally good at pattern recognition across large text datasets. A human reviewing 500 support tickets per week might catch broad themes. An AI tool scanning those same tickets can surface micro-patterns — clusters of friction around a specific workflow step, a correlation between certain user profiles and specific failure modes, sentiment shifts that precede churn — that no human reviewer would reliably find.

I worked on a curriculum platform serving children’s ministry volunteers where the support inbox was consistently a clearer signal of product-market fit issues than any analytics dashboard we had. One pattern that kept recurring in tickets — volunteers struggling to find resources on spotty rural internet — didn’t appear anywhere in our usage data. It appeared in the inbox. When we ran that pattern through basic text clustering, we found it was the third most common friction category, affecting users we’d never targeted in our discovery work. That insight drove an offline-first redesign that meaningfully improved retention in our rural segment.

The pattern is consistent across every product I’ve worked on: the support inbox knows things your dashboard doesn’t. The teams that build systematic processes to extract and act on that signal have a durable information advantage over teams that don’t.

Building a Support Intelligence System

Turning support data into AI strategy fuel doesn’t require a sophisticated tech stack. It requires a systematic process and a commitment to treating support insights as a first-class input into product decisions — not an afterthought.

The minimum viable version looks like this: someone on the team reads and categorizes every support ticket weekly, tagging by friction type, user segment, and severity. Those categories get reviewed in sprint planning. High-frequency friction categories go on the roadmap; emerging friction patterns trigger user interview follow-up. That’s it. No AI tools required, though they accelerate the process significantly when you have volume.

The more sophisticated version adds AI-assisted sentiment analysis and clustering to your helpdesk workflow — tools like Zendesk’s AI features, Intercom’s categorization, or even a simple export into a text clustering tool. The goal is to reduce the time between “user experiences friction” and “product team knows about it and understands its scope.” The faster that loop closes, the more responsive and credible your product team becomes.

Your Turn: Apply This Today

Whether you have a mature support operation or a shared inbox that nobody owns, here’s how to start turning support data into strategic signal — this week:

• Spend 30 minutes reading raw support tickets this week — not summaries. Read them as a product leader, not as a support manager. You’re looking for the underlying need behind the surface complaint. A ticket about a confusing UI is often a ticket about a missing mental model. What is the user actually trying to do?
• Apply Munger’s inversion. Ask: “What would we have to do to guarantee users keep struggling with this?” Write down the three things your product would have to do to make the support inbox worse. Then check whether any of those things are currently true. The answers will be uncomfortable and useful.
• Tag this week’s tickets by friction type. Even a rough taxonomy — navigation, missing feature, confusing workflow, performance, trust — will reveal patterns in one week that monthly summaries miss. Do it manually first; automate later.
• Pull one raw user quote from the inbox and bring it to your next team meeting. Read it aloud. Ask the team: “What does this user actually need?” One real quote does more to align a team around user reality than three slides of aggregated survey data.
• Add support data review to your sprint planning agenda. Even five minutes — “what did the inbox tell us this week?” — changes the dynamic. Decisions made with fresh user signal are better decisions, and the habit compounds over time.
• Identify one support-informed fix you can ship in the next sprint. Not a big feature — a small, targeted improvement that directly addresses a recurring friction category. Show the team what happens when support data drives prioritization. The results build the habit faster than any process mandate will.

Support data and retention data are closely linked signals. What Retention Data Actually Tells You (And What It Doesn’t) covers how to build a complete picture of user health beyond churn numbers. And Munger’s Mental Models and AI Product Decisions goes deeper on applying inversion and other mental models to product strategy.

Trying to build better feedback loops between your users and your product team? I consult with product leaders on user research systems, data strategy, and the organizational practices that close the gap between what users experience and what gets built. Let’s talk.

Six months ago, I was coaching a product leader at a faith-tech nonprofit who was drowning in the flood of AI tools hitting his inbox. He’d spent hours watching tutorials, clicking through demos, and trying to “keep up” with every new feature drop. His voice cracked over Zoom as he admitted: “I’m learning a lot, but I’m not getting anywhere.”

He wasn’t lazy. He wasn’t slow. He was caught in the most common trap in AI learning — mistaking tool fluency for strategic capability. He knew how to use the tools. He had no idea which problem to point them at.

Learning AI Without a Purpose Kills Momentum

This pattern shows up everywhere in product organizations right now. Teams attend AI workshops, subscribe to newsletters, build internal sandboxes — and then struggle to translate any of it into shipped product improvements. The bottleneck isn’t knowledge. It’s the absence of a clear problem that the knowledge is meant to serve.

There’s a meaningful distinction between AI literacy and AI effectiveness. Literacy is knowing what the tools can do. Effectiveness is knowing which problem in your specific product context is worth solving with them, and having the judgment to evaluate whether the tool actually helps. Most AI learning programs develop the first. Almost none develop the second.

The result is product leaders who can speak fluently about LLMs, embeddings, and RAG pipelines but can’t answer the question that actually matters for their team: “What is the most important thing AI can do for our users right now?” That gap is expensive. Not just in time and training budget — in team credibility and strategic direction.

The Mental Model That Changes How You Learn

Charlie Munger’s latticework mental model is useful here. His argument was that knowledge organized around real problems is exponentially more useful than knowledge accumulated for its own sake. Every new concept anchors to an existing one, and the whole structure becomes more useful with each addition. Knowledge without a problem to anchor to just drifts.

Applied to AI learning, the implication is direct: start with the problem, not the tool. Before you invest time in learning any AI capability, write down the specific friction point in your product that you’d like it to address. Not “AI could make our onboarding better” — that’s too vague to act on. Something like: “Our support team spends 40% of their time answering questions that could be answered by a well-designed in-product FAQ. Could an AI-assisted feature reduce that?” Now you have a problem worth learning toward.

This reframe does something important: it makes your AI learning time accountable. If you’re three hours into a tutorial and you can’t articulate how it connects to your stated problem, that’s a signal — either the tutorial is the wrong one, or your problem definition isn’t sharp enough yet.

Clear Thinking Beats Endless Learning

The product leaders I’ve seen develop genuine AI effectiveness share a habit: they apply opportunity cost thinking ruthlessly to their learning time. Every hour spent on a tutorial that doesn’t connect to a current product problem is an hour not spent on user interviews, roadmap clarity, or team alignment. The cost is real even when it’s invisible.

This doesn’t mean stopping learning. It means changing the sequence. Identify the problem first. Map the assumptions behind the problem. Then go find the specific AI capability that addresses it — and learn only that, deeply, before moving on. You’ll learn slower in volume and faster in applicability. And applicability is what actually ships.

One practical reframe I use with teams: replace “keep up with AI” as a goal with “improve one specific outcome in the next 30 days using AI.” The first goal is a treadmill. The second is a target. Targets produce movement; treadmills produce fatigue.

Your Turn: Apply This Today

Before you open the next AI newsletter or sit through the next demo, run through this checklist to make sure your AI learning is anchored to something real:

• Write down your current product’s top three friction points. Not AI opportunities — actual user or team pain points. Any AI learning you do this month should connect directly to one of these three items.
• Cancel or pause one AI learning subscription that you can’t connect to a current problem. The mental overhead of processing irrelevant information is a real cost. Reduce the noise before adding more signal.
• If you’re learning an AI tool without a clear problem to solve, pause and redirect that time to user interviews. Thirty minutes of user conversation will point your AI investment better than most tutorials will.
• Set a 30-minute timer this week to map a mental model for your product’s biggest gap. Start with the end goal (e.g., higher retention, faster activation) and work backward to the root cause. That root cause is where AI learning should be aimed.
• Test one AI tool or feature against a specific friction point in the next two weeks. Don’t aim for perfection — aim for a measurable result: “Reduce support ticket volume by 10%,” “Cut onboarding time by two steps.” Specificity is what makes the test informative.
• Share this framing with your team in your next meeting. Walk them through prioritizing mission-relevant learning over tech hype using one real user story. Teams that learn together toward shared problems develop AI effectiveness faster than teams where everyone is self-directing their own curriculum.

If you’re working through where AI fits in your product strategy, Why Your AI Feature Doesn’t Need More Data — It Needs Better Problem Definition addresses how to scope AI features correctly before you write a line of code. And Munger’s Mental Models and AI Product Decisions goes deeper on the latticework framework applied to product leadership.

Working through how to make your team’s AI investment actually move the needle on outcomes that matter? I consult with product leaders on AI strategy, learning frameworks, and the organizational dynamics that determine whether AI capability translates into product impact. Let’s talk.

The request comes in through Slack, dressed up as a technical conversation: “We need more training data before we can improve the model.” Sometimes it’s true. More often, it’s a symptom of something upstream that no amount of data will fix.

I’ve sat in product reviews where teams requested months of data collection before they could ship a meaningful AI feature — only to discover, after collecting the data, that they’d been optimizing for the wrong output the whole time. The model got better at predicting something. It just wasn’t predicting the right thing.

The AI Feature Problem That Isn’t a Data Problem

Most AI feature failures I’ve seen in product organizations aren’t engineering failures. They’re problem definition failures. The team knew what they wanted to build. They knew which model architecture they’d use. They had a rough sense of the training data they’d need. What they hadn’t done was write a crisp one-paragraph answer to a deceptively simple question: What specific decision are we trying to improve, for whom, and how will we know the improvement is real?

That question sounds basic. In practice, it’s brutally hard to answer precisely — and most AI feature discussions move past it without ever settling it. Instead, teams anchor on the technical implementation (which model, which API, which pipeline) and skip the product fundamentals that determine whether any of it will matter.

The result is a common and expensive failure mode: you ship an AI feature, it’s technically impressive, and adoption is flat. Users aren’t hostile to it — they just don’t reach for it. Because the feature is solving a problem that wasn’t sharp enough to justify its existence in the first place.

Problem Definition Before Model Selection

There’s a sequence that high-performing AI product teams follow — often implicitly — that lower-performing teams skip. It goes: problem definition → success metric → data requirements → model selection. Most teams invert this. They start with a model or an API capability, then work backward to find a use case. The resulting features are technically coherent but strategically thin.

Problem definition, done right, answers four things before any engineering begins:

Who has the problem? Not “our users” — a specific persona, role, or workflow. The tighter your answer, the more precise your feature can be. Vague personas produce vague AI features that try to be useful to everyone and end up indispensable to no one.

What decision are they currently making badly? AI is most useful when it augments or automates a decision that a human is already making but making slowly, inconsistently, or with incomplete information. If you can’t identify the decision, you can’t define what “better” looks like.

What does “better” actually mean? Faster? More accurate? More consistent? Less effortful? These aren’t the same, and they don’t optimize for the same outputs. A feature that reduces decision time by 40% but introduces 15% more errors may be worse than no feature at all — depending on the stakes of the decision.

How will you measure the improvement? Before you define your data requirements, you need your success metric. If you can’t articulate a measurable outcome that would tell you the feature worked, you’re not ready to scope the data pipeline.

Why Teams Skip This Step

Skipping problem definition isn’t laziness. It’s usually organizational pressure. There’s a demo to prep for. There’s a competitor who just shipped something. There’s an executive who read about the technology and wants to see it in the product. In those conditions, “we need to define the problem more precisely” sounds like a stall tactic. It isn’t — but it can feel like one.

The reframe I use with teams: problem definition doesn’t slow down AI feature development. It accelerates it. When the problem is crisp, data requirements become obvious. Model selection becomes obvious. Evaluation criteria become obvious. The team spends less time rebuilding the pipeline because they didn’t spec it wrong the first time.

I’ve watched teams spend 12 weeks collecting data for a feature that took 4 weeks to build — only to realize at launch that they’d defined the output variable incorrectly. A week of problem definition work at the front would have surfaced that misalignment long before the data collection started.

The Practical Test: Can You Write the Prompt?

Here’s a heuristic I’ve started using with teams evaluating AI features: can you write the prompt that would produce the output you want, and does that output solve the problem as you’ve defined it? If you’re using a generative model, this is literal — write the prompt. If you’re using a predictive model, translate: can you describe in plain English what you’re asking the model to predict, and does that prediction map to a real decision that real users need help making?

If you can’t write the prompt — or if the prompt output doesn’t map clearly to a user decision — you don’t have a data problem. You have a problem definition problem. And that’s a conversation to have in a product review, not a sprint planning session.

Your Turn: Apply This Today

Before your team writes another line of code or collects another batch of training data, run your AI feature through this problem definition checklist:

• Write the one-paragraph problem statement. Include: who has the problem, what decision they’re currently making badly, what “better” means in measurable terms, and how you’ll know the feature worked. If your team can’t agree on this paragraph in one working session, that’s your first sprint — not the model.
• Identify the specific decision your AI feature augments or automates. If you can’t name a decision, you don’t have an AI problem — you may have a search problem, a dashboard problem, or an information architecture problem. AI is not the right hammer for every nail.
• Define your success metric before scoping data requirements. What measurable outcome will tell you the feature improved the user’s decision? Write it down. Lock it. Then — and only then — work backward to determine what data you need to produce that outcome reliably.
• Run the “prompt test.” Can you write the prompt (or describe the prediction) in plain language? Does that output directly address the decision you identified? If there’s a gap between the model output and the user’s decision, that gap is your product design problem.
• Interview three users about the decision before building. Ask them to walk you through the last time they made this decision. What information did they use? Where did they get stuck? What would have made it faster or easier? Their workflow, not your intuition, should drive your data spec.
• Set a problem definition review gate. Before any AI feature moves from ideation to data collection, require a written problem definition document. One page. Four questions answered. This gate will save you more engineering cycles than any model optimization will.

Related reading: The Product Leader’s AI Infrastructure Blind Spot covers the organizational patterns that cause AI investments to underperform, and Opportunity Solution Trees Meet AI Reality at Scale addresses how to adapt discovery frameworks when AI is the solution space you’re exploring.

Working through AI product strategy and finding that your team keeps building features that don’t land? I consult with product leaders on AI feature scoping, problem definition frameworks, and the organizational dynamics that cause AI investments to underdeliver. Let’s talk.