The most dangerous moment in any AI product initiative isn’t the launch. It’s the planning session where someone says “let’s just try it and see what happens.” I’ve been in that room. The energy is high, the timeline is short, and constraint feels like the enemy of progress. It isn’t. Constraint is what keeps experimentation from becoming chaos.
I learned this the hard way working on a project for children’s ministry resources. We had the technical capability to use AI to auto-generate lesson plans at scale. The business case was obvious. The engineering was ready. What we hadn’t done was define what harm would look like if we got it wrong — and in a context where volunteers were trusting us with theologically sensitive material, that was the question that mattered most. We paused. We defined the guardrail. We shipped something better because of it.
Why Guardrails Accelerate AI Experimentation, Not Slow It Down
There’s a counterintuitive truth about constraint in product work: the teams that define boundaries before they start experimenting move faster than teams that don’t. Not because they’re more cautious, but because they spend less time relitigating the same decisions. Every time a team without guardrails hits an ambiguous call — “should we use this user data for this?” “is this recommendation too aggressive?” — they stop to debate it. Teams with guardrails already know the answer. The constraint bought them speed.
John Wesley’s Three Simple Rules — Do No Harm, Do Good, Stay in Love with God — were designed as a framework for community life, not product strategy. But I’ve found them to be one of the clearest models I know for scoping AI experimentation in mission-driven organizations, because they’re sequenced by priority and genuinely hard to rationalize around.
Guardrail One: Define What Harm Looks Like Before You Build
“Do No Harm” sounds obvious until you try to specify it. Harm in an AI context is surprisingly easy to overlook because it’s often diffuse, delayed, and hard to attribute. A recommendation engine that prioritizes engagement over depth doesn’t harm anyone in a visible way on day one. Over six months, it reshapes behavior in ways that may run directly against the product’s stated mission. That’s harm. It just doesn’t show up in your sprint metrics.
Defining harm specifically, before you build, forces the conversations that matter. In our children’s ministry project, the harm question surfaced a concern nobody had articulated: what happens when AI-generated content contains a theological error that a volunteer doesn’t catch? That’s a trust problem, not just a content quality problem. We added a human review gate. The product shipped later and was far more trusted by the volunteers who used it.
For your context, harm might be data privacy for members, cultural insensitivity in generated content, algorithmic bias in which users get which experiences, or recommendations that drive the wrong behaviors. The form it takes is specific to your product and your users. Name it explicitly in your feature spec before engineering starts.
Guardrail Two: Measure “Doing Good” Before You Claim It
“Do Good” is the guardrail most product teams think they’ve already cleared. They haven’t — they’ve assumed it. There’s a meaningful difference between “this feature is directionally good for users” and “this feature measurably improves a specific outcome for a specific user in a way we can verify.” The first is a hypothesis. The second is a product decision.
I’ve watched teams deploy AI features in faith-tech contexts — sermon prep tools, discipleship engagement nudges, content recommendation engines — that were built with genuinely good intentions and produced genuinely mixed results. Not because the technology was wrong, but because “doing good” was never defined precisely enough to know whether the feature was achieving it. Usage metrics went up. Whether people’s engagement with faith deepened was never measured. That’s a guardrail that was never set.
Before any AI feature ships, I want a one-sentence definition of what “doing good” means in measurable terms: “Users who engage with this feature will [specific behavior] at [measurable rate] within [time window].” If the team can’t write that sentence, the feature isn’t ready to build.
Guardrail Three: Stay Grounded in the Mission When the Hype Pulls You Away
“Stay in Love with God” — translated for product teams — means staying grounded in the specific mission that justifies the product’s existence, especially when vendor pitches and industry trends are pulling you toward shiny features that have nothing to do with it. This is harder than it sounds in 2026. The AI capability landscape changes fast enough that every quarter there are new things your product “could” do. The question is whether doing them serves the people you’re actually building for.
I’ve been in strategy sessions where the room spent an hour excited about a generative AI capability that had no clear connection to user outcomes. The capability was impressive. The use case was thin. The right move was to say no — not because the technology was bad, but because chasing it would have consumed engineering cycles that belonged to the actual problem the product existed to solve.
This guardrail is a practice, not a policy. It requires someone in the room willing to ask “how does this directly serve our users?” without apologizing for slowing the conversation down. Usually that person is the product leader. Make it a habit.
Your Turn: Apply This Today
Before your next AI feature enters the roadmap, run it through these three guardrails explicitly — not as a checklist to complete, but as questions that need honest answers:
- Define harm for your specific context in writing. For the AI feature currently in planning, name the two or three ways it could harm users if it doesn’t work as intended. Data exposure, bad recommendations, eroded trust, misrepresented information — whatever is relevant. Add this to the feature spec. If you can’t name the harm, you haven’t thought about it carefully enough yet.
- Write the “doing good” sentence before scoping data requirements. “Users who engage with this feature will [behavior] at [rate] within [timeframe].” If your team can’t complete that sentence in one working session, the feature definition isn’t ready. This conversation is cheaper than a sprint of building in the wrong direction.
- Put your mission statement in the room when you make AI prioritization decisions. Literally — write it on the whiteboard or put it in the meeting doc. When a new AI capability comes up, the first question is “how does this serve [mission]?” Features that can’t answer that question belong in a backlog, not the current sprint.
- Say no to one trending AI feature this quarter. Not because it’s bad, but as practice. Find one thing your team has been considering because it’s interesting or because a competitor shipped it, and explicitly decline it because it doesn’t clear your guardrails. Document the decision. This builds the muscle of constraint before you need it for a harder call.
- Run a 30-minute team session this week using the three guardrails. Pick your current highest-priority AI initiative and put it through all three questions as a group. Where do people disagree? That disagreement is useful data about misaligned assumptions that would have surfaced at the worst possible time if you hadn’t surfaced it now.
- Interview three users about what “harm” and “help” look like from their perspective. Your internal definition of both will be incomplete without user input. Ask: “What would this product have to do to lose your trust?” and “What would genuinely change your week for the better?” Their answers will sharpen all three guardrails faster than internal debate will.
The constraint framework connects directly to how you define AI features in the first place. Why Your AI Feature Doesn’t Need More Data — It Needs Better Problem Definition addresses how to scope AI work before you start building. And Agency Isn’t Enough: Why AI-Era Product Teams Need Constraint Over Freedom covers the organizational dynamics that make guardrails hard to maintain under pressure.
Working through how to structure your team’s AI experiments so they stay grounded in mission and user outcomes? I consult with product leaders and ministry innovators on constraint-driven AI strategy, feature scoping, and the organizational habits that keep AI investment pointed at the right problems. Let’s talk.