Blog

You’re the hiring manager at a midsize faith-tech organization who has now posted the same senior product role four times in nine months. Each posting adds another requirement about AI fluency or stakeholder management, yet the inbox stays thin. The candidates who do apply are either fresh out of boot camps or veterans who have already burned out at larger ministries. You keep adjusting the language, but the right people never seem to surface.

This pattern is not unique to your posting. It is the default approach most faith-tech teams still use when they need operators who can ship tools that actually survive ministry handoffs and budget cycles. Job boards reward visibility and self-promotion. They miss the people who have spent years quietly fixing the exact problems your organization now faces.

John Wesley’s three simple rules offer a different lens. Do no harm. Do good. Stay in love with God. Applied to hiring, the first rule means refusing processes that quietly damage the relational networks that already exist. The second means creating specific, useful asks that travel well through those networks. The third means keeping the final decision tied to the people who will actually live with the outcome rather than letting HR templates take over.

Map the quiet operators first

The best product people in this space rarely update LinkedIn. They are the ones who built the volunteer scheduling layer that still runs at three different children’s ministry networks because no one has forced them to migrate to the new platform. They fixed the print export bug that kept breaking for the 7-minute volunteer on Sunday morning. They know which reorgs actually changed decision rights and which ones were just new org charts printed for a meeting.

Start by listing every person you have already worked with who has delivered something that lasted more than one budget cycle. Do not limit the list to people currently looking for roles. Include the person who left two years ago to care for aging parents but still answers questions about the old curriculum database when asked. Include the contractor who stayed on a project after the contract ended because the ministry lead kept calling.

This map is not a sourcing trick. It is the only reliable record of who actually understands the constraints of shipping to volunteers, pastors, and small teams who will never file a support ticket. Job posts do not surface this information because the people on the map are not optimizing for applications.

Write the one-paragraph ask that travels

Once the map exists, the next step is a single paragraph that can be forwarded without losing its meaning. The paragraph names the exact problem the role must solve, the three constraints that have already broken previous hires, and the one decision the new person will own in the first ninety days. It does not list technologies or years of experience. It describes the failure mode that keeps repeating.

Send this paragraph directly to the three people on your map who are not looking but know the next person who would be right. Ask them to forward it only if they can name someone who has already solved a version of the same problem. The rule against harm shows up here: do not ask them to post it publicly or to recommend someone they barely know. The ask must respect the weight of their endorsement.

This paragraph travels because it gives the forwarder a clear test. They can decide in thirty seconds whether the person they are thinking of matches. Most job posts fail this test because they require the forwarder to do the translation work themselves.

Close the loop with the person who still signs the budget

The final rule requires that the person who controls the budget hears directly from the mapped operators before any offer is extended. This is not a formal interview. It is a thirty-minute conversation where the budget owner describes the last three tools that failed to stick and asks the candidate what they would have done differently on day one.

In practice this step surfaces mismatches that a hiring committee never sees. The quiet operator who built the reliable children’s ministry export will immediately ask which current leader still has sign-off on content changes. If the budget owner cannot name that person, the operator knows the role will repeat the same handoff failures. The conversation ends quickly and without wasted time on both sides.

This closing step also protects the organization from the common pattern where an approved headcount gets filled by the candidate who performs best in a panel rather than the one who already knows how the actual work moves.

Your Turn: Apply This Today

• Block two hours this week to build the initial map of five operators who have shipped something that still runs after a reorg or budget cut.
• Write the single-paragraph ask for the current open role and send it only to the three people on that map who are not actively searching.
• Schedule the thirty-minute budget-owner conversation with the first candidate who receives a direct forward from your map.
• Remove the current job posting from all public boards until you have completed the first three direct outreaches.
• Document which three constraints from past failed hires appear in the paragraph you wrote and confirm the budget owner still owns those constraints.
• Send a one-sentence follow-up to each person who forwarded the paragraph, naming the outcome of the budget-owner conversation.

The pattern of reposting the same role while the operators stay hidden shows up again in how teams structure handoffs. See “The Three-Person Pod That Still Needed a Fourth Set of Eyes” and “The Ministry PM Who Handed Off Captain Duties Without the Handoff Log” for the downstream effects.

I consult with ministry product leaders on mapping existing operator networks and replacing job posts with direct, named outreach that respects actual budget owners. Let’s talk.

Most AI product teams treat agent work as an exercise in feature velocity rather than an exercise in transferring judgment from one person to the next.

The result is systems that perform well when the original builder is in the room and stall the moment that person steps away. This pattern shows up whether the agent drafts volunteer schedules, summarizes teaching notes, or routes prayer requests. The first run succeeds because the builder still holds the mental model. The second and third runs fail because no one else holds the same model.

This is the foundational misread that causes product teams to optimize for launch metrics instead of handoff metrics. Teresa Torres’s continuous discovery framework makes the distinction sharp. Torres argues that discovery is not a phase but a set of small, repeating loops that keep the team in contact with the actual problem space. When those loops stay inside one person’s head, the team stops discovering as soon as that person moves on.

The same principle applies to agents. An agent is not a finished product until the discovery loop that created it can be run by someone else without the original builder present.

Stop shipping agents that only the builder can run

Children’s ministry platforms often see this first. A volunteer coordinator builds an agent that pulls curriculum themes and suggests age-appropriate activities. In testing it works cleanly because the coordinator knows which fields are reliable and which need manual override. Two weeks later a new volunteer tries the same flow and receives mismatched age groups because the override rule was never written down.

The agent itself is not the problem. The problem is that the builder treated the working demo as the end of the work rather than the start of a transfer process. Continuous discovery requires that the team document the questions the agent cannot yet answer, not just the ones it can. Without that documentation the next person inherits only the surface behavior.

Ministry teams feel the cost quickly. A single reliable volunteer leaves and the agent becomes shelfware. The team then concludes the technology failed when the real failure was the missing handoff step.

Make the handoff visible before the first demo

Teams that follow Torres’s approach insert a handoff checkpoint before any internal demo. They write the exact sequence another person must follow to reach the same result the builder reached. This sequence includes the data sources, the places where judgment is required, and the signals that mean the output should be rejected.

One platform team adopted this rule after an agent that routed small-group requests worked for its creator but produced inconsistent groupings once handed to the operations lead. The team added a one-page handoff document that listed the three judgment calls the agent could not yet make. The next iteration included those calls in the prompt, and the operations lead could run the loop without asking for clarification.

The checkpoint forces the builder to surface tacit knowledge before it is lost. It also surfaces gaps in the agent itself that would otherwise remain hidden until someone else tried to use it.

Measure the second and third person who can explain what just happened

Standard product metrics track time to first value or number of tasks completed. Those numbers stay high as long as the builder stays involved. The more useful metric tracks how many additional people can explain the agent’s decision without referring back to the builder.

In one case a teaching-notes agent was measured by how many staff members could describe why it flagged certain passages for review. After the handoff document was introduced, three staff members could give the same explanation the original product manager had given. Retention of the agent rose because the explanation no longer depended on one person remaining in the role.

Continuous discovery treats this transfer as observable behavior, not assumed goodwill. If the second and third people cannot restate the logic, the discovery loop has not yet left the builder’s head.

Your Turn: Apply This Today

• Pick one agent that shipped in the last quarter and list the three judgment calls it still requires.
• Write the exact sequence a new team member would follow to reach the same output without asking you for help.
• Run that sequence with a colleague who was not part of the original build and note every point where they hesitate.
• Add the missing judgment rules to the prompt or the supporting document before the next sprint planning meeting.
• Schedule a 30-minute review two weeks after the update and measure how many people can explain the agent’s output without your presence.
• Record the names of those people and treat that list as the real success metric for the agent.

The same transfer problem appears in schedule agents that keep running after the original owner leaves and in pod structures that still require an extra set of eyes to stay stable. Both cases show that the agent only becomes durable once the discovery loop moves beyond its first builder.

I consult with product leaders and ministry technology teams on building agent loops that transfer judgment and designing visible handoffs. Let’s talk.

I spent a full year chasing AI certifications and structured courses. I mapped out modules on machine learning fundamentals, prompt engineering tracks, and even a side sequence on ethics frameworks. The plan felt responsible and thorough. It also kept me from shipping anything real with the tools already in my hands.

The cost showed up in missed product decisions. While I collected badges, teams around me were testing small integrations that changed how volunteers completed tasks or how readers moved through content. I had the theory but none of the constraint-driven instincts that only appear when you are forced to decide what not to build.

This pattern is the foundational misread that causes product teams to treat skill development as a degree instead of an ongoing series of constraints. The result is slower judgment under real pressure and less ability to recognize the small opportunities that compound.

John Wesley’s three simple rules offer a better lens. Do no harm. Do good. Stay in love with God. Wesley used them to keep early Methodists focused on immediate action rather than endless preparation. The same three rules can filter what AI knowledge is worth pursuing next and what can wait.

The curriculum trap I built

I built the trap with good intentions and a spreadsheet. Every week I added another course or paper. I told myself the foundation had to be complete before I could responsibly advise on product choices. The spreadsheet grew while actual experiments stayed on a someday list.

The mistake compounded when I started reviewing other people’s work. I could critique model choices in theory but had never felt the friction of a volunteer trying to finish a lesson plan on a phone with one hand while managing kids with the other. Without that friction, my recommendations stayed abstract.

Real product work punishes the linear approach. Constraints appear in the moment: limited compute budget, a user base that prints everything, or a ministry leader who needs the output in under seven minutes. A curriculum rarely surfaces those constraints early enough to shape judgment.

Wesley’s rules as a filter for what to learn next

Do no harm first. Before I chase the newest model release, I ask what downstream effect it might have on the people already stretched thin. In one case this meant skipping an advanced summarization tool because it would have removed the brief human review step that caught doctrinal drift in children’s material.

Do good next. I now look for the smallest capability that improves an existing workflow today rather than the largest capability that might matter later. A simple classification model that routes volunteer questions to the right curriculum page produced more ministry impact than months of studying generative video.

Stay in love with God keeps the filter from becoming purely utilitarian. The rule surfaces when a technical choice begins to erode the sense that the work still belongs to something larger than efficiency. If a new technique requires hiding how decisions are made from the people who will live with them, the rule flags it before the roadmap meeting.

How faith-tech teams can apply the same constraint

Teams can run the three rules against any proposed learning goal in under ten minutes. The exercise replaces the need for another quarter-long upskilling plan. It surfaces whether the next skill actually serves the users who already show up every week.

One team I watched used the filter on an internal request to master fine-tuning. After running the rules they chose instead to deepen their understanding of retrieval-augmented generation because it let them keep source material visible to pastors who needed to verify accuracy. The narrower choice shipped in six weeks.

Another group applied the same test to a proposed ethics certification track. They realized the track would pull senior attention away from reviewing how an existing chatbot answered questions from new believers. They dropped the certification and added a weekly review of live logs instead. The change improved trust faster than any credential.

The pattern holds across both ministry and enterprise settings. Teams that treat the rules as an immediate filter move from learning to shipping while the context is still fresh. Teams that treat learning as a separate program keep rediscovering the same constraints later, at higher cost.

Your Turn: Apply This Today

• Pick one AI capability you have considered studying and run Wesley’s three rules against it in writing before the end of the week.
• Identify the single current user friction that the capability might address and test a no-code version of it inside an existing product flow this month.
• Drop any learning goal that cannot be tied to a real user constraint observed in the last thirty days.
• Schedule a thirty-minute review of live usage data instead of enrolling in the next course on your list.
• Document one instance where following the three rules caused you to abandon a promising technique and note the time saved.
• Share the filter with one teammate and apply it together to their current learning backlog before the month ends.

This approach lines up with what I have written elsewhere about treating digital discipleship as a product problem rather than a content problem. It also connects to earlier posts on choosing metrics that actually reflect mission progress instead of activity volume.

I consult with product leaders and ministry teams on AI learning constraints, product roadmapping under real user limits, and building filters that keep technical choices aligned with mission. Let’s talk.