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.