Picture this: a faith-tech product manager spends three months building an internal AI tool to streamline sermon prep for her team. The algorithm works beautifully in testing. On launch day, she sends an excited email to the whole staff. Two weeks later, exactly two people are using it—and one of them is her. Sound familiar?
A few weeks back, a faith-tech PM messaged me with this exact frustration: “Josh, we built an internal AI tool to streamline sermon prep for our team, but no one uses it. What did we miss?” My answer is straightforward—your tool isn’t failing because the AI doesn’t work; it’s failing because it wasn’t designed as a product with your team’s real needs and workflows in mind.
Internal tools, especially AI-driven ones, often get treated as side projects or tech experiments in faith-tech spaces. But if you want adoption, you’ve got to approach them with the same product mindset you’d bring to a customer-facing app. That means intuitive design, clear value, and alignment with your team’s mission—not just a shiny algorithm.
I’ve seen this play out in my own work on tools for ministry leaders. Build a functional AI widget without user-centric design, and it sits unused. Treat it like a product, and even non-tech staff start relying on it daily.
This is the foundational misread that causes faith-tech teams to fumble internal AI tools. They assume “if we build it, they will come,” ignoring the reality that even internal users need a compelling, frictionless experience. It’s not enough to solve a problem on paper; the solution has to feel indispensable in practice.
To unpack this, I keep coming back to Donald Norman’s design principles for usability. Norman, a pioneer in human-centered design, argued that good products don’t just function—they communicate their purpose and fit seamlessly into the user’s world. His framework, rooted in concepts like affordances and feedback, isn’t just for consumer gadgets; it’s a lens for why internal AI tools in faith-tech often fail to stick.
Why Internal Tools Fail Without Product Thinking
Most internal AI tools in faith-tech start with a noble goal—save time, reduce grunt work, or scale impact. Think of a tool to auto-generate discussion questions for small group leaders. Sounds great, right?
But here’s the rub: they’re often built by engineers or data folks who don’t live the day-to-day of ministry staff. The tool might spit out decent questions, but if the interface feels like a clunky spreadsheet or the output doesn’t match the tone of a pastor’s teaching style, it’s dead on arrival.
I’ve watched this happen with teams I’ve advised. One group built an AI to summarize sermon feedback from online forms. The tech worked, but the summaries felt robotic, and the staff had to spend more time editing than they saved. No product mindset—no empathy for the user’s real pain—meant no adoption. The tool wasn’t wrong; it was just never designed for the people who were supposed to use it.
Norman’s principle of “discoverability” applies here. If users can’t instantly see how to use a tool or why it helps, they won’t bother. Internal tools need to communicate their value from the first click, or they’re just expensive shelfware.
Designing AI for Non-Tech Ministry Staff
Faith-tech teams often serve users who aren’t tech-savvy—think volunteer coordinators or part-time pastors. I remember working on a curriculum platform where our core users were “7-minute volunteers”—folks with barely enough time to prep a kids’ lesson, let alone learn a new tool. That constraint shaped everything we designed, from button labels to the number of steps in any workflow.
AI tools for these folks can’t assume digital fluency. If your internal chatbot for scheduling requires a tutorial, you’ve already lost. Norman’s idea of “affordances”—design cues that hint at how something works—means buttons should look pressable, workflows should feel obvious, and jargon should be nonexistent.
I’ve seen a ministry team try an AI tool for event planning. The tech could predict attendance and suggest venues, but the dashboard was a maze of dropdowns and filters. Staff ignored it, sticking to their messy Google Sheets. Why? The design didn’t meet them where they were. The tool optimized for capability, not for the actual human sitting in front of it.
Contrast that with a project I supported where we built an AI assistant for sermon research. We made it as simple as texting a friend—type a topic, get bullet points. Non-tech staff loved it because it felt natural, not alien. Design for the user’s reality, not your ideal tech world.
Measuring Adoption Beyond Usage Stats
Faith-tech teams often gauge an internal tool’s success by raw numbers—logins, queries run, hours spent. But those metrics lie. A tool with high usage might still be hated if staff only use it under duress.
I’ve been in rooms where leaders celebrated “100% login rates” for an AI reporting tool, only to learn later that users resented every click. They complied because they had to, not because the tool helped. Norman’s feedback principle kicks in here—design must give users a sense of control and clarity, or it breeds frustration regardless of how often people open it.
On a project for a global discipleship app, we learned to track something deeper: completion rates. Did users finish the task the tool was built for? If our AI suggested devotionals but users dropped off before sharing them with their group, we knew the design failed somewhere. That single metric revealed more about adoption than any login dashboard ever had.
True adoption shows in qualitative signals too. Are staff mentioning the tool in meetings unprompted? Are they asking for new features? Numbers matter, but stories of real impact—how a tool saved a pastor an hour of prep—tell you if you’ve built something that sticks.
Norman’s lens reminds us that usability isn’t a checkbox; it’s the heartbeat of adoption. Internal AI tools in faith-tech need to be measured by how they empower mission, not just by how often they’re opened. Build for felt value, and the stats will follow—but more importantly, so will the people your ministry is trying to serve.
Your Turn: Apply This Today
- Map your internal AI tool’s user journey this week by sketching out every step a non-tech staff member takes to use it—identify where they might get stuck or frustrated.
- Interview three users of your tool by Friday, asking one question: “What’s the hardest part of using this?” Write down their exact words and brainstorm one design fix for each pain point.
- Simplify one core feature of your tool by next Monday—cut out unnecessary clicks or fields so it feels as easy as sending an email.
- Define a “completion” metric for your tool this month—track whether users finish the key task it’s built for, not just whether they log in.
- Set up a 15-minute feedback session with your team in the next two weeks to hear unfiltered thoughts on what the tool does or doesn’t do for their mission.
- Prototype a quick visual cue or tooltip by the end of the month to make the tool’s purpose obvious at first glance—test it with one user and iterate based on their reaction.
The internal tools that endure in faith-tech aren’t the ones with the most features or the most sophisticated AI—they’re the ones that feel like they were made for the people using them. When ministry staff reach for a tool without being asked, when they recommend it to a colleague, when they notice it’s missing on a day it’s down—that’s the goal. That’s product thinking applied to mission. And it starts with caring more about the person at the keyboard than the algorithm behind the screen.
If you’re wrestling with internal AI adoption or want to dive deeper into designing for faith-tech teams, check out my posts on AI Prototyping Without Mission DNA Builds the Wrong Product and The Complete Guide to AI Product Strategy for Faith-Tech and Ministry Leaders. They’ll give you more angles on aligning tech with mission.
I consult with faith-tech product leaders and ministry innovators on building internal tools with a product mindset, designing for non-tech users, and measuring true adoption. Let’s talk.