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.