Blog

A ministry product manager recently asked whether they should accept the head-of-product offer from a scaling faith-tech company or stay put and resolve the recurring agent handoff failures in their current role. The answer is to treat the constraints of the role you already hold as the job to be done, then interview yourself against those constraints before you optimize for title or compensation.

Teresa Torres’s continuous discovery habit makes this possible. Instead of waiting for a career crisis to clarify what you actually need, you run small, frequent interviews with yourself using real evidence from the last three times work broke. The method surfaces the functional, emotional, and social jobs that a new role must actually perform.

This is the foundational misread that causes ministry product teams to chase the wrong next step. People collect job descriptions and salary ranges instead of mapping the specific constraints that keep breaking their current work.

The functional job ministry PMs actually hire a new role to do

The functional job is rarely “lead a larger team” or “ship more features.” In the places I have watched this play out, the real job is to reduce the number of times a children’s ministry volunteer prints a broken curriculum packet at 8:15 on Saturday night. That constraint shows up in Sermons4Kids data as volunteer completion rate, not in any feature roadmap.

When ministry PMs skip this step, they accept roles that expand scope without touching the handoff points that actually determine whether content reaches the end user intact. The new title arrives, the headcount grows, and the same packet still prints wrong because the underlying job was never named.

Continuous discovery requires logging the exact failure mode each time an agent schedule or volunteer workflow breaks. After three cycles you have a short list of functional outcomes the next role must improve, not a list of companies that sound impressive.

The emotional and social jobs that surface only after three agent schedules break

The emotional job appears once the third schedule failure has already cost a volunteer their evening and a pastor their trust. What the PM actually needs is relief from the repeated sense that the system will fail again the moment they step away. That relief is not delivered by a larger budget; it is delivered by decision rights over the handoff layer.

The social job surfaces in the same moment. Ministry leaders watch how peers treat the person who owns the broken schedule. If the pattern is blame without authority, the next role must change the social position, not just the reporting line. Torres’s method forces you to write the emotional and social jobs in the same format as the functional ones: “I need to feel X when Y happens so that Z relationship stays intact.”

Most ministry PMs discover these jobs only after they have already accepted an offer. Running the interview on the current constraints first makes the social and emotional requirements visible while you still have time to test whether a new role can actually meet them.

How to run the interview on yourself without self-deception

Start with the three most recent handoff failures. For each one, write the exact constraint that was violated, the moment the failure became visible, and what you did in the following 48 hours. Do not translate the constraint into strategy language; keep the wording the volunteer or pastor used when they described the problem.

Next, list the outcomes you would need to see in the current environment for those same failures to stop occurring. If none of those outcomes can be achieved without a title change, the data is telling you the role itself must change. If some outcomes are reachable with current authority, the data is telling you to run one more discovery cycle before you update your résumé.

The final check is to ask what would have to be true in a new role for the same constraints to be solved faster. Write the answer as a testable outcome, not a feeling. Continuous discovery keeps the loop short enough that you can validate or discard the hypothesis before you enter conversations with recruiters.

Your Turn: Apply This Today

• Block two hours this week and list the last three handoff failures in your current role, using the exact language volunteers or pastors used to describe them.
• For each failure, write one functional outcome, one emotional outcome, and one social outcome that would have prevented it.
• Score your current authority on a 1-5 scale for whether you can move each outcome this quarter without a new title.
• Write the single smallest test you could run in the next ten days to improve the lowest-scoring outcome.
• Run that test and record whether the constraint moved; if it did not, document the exact authority or resource gap that blocked it.
• Compare the documented gap list against any job description you are currently considering before you reply to the next recruiter message.

The same continuous discovery lens appears in “The Night the New Career Tool Asked the Wrong Job” and “The PM Who Inherited the Agent Schedule”, where the pattern of chasing the wrong job repeats across different ministry contexts.

I consult with ministry product leaders on running jobs-to-be-done interviews for their own roles and designing for agent handoffs in faith-tech teams. Let’s talk.

The volunteer coordinator’s cursor blinked on the row for Sarah. The note sat right there in the cell: Tuesday nights only, no phone after 7. Three weeks of 9 p.m. prep slots stared back from the calendar the agent had just pushed. The coordinator muttered something about Sarah’s toddler and the phone rule, then closed the laptop without fixing it.

The agent had pulled from public availability fields and nothing else. It treated every Tuesday the same. No record existed in its prompt of the last time Sarah had declined a late slot, or why the printed roster from two months ago still carried her constraint in red ink.

That single overwritten assignment revealed the real limit. Off-the-shelf agents arrive with no memory of how a ministry team actually passes work between people week after week. They optimize for the data they can see at the moment of the call.

Why generic agents treat every request as stateless

Jensen Huang has made the case for sovereign AI: the principle that organizations lose leverage when they hand critical decision loops to external models without owning the underlying data. The same pattern appears here at team scale. The coordination history that matters most sits outside the agent’s view, locked in heads, old spreadsheets, and printed sheets that never reach the API.

Generic platforms therefore treat every new request as stateless. They read whatever fields the volunteer profile exposes and generate the next assignment. When the constraint lives in a comment field that the agent never ingests, or in a conversation from last quarter that no one transcribed, the model has no chance to respect it. The first contact with the roster erases the rule because the rule was never part of the model’s working memory.

Ministry teams see this pattern repeat on every recurring task. Children’s ministry prep, hospitality setup, and follow-up calls all carry similar hidden constraints that only surface after the agent has already acted. The platform does not fail because the model is weak. It fails because the input layer never captured the history that made the constraint legible.

The lightweight wrapper that gave the team its state back

The smallest fix that worked was a narrow wrapper around the existing spreadsheet. We exported the last eight weeks of assignments into a simple table that included the original constraint note, the date it was noted, and the outcome of each attempted override. That table became the first context block passed to the agent on every new scheduling run.

We kept the wrapper to fewer than two hundred lines. It read the shared sheet, appended the recent rows, and stripped anything older than sixty days. No new database, no vector store, just a daily CSV that the agent prompt could consume without extra tooling. The agent now received Sarah’s constraint as a fact that had already been tested three times rather than as an optional preference.

That harness also logged every time the agent proposed a change that violated a stored rule. The log became the only source of truth the team trusted when they reviewed the schedule on Friday mornings. Within two weeks the number of manual corrections dropped from an average of eleven per week to two.

The real cost of each overwritten assignment

The real cost appeared after the third bad schedule. Sarah stopped replying to texts. Two other volunteers who had been reassigned outside their stated limits sent polite notes that they would sit out the next rotation. The printed roster had to be rebuilt by hand for the quarter because no one trusted the agent’s output.

Each overwritten slot had cost roughly forty minutes of coordinator time to repair plus the quiet loss of one volunteer’s reliability. After three cycles the cumulative friction exceeded the price of the agent subscription itself. The team had paid for automation and received additional administrative work plus damaged trust.

The pattern repeated on a different team that managed hospitality. Their agent kept placing the same two people on consecutive Sundays despite a standing rule against back-to-back service. Only after the fourth conflict did anyone trace the failures to the absence of a stored handoff state. The fix required the same lightweight wrapper, not a larger model.

Your Turn: Apply This Today

Map the last three handoff failures in your current system and write the single state rule each one violated.

• Pull the three most recent volunteer schedules that required manual fixes and list the exact constraint each one ignored.
• For each failure, write one sentence that states the missing rule in the form the agent should have received it.
• Check whether that rule currently lives in any field the agent prompt can read today.
• If the rule lives only in a comment, email, or printed sheet, add it to the daily export the agent receives.
• Run the next scheduling cycle with the added rule and record whether the agent still proposes the same violation.
• After three cycles, compare the number of manual corrections against the prior three cycles and note the difference in coordinator hours.

The same state problem shows up in career tools that misread internal mobility rules and in data projects that treat ministry history as optional context. The PM Who Inherited the Agent Schedule and The Data Moat That Actually Matters for Small Ministry Teams both trace how small teams regain control once they own the handoff layer rather than hoping a generic model will infer it.

I consult with faith-tech product leaders on agent memory layers, volunteer coordination systems, and minimal harnesses that preserve ministry state. Let’s talk.

The data flywheel model that circulates widely in product and venture circles treats every internal message as potential fuel for better agents. It assumes context survives extraction. In ministry teams, that assumption breaks because coordination carries irreversible handoff judgments that no model can reconstruct once the thread is flattened.

This model collapses for the same reason Solomon’s judgment exposed the false claim on the child. The one willing to divide the archive is rarely the one who carried the original constraints. Ministry teams discover too late that flattened Slack logs no longer contain the reasons a schedule changed or a volunteer was reassigned.

How archived volunteer schedules lose their meaning once stripped for model training

Volunteer schedules in a children’s ministry system sit inside chains of exceptions. One entry shows a name moved from 9 a.m. to 11 a.m. The surrounding messages explain that the regular driver canceled because of a sick child and the backup needed a printed copy mailed because they print at the church office. Remove those messages and the schedule becomes a list of names and times with no trace of why the change mattered.

Models trained on the stripped list learn patterns that never existed. They start suggesting the same volunteer for back-to-back slots across locations because the constraint about travel time lived only in the thread. The schedule itself gives no signal that the assignment was always meant to stay local.

Teams notice the damage only when an agent proposes a rotation that violates unspoken rules the original planners never wrote down. The archive still contains the dates. It no longer contains the judgment that kept certain names off certain weeks.

The cost of letting external agents rewrite coordination history without the original constraints

External agents trained on exported ministry logs begin generating new versions of past handoffs. They produce summaries that sound complete yet omit the single sentence that blocked an earlier plan. A coordinator who later searches the record finds only the agent’s rewrite and assumes the constraint never existed.

Solomon’s test was simple: the real owner refuses the division. Ministry teams that hand archives to training pipelines without ownership rules perform the division themselves. They accept a cleaner dataset in exchange for permanent loss of the reasons certain decisions were rejected.

The cost appears in future planning cycles. New volunteers receive assignments that repeat mistakes already solved in the original thread. The agent has no way to surface the constraint it never received, so the same conflict surfaces again six months later with different names attached.

Why ministry teams need explicit ownership rules before any internal archive becomes training data

Ownership rules must name both the data and the surrounding context. A rule that only covers names and dates leaves the judgment layer unprotected. Teams need a second category that marks any thread containing a rejected plan or an exception that never became policy.

These rules also decide who can grant extraction rights. In practice that person is the one who would recognize when stripping the thread removes the only record of why a decision was made. Without that gate, the archive moves to training sets based on volume rather than on whether the handoff context remains intact.

Teams that skip this step discover the problem only after an agent begins answering questions about past schedules. The answers reference events that match the flattened data but contradict the actual constraints that governed the original work. Reversing the training requires deleting the model weights, not simply restoring the original files.

Your Turn: Apply This Today

• Pull the last six months of volunteer coordination threads from one ministry program and export them to a separate folder without the surrounding messages.
• Tag every handoff that references a prior exception mentioned only in the thread, not in the final schedule entry.
• Mark any thread where a plan was rejected because of a constraint that never appears in the exported schedule itself.
• Write a one-sentence ownership rule for each tagged handoff that would need to travel with the data if it ever left the team.
• Identify which of those rules would be invisible to an external agent trained only on the stripped schedule.
• Bring the tagged list to the next team meeting and decide which threads stay out of any future training pipeline.

The Question I Kept Answering About Internal Ministry Data and The PM Who Inherited the Agent Schedule both trace the same pattern of lost context when coordination records move outside the original team.

I consult with ministry product leaders and faith-tech PMs on internal archive governance, context preservation before model training, and explicit ownership rules for coordination history. Let’s talk.