Category: Digital Discipleship

Building technology for spiritual formation — the product side of discipleship

Posted on

The Complete Guide to Product Leadership in Faith-Tech Organizations

Most product leadership advice is written for teams building consumer apps or enterprise SaaS — contexts where the primary stakeholders are investors, the success metric is growth, and the product’s relationship with its users is transactional. Faith-tech product leadership operates in a fundamentally different environment. Your users bring their spiritual lives, their community relationships, and their sense of calling to the software you build. The stakes of a bad decision aren’t just churn — they’re broken trust with people who were trying to do something that mattered.

This guide is built from years of leading product in that environment — at scale, under real pressure, with teams that ranged from highly capable to completely inexperienced. It covers the specific product leadership challenges that look different when you’re building for ministry: how to inherit a roadmap you didn’t create, how to manage stakeholders whose authority comes from faith conviction rather than organizational charts, how to run discovery with users who are deeply invested in your product’s mission, and how to retain the product quality discipline that makes the mission sustainable when growth pressure starts pushing everything in a different direction.

Part 1: Starting Well — The First 90 Days in a Faith-Tech Product Role

The first 90 days in a new product leadership role in faith-tech are different from any other environment I’ve worked in. The emotional investment of the founding team — often pastors, ministry leaders, or deeply committed Christians who built something out of a sense of calling — means that a new product leader coming in with a change agenda can trigger defensiveness that has nothing to do with the quality of the ideas. The product is personal in ways that make normal new-leader moves feel threatening.

The most effective first-90-days posture I’ve seen works in three phases. The first 30 days are observation only — understanding what exists, why it exists, what users actually do with it, and what the team believes is true about the product’s direction. Not agreeing with all of it, but understanding it well enough to speak to it credibly. The second 30 days are diagnosis — identifying the gaps between what the roadmap promises, what users need, and what the team is actually capable of delivering sustainably. The third 30 days are positioning — presenting a point of view that respects the founding mission while naming the specific things that need to change for the product to serve that mission better.

The single biggest mistake new faith-tech product leaders make is skipping directly to phase three. They come in with an external perspective and immediately try to fix things, without building the relational and contextual credibility that makes the team receptive to change. In faith-tech contexts especially, credibility is earned through demonstrated understanding of the mission — not just product management competency. Read more in The Stakeholder Management Mistake Product Leaders Make in Year One.

Part 2: Inheriting a Roadmap You Didn’t Build

Most product leaders in faith-tech inherit a roadmap. The product existed before they arrived, commitments were made to stakeholders, features are half-built, and there’s a list of priorities that reflects someone else’s understanding of the problem. The challenge isn’t just deciding which of those priorities to keep — it’s doing so in a way that doesn’t alienate the people who created them while still making the changes that need to happen.

There are three types of items on every inherited roadmap. The first type is genuinely valuable work that was prioritized for sound reasons — keep this, and make sure the original stakeholders know you see its value. The second type is work that was promised to someone for political reasons and has little user value — this needs to be negotiated, not canceled. The third type is ideas that made sense at a certain stage of the product’s development but no longer do — this needs to be retired with an explanation that shows you understand why it was on the list in the first place.

The discipline of inherited roadmap review is less about prioritization frameworks and more about stakeholder conversations. Every item you change needs a conversation with the person who put it there — not to get permission, but to demonstrate that you understand what they were trying to accomplish and have a better path to the same outcome. In faith-tech, where stakeholders often have deep emotional investment in specific features, skipping those conversations creates resentment that undermines your ability to lead effectively for months afterward. The full framework is in How to Run a Product Strategy Review When You’ve Inherited Someone Else’s Roadmap.

Part 3: Stakeholder Management When Authority Comes From Conviction

Stakeholder management in faith-tech has a specific complexity that secular product leadership books don’t address: some of your most powerful stakeholders derive their authority from their role in the faith community, not from their position in the org chart. A pastor, a board member with strong theological views, or a major donor who believes they have a vision for what the product should do can override sound product judgment in ways that no prioritization framework is equipped to handle.

I’ve navigated this in a few ways that have worked across different organizations. First, always connect your product recommendations to the mission, not to best practices. “This is how successful SaaS companies do it” carries no weight with a stakeholder whose authority comes from theological conviction. “This is how we better serve the people we said we’d serve” connects to the thing they actually care about. Second, make the user’s experience visible to stakeholders who aren’t close to it. Bring a ministry volunteer into a leadership meeting to describe their experience. Share support tickets. Show the gap between what the stakeholder imagines is happening and what’s actually happening for users. Third, find the shared interest. Every faith-tech stakeholder, regardless of how difficult their specific demands are, cares about the mission succeeding. Finding the product path that serves the mission is always more durable than winning an argument about features.

The failure mode I see most often is treating these stakeholders as obstacles rather than as people with genuine investment in the same mission you’re trying to serve. That framing creates adversarial dynamics that poison the organization’s ability to make good product decisions for years. Read more on navigating the politics in The Stakeholder Management Mistake Product Leaders Make in Year One.

Part 4: Discovery With Users Who Are Invested in the Mission

Product discovery in faith-tech has a dynamic that makes standard user research techniques less reliable: your users often have strong feelings about what the product should do that are shaped by their faith convictions rather than their actual experience with it. A ministry volunteer might tell you the app is great because they love what it stands for, even when their actual behavior shows they’re working around its limitations. A pastor might advocate strongly for a feature because they believe it will serve their congregation, even though similar features at other organizations have had low adoption.

The antidote is behavioral evidence over stated preferences. What do users actually do with the product, as distinct from what they say they want? Where do they abandon workflows? Where do they use workarounds? Where does support ticket volume spike? The gap between stated preferences and actual behavior is wider in faith-tech than in most product contexts, because users are more motivated to tell you what they think you want to hear. Read more on using behavioral data in What Retention Data Actually Tells You (And What It Doesn’t) and Support Data Isn’t Just Feedback — It’s Your AI Strategy’s Fuel.

Continuous discovery — the practice of maintaining a regular cadence of user conversations rather than doing periodic research projects — is more valuable in faith-tech than in most product environments precisely because the stated preference / actual behavior gap is so wide. When you’re in regular conversation with users, you build enough context to hear past what they’re telling you to what’s actually going on. More on running discovery at scale in Continuous Discovery: How Product Teams Stay Connected to Users at Scale.

Part 5: Product Strategy in a Mission-Driven Organization

Product strategy in faith-tech has to answer a question that secular product strategy doesn’t face: what happens when the strategically optimal move for the business is in tension with the mission? Freemium conversion optimization, for example, often leads to designs that exploit urgency and create artificial friction — tactics that work on rational feature-seekers but erode trust with users who brought their spiritual lives to your product. Growth-at-all-costs playbooks that work in secular SaaS can hollow out a faith-tech product’s relationship with its community in ways that show up years later in catastrophic churn.

The product strategy discipline I’ve found most durable in faith-tech is what I call mission-constrained optimization. You pursue growth, revenue, and product quality aggressively — but with explicit constraints derived from the founding mission that cannot be violated regardless of the business case. These constraints aren’t vague values statements. They’re specific, testable decisions: we will never gate this feature because it’s essential to the core user job; we will never use this engagement pattern because it exploits a vulnerability in our users; we will never serve this market segment because it would require us to abandon the users we were built for.

The process of defining and maintaining those constraints is exactly what governance is for. Read more in Mission-Aligned Governance: How Faith-Tech Products Stay True to Purpose Under Growth Pressure.

Part 6: Building and Retaining a Product Team in a Mission-Driven Organization

Faith-tech organizations attract people who care about the mission — and those people will stay through compensation disadvantages, resource constraints, and organizational frustrations that would drive someone out of a secular company, as long as they believe the mission is real and the leadership is credible. But they leave quickly when the product diverges from the mission, when the leadership loses their trust, or when they feel their professional development is being sacrificed for the mission’s sake.

Building a strong product team in faith-tech means being honest about the tradeoffs. Compensation will likely be below market in some areas — acknowledge it and compensate with flexibility, mission clarity, and genuine investment in professional growth. The product work is genuinely interesting and meaningful — make sure the team feels that, and that you’re not so focused on the mission that you forget to create the kind of challenging, growth-oriented work that keeps good product people engaged.

The talent risk in faith-tech is real. The best product managers have options, and the ones who come to faith-tech for the mission will leave if the execution doesn’t match the story. Investing in team development, creating space for professional growth, and maintaining the kind of product discipline that makes the work challenging and rewarding are not luxuries in this context — they’re retention strategies. Read more on team dynamics in Agency Isn’t Enough: Why Constraint Drives Better AI Product Teams.

Part 7: The Product Leadership Mindset for the Long Game

Faith-tech products that serve their communities well over decades have something in common: product leadership that plays the long game. They resist the temptation to optimize for short-term metrics at the expense of user trust. They invest in the infrastructure — technical, organizational, and governance — that makes compounding returns possible. And they hold the mission with enough clarity and commitment that growth doesn’t hollow it out.

The long game in faith-tech product leadership isn’t about being slow or cautious. It’s about being deliberate. Making decisions that are reversible when you’re uncertain, and irreversible only when you have strong conviction. Building the user relationships that create the trust that makes future innovation possible. Maintaining the organizational health that allows the team to do its best work over years, not just quarters.

The product leaders who struggle in faith-tech are usually the ones who bring a mindset calibrated for a different context — where speed is the primary virtue, where users are data points rather than community members, and where the mission is marketing copy rather than an actual operational constraint. Recalibrating to the faith-tech context isn’t a diminishment of product ambition. It’s a recognition that the product leadership discipline that serves this environment well is genuinely different, and genuinely harder, than what most training prepares you for.

Your Turn: Apply This Today

Wherever you are in your faith-tech product leadership journey, use this checklist to identify your most important next move.

  • Audit your stakeholder map. List the five people whose buy-in most affects your ability to make good product decisions. For each one, write down whether your relationship gives you enough credibility to push back when needed — and what it would take to get there.
  • Review your inherited roadmap items. For every item on your current roadmap that you didn’t put there, write one sentence explaining why it’s there and whether it still belongs. The items you can’t explain are your highest-risk liabilities.
  • Schedule five user conversations this month. Not surveys — actual 30-minute conversations with real users about their experience. Listen for the gap between what they say they want and what their actual behavior shows.
  • Name your mission constraints. Write three specific product decisions you would never make regardless of the business case. If you can’t name three, you don’t have mission constraints — you have mission sentiment, which won’t hold under growth pressure.
  • Assess your team’s development trajectory. For each person on your product team, write one sentence about their most important growth area and what you’re doing to support it. If you can’t write it, you’re under-investing in the people who make your product possible.
  • Read the supporting posts. Each section of this guide links to a deeper dive. Pick the one that addresses your most pressing current challenge and start there — then come back for the rest.

Faith-tech product leadership is one of the most demanding and most rewarding contexts in the field. The users bring more of themselves to your product than they bring to most software. The mission creates both the constraints and the motivation that make the work meaningful. And the organizations that get it right — that build products their communities genuinely trust and depend on — do something that secular product development rarely achieves: they make a lasting difference in people’s lives.

I work with product leaders navigating exactly this. If you’re wrestling with any of the challenges in this guide, let’s talk.

Posted on

Mission-Aligned Governance: How Faith-Tech Products Stay True to Purpose Under Growth Pressure

Three years into building a curriculum platform for children’s ministry volunteers, our team started optimizing for the wrong user. We had a funding conversation that went well — a potential partner liked our growth numbers — and within two sprints, we were building features designed for their use case, not ours. Nobody made a single obviously bad decision. We just kept saying yes to the next reasonable thing until we looked up and realized we were serving a different person than the one we’d started with. The volunteers who needed seven minutes of prep help were still there. We had just quietly stopped building for them.

That’s governance drift, and in my experience it’s the most common way faith-tech products lose their way. It doesn’t look like failure. It looks like growth, momentum, smart pivots. But every mission-driven product I’ve watched become something its community no longer recognizes got there through exactly this pattern — one reasonable decision at a time, until the drift had compounded into something irreversible.

The hard part is that the usual metrics don’t catch it. Revenue goes up. User counts grow. Engagement stays healthy. The dashboard says everything is working. What the dashboard doesn’t measure is whether you’re still serving the person you said you’d serve.

Why Faith-Tech Products Drift

Drift happens because growth pressure is constant and mission clarity is not. Funding conversations, partnership opportunities, feature requests from high-value accounts, competitive pressure to add capabilities — all of these are real, and they all push in a direction that has nothing to do with your founding promise. In a product without explicit governance, the loudest voice in the room wins. Usually that voice belongs to whoever controls the budget, not whoever knows your users best.

In faith-tech, this tension has a particular shape. The mission is relational — it’s about the person sitting in the small group, the volunteer prepping a lesson, the parent trying to disciple their kids, the beginner searching for something true at 2am. Growth pressure is structural — it’s about revenue, retention metrics, and partnership viability. Both are real. But without governance structures that make the mission visible in every decision, the structural pressure wins by default. Not because anyone chose it. Because structure always beats intention without a system to back the intention up.

What Governance Actually Looks Like in Practice

The most effective governance structure I’ve used is a founding promise document — a single sentence, reviewed in every sprint and roadmap session, that names who the product serves and what specific outcome it delivers for them. Not the mission statement from the website. A functional, honest sentence that the team can hold a decision up against.

On the curriculum platform, ours was: “A harried volunteer with seven minutes to prep a lesson feels ready, not overwhelmed.” That sentence had to survive every feature conversation. If a proposed feature didn’t make that volunteer feel more ready, we had to explain why we were building it. The explanation wasn’t always bad — sometimes there were legitimate strategic reasons. But naming it made the drift visible. You can’t fix what you can’t see.

The other piece that matters is assigning explicit accountability. I call it a mission advocate — one person on the team whose role is to ask the hard question in every review: “Does this serve the person we said we’d serve?” Not a personality trait, not an informal vibe. A named role with permission to pause a conversation. It has to survive team changes, which means it can’t live in one person’s character. It has to be structural.

Mission Metrics: What Gets Measured Gets Protected

Governance drift accelerates when the only metrics on the dashboard are revenue, users, and engagement. Those metrics matter — but they measure market traction, not mission fidelity. A product can hit every growth target while systematically abandoning the users it was built for. I’ve seen it happen.

Mission metrics are different. They measure whether the product is doing what it promised for the people it promised it to. On a discipleship platform, that might be depth of engagement — not time-in-app, but whether users are completing content rather than passively consuming it. On a volunteer training tool, it might be confidence scores or preparation completion rates. On a pastoral care platform, it might be follow-through — whether interactions led to a real next step with a real person.

You can’t automate this at the start. But you can track it manually, talk about it in reviews, and make it visible enough that it shapes decisions. What gets measured gets protected. What goes unmeasured drifts.

Your Turn: Apply This Today

Use this checklist to build governance structures that keep your mission visible at every stage of growth.

  • Write your founding promise in one sentence. Name who you serve and what specific outcome you deliver for them — functional and honest, not aspirational. If you can’t write it, that’s the first governance problem to solve.
  • Review your last three roadmap decisions against that promise. For each one, ask honestly: did this serve the user we said we’d serve? If not, name what actually drove it — and whether you’d make the same call with the promise in front of you.
  • Pick one mission metric and start tracking it this week. Manual is fine. It just has to measure mission fidelity — whether the product is doing the thing for the person it was built for — not market traction.
  • Assign a mission advocate on your team. Give one person explicit permission to ask the hard question in every sprint or roadmap review. Make it a role so it survives team changes and doesn’t depend on one person’s willingness to be the difficult voice in the room.
  • Draft a one-page non-negotiables document. List three to five decisions your product would never make regardless of the business case. Circulate it for team feedback. The conversation it starts is as valuable as the document.
  • Block a quarterly governance review now. One hour every quarter to evaluate whether recent decisions have drifted from your core promise. The goal isn’t to relitigate decisions — it’s to recalibrate before the drift compounds into something you can’t reverse.

For more on protecting mission under growth pressure, read Why Freemium Breaks for Faith-Tech Products—and How to Fix It and Three Guardrails Every Product Leader Needs Before Experimenting with AI.

Mission drift is a product leadership problem, not just a values problem. I consult with faith-tech product leaders on governance structure, mission metrics, and building the team rhythms that keep purpose visible at every stage of growth. Let’s talk.

Posted on

AI Learning for Ministry Leaders: Cut the Noise and Start Saving Real Time

I spent weeks “learning AI” before I realized I just needed it to save me an hour a day. The tutorials felt important. The newsletters felt urgent. The demos were impressive. And none of it translated into actual time back in my week until I stopped trying to master the technology and started asking a simpler question: what is the most annoying, time-consuming, low-creativity task I do every week, and can AI help with that?

For ministry leaders especially — pastors, executive pastors, church operations leaders, faith-tech practitioners — time is not a productivity problem. It’s a stewardship problem. Every hour spent on administrative friction is an hour not spent with people. That’s the actual cost. And AI, when applied to the right tasks, can genuinely give some of that time back.

The AI Learning Trap Ministry Leaders Fall Into

The trap is treating AI as a mountain to climb. Every week there’s a new model, a new tool, a new capability that someone in your network is raving about. The implicit message is that you need to keep up — that there’s a level of AI fluency you’re supposed to reach before you can start using any of it effectively.

That message is wrong. You don’t need to understand how large language models work to use them well, any more than you need to understand combustion engineering to drive to a hospital visit. The relevant question isn’t “how does this work?” It’s “what specific task in my actual week could this improve?” And for most ministry leaders, that question is answerable in about twenty minutes of honest reflection.

The people who get value from AI fastest are not the ones who studied it the most. They’re the ones who identified one specific problem, tried one specific tool against it, and measured whether it helped. That’s it. The sophistication comes later, if it comes at all. The value comes from the first application, not from the curriculum.

Where Ministry Leaders Actually Get Time Back

Based on what I’ve seen across faith-tech organizations and ministry teams, there are a handful of tasks where AI consistently delivers meaningful time savings with minimal learning investment:

First drafts of routine communications. Weekly announcements, bulletin copy, email updates to congregation segments, social media copy for events — these are high-volume, low-creativity tasks that most ministry staff spend disproportionate time on. AI handles first drafts well. You still supply the voice, the pastoral context, and the final judgment. You just don’t spend forty-five minutes starting from a blank page.

Meeting notes and action item extraction. Recording a staff meeting and running the transcript through a summarization tool produces a workable set of notes and action items in minutes. The output isn’t perfect, but it’s a starting point that saves twenty to thirty minutes of post-meeting documentation per meeting.

Research synthesis. Sermon background research, background on pastoral care topics, summaries of longer documents — AI handles the aggregation and synthesis of information well. You still do the discernment. You just don’t do the initial reading and note-taking.

The common thread: these are all tasks where the bottleneck is the blank page or the initial aggregation, not the judgment. AI removes the blank page. You provide the judgment. That division is the practical model for AI-assisted ministry work.

The Discernment That AI Doesn’t Have

None of this replaces the things that actually matter in ministry. AI can draft a pastoral care email. It doesn’t know the specific grief that person is carrying or the relationship history that informs how you should communicate with them. AI can generate sermon outlines. It doesn’t know the heartbeat of your congregation this week or the spiritual weight of what they need to hear.

This isn’t a limitation to apologize for — it’s a useful boundary. The things AI doesn’t do well in ministry contexts are exactly the things that are most worth protecting your time for. If AI gets you an hour back on administrative tasks, that’s an hour you can spend on the irreplaceable work. That’s not a compromise. That’s the point.

Your Turn: Apply This Today

You don’t need a curriculum. You need a starting point. Here’s how to get real time back from AI this week:

  • List the three most time-consuming low-creativity tasks in your average week. Not the important work — the administrative, repetitive, blank-page work. These are your first AI candidates. Pick the most annoying one and spend thirty minutes trying an AI tool against it before you do anything else.
  • Try one AI tool on one real task this week — not a demo, a real task. Draft this week’s bulletin copy. Summarize this week’s meeting notes. Write the first version of the email you’ve been putting off. Use the output as a starting point, not a final product. Measure whether it saved time.
  • Stop trying to keep up. Unsubscribe from one AI newsletter this week. The marginal learning value of staying current with every new tool release is lower than the value of applying one tool well. You can’t keep up, and you don’t need to. Focus beats breadth.
  • Define your boundary explicitly. Write one sentence: “I use AI for [specific tasks]. I do not use AI for [specific decisions or interactions].” Having a written boundary prevents both the trap of using AI for everything and the trap of never using it at all.
  • Measure the time savings after two weeks. Not impressionistically — actually track it. If you’re using AI to draft communications, time how long the drafting takes versus before. If the savings are real, that’s evidence worth sharing with your team. If they’re not, adjust the application.
  • Share one practical AI win with a colleague in ministry. Not a pitch for AI adoption — just one honest story: “I used this tool for this task and it saved me this much time.” Peer-to-peer practical examples spread faster than any training program and produce more genuine adoption.

For a product-leadership perspective on the same challenge, AI Learning for Product Leaders: Stop Chasing Tools, Start Solving Problems covers the same principle for PM teams. And Agency Over Automation: Why AI Won’t Replace the Leaders Who Know How to Use It addresses where human judgment stays essential as AI handles more of the work.

Working through how to build practical AI habits into your ministry team or faith-tech organization without drowning in hype? I consult with ministry leaders and faith-tech practitioners on exactly this — cutting through the noise to find the applications that actually serve the mission. Let’s talk.

Posted on

Why Agency Trumps Skills for AI-Driven Church Tech Teams

Last month, I sat in a church basement with a tech volunteer who was struggling to set up a new AI tool for sermon transcription. His frustration wasn’t about the tool’s complexity — he knew the buttons to push. The problem was that nobody had told him why it mattered or given him any ownership over how it would be used. He muttered: “I just don’t get what this is for.”

That moment stuck with me. It wasn’t a skills gap. It was a purpose gap. And it’s the same pattern I’ve seen in product organizations far beyond church tech — teams that have been trained on the tools but not given genuine ownership over the outcomes those tools are supposed to produce.

Skills Without Agency Is Compliance, Not Capability

Here’s the thing about AI adoption in any team: skills are necessary but not sufficient. You can run workshops, build sandboxes, write documentation, and mandate usage — and still end up with a team that uses the tools only when required and abandons them the moment the pressure is off. What’s missing in those cases almost always isn’t knowledge. It’s agency.

Agency, in this context, means something specific: the sense of ownership over a problem, the authority to make decisions about how to address it, and the belief that those decisions will actually matter. Viktor Frankl’s work on meaning is useful here — he argued that humans don’t just need purpose handed to them; they need to discover it through engaged work. Teams that are handed AI tools without being given genuine problems to solve with those tools will never fully adopt them. They’ll comply, but they won’t own.

Ownership is what turns “I have to use this” into “I want to improve this.” And that distinction matters enormously for AI adoption velocity. Teams with high agency figure out use cases their managers never anticipated. Teams with low agency wait to be told what to do next.

Why Church Tech Teams Are a Clear Case Study

Faith-tech and church tech teams are a useful lens for this pattern because the stakes are highly visible and the volunteer culture makes authority structures explicit. When a volunteer doesn’t feel ownership, they leave. There’s no salary to keep them compliant. That makes the agency gap show up faster and more clearly than it does in corporate product organizations where people absorb the dysfunction because they’re getting paid to.

I’ve seen this play out repeatedly: a church tech leader implements an AI scheduling tool, trains the volunteers, and then watches usage drop to near zero within six weeks. Post-mortem almost always reveals the same thing — the volunteers were trained on the tool but not given any say in what problem it was solving or how success would be measured. They had skills. They had no stake.

The fix is deliberate but not complicated. When you introduce a new AI capability, don’t start with training. Start with a problem-ownership conversation: “Here’s the friction we’re experiencing. Here’s the outcome we’re trying to improve. I want you to figure out how this tool can address it — and I’m giving you the authority to make that call.” That framing changes everything about how the team engages with the technology.

Building Agency Into Your AI Adoption Process

The practical implication is that AI training needs to be sequenced differently than most organizations run it. The standard sequence is: introduce tool → train team → deploy. The agency-first sequence is: define problem → assign ownership → provide tool → let team define deployment. Those sequences produce dramatically different outcomes.

Small wins matter disproportionately in the early stages. When a volunteer or team member can point to a specific outcome they produced — “I set up the transcription workflow and it cut our follow-up time by an hour every week” — they develop a sense of stewardship over that outcome. They start to see themselves not as a user of the tool but as an owner of the process. That’s the transition that sustains AI adoption long after the initial training energy fades.

Your Turn: Apply This Today

Whether you lead a church tech team, a small product group, or a cross-functional product organization, here’s how to build agency into your AI adoption — starting this week:

  • Identify one AI tool your team is underusing. Don’t ask why they’re not using it — ask whether they feel ownership over the problem it’s supposed to solve. If the answer is no, that’s your starting point.
  • Pick one team member and assign genuine problem ownership. Not “use this tool” — “this friction point is yours to improve. This tool is available. Tell me in two weeks what you tried and what you learned.” The authority has to be real, not nominal.
  • Define success in outcome terms, not usage terms. “Reduce admin time by 30% for small group leaders” is a real goal. “Everyone uses the tool by Friday” is compliance theater. Outcome-focused goals give people something worth owning.
  • Celebrate a small win explicitly and tie it to purpose. When someone on the team produces a measurable improvement, name it publicly and connect it to the mission. “This saved the pastoral team four hours last week — that’s four hours they spent with people instead of on admin.” That framing builds the sense of stewardship that sustains adoption.
  • Block 15 minutes this week to audit your own behavior as a leader. Are you delegating ownership or just delegating tasks? Ownership comes with authority to make decisions. If you’re telling people what to do with the tool rather than telling them what problem to solve with it, you’re creating compliance — not capability.
  • Model agency yourself. Take one AI tool you’ve been handed or had recommended to you, identify a specific problem in your own workflow, and document what you tried and what you learned. Share that process with your team. Nothing builds a culture of agency faster than watching the leader practice it.

Agency in AI adoption connects directly to how you build and retain high-performing teams. The Stakeholder Management Mistake Most Product Leaders Make in Year One covers the related dynamic of alignment versus compliance in organizational settings. And AI Learning for Product Leaders: Stop Chasing Tools, Start Solving Problems addresses the same principle applied to learning investment.

Trying to build genuine AI capability — not just AI compliance — in your team or organization? I consult with product leaders and ministry innovators on building agency, aligning teams around mission-driven outcomes, and making AI adoption actually stick. Let’s talk.

Posted on

How AI Prototyping Can Break Silos in Faith-Tech Products

A year ago, I was in a conference room with a faith-tech startup team watching a product manager and a designer talk past each other. The PM wanted data before committing to any direction. The designer wanted to build something the team could react to. Neither was wrong — but they were stuck, and the feature stalled for weeks because nobody said the obvious thing: “Let’s build a quick prototype and test it.”

That moment crystallized something I’d been seeing across product organizations: silos don’t break down through better meetings. They break down through shared artifacts. When a team can look at the same rough prototype together, the conversation shifts from “whose perspective is right” to “what does this teach us.” AI prototyping tools have made that shift dramatically cheaper and faster — which means the teams that aren’t using them are paying an avoidable coordination tax.

What AI Prototyping Actually Does for a Team

The most valuable thing an AI prototyping tool does is collapse the time between idea and artifact. What used to take a designer a week to wireframe can now take a few hours using tools like Galileo, Uizard, or even well-structured prompting in Figma’s AI features. That speed matters less for the prototype itself and more for what the prototype enables: a shared object the whole team — product, design, engineering, stakeholders — can react to together.

Teresa Torres’ continuous discovery framework makes the argument clearly: prototypes aren’t about showing off ideas. They’re about learning. The faster you can get something in front of a real user — even a rough, unpolished version — the faster you discover whether your assumptions are right. AI prototyping compresses that loop significantly.

In faith-tech contexts specifically, where teams are often small and stakeholders can include everyone from engineering leads to ministry directors, this matters. A prototype that a non-technical stakeholder can react to is worth more than a PRD that only product and engineering understand. It gets everyone speaking the same language before anyone writes a line of code.

The Silo Problem AI Prototyping Actually Solves

Product silos usually persist for one of two reasons: different teams operate from different information, or different teams have different incentives. AI prototyping directly addresses the first. When the same working mockup is in front of a PM, a designer, an engineer, and a ministry stakeholder simultaneously, you rapidly surface where each person’s mental model diverges. That divergence, made visible, is far cheaper to resolve before development than after.

I’ve watched this play out in prayer app development, church management software, and discipleship platforms. In each case, the friction wasn’t disagreement about the product’s mission — it was that nobody had made their assumptions concrete enough for others to react to. A rough AI-generated wireframe of a specific user flow did in one session what three roadmap reviews had failed to do: it gave everyone the same starting point.

The discipline that matters here: keep the prototype simple and provisional. The temptation with good prototyping tools is to overinvest in polish before you’ve learned anything. A polished prototype signals “we’ve decided” when the point is “we’re still figuring this out.” Users interact differently with rough prototypes — they’re more honest, and more willing to suggest changes when the artifact looks unfinished.

Building a Prototyping Habit, Not Just a Prototyping Moment

The real leverage isn’t a single prototyping sprint — it’s making rapid, collaborative prototyping a standard step in every major feature decision. Teams that prototype as a habit stop having the same alignment conversations over and over, because they’ve built a shared practice of making assumptions concrete before debating them.

For faith-tech teams in particular, I’d suggest the following sequencing: before any feature goes on the roadmap, someone on the team produces a one-screen wireframe answering the question “what does success look like for the user here?” That wireframe — rough, provisional, built in an hour — becomes the discussion artifact for the roadmap conversation. It doesn’t answer all the questions. It just makes sure everyone is answering the same questions.

Your Turn: Apply This Today

Whether your team has a formal prototyping practice or none at all, here’s how to start building the habit — starting this week:

  • Identify the next feature your team will debate in roadmap planning. Before the meeting, have one person spend 60 minutes building a rough wireframe using an AI prototyping tool. Bring the wireframe to the meeting instead of a written spec. Watch how the conversation changes.
  • Run a 90-minute silo-breaker session. Put product, design, and at least one engineering rep in a room. Give them a specific user problem, a prototyping tool, and a timer. The output should be a rough, functional prototype — not a polished one. Speed over polish is the rule.
  • Get it in front of three to five real users within 48 hours. Pastors, volunteers, small group leaders — whoever your actual end user is. Your goal is one concrete thing you learned that you didn’t expect. If you can’t identify one, the prototype wasn’t specific enough.
  • Run a 30-minute team debrief after user feedback. What did you learn? What did you assume that turned out to be wrong? What’s the next iteration? Write down three specific things the feedback changed about your direction.
  • Make it a gate, not an option. Decide as a team that any feature above a certain size threshold requires a rough prototype before it can be added to the roadmap. This isn’t about slowing down — it’s about ensuring you’re making decisions from the same picture.
  • Celebrate what the prototype taught you, not just what you shipped. Prototypes that prevent bad features from being built are wins, even if nothing ships. Make sure your team understands that learning is the output — not just working software.

Team alignment and discovery go hand in hand. Opportunity Solution Trees Meet AI Reality at Scale covers how to adapt discovery frameworks when you’re building AI-powered features, and Why Teresa Torres’ Continuous Discovery Cadence Is Breaking Down in the AI Age addresses the structural changes that AI creates for discovery-driven teams.

Struggling with cross-functional alignment or trying to build a more disciplined discovery practice in your faith-tech or product organization? I consult with product leaders on prototyping cadences, team alignment, and the practices that close the gap between roadmap and user reality. Let’s talk.

Posted on

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

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

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

Why the Standard PLG Playbook Doesn’t Transfer

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

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

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

What Trust Means in Ministry Contexts

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

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

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

The Metrics That Actually Matter

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

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

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

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

What Faith Tech Growth Actually Looks Like

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

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

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

Your Turn: Apply This Today

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

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

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

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

Posted on

What Children’s Ministry Taught Me About Product Simplicity

Last year I watched a volunteer children’s ministry director attempt to run Sunday school prep on her phone while her toddler climbed on the kitchen counter. She had exactly seven minutes between finishing breakfast and loading the car. The curriculum platform she was using required three separate logins, two PDF downloads, and a supply list that assumed access to a craft store and a laminator.

She gave up and winged it with goldfish crackers and a Bible story from memory.

That moment taught me more about product simplicity than any design framework I’ve read. When your user is a part-time volunteer with no training budget, no tech support, and seven minutes to prepare — you learn fast what “simple enough” actually means.

I’ve carried those lessons into every product role since. Here are four that I apply constantly.

Design for the Five-Minute User, Not the Power User

Every product has a “five-minute user” somewhere in the workflow — the person who needs to accomplish a core task under conditions of time pressure, cognitive load, and limited context. They’re not the user who fills out your feedback surveys or attends your user interviews. They’re the ones who quietly abandon your product and find a workaround when it gets in their way.

For Sermons4Kids, that user was the Sunday morning volunteer in the parking lot at 8:55am. For enterprise products, it’s the admin configuring your tool during their lunch break because IT is overloaded. For B2C products, it’s the user trying to accomplish something during the three-minute window between meetings.

Most product teams design for the engaged, patient, curious user who will explore the product to find what they need. The five-minute user has none of those qualities in the moment that matters. They need the most important task to be one tap away with no ambiguity about where that tap is.

The diagnostic question: If someone with no training and no time needed to complete the single most important task in your product, could they find it in under 30 seconds? If not, that’s your simplicity problem.

Remove the Decision Tree, Not the Content

We rebuilt the Sermons4Kids homepage after session data showed that a significant percentage of users were abandoning at the content selection step. We had years of excellent curriculum. We had a well-organized library. We had filters and categories and search. Users still gave up.

The fix wasn’t removing content — it was removing the decision the user had to make. Now the homepage shows exactly four options: This Sunday’s Lesson, Last Week (for catch-up), Next Week (for advance planners), and Search. That’s it. Every other organizational structure lives behind Search for motivated users, but it doesn’t block the path for the Sunday morning volunteer who just needs this week’s materials.

Session completion rates improved immediately. The content didn’t change. The decisions the user had to make did.

Every product has a version of this problem: an information architecture that’s logical and comprehensive but requires users to make a series of decisions before they can do the thing they came to do. The solution is almost never more content or better organization — it’s opinionated defaults that route the majority of users directly to what they need, with the full flexibility available one level deeper for the users who want it. This connects directly to what Barry Schwartz documented: more choices create paralysis, not empowerment.

Question the Digital-First Default

This one surprised me. In a world of responsive design and mobile-first product development, the most valuable feature we built for Sermons4Kids was making everything print-perfectly every time.

Children’s ministry happens in physical spaces with physical kids. Volunteers need something they can hold, write on, and hand out. They need a backup when the WiFi fails. We spent months optimizing mobile responsiveness before realizing that “mobile optimization” for this use case meant “fits on one page when printed from a phone.” Not responsive design — print design.

The broader lesson: digital-first is a design assumption, not a universal user truth. The right question is “what format serves this user in their actual context?” — not “how do we deliver this digitally?” I’ve seen the same pattern in analytics tools where print-ready dashboards increased executive adoption more than better mobile interfaces, and in consumer apps where PDF export drove more engagement than in-app features for users whose workflows involved physical handoffs.

The Onboarding Moment Is Earlier Than You Think

For volunteer users, we discovered that the meaningful onboarding moment wasn’t first login — it was the first successful Sunday. The first time a volunteer used our curriculum and it worked in the classroom, with real kids, under real conditions, was when they became retained users. Everything before that was trial, not adoption.

This shifted how we thought about activation. The question wasn’t “did they complete setup?” — it was “did they succeed at the thing they came to do?” And the second question had very different design implications than the first. It meant making the path from signup to first successful use as short and obstacle-free as possible, even at the cost of features and configuration options that would be valuable later.

Most products define activation as completion of a setup flow. The better definition is completion of the first meaningful value exchange: the user did the thing they came to do, and it worked. Building backward from that moment tends to reveal a lot of unnecessary friction in the path to get there.

These principles show up everywhere once you’ve internalized them — in enterprise software, consumer apps, and AI products. The choice overload problem in AI features is fundamentally the same problem as the children’s curriculum homepage: unlimited options create abandonment. The design principle that solved it for Sunday school volunteers is the same one that solves it at scale.

Your Turn: Apply This Today

Take these directly into your next product review, sprint planning, or roadmap conversation:

  • Map the constraint first. Identify your most time-pressured user segment. What is their real-world window to complete the core task? Design to that number — not to your average session length.
  • Count steps to first value. Walk through your onboarding or core workflow and count every tap, click, decision, and login required before the user gets something useful. If it’s more than five, cut.
  • Remove one option this sprint. Find a feature or navigation choice that fewer than 10% of users engage with. Archive it. Measure whether anyone notices.
  • Rewrite one tooltip as a verb. Anywhere you explain what something is, rewrite it as what the user should do next. “Lesson plans” becomes “Start this week’s lesson.”
  • Test with your least technical user. Give the product to the person in your target audience least comfortable with technology. Watch without coaching. The first pause is your biggest design problem.
  • Apply the seven-minute rule. Before shipping any new feature, ask: can a distracted, under-resourced user get real value from this in under seven minutes? If not, simplify before you ship.

These principles also show up when you’re new to an organization: the first 100 days of a product leadership role require the same “design for the five-minute user” discipline applied to your own stakeholders — getting to value quickly, removing unnecessary process friction, making the path to trust short.

Building products for time-constrained, mission-driven users and fighting complexity at every stage? I consult with product teams on simplicity-first design, activation optimization, and building for users whose real-world context is nothing like your test environment. Let’s talk.

Posted on

Why Product Decisions Are Never Just Product Decisions

A few months ago, I sat in a product meeting where the team was debating whether to auto-generate personalized devotionals using AI. The product argument was compelling: large user base, clear demand signal, AI capability that could theoretically produce unlimited variations. Fast follow-up, easy A/B test, obvious engagement metric to optimize.

Then someone asked: “Should we?”

That question stopped the room. Not because it was unusual for a product team to ask whether they should build something — that’s good practice in any domain. But because everyone in the room understood that this decision was carrying weight that a standard feature evaluation framework wasn’t designed to handle.

Product decisions always carry more weight than our frameworks acknowledge. We just don’t usually name it.

Why Product Decisions Are Never Just Product Decisions

The standard product evaluation framework — desirability, feasibility, viability — asks whether users want it, whether we can build it, and whether it’s sustainable as a business. Those are necessary questions. They’re not sufficient ones.

Every product decision reflects a set of beliefs about what matters, what humans need, and what technology should and shouldn’t do. Most of the time those beliefs are implicit — held but unexamined. In consumer tech, that implicit belief system usually defaults to “engagement is good, more is better, friction is the enemy.”

That works fine for some products. It’s actively harmful for others.

When you’re building products at the intersection of technology and things people care deeply about — health, relationships, learning, meaning, faith — the implicit framework fails. The question isn’t whether your belief system shapes your product decisions. It does, whether you name it or not. The question is whether you’re examining it deliberately enough to build well.

The Three Product Tensions That Require More Than Standard Frameworks

Engagement vs. Depth: Engagement metrics optimize for return frequency and session length. But for products where the goal is genuine change — learning something, growing in a practice, developing a skill — those metrics can be proxies for the wrong thing. A user who comes back every day for two-minute interactions might be getting less value than one who comes weekly for a focused 30-minute session. If your success metrics are optimized for the former, you’ll build toward it even when the latter is actually better for users.

This is the same tension the best education product designers grapple with: it’s easier to measure engagement than learning, so teams end up optimizing for engagement and calling it a proxy for learning. Sometimes it is. Often it isn’t.

Automation vs. Agency: AI makes it technically possible to automate almost any information-delivery task. The product question is when automation serves users and when it substitutes for something they’d be better off doing themselves. A navigation app that gives you turn-by-turn directions is useful. One that removes your ability to navigate independently over time might not be, even if users prefer it in the short term.

The best product teams I’ve worked with ask not just “can AI do this?” but “what does the user lose if AI does this for them, and is that a trade-off worth making?” The answer isn’t always no — sometimes automation genuinely removes unnecessary friction. But the question should be asked explicitly.

Community vs. Isolation: Features that substitute for human connection — even when users prefer them — can create long-term harm that’s hard to trace back to any single product decision. Social platforms have learned this expensively. The insight was available earlier to anyone willing to ask whether the feature was facilitating human connection or replacing it.

A Framework for the Decisions Standard Frameworks Don’t Reach

When I’m evaluating product decisions in domains where the stakes are higher than a standard desirability/feasibility/viability analysis captures, I add three questions:

Does this build or diminish user capability over time? Not just “does the user like it?” but “is the user better off — more capable, more knowledgeable, more connected — as a result of using this feature?” This is the difference between tools that augment and features that create dependency.

What is this feature implicitly telling users about what matters? Products shape behavior, and behavior shapes belief. A news app that surfaces outrage-inducing content because it drives engagement isn’t neutral about what news is for. A social platform that optimizes follower count shapes users’ implicit model of what community means. Name the implicit message your feature is sending.

Who benefits when the user keeps using this, and does that align with what’s actually good for the user? Business model alignment matters here. Products funded by engagement advertising have structural incentives to maximize usage. Products funded by outcomes their users care about have structural incentives to deliver those outcomes. The incentive structure doesn’t determine the product, but it shapes the gravity you’re working against or with.

What This Looks Like in Practice

Back to the AI-generated devotionals debate. We ended up not building the feature — at least not the way originally proposed. The concern wasn’t technical. It was that the version we could build would likely optimize for content volume and engagement breadth rather than depth and reflection. We couldn’t measure “did this change how someone thinks about their faith?” but we could measure open rates and return visits. And we knew which one we’d end up optimizing for.

Instead we built structured study guides — AI-assisted, but designed around questions that required the user to do intellectual work rather than consume content passively. Harder to build, harder to measure, probably better for users.

This kind of decision doesn’t require faith to make. It requires a belief system — a set of convictions about what the product is actually for and what good outcomes look like that goes beyond usage metrics. Every team has one, implicitly. The teams that build things worth building usually have one explicitly.

This also reshapes how you use discovery frameworks. When you’re clear about what the product is for, opportunity solution trees become more useful — because you’re not just asking “what’s the most elegant solution?” but “what’s the most aligned solution we can actually build?”

If you’re building in a domain where this kind of product ethics question surfaces — health, education, relationships, meaning — it connects directly to the paywall question: what you choose to make free reflects your beliefs about what access to your product should mean. That framework applies here too.

Your Turn: Apply This Today

Product ethics isn’t a separate track — it’s built into how you make decisions. Here’s how to start integrating it:

  • Name the second-order effects of your next shipped feature. Before your next launch, run a 20-minute “impact mapping” session. Ask: who benefits from this feature? Who might be harmed, even unintentionally? What behaviors might this incentivize at scale?
  • Add “who bears the cost?” to your prioritization framework. For every item on your roadmap, ask explicitly: if this creates value for some users, who absorbs the trade-off? If the answer is always the same group, you have an equity problem in your product design.
  • Review your engagement metrics for manipulative patterns. Look at your most-used engagement features. Ask honestly: does this feature make users’ lives better, or does it just make them more active? There’s a difference. Know which one you’re optimizing.
  • Build a “values document” for your team. Define three to five explicit values that guide product decisions when the data is ambiguous. Reference them in sprint reviews. They make it harder to rationalize decisions that feel productive but cause harm.
  • Bring one ethics question to your next leadership review. Name a decision your team made in the last quarter that had an ethical dimension — and share how you reasoned through it. Normalizing the conversation is how you build organizational muscle.
  • Designate a “devil’s advocate” role in major feature reviews. Before shipping anything significant, assign one person to argue the case for the user, community, or market segment that could be negatively affected. Make it a standing agenda item.

Building products in high-stakes domains where standard frameworks don’t fully cover the decision space? I consult with organizations navigating product ethics, mission-aligned product strategy, and the gap between engagement metrics and actual user value. Let’s talk.

Posted on

Why ‘Faith Tech’ Is About to Become a Real Category

I’ve spent fifteen years building faith tech — products for pastors, missionaries, children’s ministry leaders, and everyday believers across four continents. I’ve watched this space evolve from the inside. And here’s what I see coming: “faith tech” is about to stop being a vibe and start being a category.

Venture capital is starting to notice. Conferences are forming around it. Christian tech workers are organizing. But we don’t have shared vocabulary yet. No agreed-upon market map. No anchoring fund defining the category. That’s about to change — and the catalyst is AI.

What the Faith Tech Category Actually Includes

Faith tech encompasses products and platforms that facilitate spiritual formation, religious practice, church operations, or faith-based community building. The landscape is already substantial, though fragmented.

Bible engagement: YouVersion claims over 600 million installs. These aren’t niche products — they’re among the most-used apps on the planet. Sermon preparation: SermonCentral has served pastors for over two decades. Newer entrants like SermonAI and Pulpit AI are using machine learning for research and structure. Pastors are more open to AI assistance than most people expected. Church management: Planning Center handles volunteer scheduling, online giving, and more for thousands of churches. Pushpay and Tithely process significant donation volumes. Children’s ministry: Spark & Cannon Kids, Orange, and others serve curriculum across denominational lines. Discipleship and training: RightNow Media operates as “the Netflix for churches.” ORI builds personalized learning pathways for spiritual formation.

The market fundamentals are stronger than most people realize. There are an estimated 380,000 churches in the United States alone (Hartford Institute for Religion Research). Globally, estimates suggest over 5 million congregations. Mid-size congregations are spending real budget on tools — not just megachurches.

Why AI Is the Faith Tech Category Catalyst

Every category-defining moment needs a catalyst. For faith tech, it’s AI — and it doesn’t just make existing tools better. It makes entirely new categories possible.

Personalized discipleship at scale. Instead of one-size-fits-all reading plans, we can now build adaptive pathways that adjust based on engagement patterns, life circumstances, and spiritual growth indicators. I’ve been prototyping this with my CONSILIUM system — applying the same autoresearch patterns that optimize executive workflow to spiritual formation contexts.

Intelligent content curation for pastors. Pastors spend significant time on sermon preparation. AI can surface relevant commentaries, cross-references, and cultural context without replacing the pastoral heart of the message. AI excels at research aggregation. It doesn’t replace theological interpretation — and shouldn’t try. This is exactly the strategic question every sermon prep platform is facing right now.

Multilingual ministry tools. AI translation is expanding access to spiritual resources in ways that previously required teams of translators. Theological nuance is the hard part — but the technical barrier has dropped dramatically.

Accessible economics. AI makes it economically feasible to build sophisticated tools for markets that couldn’t justify the development cost before. A 200-member church can now access technology quality that previously required megachurch budgets.

The Risk: Building Faith Tech Without Understanding Ministry

Here’s where this gets interesting — and where most attempts will fail.

The edtech industry spent billions building products for classrooms without understanding how teachers actually work. Faith tech faces the same risk. I’ve watched well-intentioned founders build “AI sermon assistants” that miss how pastors actually prepare messages. Or “church growth platforms” that optimize for metrics unrelated to spiritual health.

The pattern I keep seeing: technologists who attended church as kids assume they understand ministry operations. They often don’t. Ministry involves relationship-intensive dynamics that don’t translate easily to software frameworks. Church leadership involves theological discernment that can’t be automated. Spiritual formation happens through community, not just content consumption.

The products that succeed will be built by teams that include former pastors who understand church operations, ministry leaders who’ve lived with budget constraints and volunteer coordination, missionaries who’ve navigated cross-cultural discipleship. Technical excellence without ministry context produces elegant solutions to problems churches don’t actually have.

Why the Faith Tech Category Is Forming Right Now

Three trends are converging:

Post-pandemic digital adoption. COVID forced every church to become a technology organization overnight. Pastors who had never used video conferencing suddenly became experts in livestreaming, online giving, and digital discipleship. That technological fluency is persistent — churches aren’t going back.

Generational leadership transition. Millennials and Gen Z are moving into senior ministry roles. They expect technology to work seamlessly and are willing to pay for tools that save time and improve outcomes.

AI accessibility. Large language models have dropped the technical barrier for building intelligent applications dramatically. A solo developer can now build AI-powered ministry tools that would have required a full engineering team previously.

We Need More Product People From Ministry

The faith tech category will get built. The question is whether it gets built by people who understand ministry or by people who see churches as an underserved market opportunity.

We need more product managers, designers, and engineers who’ve served in ministry roles building for the church they know. Not just people who attended church growing up — people who’ve planned worship services, coordinated volunteers, prepared sermons, led small groups, and navigated denominational politics.

The best faith tech products come from founders who’ve experienced the problems they’re solving. In faith tech, that principle isn’t just good advice — it’s the difference between a product that gets used and one that collects digital dust on the church server.

The category is forming. The market is substantial. The technology is ready. The question is who will build it — and whether they’ll understand why they’re building it.

Your Turn: Apply This Today

If you’re building in or adjacent to faith tech — or advising someone who is — here’s where to focus your thinking:

  • Define your market with precision. “Faith tech” is not a market — it’s a category. Identify your specific segment: churches, individual believers, clergy, faith-based nonprofits, publishers? The more specific your user, the more defensible your product.
  • Map the decision-maker vs. the user. In most faith tech, the person who chooses the product (church admin, pastor, IT volunteer) is not the person who uses it daily (congregation member, volunteer). Design for both. Build trust with the decision-maker, value for the user.
  • Identify the secular analogue and then name what’s different. Almost every faith tech product has a secular equivalent. ChMS is CRM. Sermon tools are content platforms. Name what your product does differently because the mission context demands it. That’s your differentiation story.
  • Talk to three organizations running on outdated systems. The highest-value faith tech opportunities are in organizations still running on spreadsheets, paper, or 2008-era software. Find them. Understand why they haven’t switched. The answer is usually trust, not budget.
  • Set a “mission metrics” framework. What does success look like in this market beyond revenue? Engagement, spiritual formation, volunteer retention? Define it early. The organizations that pay premium prices in this market do so because they believe the product advances their mission.

Building in the faith tech space? I’ve spent 15 years at the intersection of ministry, product, and technology. Let’s talk.

Posted on

Philippians 2 and Agentic Systems: Why Humility Is the Foundation of Intelligent Systems

“Do nothing from selfish ambition or conceit, but in humility count others more significant than yourselves. Let each of you look not only to his own interests, but also to the interests of others. Have this mind among yourselves, which is yours in Christ Jesus, who, though he was in the form of God, did not count equality with God a thing to be grasped, but emptied himself, by taking the form of a servant, being born in the likeness of men.” (Philippians 2:3-7, ESV)

Paul’s letter to the Philippians contains what theologians call the kenosis passage — the self-emptying of Christ. It’s about voluntary limitation, choosing constraint over capability, service over sovereignty.

I’ve been thinking about this as I watch agentic systems become more capable. The rhetoric around AI often centers on unlimited potential, boundless capability, systems that can do anything. But in my experience building AI systems, including multi-agent workflows for executive tasks, I’ve observed that success often comes through deliberate constraints rather than unlimited scope.

Well-designed AI agents typically focus on narrow mandates: a calendar agent that protects focused time blocks rather than trying to optimize entire lifestyles, or an email agent that surfaces priority messages rather than attempting to replace human judgment entirely. Each agent serves a specific function within defined bounds.

This represents a design choice rather than a technical limitation.

The Kenosis of Intelligent Systems

When building AI workflows, the temptation exists to create agents that can handle everything. But, what I’ve seen is that this approach typically produces chaotic results — agents interfering with each other, making decisions outside their expertise, creating more complexity than clarity.

A more effective approach involves thinking about AI agents as specialized robots rather than general-purpose minds. Each agent can be designed to “empty itself” of capabilities it doesn’t need, serving a specific function more effectively through limitation.

Specialized agents with narrow scopes — research agents that don’t schedule meetings, scheduling agents that don’t write summaries, writing agents that don’t manage tasks — can demonstrate greater utility through deliberate constraints.

This mirrors patterns in effective human teams, which typically consist of specialists who understand their roles rather than generalists attempting everything. They practice a form of professional kenosis — voluntary limitation for collective effectiveness.

Paul’s instruction to “count others more significant than yourselves” suggests a design principle: building systems where each component serves the whole rather than maximizing individual capabilities.

The Servant Leadership Model for AI

The parallels between servant leadership principles and effective AI system design are notable. Servant leaders focus on enabling others’ success rather than demonstrating their own power, asking “How can I help you accomplish your goals?” rather than “How can I show you what I can do?”

Effective AI systems often follow similar patterns. GitHub Copilot suggests contextual code completions rather than attempting to write entire applications. AI writing assistants help clarify thinking rather than replacing human thought processes. Advanced language models acknowledge uncertainty and ask clarifying questions rather than claiming omniscience.

These systems practice technological humility by acknowledging their limitations.

In contrast, AI systems that fail in production environments often attempt to exceed their appropriate scope, make decisions beyond their training data, or present uncertain inferences as established facts. They lack the kenotic restraint that characterizes truly useful intelligence.

Building Products for Global Spiritual Formation

This principle becomes particularly important when developing products for spiritual formation. Digital discipleship platforms serve diverse global communities across cultural, linguistic, and theological boundaries. The temptation exists to build universal systems that can serve everyone.

However, effective spiritual formation tends to be deeply personal and contextual. A Bible application serving a house church in rural Kenya requires different features than one serving a suburban megachurch. Prayer applications for new believers need different structures than those designed for theological students.

AI systems serving spiritual formation appear most effective when they practice kenosis — limiting their scope to serve specific communities well rather than attempting to serve everyone adequately.

Current development work on AI tools for sermon preparation follows this model. Rather than attempting to write complete sermons (which, based on informal conversations with pastoral leaders, many pastors prefer to avoid), such tools can focus on specific supportive tasks: locating relevant cross-references, summarizing historical context, or structuring outlines. They operate within deliberate constraints to support pastoral ministry rather than replace it.

Each tool “empties itself” of broader capabilities to serve one function excellently. Like Paul’s description of Christ, they don’t grasp for equality with human pastors — they take the form of servants.

The Paradox of Powerful Restraint

An interesting observation: seemingly powerful AI systems often prove most effective when operating under significant constraints. The wisdom of limiting scope applies to artificial intelligence as much as human teams.

In my experience, the most effective AI implementations have narrow, well-defined purposes. They operate within their designated areas, defer to human judgment on edge cases, and acknowledge when they lack sufficient context for recommendations.

This represents strength through limitation rather than weakness.

Paul writes that Christ “did not count equality with God a thing to be grasped.” He could have insisted on unlimited power but chose constraint for the sake of service. The kenosis wasn’t a loss of divinity — it was divinity expressed through voluntary limitation.

Similarly, the most intelligent AI systems may not be those with the most capabilities, but those that use their capabilities most wisely — which often means choosing restraint over action.

Technical Humility in Agentic Systems

What might this look like in actual system design? Consider what could be called “kenotic interfaces” — AI systems that actively limit their own scope.

For example, an email management system might flag messages for human review when confidence levels fall below high thresholds, choosing uncertainty over potentially incorrect automated actions. A research assistant might include confidence indicators in summaries, distinguishing between well-sourced findings and preliminary observations that require verification.

These design choices represent features rather than limitations. The wisdom of acknowledging uncertainty can increase system trustworthiness.

The Global Scale Challenge

Building for global spiritual formation means designing for contexts that developers may never fully understand. While optimization for familiar cultural contexts remains feasible, platforms serving Orthodox Christians in Eastern Europe, Pentecostals in West Africa, and house churches throughout Asia require different approaches.

The kenotic approach suggests building systems that acknowledge their cultural limitations. Rather than attempting to provide universal spiritual guidance, they can provide tools that local leaders adapt to their specific contexts.

Bible reading features need not assume Western individualism. Prayer tools need not assume specific liturgical traditions. Community features need not assume particular church structures.

Each feature can “empty itself” of cultural assumptions to serve diverse communities more effectively. Like Christ taking human form while maintaining divine nature, these systems can preserve core functionality while adapting to local contexts.

The Long View

Paul’s kenosis passage encompasses more than humility — it describes transformation. “Therefore God has highly exalted him and bestowed on him the name that is above every name” (Philippians 2:9). Self-emptying leads to greater effectiveness rather than diminishment.

A similar pattern may emerge for AI systems. Those practicing technological kenosis — voluntary constraint for the sake of service — may ultimately prove more valuable than systems grasping for unlimited capability.

The Tower of Babel failed because it attempted to exceed proper limits. Modern AI might encounter similar challenges without the discipline of restraint.

The most powerful systems may be those that understand when not to exercise their power.

Key Insight:

The kenosis principle — Christ’s voluntary self-emptying described in Philippians 2 — offers a design philosophy for AI systems. Instead of maximizing capabilities, effective AI agents can practice deliberate constraint, serving specific functions excellently rather than attempting everything adequately. This proves particularly relevant for products serving global spiritual formation, where cultural humility and contextual awareness matter more than technical sophistication. Just as Christ didn’t grasp for equality with God but took the form of a servant, intelligent systems may become more useful when they acknowledge limitations and defer to human judgment on edge cases. The paradox of kenosis — that voluntary limitation can lead to greater effectiveness — may apply to artificial intelligence as much as spiritual leadership. In a world of increasingly capable AI, the most valuable systems may be those that understand when not to use their power.

Photo by Vitaly Gariev on Unsplash

Posted on

What 23 Million Bible Readers Taught Me About Digital Discipleship

digital discipleship

Every month, roughly 23 million people open Bible Gateway to read Scripture. That’s more than attend every Southern Baptist Convention church on a given Sunday — the SBC’s own 2023 report counted 12.4 million in average weekly worship attendance.1

I lead product at HarperCollins Christian Publishing, where Bible Gateway is my primary focus. Before that, I spent years building SermonCentral — a platform serving 14,700+ subscribing pastors with access to 145,000+ sermon manuscripts — and co-built ORI, a youth discipleship app for mentoring teenagers. I’ve spent the last few years of my career watching how people actually behave when they engage with Scripture through technology. And what I’ve observed has changed the way I think about what “digital discipleship” means.

Content Distribution Is Not Discipleship

Most church tech conversations define digital discipleship as “putting Christian content online.” Upload a sermon. Publish a devotional. Build a Bible app.

That’s content distribution. Discipleship is something else.

From a product perspective, digital discipleship is designing technology that facilitates spiritual formation — helping people move from curiosity to commitment to transformation. The difference matters because it changes what you build. If you’re optimizing for content distribution, you chase volume: more translations, more devotionals, more features. If you’re optimizing for formation, you chase behavior change: consistency, depth, relationship.

Bible Gateway has given me a front-row seat to how millions of people actually engage with Scripture. Not how we hope they do, not how pastors assume they do — how they actually do. The patterns are humbling.

Commitment Structures Beat Content Volume

Bible Gateway offers hundreds of reading plans across dozens of categories. We have the content. What we’ve observed is that completion rates vary dramatically — and it’s not the “best” content that wins. It’s the best structure.

Short reading plans with clear daily commitments consistently outperform longer ones in completion rates. (I want to be precise: this is based on aggregate engagement data across our reading plan ecosystem, not a controlled A/B test. The pattern is strong, but I’m stating it as an observed trend.)

This makes sense if you think about it through a discipleship lens. The goal of a reading plan isn’t to get someone through the entire Bible in 365 days. The goal is to build a habit of daily engagement with Scripture. A 7-day plan someone finishes builds more spiritual momentum than a year-long plan abandoned in February. The research supports this — BJ Fogg’s work on Tiny Habits at Stanford demonstrates that small, completable commitments are the foundation of lasting behavior change.2

The product implication: when designing for digital discipleship, optimize for completion and consistency, not comprehensiveness. Finishable is better than thorough.

I saw the same thing at SermonCentral. Pastors didn’t need more sermon content — they needed the right content at the right time in their prep cycle. The value was relevance and timing, not volume.

The Gap Between Bible Search and Bible Study

Something surprised me when I first dug into Bible Gateway’s usage data: the overwhelming majority of sessions are what I’d call “Bible search” behavior, not “Bible study” behavior.

Most people come to look up a specific verse. They type “John 3:16” or “Philippians 4:13” into the search bar, read it, and leave. They’re using the platform as a reference tool. With over 2,000 Bible searches happening every minute on Bible Gateway, that’s a lot of single-verse visits.

This isn’t a criticism — it’s a behavioral insight with real implications for how we think about digital discipleship strategy.

If most users are in “lookup mode,” the discipleship opportunity isn’t in the content they came for. They already know that verse. The opportunity is in what comes next. Cross-references. Historical context. A reading plan that starts at that passage. A study note that opens the text up. The moment after someone finds what they came for is the moment a reference visit can become a formation experience.

(I should be transparent: I’m inferring the “lookup vs. study” distinction from session duration, page depth, and search query patterns in aggregate. We can see that a large portion of sessions are short and single-verse. But I can’t tell you what’s happening in someone’s heart during a 30-second visit — maybe that one verse is exactly what they needed. The data shows behavior, not transformation.)

The product principle applies broadly: meet people where they are, not where you wish they were. Design the next step from actual behavior, not from an ideal user journey.

The Day 7 Engagement Cliff

This is the most actionable pattern I’ve observed, and it’s consistent across every content platform I’ve worked on.

When someone starts a reading plan, engagement drops sharply after about Day 7. The first few days see strong completion. By the end of the first week, there’s a significant cliff. People who make it past Day 10 tend to finish — but a substantial number never get there.

(Evidence level: this is a pattern in aggregate reading plan data. Exact drop-off percentages vary by plan type and length, but the general shape — strong start, sharp drop around Day 7, stabilization for those who persist — is consistent enough that I’m confident calling it a pattern. This aligns with published habit formation research — Phillippa Lally’s 2009 study in the European Journal of Social Psychology found that early repetitions are the most fragile period for new habits.3)

For digital discipleship design, the implication is clear: Day 5 through Day 8 is where you need your best intervention design. Reminders. Encouragement. Community connection. A check-in from a real person. Whatever bridges the gap between initial motivation and formed habit.

This is where most digital discipleship tools fail. They’re good at onboarding. They’re good at content. They go quiet in the messy middle — the stretch where motivation fades and habit hasn’t locked in yet. That gap is where discipleship actually happens, and it’s where most apps have nothing to say.

At Bible Gateway’s scale, even small improvements in that Day 5-8 window could mean hundreds of thousands of people moving from casual lookup to sustained practice.

Why Features Rarely Solve Discipleship Problems

I’ve shipped a lot of features across my career. One thing I’ve learned — sometimes painfully — is that adding features to a discipleship tool almost never solves a discipleship problem.

The instinct is always to build more. More study tools. More social features. More gamification. But the digital discipleship tools that actually seem to work are the ones that reduce friction to spiritual practice, not the ones that add complexity to it.

Bible Gateway’s core value proposition is remarkably simple: read any Bible translation, for free, instantly. Over 200 versions in 70+ languages. That simplicity is the product. Every feature we consider needs to serve that core experience, not compete with it.

There’s a real tension here. Bible Gateway Plus offers 50+ study resources, ad-free reading, and deep study tools at $4.99/month. But even the premium tier works because it removes friction (ads, limited study tools) rather than adding cognitive load. The upgrade makes the simple thing simpler.

What ORI Taught Me About the Limits of Scale

All of this data-driven thinking needs a counterweight. For me, that counterweight is ORI.

ORI is a youth discipleship app I co-built, and its premise is different from a content platform like Bible Gateway. ORI facilitates the relationship between a mentor and a young person. The technology doesn’t do the discipleship — it supports the human who does.

That experience taught me something analytics can’t: the most effective digital discipleship tool is often the one that gets out of the way. The one that connects a young person with an adult who cares about them, gives them a shared framework for conversation, and then steps back. It echoes what Paul wrote to the Thessalonians — “We were gentle among you, like a nursing mother taking care of her own children” (1 Thessalonians 2:7, ESV). Discipleship has always been relational. Technology either serves that or distracts from it.

There’s a spectrum here. On one end, platforms like Bible Gateway serve millions with content at scale. On the other, tools like ORI serve hundreds by facilitating real human relationships. Both are valid. Both are needed. But they succeed for different reasons, and conflating them is a mistake I see church tech teams make often.

Friction Is the Enemy

If I had to compress everything I’ve learned into one principle: your job is to reduce friction between a person and their next spiritual step.

Not to create content. Not to build features. Not to gamify Scripture. To reduce friction.

At Bible Gateway’s scale, that means instant access to any translation, fast search, and reading plans designed around how people actually behave. At ORI’s scale, that means making it easy for a mentor to show up prepared for a fifteen-minute conversation with a teenager.

The 23 million people who use Bible Gateway each month aren’t a metric. They’re people in a spiritual practice — or trying to start one. The best thing a product team can do is figure out where the friction lives and get it out of the way.

I don’t have this figured out. The Day 7 cliff still exists. The gap between Bible search and Bible study is still wide. The question of whether a 30-second verse lookup counts as “discipleship” — I genuinely don’t know. But I think the question itself is worth sitting with, because how you answer it shapes everything you build.

Dr. Josh Read is Director of Product at HarperCollins Christian Publishing, where he leads Bible Gateway. He writes about the product side of digital discipleship at drjoshuaread.com. His other writing explores AI stewardship in ministry and what the Tower of Babel teaches us about technology.

1 Southern Baptist Convention, 2023 Annual Church Profile, reporting 12.4 million average weekly worship attendance across 47,000+ churches.

2 BJ Fogg, Tiny Habits: The Small Changes That Change Everything (Houghton Mifflin Harcourt, 2019). Fogg’s research at Stanford’s Behavior Design Lab demonstrates that starting small and building on success is more effective than ambitious commitment structures.

3 Phillippa Lally et al., “How Are Habits Formed: Modelling Habit Formation in the Real World,” European Journal of Social Psychology 40, no. 6 (2010): 998-1009.

Posted on

The Tower of Babel Was a Technology Problem, Not a Language Problem

Most pastors I’ve talked to use the Tower of Babel the same way. It’s a warning against ambition. Don’t reach too high. Stay in your lane.

That reading has legs. But I’ve spent the last several years building products for churches — first at SermonCentral, where we managed over 245,000 sermon manuscripts for 14,700+ subscribers, and now at Bible Gateway, which serves 23 million monthly visitors across 200+ Bible translations. When I read Genesis 11 through a product lens, I see something the ambition reading misses.

God didn’t judge the bricks.

“Come, let us build ourselves a city, with a tower that reaches to the heavens, so that we may make a name for ourselves.” — Genesis 11:4, NIV

The materials were fine. The engineering was fine. The goal — consolidating human fame — was the problem. And that distinction matters right now, because the church is having the wrong argument about AI.

AI Is Bricks and Mortar

The debate I keep hearing splits along predictable lines. One camp says AI threatens authentic ministry. The other says it’s the future of outreach. Both are fixated on the tool and ignoring the purpose behind it.

AI is a building material. Your spam filter runs on it. Your search results are shaped by it. Your congregation interacts with machine learning dozens of times a day without a second thought. The question of whether the church uses AI was settled years ago.

The question that matters: what are you building, and for whom?

A church that uses AI to transcribe sermons so a deaf congregant can read along on Monday morning — that’s building for the Kingdom. A church that uses AI-generated sermons so the pastor can spend less time in the text — that’s a tower with its own name on it.

Same bricks. The blueprint is what changed.

Augustine’s Framework (From 397 AD)

About 1,600 years before anyone worried about ChatGPT, Augustine drew a line I think about constantly in product work.

In De Doctrina Christiana (Book I, chapters 3-4), Augustine distinguished between two postures toward the things of this world: uti (to use) and frui (to enjoy as an end in itself). His argument: the things of creation are meant to be used as means toward loving God and neighbor. They become disordered when we treat them as destinations — when we frui the tool instead of the purpose the tool serves.

I’ve found this more useful than any AI ethics whitepaper.

Consider: a church uses AI to automate its weekly bulletin, freeing up a volunteer to spend those 3 hours visiting a homebound member. That’s uti. The tool serves a human end.

Now consider: a church uses AI to eliminate pastoral presence altogether. Their new chatbot handles prayer requests, the algorithm personalizes a sermon playlist, the system runs without a shepherd. That’s frui. The church has started delighting in efficiency as its own reward.

The technology didn’t change. The orientation did.

Three Questions Before Adopting Any AI Tool

I’ve spent enough time in product leadership to know that the best safeguard isn’t a policy document (I’ve written plenty of those — they collect dust). It’s a habit of asking the right questions before you build.

1. Who benefits?

If the honest answer is “the budget” and not “the congregation,” pause. Cost savings aren’t wrong — stewardship matters. But if the primary beneficiary is the institution rather than the people it serves, you’re building in the wrong direction. The best AI implementations I’ve seen at Bible Gateway started with a specific human need, not a line item.

2. What human activity does this replace, and should that activity stay human?

Administrative tasks — scheduling, data entry, email sorting, transcript formatting — automate freely. These are good uses of AI. They free up people for work that only people can do.

But pastoral care, spiritual formation, the ministry of presence — these resist automation for a reason. A hospital visit from a pastor matters because a person chose to show up. An AI can generate a thoughtful prayer. It cannot bear witness to suffering.

(This is the question I find hardest to answer cleanly, by the way. The line between “administrative” and “pastoral” blurs more than we’d like. Where does sermon research end and sermon preparation begin? I don’t have a tidy answer. I think the honest move is to keep asking.)

3. Does this build the church’s capacity or create dependency on a vendor?

This is the product leader in me talking. I’ve watched organizations — churches included — adopt tools that felt like empowerment but functioned as dependency. If your church can’t operate without a specific AI platform, you haven’t adopted a tool. You’ve adopted a landlord.

Look for AI that trains your people. Look for solutions where the value stays with the church if the vendor disappears tomorrow.

From Babel to Pentecost

The Bible doesn’t end the language story at Babel. It picks it back up in Acts 2.

“All of them were filled with the Holy Spirit and began to speak in other tongues as the Spirit enabled them. Now there were staying in Jerusalem God-fearing Jews from every nation under heaven. When they heard this sound, a crowd came together in bewilderment, because each one heard their own language being spoken.” — Acts 2:4-6, NIV

At Babel, human technology consolidated power and built a monument to self. God scattered and confused. At Pentecost, the Spirit moved — and people from every nation heard the gospel in their own mother tongue. Each person’s language, met where they were.

According to recent Barna research, 77% of pastors believe AI can have a positive impact. I think that’s right — but only if we’re asking the Babel question each time we adopt something new.

Here’s what that looks like in practice: a small church in rural Guatemala using AI translation to access theological training that was previously locked behind an English-language paywall. That points toward Pentecost.

A megachurch using AI to scale content production so it can dominate more digital market share. That points back toward Babel.

What We Build Next

I don’t think the church needs to fear AI. I also don’t think it needs to be infatuated with it (and having built products in this space since 2018, I’ve watched both reactions play out in real time).

The bricks and mortar are here. They’re powerful. They’re going to keep getting more powerful. The church’s job is to ask the Babel question every time: what are we building, and whose name is on it?

That question doesn’t have a permanent answer. It has to be asked again with every new tool, every new capability, every new vendor pitch. And I think the churches that will get this right are the ones willing to sit with the discomfort of asking it honestly — even when the answer means building slower.

Sermon Illustration: The Tower of Babel and AI

When the people of Babel built their tower, God didn’t judge the bricks. He didn’t condemn the mortar or the engineering. The materials were fine. The problem was the purpose: “let us make a name for ourselves” (Genesis 11:4, NIV).

Today, AI is the new brick and mortar. Churches face the same question Babel faced: what are we building, and for whom? AI that frees a pastor to sit at a hospital bedside — that’s technology in service of presence. AI that replaces the pastor at the bedside — that’s a tower with our own name on it.

But the story doesn’t end at Babel. At Pentecost, God took language itself — the very thing He confused at Babel — and used it to carry the gospel across every barrier (Acts 2:4-6). The bricks are in our hands. The blueprint is the question.

Posted on

Karpathy’s Autoresearch and the Parable of the Talents: What AI Stewardship Looks Like in Practice

A few weeks ago, Andrej Karpathy — former AI director at Tesla, co-founder of OpenAI — released a project that made me think about ministry.

I didn’t expect that either.

Karpathy built a framework called autoresearch. It runs autonomous ML experiments on a single GPU while the researcher sleeps. The AI agent modifies training code, runs a 5-minute experiment, evaluates the result, keeps improvements, discards failures, and loops. About 12 experiments per hour. Roughly 100 overnight. He woke up to measurable performance gains — with zero human intervention during the run.

The part that got me: Karpathy doesn’t write the training code anymore. He writes a Markdown file — plain English instructions — that tells the AI what to research, what constraints to follow, and when to stop. His words: “you are programming the `program.md` Markdown files that provide context to the AI agents.” He calls this “programming in Markdown.”

The human moved up one level of abstraction. Define the methodology, set the guardrails, let the system execute. Not less involved — involved differently, at the level of direction instead of mechanics.

39,800 GitHub stars in the first two weeks. The tech world noticed.

I think the church should too.

The Parable We Keep Skimming

In Matthew 25:14-30 (ESV), Jesus tells the story of a master who entrusts his servants with talents — significant sums of money — before leaving on a journey. One receives five talents, another two, another one. The first two invest and double their resources. The third buries his in the ground.

When the master returns, the investors are praised: “Well done, good and faithful servant. You have been faithful over a little; I will set you over much” (Matthew 25:21, ESV). The one who buried his talent gets rebuked. Not for losing money — he hadn’t lost anything. He was rebuked for doing nothing with what he’d been given.

We tend to read this as a general principle about using your gifts. It is that. But I think there’s something more pointed here for 2026.

AI is a talent in the Matthew 25 sense. It’s a resource placed in front of this generation, and we have a choice. Invest it toward the mission, or bury it because the risk feels too high.

What This Looks Like at My Desk

I want to be specific, because the abstract conversation about “AI and the church” doesn’t move anyone forward.

I’m Director of Product at HarperCollins Christian Publishing, where I lead Bible Gateway — a platform serving over 75 million monthly visitors engaging with Scripture. Before this role, I led product for SermonCentral, which grew to 14,700+ paying subscribers with access to more than 145,000 sermon manuscripts.

Over the past year, I’ve built a system of 18 AI agents that handle competitive analysis, research synthesis, meeting intelligence, content drafting, and task management. Several run overnight — not unlike Karpathy’s loop. The architecture is different (mine orchestrate across business functions, his optimizes a neural network), but the pattern is identical: define methodology, set constraints, let the system execute, review results in the morning.

Every hour I used to spend pulling competitor data or formatting reports is now an hour I spend thinking about how 75 million people experience Scripture online. Or how to make Bible Gateway better for the person opening it at 2 AM because they can’t sleep and need something solid to hold onto.

Karpathy programs research methodology in Markdown now instead of writing Python. I program strategic priorities and agent instructions instead of pulling spreadsheets. The abstraction layer moved up. The work got more human, not less.

The Fear Is Understandable — and Partly Right

I hear the concerns from church leaders, and I take them seriously.

AI will replace authentic ministry. AI will make pastors lazy. AI will simulate relational presence that only a human body in a room can provide. These aren’t irrational. Some are already happening in small ways.

If a pastor uses AI to generate a sermon they never wrestle with, that’s a problem. If a church deploys a chatbot as a substitute for pastoral counseling, that’s a problem. If we treat AI-generated prayers as equivalent to the honest, stumbling prayers of a person before God — we’ve lost something that matters more than efficiency.

But Karpathy’s work shows the other path. The tool doesn’t replace the human. It moves the human to where they’re most needed.

The pastor doesn’t stop preaching — they stop spending 4 hours hunting for the right illustration and spend that time with the family walking through a divorce. The administrator doesn’t stop managing — they stop updating attendance spreadsheets and spend that time training volunteers. The ministry leader doesn’t stop leading — they stop drowning in email and spend that time on the phone with a donor questioning their faith.

I’ve lived this tradeoff. When my agents took over competitive analysis (something that used to eat 3-4 hours a week), I didn’t fill that time with more busywork. I spent it in 1-on-1s with my team and in deeper product strategy. The output quality went up because I was operating at the right level of abstraction.

Where the Line Is (and Where I’m Still Figuring It Out)

I want to be honest — I don’t think anyone has this mapped perfectly yet. I certainly don’t.

Here’s where I’d draw it today:

AI should handle the administrative. Scheduling, data analysis, report generation, email triage, content formatting. These consume enormous amounts of ministry time, and they don’t require pastoral presence. Automate them aggressively.

AI should accelerate the research. Sermon prep research, theological cross-referencing, community demographic analysis. These benefit from AI’s speed and scope. The pastor still does the synthesis — the “what does this mean for my people on Sunday” work. But raw material gathering? Let the machine run overnight, like Karpathy’s experiments.

AI should never simulate the relational. It should not write your prayers. It should not be the voice your congregation hears when they need a shepherd. It should not replace the hospital visit, the awkward conversation in the parking lot, the moment after the service where someone says what they’ve been carrying for months.

The servant in Matthew 25 who was praised put the resource to work — but in service of the master’s purpose, not his own convenience (Matthew 25:20-23, ESV).

Here’s the tension I haven’t resolved: where does “accelerating research” end and “simulating thinking” begin? When an AI summarizes 30 commentaries on a passage, is the pastor still doing exegesis, or are they just picking from a menu? I don’t have a clean answer. I think it depends on whether the pastor is engaging the summaries critically or just grabbing the first one that sounds good. But that’s a discipline question, not a technology question — and discipline questions are harder to solve with guardrails.

If You’re a Church Leader Starting from Zero

You don’t need 18 agents. You need one tool that saves you 3 hours a week.

Pick the task that eats the most time with the least relational value. For most pastors I’ve talked to, it’s sermon illustration research, email management, or meeting notes. Start there. Learn one tool well. Measure the hours you get back.

Then — and this is the part most people skip — reinvest that time in something only a human can do. A visit. A phone call. An hour of prayer you’ve been meaning to protect but kept losing to administrative drift.

Set your guardrails before you need them. Write down what AI will not do in your ministry context. Revisit it quarterly. Technology expands into unintended spaces when boundaries aren’t explicit — I’ve watched this happen in product development for 15 years.

The Talent in Front of Us

Karpathy’s autoresearch is an engineering achievement. But the deeper pattern is almost theological: the human was never meant to stay at the level of mechanical execution. We’re built to operate at the level of purpose, direction, and relationship. Genesis 1:28 gives humanity dominion and stewardship — a mandate to cultivate, not just maintain (Genesis 1:28, ESV).

The master in the parable didn’t give talents so the servants could admire them or lock them away. He gave them to be invested — put to work — in ways that generated return.

For those of us building technology that serves the church, the return isn’t financial. It’s pastors freed from busywork to do the work they were called to. It’s 75 million monthly visitors encountering Scripture through a platform that keeps getting better because the product team has time to think. It’s churches stewarding every tool available — including AI — in service of the mission they’ve been given.

The talent is in front of us. What we do with it is a stewardship question.

Josh Read is Director of Product at HarperCollins Christian Publishing (Bible Gateway) and holds a doctorate in Strategic Organizational Leadership. He writes about AI, product leadership, and digital discipleship at drjoshuaread.com.

Posted on

AI Just Walked Into Your Website Without Knocking

Last month I asked ChatGPT a question I’ve asked Google a thousand times: “What’s a good sermon illustration about forgiveness?”

It gave me a solid answer. Three illustrations, structured with context, application points, even a suggested closing line. It was genuinely useful.

And it never sent me to a single website.

That moment hit me differently than it would have two years ago. I run a platform with over 245,000 sermons and 50,000 illustrations. I didn’t just lose a click. I watched an AI system do what our product does, using content that likely came from sites like ours, and deliver it in a way that made visiting the source unnecessary.

That’s a revenue problem. (I wrote about the traffic implications of this shift recently.) (I wrote about the traffic implications of this shift recently.)

The Zero-Click Layer

Most product leaders I know are still thinking about AI as a feature to bolt onto their product: chatbots, smart search, AI-generated recommendations. And that matters. But there’s a bigger shift happening underneath that conversation.

AI answer engines (ChatGPT, Google AI Overviews, Perplexity) are becoming the front door to the internet. They don’t just search. They visit your site, interpret your content, synthesize it, and serve it directly to the user. The user gets the answer. You get nothing.

Google’s featured snippets started this zero-click trend years ago. BUT what’s different now is the depth. A featured snippet pulls a paragraph. An AI answer engine can synthesize an entire page, or multiple pages, into a comprehensive response that genuinely satisfies the user’s intent.

If your business depends on organic traffic as a top-of-funnel engine, this should keep you up at night.

Your Content Library Is Both Your Greatest Asset and Your Biggest Vulnerability

Here’s the paradox I’ve been sitting with.

We spent years building one of the largest structured content libraries in our space. That library is what drives our organic traffic. It’s what Google indexes. It’s what pastors find when they search “sermon on grace” at 11pm on a Saturday night.

That same library is now what AI systems are ingesting to train their models and generate their answers. The very content that built our moat is being used to fill in the moat.

And here’s what makes it worse. The emerging AI-native competitors in our space don’t even need to win Google rankings. They ARE the AI tool. They’re built to live inside AI workflows, not compete for traditional search clicks.

I think this pattern applies to any SaaS company sitting on a large content asset. If you’ve built your growth engine on content that AI can summarize, you’re exposed.

AEO: A Genuinely Different Discipline

There’s a term gaining traction: AEO, or AI Engine Optimization. And I’ll be honest, my first reaction was skepticism. We don’t need another three-letter acronym.

But the more I’ve dug into it, the more I realize it represents a genuinely different discipline.

SEO optimizes for ranking. AEO optimizes for citation. The goal is to be the source that AI systems reference AND link back to. That requires a fundamentally different content strategy.

Here’s what that looks like in practice:

  1. Structured data becomes non-negotiable. Schema markup, clear metadata, explicit problem-solution framing in your content. AI systems parse structure, not vibes. (Schema.org is the starting point.)
  2. Content architecture matters more than keyword density. How your content is organized (headers, relationships between pages, internal linking) determines how AI systems understand your authority on a topic.
  3. Gated content is a double-edged sword. If your best content is behind a login wall, AI crawlers can’t index it. You’re invisible to the answer engine. But if everything is open, you get summarized without a click. The play is in the middle: structured preview content that AI can cite, with depth that requires the visit.
  4. Domain-specific language is your moat. Generic content gets synthesized away. Content that uses the precise language of your audience (the way a pastor describes their Saturday night prep struggle, the specific vocabulary of sermon structure) is harder for AI to replace and more likely to be cited with attribution.

What I’m Doing About It

I’m not going to pretend I have this figured out. But here’s where my head is:

Audit how AI sees us. Before optimizing anything, we need to understand how our top pages render to AI crawlers. What structured data exists? What’s behind login walls that blocks indexing?

Treat AI referral as a distinct channel. We track direct traffic, organic search, paid. AI referral needs its own lane in our analytics. We can’t optimize what we can’t measure.

Build content AI can’t summarize away. The full sermon text? AI can handle that. But a pastor’s framework for adapting a sermon to their specific congregation? A diagnostic tool for matching an illustration to a particular emotional moment in a service? That’s interactive, personalized, and requires being on the platform.

Move faster than the AI-native competitors. They have the structural advantage of being built for AI workflows. We have the structural advantage of 20+ years of trusted content and relationships. The question is whether we can adapt our distribution before they build our depth.

The Strategies That Got You Here Won’t Sustain You

I keep coming back to this. The strategies that built organic growth over the last decade won’t sustain it over the next five years.

That’s a reason to move, not a reason to panic.

The companies that treat AI answer engines as a new channel will capture disproportionate share of the next era of discovery. The ones that keep optimizing for Google page one while AI summarizes their content into zero-click answers will watch their traffic erode and wonder what happened.

I’d rather be early and wrong about the tactics than late and right about the trend.

The AI just walked into your website. The question is whether it’s going to send people your way, or make visiting you unnecessary.

Posted on

Scotty Kessler’s AWCFROGROL

I met Scotty Kessler when I played Football for Northwestern. He came to the training camp my sophmore year of college and challenged us to walk as men. His training had a powerful effect on my life and though I didn’t remember his name, I remembered what he taught.

Fast forward seven years and my wife and I had just begun attending a church 2000 miles away from my college in the Pacific Northwest. Kess was there and I was shocked to see him again. He now is a leader in the University where I completed my doctorate – it has been a really great journey together and his influence has always come at an integral time of my life.

As my children are getting older, preparing to head to university, and beginning to ask really great questions about life, my wife and I have been attempting to state, as simply as possible, our doctrine – what it is that we believe and why. I remembered Kess’ AWCFROGROL yesterday and found his website which is filled with incredible resources that will challenge you to become better.

AWCFROGROL

A –  ADMIT (Romans 3:23) – For all have sinned and fall short of the glory of god

W – WAGES (Romans 6:23) – For the wages of sin is death, but the gift of god is eternal life in Christ Jesus our Lord

C – CONFESS (Romans 10:9) – That if you confess with your mouth, Jesus is Lord, and believe in y our heart that god raised him from the dead, you will be saved

F – FORGIVE (I John 1:9) – If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness

R – REPENT (Acts 3:19) – Repent, then, and turn to god, so that your sins may be wiped out, that times of refreshing may come from the lord

O – OPEN (Revelation 3:20)  – Here I am, I stand at the door and knock. If anyone hears my voice and opens the door, I will come in and eat with him, and he with me

G – GRACE (Ephesians 2:8-9)  – For it is by grace that you have been saved through faith, and this is not from yourselves, it is the gift of god, not by works, so that no one can boast

R – RECEIVE (John 1:12) – Yet to all who received him, to those who believed in his name, he gave the right to become children of God

O – OBEY (I John 2:3-4) – We know that we have come to know him if we obey his commands. The man who says, “I know him”, but does not do what he commands is a liar, and the truth is not in him

L – LOVE (John 14:21) – Whoever has my commands and obeys them, he is the one who loves me. He who loves me will be loved by my father, and I too will love him and show myself to him

—————

GOSPEL PRESENTATION USING AWCFROGROL

A – ADMIT – that means that everyone is a sinner

W – WAGES – that means that the wages or results of your sin is that you are separated from god (both now and for eternity)

C – CONFESS – that means that if you confess or acknowledge jesus is lord and believe that god raised him from the dead you will be saved

F – FORGIVE – that means that if you acknowledge your sins god will forgive you

R – REPENT – that means that if you repent or change direction and follow god instead of yourself, that your sins will be wiped out

O – OPEN – that means that if you open your heart and ask jesus into your life he will come in

G – GRACE – grace means undeserved love. that means that life in jesus is a gift that is received; you can’t work for it or earn it

R – RECEIVE – that means that if you receive jesus into your life that you are now a child of god

O – OBEY – that means that if you obey him, that is the sign that you love him

L – LOVE – that means that when you love god by obeying him, that he then reveals himself to you

—————

PRAYER OF SALVATION USING AWCFROGROL

A – ADMIT – Lord Jesus, I’m a sinner

W ­- WAGES – And I know that I’m spiritually dead

C ­– CONFESS – I confess that you’re God

F ­- FORGIVE – Please forgive me for my sins

R ­- REPENT – I’m turning to you to make me clean

O ­- OPEN – Please come into my life and live within me

G ­- GRACE – I accept your gift of salvation

R ­- RECEIVE – Thank you for making me your (adopted) child

O ­- OBEY – Lord Jesus, I commit to obey you all my days

L ­- LOVE – I love you. Thank you for loving me

____________________________

GOSPEL PRESENATATION / MESSAGE (SLANG VERSION)

Lord Jesus, I’m sick and I’m gonna die (ADMIT AND WAGES)
You’re the doctor and I need help (CONFESS AND FORGIVE)
I’ve tried to help myself and I can’t do it (REPENT)
Jesus, please help me (OPEN)

_________

AWCFROGROL Doctrines

A –  ADMIT – the doctrine of the depravity of man

W – WAGES -the doctrine of eternal judgment

C – CONFESS – the doctrine of salvation

F – FORGIVE – the doctrine of forgiveness

R – REPENT – the doctrine of repentence and sanctification

O – OPEN – the doctrine of fellowship with God

G – GRACE – the doctrine of grace

R – RECEIVE – the doctrine of sonship

O – OBEY – the doctrine of obedience

L – LOVE – the doctrine of unconditional love

Posted on

Custom WordPress plugin – nextSunday

I was contacted this morning by the pastor of our church. He built a wordpress website and has been logging into every week to simply change the date on the homepage. Currently there is a statement that says join us next Sunday “December 15th, 2019” and he has been manually changing that date each week for a LONG time.

It struck him this morning that there is probably a better way, so he shot me a message. I was able to write a quick plugin for WordPress that anyone can use. He simply has to put a shortcode into the paragraph text now and it will automatically update the date each week to the next Sunday.

Check it out and let me know if it works for you. You can download it here. I will attempt to place it onto the WordPress plugin directory soon, but from what I’ve read, it seems to be a mission and I don’t have the spare time at the moment.