You are the product manager who just got told to lead a three-person pod that will own every workflow from volunteer onboarding to curriculum delivery. The mandate arrived with an org chart that looks clean on paper and a budget line that says “AI-native.” No one mentioned the actual people who will use what you ship.
You know the risk. Three generalists can move fast when every decision loops through one operator who still touches the real work. But the moment that operator starts letting the model close the loops, the whole setup quietly stops serving the people it was built for.
Teresa Torres built her continuous discovery habit on the simple claim that teams only ship useful products when they keep running lightweight interviews with real users every week. The framework forces the product person to stay in the room where the work actually happens instead of letting assumptions harden inside a document or a prompt history. When the pod is small, that single discipline becomes the only thing that keeps the model from becoming the default decision maker.
The pod collapses when discovery stays inside the chat window
Teresa Torres always started with the assumption that the team’s current understanding is incomplete. In a three-person generalist pod the temptation is to treat the model as the stand-in for that missing understanding. A quick prompt produces a volunteer flow, the flow looks reasonable, and the sprint begins. The problem is that the model has never watched a children’s ministry volunteer try to print a lesson on a church copier that only works half the time.
The collapse happens quietly. The pod ships the feature. Usage numbers look flat. No one can point to a single conversation with an actual volunteer that would explain why. Continuous discovery, in Torres’s terms, requires the product owner to schedule and run the interview themselves, not delegate the synthesis to a model. When the pod skips that step, every later decision rests on an untested mental model of ministry work.
One person must still watch the child-protection log
Ministry tools carry constraints that most enterprise software never faces. A lesson plan that accidentally surfaces a child’s photo to the wrong volunteer is not a usability issue; it is a safety failure. The model can generate clean copy and attractive layouts, but it cannot carry the liability or the institutional memory of past incidents.
In practice this means the single operator in the pod has to keep a standing review of every change that touches identity data or permissions. Torres’s continuous discovery habit helps here because the weekly interview often surfaces the edge case the model missed. The volunteer mentions that their phone number changed and the old one still routes to the previous church administrator. That single sentence forces a design change no amount of prompt refinement would have produced.
The operator who skips this review is not being efficient. They are creating the conditions for the first real incident that will later require the entire pod to stop and rewrite the permission model under pressure.
Authenticity comes from the friction the model cannot remove
Torres’s framework treats ongoing contact with users as the source of product judgment, not as a research phase that ends. In a generalist pod the operator who keeps running live sessions with volunteers develops a feel for what actually lands. The language that feels natural, the step that always gets skipped, the moment when a volunteer reaches for a printed page instead of the screen.
That friction is the signal. A model can remove every visible obstacle and still produce something that feels off to the person who has to use it on a Sunday morning. The operator who protects time for direct observation keeps the pod’s output tethered to the actual texture of ministry work. When that loop breaks, the product begins to optimize for the model’s idea of cleanliness rather than the volunteer’s idea of getting the job done.
Your Turn: Apply This Today
- Book one 20-minute call this week with a children’s ministry volunteer who has used your current tool at least twice; do not use the model to draft the questions.
- Run the session using the exact screen or printout the volunteer would have in front of them and take notes by hand.
- Within 24 hours write the single most surprising sentence from that call and share it with the other two pod members before the next planning meeting.
- Identify one workflow step the volunteer skipped or worked around and add it to the backlog as a discovery item rather than a build item.
- Schedule the next identical call for the same time next week before you close the calendar invite for this one.
- Refuse any model-generated summary of the session; keep the raw notes as the only record the pod uses for the next two sprints.
The same pressure to collapse discovery into the model appears in Letter to the PM Who Inherited the Agent Pilot and The Benchmark Number That Still Needed a Human Gate. Both posts trace what happens when the operator stops running the live loop.
I consult with product leaders running small AI pods on continuous discovery and human oversight in ministry tools. Let’s talk.