Last month, I sat in a church basement with a tech team lead drowning in AI tools. He had a dozen browser tabs open, each promising to automate something — sermon prep, small group scheduling, follow-up emails. His face was pure frustration. “I can do anything with these,” he said. “But I have no idea what I should do.”
I’ve heard variations of that sentence from product leaders at organizations far beyond church tech. The promise of AI is unbounded capability. The reality is that unbounded capability without constraint produces paralysis, not progress. Giving a team agency over a blank canvas doesn’t produce great work — it produces anxiety. The teams that are actually moving forward with AI aren’t the ones with the most freedom. They’re the ones with the clearest guardrails.
Why Too Much Freedom Is a Product Problem
There’s a well-documented psychological pattern here: when options multiply, decision quality degrades. Barry Schwartz called it the paradox of choice. The same dynamic that makes consumers freeze in front of 47 varieties of salad dressing also makes product teams stall when handed AI capabilities with no defined scope.
I’ve watched product teams spend entire quarters “exploring AI possibilities” — building demos, attending workshops, writing strategy documents — without shipping a single user-facing improvement. The exploration felt productive. The output wasn’t. And the root cause wasn’t lack of skill or motivation. It was the absence of a constraint that forced a decision.
Constraint isn’t the opposite of agency. It’s the container that makes agency useful. A product manager with agency and no constraint is a sculptor with clay and no deadline. A product manager with agency and clear constraint is a sculptor with clay, a deadline, and a specific brief. The second one ships.
Wesley’s Three Rules as a Product Constraint Framework
John Wesley’s Three Simple Rules — Do No Harm, Do Good, Stay in Love with God — were written as a framework for Methodist community life in the 18th century. I’ve found them to be a surprisingly clean model for AI product constraints, particularly because they’re sequenced by priority and genuinely hard to game.
“Do No Harm” maps directly to the first constraint every AI product decision should clear: are we breaking anything? Are we introducing complexity that frustrates users who didn’t ask for it? Are we shipping a feature that serves the roadmap more than it serves the user? The discipline of asking “what harm could this cause?” before shipping has stopped more bad ideas on my teams than any review process.
“Do Good” maps to the second constraint: is there measurable user benefit? Not “this is technically impressive” or “this will differentiate us in demos.” Actual user benefit, with a metric attached. I’ve watched teams get seduced by generative AI for content creation, spend months iterating on algorithms, and launch to crickets — because they never defined what “doing good” for the user actually looked like in this context.
“Stay in Love with God” — secularized, this becomes “stay grounded in mission.” AI hype can pull organizations away from the thing they exist to do. I’ve been in strategy meetings where the room buzzed about “transformative AI roadmaps” while the core problem — equipping the people the product is supposed to serve — got lost. Constraint means refusing to drift with every AI trend, and anchoring back to the specific outcome that justifies the product’s existence.
Constraint as a Design Principle, Not a Limitation
The reframe that helps teams most: constraint isn’t what you can’t do. It’s what you’ve decided to do first. A constraint says “this quarter, we’re only using AI to address user friction in the onboarding flow” — not because other AI applications don’t matter, but because focus produces better outcomes than breadth. You can revisit the other applications next quarter. You can’t revisit the quarter you spent spinning.
Teams that build constraint-first AI strategies share a few common habits: they define their AI investment in terms of specific user outcomes before selecting tools, they set explicit scope boundaries for each AI experiment, and they treat “we should also try X” as a backlog item rather than a current sprint addition. These habits sound bureaucratic until you see what the alternative produces — which is usually a lot of demos and very little improvement in the metrics that matter.
Your Turn: Apply This Today
If your team has been in “AI exploration mode” without clear traction, here’s how to apply constraint thinking and start moving:
- Run every current AI initiative through the “Do No Harm” filter. For each active experiment, ask: who could this hurt, confuse, or frustrate — and are we certain that’s not happening? If you can’t answer that question with evidence, the experiment isn’t ready to ship.
- Define “Do Good” in measurable terms before the next sprint. Write one sentence per AI initiative: “We’ll know this is working when [specific user behavior or metric] changes by [amount] in [timeframe].” Initiatives that can’t complete that sentence don’t belong in the current sprint.
- Do a mission audit on your AI roadmap. List every AI initiative your team is working on. For each one, answer: how does this directly serve the specific outcome that justifies this product’s existence? Items that can’t answer that question are candidates for the backlog, not the sprint.
- Set one explicit scope constraint this quarter. Not a theme — a boundary. “This quarter, AI investment is limited to reducing time-to-value in our onboarding flow.” Decide what’s out of scope and write it down. Teams that know what they’re not doing are faster than teams that can do anything.
- Build a “next quarter” list. Every time someone says “we should also try [AI thing],” add it to a visible next-quarter list rather than the current backlog. This preserves the idea without letting it dilute the current focus. The list becomes a gift to your future self at quarterly planning.
- Review your constraint at the end of each sprint. Ask: did this constraint help us make better decisions, or is it the wrong constraint? Constraints should be reviewed, not assumed. The goal isn’t rigidity — it’s focus. If the constraint is pointing your team at the wrong problem, change it.
Constraint thinking 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 covers how to scope AI work before you start building. And Three Rules for AI Prompt Design: John Wesley’s Constraint Framework applies the same Wesley framework specifically to prompt engineering discipline.
Working through how to focus your team’s AI investment and stop spinning on exploration without outcomes? I consult with product leaders on AI strategy, constraint frameworks, and the organizational habits that turn AI capability into shipped product impact. Let’s talk.