Blog

The “master voice document” framework pushed in most product playbooks, from requirements templates popularized by product leaders like Marty Cagan to the Notion template libraries that circulate in every ministry tech Slack, collapses once a reorg changes who actually holds approval power. The advice treats the file as a finished artifact that new teams inherit and apply. In practice the file sits untouched while the children’s ministry volunteer still prints the wrong lesson plan because the instructions never recorded the exact permission shift that happened in the last budget meeting.

This approach assumes clarity travels through publication. It does not. The file compounds confusion instead of value because no one returns to it after the handoff that actually mattered.

The result is a common misread: teams believe a persistent file earns its keep by surviving the initial write. In reality the file only stays useful when every real-world change gets tested against the same three filters John Wesley used for his own movement. Do no harm. Do good. Stay in love with God. Applied to a markdown file, these become questions about whether an instruction creates confusion for the next person who must act, whether it improves the outcome for the end user, and whether it keeps the work aligned with the actual mission rather than the last org chart.

Write the first version from a single observed failure

The first version of any persistent file should come from one concrete breakdown you watched happen, not from a general desire to document process. At one children’s curriculum ministry, a volunteer finished a 45-minute setup only to realize the lesson file assumed the church had already moved to the new curriculum platform. The failure was not the platform itself. It was the missing note that the transition required a one-time override from the children’s director before any volunteer could print.

That single observation became the seed paragraph in the file. Everything else followed from it. The paragraph described the exact email chain, the permission that was missing, and the two-minute fix that would have prevented the delay. No other history entered at this stage.

Starting here keeps the file short enough that the next person actually reads it. Starting from a template or a previous version bloats the document with rules that never caused a real problem in your context.

Force the file through the three-rule filter after each change

After every handoff the file must pass through the same three questions. First, does this instruction create any confusion that could harm the person who has to act next? Second, does it actively improve the outcome for the volunteer or the family using the resource? Third, does it keep the decision tied to the mission rather than to whoever currently holds the title?

In one reorg the curriculum team added a new review step that required the senior pastor to sign off on every children’s lesson. The file recorded the step. Then the filter removed it. The step created harm by slowing release by ten days. It did not improve the lesson quality. It only protected a title. The paragraph stayed out.

Running every edit through these questions turns the file into a living record of what actually survived contact with real authority. Without the filter the file slowly fills with the preferences of the last person who held power.

Delete anything that did not affect a real permission gate

Most voice files accumulate paragraphs that describe tone or audience but never decided who could release the next version. Those paragraphs go. If a sentence never changed who had to approve or who could override, it did not earn its place in the file.

One ministry kept a long section on “warm and accessible language for families.” The section never altered a single permission gate. It stayed decorative. After the third reorg the section disappeared. In its place the file now holds the one sentence that actually mattered: the children’s director alone can approve a print override when the platform update lags.

Deletion keeps the file short enough to matter during the next crisis. Retention of unused language turns the file into another ignored archive.

Your Turn: Apply This Today

• Identify the single handoff you observed in the last four weeks where verbal instructions caused a delay and write the exact failure into a new or existing markdown file before Friday.
• Run every existing paragraph in that file through the three questions this week and delete any line that never changed a permission.
• After the next team meeting, add one new paragraph that records the actual override or approval that occurred and note who held the gate.
• Schedule thirty minutes next Monday to test whether the updated file prevents the same failure for the person who will use it next.
• Remove any section that describes general tone or audience unless it directly names who must approve when that tone conflicts with a new requirement.
• Share the revised file with the one person who will inherit the next reorg and ask them to mark the first sentence that would have confused them.

The same discipline that kept one voice file intact through three ministry changes also shows up in how we track real retention for volunteer tools and how we decide which AI instructions survive contact with actual users.

I consult with ministry product leaders and faith-tech PMs on building persistent documentation systems and applying mission filters to AI instructions. Let’s talk.

Most teams racing to adopt AI for faster code generation are optimizing the part of the process that least determines whether the final product serves its intended users. The bottleneck was never raw output speed. It sits in the handful of inputs that still require a human to score before any generated work can be reviewed.

Teresa Torres built continuous discovery around the idea that product teams must keep live contact with the opportunity space rather than batching assumptions into long development cycles. When AI multiplies the volume of code or content produced, the same principle applies but inverted: the inputs themselves must be locked and validated first. Without that step, teams simply generate more of what they already misunderstand.

This pattern shows up in ministry tooling whenever an engineering group adds an LLM step to an existing workflow. The volume of pull requests rises. The time from ticket to merge drops on paper. Yet the handoff to content reviewers or volunteer testers still stalls on the same three questions that existed before the model was introduced.

Identify the three inputs that still need human judgment

The first input is the problem statement framed as a user outcome. In a curriculum tool, this might be the exact constraint a volunteer faces when preparing a lesson in seven minutes on a phone. AI can expand that statement into code, but only a person who has watched the volunteer actually work can confirm the outcome is stated correctly.

The second input is the definition of done for any theological or pastoral alignment check. A generated component that handles scripture references must still pass a human filter on whether the references respect the intended teaching emphasis. Torres would call this an explicit opportunity, not a solution detail. The filter cannot be automated without first freezing the criteria in writing.

The third input is the edge-case description for the least technical user. Ministry products routinely break when a user lacks admin rights, reliable internet, or comfort with digital forms. These descriptions must be written by someone who has observed real failure modes, then locked before generation begins.

Once these three inputs are captured and signed off, generation can proceed at any speed. The human scoring step happens once, upstream, rather than repeatedly during review.

Shift review effort to automated verification on those frozen inputs

With the inputs fixed, automated checks can run against them instead of against the generated output. A simple script can confirm that every new component references the approved outcome statement. Another can flag any code path that touches scripture data without the pre-approved alignment criteria attached.

The remaining human review then narrows to two questions only: does the output still satisfy the frozen inputs, and has anything changed in the live user context since the inputs were locked? Both questions are cheaper to answer than re-evaluating the entire feature from scratch.

Teams that adopt this pattern stop treating every PR as an occasion for fresh discovery. Discovery work moves earlier and happens less often, which is exactly what Torres observed in high-performing product groups.

Measure time saved at the handoff point, not at generation

Generation time is easy to instrument and therefore tempting to optimize. The real constraint appears at the moment a reviewer or ministry partner first sees the work. That handoff point is where accumulated misunderstandings surface.

One team building volunteer scheduling features tracked the interval between PR creation and the first external reviewer comment. After freezing their three inputs, the interval dropped by more than half even though raw generation time stayed roughly the same. The reviewers no longer had to reconstruct the original intent; they only had to verify it still held.

The metric forces the team to keep the frozen inputs visible and current. When the inputs drift, the handoff interval lengthens again, giving an early signal before users ever see the product.

Your Turn: Apply This Today

• Pick the engineering workflow that produces the most reviewed artifacts this month, such as new components for a children’s ministry scheduling tool.
• Write the three frozen inputs for that workflow in a shared document before the next ticket is started.
• Add an automated check in the repository that fails any PR missing a reference to the frozen problem statement.
• Run the next PR through the checkpoint and record the exact time from merge request to first external reviewer reply.
• Compare that interval against the average from the previous three PRs in the same workflow.
• Adjust one of the three inputs based on what the comparison reveals and repeat the checkpoint on the following PR.

Two earlier posts on the blog explored how continuous discovery habits transfer to ministry product teams and why opportunity framing beats feature velocity when the users are volunteers. I consult with product leaders building ministry tools on continuous discovery practices, frozen-input checkpoints, and measuring handoff time in AI-assisted workflows. Let’s talk.

Dear Ministry PM who inherited the AI volunteer coordination tool three months after the last lead walked out,

You know the Slack thread is still pinned at the top. The one where the old captain said “we’ll figure out the override rules once the model is live.” You also know the model is live now, and every Tuesday morning three different regional directors are asking why their local kids ministry leads can’t book a room without going through a central queue that no one owns.

That handoff never happened. Not the real one. The one with the frozen inputs, the named signers, and the explicit permission gates. What you got instead was a deck and a login.

This is the foundational misread that causes ministry product teams to decentralize authority without ever building the lattice that makes decentralization work. Charlie Munger’s latticework of mental models only produces better decisions when every node carries explicit constraints and cross-checks. Remove the constraints and you simply multiply the number of people who can approve something without ever seeing the downstream cost.

Map every captain decision to an actual signer

The first place the lattice breaks is when a model output is treated as a completed action rather than a proposed one. On one curriculum platform, an AI tool started auto-generating lesson assignments for volunteer teams. The model had learned from three years of historical data that certain age groups preferred shorter videos. What it had not learned was that one region’s volunteer coordinator had a standing agreement with a local printer for paper versions only. The first time the system pushed digital-only assignments, three churches printed their own copies at their own expense and the coordinator spent the next week fielding complaints.

The fix was not more model training. It was naming the exact person who still held physical permission to change the output format. Once that signer was written into the workflow, the model could suggest, but the assignment only moved forward after the signer confirmed the input constraints had not changed. The queue disappeared because the constraint was now visible and owned.

The same pattern shows up in room booking tools. When the AI proposes a time slot, someone must still be the signer who confirms the room is not already reserved for a funeral or a food pantry distribution that never appears in the shared calendar. Without that named signer, every “autonomous” suggestion eventually lands back in the same review queue, only now the queue is larger and the original captain is gone.

Build the knowledge OS around what cannot be regenerated

Munger’s lattice requires models that cannot be rebuilt from public data alone. In ministry settings the irreplaceable pieces are almost always local relationships and physical constraints. A volunteer’s willingness to teach only on weeks when her husband is not traveling for work cannot be regenerated from usage logs. A church’s rule that the nursery must stay empty during the 8 a.m. service because the carpet is being cleaned cannot be inferred from click data.

The knowledge operating system therefore has to store these constraints as first-class objects, not as footnotes. One team created a simple shared table that every AI suggestion had to query before generating an output. The table contained only three columns: constraint description, current signer, and last verified date. Anything not in the table was treated as unknown and therefore blocked. The model’s suggestions dropped by half, but the acceptance rate on the ones that remained rose sharply because they no longer violated unstated local rules.

Without this layer, decentralization simply accelerates the rate at which bad suggestions reach volunteers. The lattice collapses because the missing nodes are the ones that actually determine whether an action is permissible.

Run the first three loops with the handoff log visible

The first time a new captain runs the system, the handoff log must be public. Not summarized, not archived, but sitting in the same interface where decisions are made. In one deployment the team kept a running document that listed every override, who made it, and what constraint had been missed. After three weekly cycles the document revealed that two regional directors were overriding the same constraint for different reasons. One needed the room for a food distribution that only happened on odd weeks; the other needed it for a counseling appointment that could not be moved. Once both reasons were visible, the model input was updated to treat those weeks as blocked, and the overrides stopped.

Visibility also surfaces when the original captain’s mental model was simply wrong. The log becomes the place where the new captain can see the difference between “this rule was never documented” and “this rule was documented but no longer holds.” Without that distinction the team keeps re-learning the same exceptions at higher speed.

Your Turn: Apply This Today

• Pick the single AI-generated workflow your volunteers interact with most and list every decision the model currently makes without a named human signer.
• For each decision, identify the one person who still holds physical authority to block or alter the output and add that name to the workflow definition this week.
• Create a shared constraint table with only three columns—description, signer, last verified date—and require the model to query it before any suggestion is shown.
• Run the next three decision cycles with a visible handoff log that records every override, the reason given, and the constraint that was missed.
• After the third cycle, update the model inputs with any constraints that appeared more than once in the log.
• Schedule a 30-minute review with the actual signers to confirm nothing in the table has changed since the last verification date.

The same lattice problems appear when AI tools are applied to sermon preparation and children’s ministry resource distribution; the posts on those topics show how the missing permission gates surface in different places but for the same structural reason.

I consult with ministry product leaders on mapping decision signers, building knowledge operating systems around local constraints, and running visible handoff loops in AI deployments. Let’s talk.