The proven-better pattern approach, drawn directly from the scaling tactics in books like “Inspired” by Marty Cagan, directs teams to locate high-performing flows from mature products and transplant them into smaller offerings. The method treats completion rates and delight signals from large user bases as reliable signals worth replicating. It promises faster iteration by skipping the need to invent from scratch. The proven-better pattern can still miss the people you most want to serve.
This method breaks for ministry tools aimed at volunteer-led congregations because the original delight signals emerged under conditions of paid staff, reliable devices, and repeated weekly exposure. A pattern built for daily app users cannot assume the same friction profile when the user opens the tool once a month on a shared tablet during set-up time. The transplant therefore lands without evidence that the underlying job still exists in the new setting.
The result is shipped features that look finished on internal demos yet produce zero measurable movement in the actual retention metric that matters for these teams: whether the volunteer completes the task before the first child arrives.
This is the foundational misread that causes product teams to treat proven patterns as context-neutral assets rather than hypotheses that still require validation. The pattern itself is not the problem. The decision to bypass the step that checks fit is.
Teresa Torres’s continuous discovery habits supply the missing lens here. Torres insists that discovery work must continue after a pattern has shown results elsewhere. The habits force teams to test the assumption that the same outcome will appear in a different environment rather than declaring the pattern “proven” once it succeeds at scale.
Where the proven-better pattern first led me wrong
I took a three-screen welcome sequence that had lifted activation numbers in a consumer reading app and dropped it into a planning tool for children’s ministry volunteers. The sequence used progress bars, a quick profile photo upload, and a one-tap “start your first lesson” button. Internal testing showed the flow completed in under ninety seconds.
When the first twenty-person church installed the update, the photo upload step failed on the shared device because the tablet camera permission had been locked down by the church IT volunteer. The progress bar never advanced for anyone who reached that screen. Completion rate for the new onboarding dropped to 12 percent within the first month.
The copy had preserved every pixel of the original pattern. It had preserved none of the conditions that made the pattern work.
Why the proven-better pattern missed the smallest churches
The original pattern produced delight because users returned daily and the app could remember their last state across sessions. In the small church setting the tool is opened once, used for ten minutes, and then closed until the next rotation of volunteers. No memory of prior sessions survives.
The progress bar that signaled momentum to a daily user now signaled an unfinished task to a volunteer who would not return for four weeks. The metric that looked like delight in the source context became an abandonment signal in the new one.
Teams measuring only the source metric never see this reversal. They ship the pattern and move to the next proven item on the list.
The discovery interview the proven-better pattern skips
A single thirty-minute conversation with a volunteer coordinator from a rural church would have surfaced the camera permission constraint and the four-week gap between uses. That conversation never occurred because the pattern had already cleared internal success criteria at the source company.
Torres’s continuous discovery habits require exactly this interview even after the pattern has data behind it. The habit is not additional work; it is the work that prevents the pattern from becoming expensive technical debt in the new context.
Your Turn: Apply This Today
- Pick the smallest user segment your product currently serves and pull the last three patterns you copied from larger products.
- Schedule one thirty-minute call this week with a single user from that segment; ask only what changed the last time they tried to complete the flow.
- Record the exact constraint they name that did not exist in the original pattern’s environment.
- Write one sentence that states whether the copied pattern still solves the job under that constraint.
- Remove or replace the pattern element that fails the test before the next sprint planning meeting.
- Repeat the interview with one new user from the same segment every month for the next quarter.
The same continuous discovery habit that would have caught the onboarding mismatch appears again in “Trust Logs Beat the Next Feature Sprint” and “The v1 Where the Model Handed Me the Safe Path.”
I consult with product leaders and ministry technology teams on continuous discovery for small-segment users, pattern transplantation risks, and retention metrics that survive volunteer constraints. Let’s talk.