I was in a windowless kids ministry office in Manila when the volunteer lead showed me the screen. Three parents had abandoned the new check-in flow because the baptism question forced a yes/no that their tradition wouldn’t allow. The metrics looked clean. The real problem sat there anyway, untouched by another discovery sprint.
That gap isn’t a usability bug. It’s the kind of trade-off most product books never name, because they assume every hard question can be answered inside the next roadmap quarter. Ministry keeps the questions that refuse to stay inside the quarter.
The Recency Trap in Faith-Tech Roadmaps
Most current roadmaps for sermon resources or prayer tools cite frameworks written after 2015. Those frameworks optimize for speed of iteration and measurable engagement within one release cycle. When the same teams face an AI agent that could generate children’s curriculum at scale, the recency bias pushes them to measure output volume first. Munger’s lattice requires pulling in an older model, such as the 1990s service-profit chain work that linked employee capability directly to customer outcome. In ministry the equivalent is volunteer capability. A 7-minute volunteer cannot absorb twenty generated lessons; they need one that already carries the theological guardrails. The lattice surfaces this mismatch before the roadmap commits engineering time.
Teams that skip the older model later discover they have built volume without transmission. Retention drops because the metric that mattered was never the one the new framework measured.
1990s Discovery Frameworks Applied to AI Agent Scoping
Discovery practices from the late 1990s, such as the original context-mapping work by Karen Holtzblatt, required teams to watch users in their actual environment for hours before writing requirements. When applied to AI agent scoping for ministry workflows, the method forces a different question set. Instead of asking what the agent could generate, the team observes how a volunteer currently decides which lesson to print on a Wednesday night. The observation reveals that the decision hinges on whether the material aligns with the church’s last three sermons, a constraint no recent product book flags. The lattice therefore adds the older model to the newer AI capability discussion and narrows scope to agents that can read the church’s own content calendar first.
Without that step, scoped agents optimize for generic biblical content and create downstream review work that volunteers refuse to do. Decision quality improves when the 1990s observation is retained alongside the 2025 capability.
Decision Quality When Older Models Replace Hype Cycles
Replacing the last three purchased product books with one pre-2010 text changes the sequence of questions a product manager asks. The older text already encodes what happened when previous technology waves—radio, television, early web—met institutions that measure success in decades. The lattice therefore surfaces the question of reversibility: can the church undo the data relationship if the tool is later sold or its terms change? Recent frameworks rarely require that question because they assume the product will iterate indefinitely. When the older model is applied first, scoping decisions shrink to features that can be turned off without losing the ministry’s own records.
The difference appears in roadmap reviews. Teams using only recent books defend scope by projected engagement curves. Teams running the same decision through an older model defend scope by whether the feature preserves the church’s ability to change its mind later. The second defense produces narrower, more durable commitments.
Your Turn: Apply This Today
- Identify the three most recent product or AI books on your shelf or Kindle and set them aside for sixty days.
- Choose one pre-2010 text—either The Innovator’s Dilemma or a 1990s ethnography of service work—and read only the chapters that address failure under technological change.
- Take one current scoping decision on your roadmap, such as an AI agent for curriculum or prayer requests, and write down the trade-off the older text forces into view.
- Run that same decision through your existing framework and note where the two outputs diverge in scope or reversibility.
- Present the two versions in your next roadmap review without naming the books, only the constraints each version surfaced.
- Track whether the older constraint changes the engineering ticket size or the success metric chosen for the quarter.
The pattern of chasing the newest methodology shows up again in the eighteen months teams spend testing successive AI frameworks before realizing the durable constraints never changed. The same pattern appears when product managers receive an AI agent mandate without first testing it against older models that already survived one technology cycle.
I consult with faith-tech product leaders and ministry technology teams on roadmap scoping, AI agent definition, and mission-aligned success metrics. Let’s talk.