I watched a volunteer lean over the check-in table, tap once on her phone, and start the countdown. No login. No toggles. Just the numbers dropping while she kept moving toward the craft table. That single tap was the payoff of shipping a narrow feature on its own instead of burying it in the platform.
We had shipped that same timer inside the main platform two years earlier. Everyone on the team could point to the setting. Hardly anyone ever used it.
Then three of them yanked the code out in a single afternoon, shipping a narrow feature that finally fit the table.
Teresa Torres calls this continuous discovery: teams must expose real users to real artifacts on a regular cadence instead of guessing inside a roadmap. The timer team followed her pattern without naming it. They treated the countdown as a product, not a module, and let usage data arrive straight from the people who actually managed Sunday morning logistics.
How shipping a narrow feature exposed actual volunteer friction
The original timer sat behind three admin screens and required a logged-in staff account. Volunteers on Sunday never had that account. They also never saw the timer because the check-in flow ended once a child was marked present. The friction lived in the gap between the designed path and the actual handoff at 9:15 a.m.
Once the standalone app appeared on the kiosk, the first data point arrived within hours. Volunteers needed to start the timer from the same device they used to greet parents. They did not want another login. The stripped version let them tap once. That single change came from watching three people fumble with the old flow during the first service.
The second data point showed up the next week. The countdown needed to reset automatically when the next group of kids arrived. The volunteer running the table did not have time to hit a reset button between services. The team added the auto-reset after seeing it happen live, not after reading a support ticket.
Discovery Loops That Only Appear Once the Tool Ships Standalone
Torres emphasizes that discovery requires repeated contact with users and working software. The timer app created that loop by accident. Every Sunday the same three volunteers used it. They started sending short voice notes on Monday mornings with the exact phrases they wanted on the second screen. One note said, “Put the next service time in big numbers so I can answer parents without looking away.” That request became the next release.
The core platform team had run user tests in a conference room six months earlier. Those tests never surfaced the voice-note pattern because the test setup used staff accounts and printed schedules. The standalone app removed the artificial conditions. Real repetition on real mornings produced the signal.
The same loop exposed a hardware constraint. The kiosk tablet overheated after ninety minutes of continuous countdown display. Volunteers solved it by propping a small fan behind the device. The team later added a low-power mode after seeing the fan trick repeated across three different churches that copied the app.
The Upgrade Path That Emerged Without Paid Acquisition
Within five weeks the timer app had spread to four other churches through volunteer group chats. None of those churches had ever used the parent check-in platform. The narrow tool acted as its own distribution channel because it solved one visible problem in under ten seconds of interaction. Shipping a narrow feature, it turned out, beat any paid acquisition plan.
The original platform team later offered an integration back into the main check-in flow. Adoption came from the volunteers who already trusted the timer. They asked for the connection themselves rather than receiving an announcement from leadership. The upgrade path ran in the opposite direction from the usual roadmap: usage data first, platform attachment second.
The same pattern now appears in two other narrow tools pulled from the same codebase. One handles classroom supply requests. The other prints name tags at the door. Both began as single-workflow experiments and now carry their own weekly usage numbers.
Your Turn: Apply This Today
- Pick one internal tool your team maintains and list every screen a volunteer must pass through before completing the single most common task.
- Remove every screen except the final action, rebuild it as a standalone web page or simple app, and deploy it on the devices the volunteers already carry on Sunday.
- Visit the location where the tool runs within seven days and watch three people use it without offering instructions.
- Write down the first sentence each user says out loud when something does not work and ship the smallest fix for that sentence the same week.
- Share the standalone link in the volunteer group chat instead of the staff newsletter and track how many new users appear without any internal announcement.
- After thirty days of live use, decide whether the narrow tool should connect back to the core platform based only on the requests that come from the volunteers themselves.
The Tuesday the Children’s Director’s Inbox Became the Real Product Spec shows the same principle applied to intake processes. The Fitness App a Pastor’s Kid Shipped Without Writing Code traces how a single workflow became its own distribution engine.
I consult with product leaders building ministry tools and faith-tech platforms on stripping narrow workflows into standalone products and running continuous discovery with volunteer users. Let’s talk.