Blog

A product team tracking 2,400 feature requests last quarter reported that 68 percent came from power users who logged in at least three times a week. The obvious reading was that the backlog now reflected the clearest priorities. The data said the opposite once the team examined who never appeared in the logs at all. Continuous discovery exists to close exactly this gap between what the data records and what the work actually requires.

The actual product owners were children’s ministry volunteers who printed materials on Tuesday nights and never created accounts. Their constraints never reached the spreadsheet. Continuous discovery, as Teresa Torres frames it, requires ongoing contact with the people whose work the software either enables or obstructs. Without that contact, the numbers simply ratified the loudest voices already inside the system.

This gap is not unique to church tools. Any product whose heaviest users operate outside the login flow will produce the same distortion. Surveys and usage metrics both miss the work that happens on paper, in cars, and in the ten minutes between the last child leaving and the volunteer locking the door.

The Tuesday night list that replaced the feature request board

The team stopped maintaining the public request board for six weeks. Instead they asked three volunteers to keep a running list on paper of every task they performed while preparing the next week’s materials. The lists arrived photographed and timestamped each Wednesday morning.

One volunteer wrote “find craft supplies that match the story” three weeks in a row. The feature request board had never contained that phrase. The team had instead built tagging improvements that assumed volunteers already knew which assets existed. The paper lists showed the search happened before the volunteer ever reached the digital library.

Another note read “print two copies because the first one always jams.” That constraint pointed to a print-preview problem, not a content problem. The usage data had shown high print-button clicks but zero time spent on failed jobs because failed jobs never generated a logged event.

How continuous discovery surfaced the real constraint

Volunteers often answered interview questions with single words: “easy,” “quick,” “simple.” Those words aligned with the product team’s own vocabulary for reducing clicks. Torres’s continuous discovery habit of asking “what does that look like on Tuesday night” forced the next question.

When pressed, “easy” turned out to mean “I can finish this while the kids are still eating snack and before the parents arrive.” The real constraint was not interface friction but calendar friction. The product had optimized for session length when the volunteer was optimizing for total elapsed time between arriving at church and leaving with everything in hand.

The same pattern appeared in the word “quick.” It described the window between the end of the service and the start of small-group setup, not the speed of any single screen. Once the team mapped the actual sequence, they removed two approval steps that had existed only to satisfy internal stakeholders who never saw the Tuesday timeline.

The single change that surfaced ownership questions

The team added one required field to every support ticket and every research note: “Who owns the outcome if this works?” The field could not be answered with a job title. It had to name the person who would notice if the change succeeded or failed.

Most answers pointed to volunteers who had never logged in. The children’s director became the named owner for curriculum readiness. The volunteer coordinator became the owner for print reliability. These names had never appeared in any prior analytics dashboard.

The change also revealed that two popular feature ideas had no owner at all. One idea improved search for pastors who prepared their own lessons; the other improved reporting for denominational staff. Neither group performed the Tuesday night work that kept the product alive week to week. Both ideas were deprioritized without debate once ownership was named explicitly.

Your Turn: Apply This Today

• Pick three volunteers who have never created an account in your current tool and schedule a single 45-minute session this week at the exact time they normally prepare materials.
• Ask each person to bring the physical artifacts they used last Tuesday—printed pages, handwritten notes, or screenshots of texts—and photograph those artifacts before the conversation starts.
• During the session, have them walk through the sequence out loud while you write only the exact phrases they use, without translating them into product language.
• After they finish, ask who would notice first if any step failed and write that person’s name next to every constraint they described.
• Within 24 hours, send each volunteer a one-paragraph summary of the constraints they named and ask them to correct anything that misstates their actual Tuesday night.
• Remove every item from your feature request board that has no named owner among the three volunteers you just met.

The same listening pattern appears in the children’s director’s inbox becoming the real product spec and in the 1997 lesson that still trips AI product teams today. Both posts trace how unlogged work surfaces only when someone stands beside the person doing it.

I consult with product leaders and ministry technology teams on continuous discovery with non-logged-in users, naming ownership of volunteer outcomes, and replacing feature boards with Tuesday-night constraints. Let’s talk.

Most product teams treat verification layers as the thing that slows an AI rollout, but ministry contexts show the opposite pattern: tools without explicit trust mechanisms reach a usage ceiling within weeks and never recover. The missing piece is almost always an AI audit trail: a record, inside the workflow, of what the model produced and who verified it.

This misread turns every efficiency gain into a hidden liability. Teams ship faster prompts and cleaner interfaces, then watch completion rates stall because the output cannot be trusted in real volunteer or pastoral workflows.

Jensen Huang’s sovereign AI argument supplies the lens. Huang insists that control over the stack is not optional once the system handles decisions that matter; dependence on external outputs without ownership creates fragility that no amount of speed can offset. The same principle applies to faith-tech products: the organization using the tool must own the verification step or it cedes authority over the very outcomes it claims to serve.

Where the AI audit trail actually lives

Most AI features in church tools generate content and stop. The prompt runs, the text appears, and the user decides whether to keep or discard it. In practice the decision never gets recorded, so the next volunteer or staff member has no way to know what was reviewed and what was accepted on faith.

The AI audit trail is not a log file sitting in an admin dashboard. It lives inside the workflow where the output is used. For curriculum tools like Sermons4Kids this means every lesson plan that reaches a volunteer must carry the record of who prompted the AI, which sources were cited, and whether a human editor confirmed the scripture references before printing. Without that record the product quietly shifts risk onto the least trained user.

Teams that add the trail after launch discover it changes retention more than any interface tweak. Volunteers finish the task because they can see the verification step was already performed. Completion rate, not session time, becomes the metric that actually moves.

The fallback that protects volunteer ownership

Ministry work is performed by people who do not own the data model. A children’s director using an AI-generated activity needs a path back to a human-authored version when the suggestion misses the mark. That path is the fallback, and it must exist before the feature ships.

The fallback is not a reset button. It is a parallel, non-AI route that preserves the volunteer’s ability to complete the task without depending on the model being correct. In practice this looks like one-click access to the last human-reviewed version of the same curriculum, with the AI output marked as optional rather than default.

Without the fallback the product forces volunteers into a position of either trusting the output or abandoning the task. Sovereign control means the team building the tool decides in advance that the human route remains the primary one. The AI augments; it does not replace the ownership the volunteer already holds.

Why tooling roadmaps keep skipping the verification step

Roadmaps prioritize visible capability because visible capability wins budget. A new generation model or a smarter prompt template shows immediate progress in a demo. Adding an audit trail or a verified fallback does not photograph well and therefore rarely survives the prioritization meeting.

The pattern repeats across faith-tech products. The feature that would let a pastor confirm an AI sermon illustration against the actual text never makes the quarter because the team is still chasing the next model upgrade. Usage data later reveals the problem: the illustrations look good in the interface but produce the same flat adoption curve seen in tools that skipped verification two years earlier.

Huang’s point on sovereignty reframes the tradeoff. The cost of adding the verification step is paid once in velocity. The cost of skipping it is paid continuously in lost trust and stalled usage. Ministry contexts make the second cost visible faster than consumer apps because the users cannot simply switch tools when the output fails; they have to keep serving the same people with whatever the product supplies.

Your Turn: Apply This Today

• Pick one existing AI workflow in your current product and add a visible confirmation checkbox that records the reviewer’s name and the date before the output is marked ready for use.
• Identify the single most common output failure reported by volunteers in the last thirty days and build the one-click fallback to the last human-reviewed version of that asset.
• Move the verification step from an optional admin setting to a required part of the core flow so every new user encounters it on first use.
• Export the last ten AI-generated items from your staging environment, run them through the proposed audit trail, and measure how many would have required a human correction.
• Replace one roadmap item that adds model capability with the verification layer for the most-used prompt template already in production.
• Share the resulting audit record format with two ministry leaders who use the tool weekly and adjust the fields based on what they say they actually need to see.

The same principle of owned verification appears in the 1997 lesson AI product teams keep missing and in the way the children’s director’s inbox became the real product spec. Both posts trace how control over the small, unglamorous steps determines whether the larger system stays usable.

I consult with product leaders and ministry technology teams on verification layers, fallback design, and roadmap prioritization that actually moves ministry usage metrics. Let’s talk.

I watched a product lead refresh the same volunteer dashboard three times in one night. Not because the numbers had changed. Because one row showed a woman in Ohio who’d opened the lesson plan at 9:14, closed it at 9:21, and never clicked “I’m in” again. That one row is why she traded dashboards for volunteer discovery interviews.

That gap between finishing the plan and deciding whether to come back is where the real work happens. Everything else—agent pilots, sentiment scores, the roadmap the exec team keeps waving—sits on top of it like fresh paint over a crack.

She started running volunteer discovery interviews instead of polling the analysts. Simple questions. What made you hesitate? What were you staring at when you almost said yes? The answers didn’t fit on any slide. They just kept showing up.

The volunteer discovery interviews that replaced the roadmap review

Your weekly sync with the children’s director used to start with feature status. You swapped the first ten minutes for one standing question: “What kept a volunteer from finishing the lesson this week?”

The answers never matched the AI wishlist. One director described a volunteer who spent twelve minutes hunting the right craft supply list because the print button sat three clicks deep. Another mentioned the parent who texted at 9 p.m. asking for the memory verse because the app only showed it inside the full lesson flow. These were not nice-to-haves; they were the moments that decided whether the volunteer opened the app again.

Torres’s method insists the interview happens while the work is fresh. You started requiring the director to bring one screenshot or one printed page that showed the exact friction. The specificity forced the team to stop theorizing about volunteer experience and start seeing it. She scheduled the volunteer discovery interviews while the frustration was still fresh.

How One Captured Pain Turned Into a Narrow Shipped Tool

A single volunteer’s email thread became the artifact. She had printed the lesson at home, realized the take-home activity required glue sticks she did not own, and spent the next morning driving to three stores before the kids arrived. The director forwarded the thread with the subject line “this is why we lose people.”

You scoped a two-week build: a one-tap “what do I need to buy” list that pulled only the items marked as supplies, formatted for a phone note or a printed half-sheet. No new AI. No new dashboard. The tool shipped to 12 pilot churches. Volunteer completion rate on those lessons rose 19 percent in four weeks. The signal was narrow enough that the build stayed small and the measurement stayed honest.

The Weekly Rhythm That Keeps the Signal Fresh

You now run a 45-minute Friday call limited to three people: the children’s director, the support lead who sees the most tickets, and you. Each person arrives with one raw artifact—no slides, no summaries. You watch the artifact together for eight minutes, then spend the rest of the time writing the smallest possible test that would remove that exact friction.

Nothing goes on the roadmap until it survives two consecutive weeks of this filter. The discipline removes the political weight of executive requests and replaces it with a growing list of narrow, volunteer-validated problems. The AI pilots still exist, but they now compete for the same scarce build time as the glue-stick list. Most of them lose.

Your Turn: Apply This Today

• Pick the one children’s director or volunteer coordinator you already email weekly and ask her to forward one volunteer message or screenshot from the last seven days before Friday.
• Block 30 minutes on your calendar this week to watch that single artifact with her on a shared screen and write the smallest test that would remove the friction.
• Ship the test to no more than three churches and define success as one observable change in volunteer completion rate, not in NPS or sign-ups.
• Cancel the next roadmap review meeting and replace it with the same 45-minute artifact review, keeping the attendee list to three people max.
• Write down the exact question you will ask every week for the next four weeks and put it in the calendar invite so it cannot drift.
• Choose one AI pilot currently on the roadmap and ask the team to name the volunteer frustration it would remove; if they cannot name one from an actual artifact, move it to the bottom of the list.

The pattern in “The Tuesday the Children’s Director’s Inbox Became the Real Product Spec” and “The Fitness App a Pastor’s Kid Shipped Without Writing Code” shows the same result: the smallest shipped change that comes from watching real labor beats the largest planned feature that never leaves the slide deck.

I consult with product leaders at ministry organizations on continuous discovery rhythms, volunteer friction capture, and narrow tool scoping. Let’s talk.