Blog

The volunteer coordinator’s laptop sat open on the scarred wooden table, its screen reflecting the overhead bulb. Her youngest reached across for another piece of bread while the older one asked about homework. She ignored both long enough to drag three phone photos into the chat window and type the phrases she had heard at the door that morning. What followed was a small lesson in screenshot-driven discovery: raw images and real words, not a written brief, shaped the next build.

Claude generated a new check-in layout in the reply. She copied the suggested changes straight into the test build her developer had left running on the side. The corrected flow loaded without the old crash. She tested it once, nodded, and closed the laptop to finish dinner.

Teresa Torres built continuous discovery on the idea that product teams must keep direct contact with users through regular, lightweight probes rather than periodic big-bang research. The Manila scene shows what that practice looks like when the person doing the probing has no formal product training and the tool in front of her is an LLM instead of a research platform.

The same principle scales when the constraints arrive as images and spoken fragments rather than translated tickets.

The screenshot-driven discovery loop that replaced the product spec

Most ministry tools still begin with a written brief that someone must first interpret. The coordinator skipped that step entirely. She sent the actual error states and the exact phrases parents used. The model treated those artifacts as the source of truth.

Each iteration stayed inside the same chat thread. She would test the suggestion on Sunday, photograph the new failure point, and paste it back the following week. The document that mattered was the running conversation itself, not a separate requirements file that would have aged out after the first service.

Continuous discovery insists on small, frequent signals over large, infrequent studies. Here the signals were visual and verbal, captured at the moment of use. No one had to schedule a discovery sprint or book a research lab. The loop ran on whatever device was already on the kitchen table.

Why spoken parent language beats polished requirements

Polished requirements smooth away the friction that actually breaks the experience. When the coordinator typed “the line was too long for the little one,” the model kept that constraint visible. It did not translate the complaint into abstract language about throughput or queue management.

Spoken fragments carry the emotional weight and the physical reality at the same time. A parent holding a toddler cannot wait in a straight line. That single sentence forced the layout to include a side bench and a second volunteer who could greet families before they reached the tablet. No requirements document written later would have recovered that detail with the same precision.

Torres warns against losing the raw data behind layers of interpretation. The LLM here acted as a direct transcription layer rather than an additional interpreter. The original words stayed in the prompt, so the generated interface stayed tethered to the real constraint.

Shipping the version that survived one real Sunday morning

After three weeks the build reached a state where it handled the busiest arrival window without crashing. The coordinator did not wait for a full regression suite. She watched the door the next Sunday, noted the three families who arrived together, and confirmed the flow stayed intact.

That single morning became the acceptance test. Everything else—edge cases, accessibility audits, future roadmap items—remained secondary until the next failure showed up in a new set of screenshots. The product advanced only when the real environment confirmed it.

Continuous discovery measures progress by the reduction of surprise in live use, not by completion of a spec. The coordinator never claimed the app was finished. She only claimed it had survived the most recent Sunday without creating new problems for the families at the door.

Your Turn: Apply This Today

• Pick the single workflow that broke last Sunday and open a fresh chat with your AI tool before you write any description.
• Take three screenshots of the exact failure states on the device the volunteer actually uses and paste them into the chat with no additional summary.
• Transcribe the two or three sentences users said out loud when the flow failed and add those lines beneath the images.
• Generate the revised screen inside the same thread and push the change to a test build the same day.
• Run the new build on the next live event and photograph whatever still breaks before you touch the prompt again.
• Repeat the loop once a week for four weeks, keeping every screenshot and spoken line in one running thread so the history stays intact.

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 both trace the same pattern of letting raw signals drive the next build instead of waiting for translated requirements.

I consult with faith-tech product leaders and ministry builders on screenshot-driven discovery loops, keeping spoken user language as the primary spec, and running continuous discovery cycles that fit around existing volunteer schedules. Let’s talk.

I spent fourteen months refusing to greenlight an AI outline generator for children’s ministry because the projected usage numbers never materialized in our internal dashboards. Every sprint review I asked the same question: show me the cohort that actually opens the tool more than once. The answer stayed flat. We had real volunteer feedback in the form of one-off emails and hallway comments, but I treated those as noise until the telemetry caught up. The mistake was treating usage data as the only signal that counted and the qualitative input as noise.

The cost showed up later. Two other teams shipped lighter versions of the same idea while we waited. Their adoption came through the exact channels we had dismissed as anecdotal. By the time our version reached the same directors, the window for shaping how they used AI had already closed.

Taste as the first filter before any usage data

Volunteer tools rarely produce clean usage signals until the workflow already matches how people actually prepare on Tuesday nights. The children’s director prints the lesson at the kitchen table, marks it with a highlighter, and hands the marked copy to the small-group leader on Wednesday. No login, no repeat session recorded. The data stays silent because the real use happens offline.

I used to treat this silence as a verdict against the feature. Now I treat it as evidence that the initial test must happen through direct observation rather than aggregated logs. One director’s reaction to a printed sample carries more weight than a month of anonymous click data that never arrives.

The practical shift is to route early decisions through taste first. Build the smallest artifact that one practitioner can hold and judge inside their existing rhythm. If it survives that single judgment, then instrument it. Not the other way around.

How Wesley’s rules expose where data stays silent

John Wesley gave the early Methodists three simple rules: do no harm, do good, and attend to the means of grace. Applied to product work, the first rule means refusing to ship something that adds friction to an already thin volunteer margin. The second means looking for concrete help that fits the actual preparation window. The third means paying attention to the repeated practices that sustain the work week after week.

Data dashboards are excellent at measuring harm once it scales. They are nearly useless at detecting whether a tool does good inside a single, unrepeated Tuesday night routine. That judgment requires the same kind of attentive presence Wesley expected of class leaders who visited homes rather than waiting for reports.

The rules therefore reorder the sequence. Taste informed by direct contact becomes the first screen. Quantitative thresholds come later, once the practice has already taken root in one location.

When to ship the version that feels right to one children’s director

We eventually released a minimal outline generator after a single director walked us through her exact Sunday morning handoff. She showed us the folder she carries, the three places she writes notes, and the moment she decides the material will not work for her group. That thirty-minute walkthrough replaced six months of waiting for cohort metrics.

The version we shipped matched her folder structure and printed cleanly on standard paper. Usage numbers appeared only after the tool was already in rotation with three other directors who heard about it through the same informal channel. The telemetry finally moved because the fit had already been tested in one real context.

Shipping on that kind of single-point confirmation feels reckless until you accept that volunteer contexts keep most usage invisible by design. The alternative is to keep polishing a tool that never enters the only workflow that matters.

Your Turn: Apply This Today

• Pick one AI feature decision currently stalled on usage projections and write the single sentence that describes the exact moment a children’s director would first hold the output in her hands.
• Find three volunteers who match the target context and schedule a thirty-minute walkthrough this week where they show you their current preparation materials without any new tool present.
• Print or mock the smallest possible version of the feature that fits inside their existing folder or notebook and watch where they mark it or set it aside.
• Note the exact point in their rhythm where the artifact either reduces a step or adds one, then adjust the mock before showing it to anyone else.
• Send the revised mock to those same three volunteers with one question: does this replace something you already do or sit on top of it?
• If two of the three say it replaces a step, ship the narrow version to their group only and measure what actually changes in their handoff rather than waiting for broader telemetry.

The same pattern shows up in The Tuesday the Children’s Director’s Inbox Became the Real Product Spec and The 1997 Lesson AI Product Teams Keep Missing.

I consult with AI product leaders and ministry tool teams on taste-driven early decisions, volunteer workflow observation, and when to release before metrics appear. Let’s talk.

The call came while I was still clearing breakfast dishes. A pastor in western Pennsylvania had one question: the AI tool that could write his entire children’s ministry curriculum in ten minutes had already been built, so why was his volunteer team still printing last year’s worksheets at the kitchen table? Reaching the smallest churches, it turned out, had nothing to do with how fast the feature was built.

He wasn’t asking about prompts or pricing. He wanted to know how the file was supposed to reach the three other volunteers who only ever showed up on Sunday morning, none of them checking product stores or reading release notes. The tool had done its part. Everything after that stayed exactly the same.

That single gap between “we shipped it” and “it actually reached the smallest room” is the part no one has fixed yet, and reaching the smallest churches lives entirely inside it.

Print-first constraints remain the real filter. A volunteer who prints the lesson at home on Thursday night does not care that the underlying model ran on a rented GPU cluster. If the output still requires reformatting to fit an 8.5-by-11 sheet and a three-ring binder, the adoption path is identical to the one that existed before the agent existed.

Completion rate inside that binder is the only metric that travels back to the builder. Every other telemetry—sign-ups, demo requests, feature usage—stops at the church office door. The cost reduction therefore changes the speed of iteration for the builder while leaving the observable result for the smallest churches unchanged. Reaching the smallest churches means winning that binder, not the dashboard.

The two distribution paths that decide reaching the smallest churches

Ministry tools travel either through denominational or regional trust nodes or through direct volunteer-to-volunteer referrals. The first path requires explicit endorsement from a person already trusted by multiple congregations; the second requires the tool to survive one successful handoff between two people who already know each other.

App-store or website discovery plays almost no role. A pastor searching for “AI children’s lesson” will still ask the children’s director at the next association meeting whether anyone has tried the new thing. That meeting is the actual product review cycle. Builders who optimize only for the website conversion funnel never reach the table where the decision is made.

Both paths are slow by design. They exist to reduce risk for volunteers who have limited time and zero tolerance for tools that fail on Sunday. Speeding up the build phase does not compress the trust verification phase that follows.

Munger’s Inversion Test Applied to an Agent Rollout

Charlie Munger’s latticework requires asking what would have to be true for the opposite outcome to occur. Instead of asking how to get the agent adopted, the useful question is what would have to be true for the smallest churches to never install it even after it is free and technically perfect.

The answer points to missing handoff artifacts. No printed one-page instruction that fits inside the existing binder. No verbal script the director can repeat in thirty seconds to a volunteer. No version that survives a lost internet connection on Saturday night. Each missing artifact is a reason the tool stays on the drive.

Inversion also reveals the second-order effect. When the agent is easy to build, teams ship more versions. Each new version increases the cognitive load on the person who must decide whether to reprint the lesson packet. The proliferation itself becomes a distribution tax rather than a distribution benefit.

Your Turn: Apply This Today

• Pick one current AI feature already in pilot and write the exact three-sentence script a children’s director would say to a volunteer at the end of a planning meeting.
• Print that script on the same sheet as the generated lesson and test whether the volunteer can complete the activity without opening a second tab or device.
• Map the next two people who must physically receive the printed sheet after the director approves it and note how many days typically pass between each handoff.
• Remove every UI element that requires the volunteer to log in or download an app; replace it with a single QR code that prints at the bottom of the page and opens the content in a browser.
• Run the inversion question with the actual volunteer: “What would have to be true for you to throw this page away and use last week’s lesson instead?” Capture the first answer verbatim.
• Schedule the next iteration of the agent only after the printed artifact survives one full Sunday with the volunteer who originally gave the answer above.

Distribution Moats Still Decide Which Ministry Tools Actually Reach Churches laid out the trust-node mechanics in more detail. The 1997 Lesson AI Product Teams Keep Missing showed how earlier technology shifts produced the same pattern when builders ignored the final handoff layer.

I consult with AI product leaders and ministry tool builders on distribution path mapping, trust-node verification, and agent rollout constraints. Let’s talk.