Blog

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.

Two years ago, I was in a cramped church office helping a small tech team work through an inbox overflowing with user complaints about their digital giving platform. One email stopped me cold. A frustrated pastor had written: “I spend more time troubleshooting this than preparing my sermon.”

That line hit harder than any crash report or churn metric ever could. It wasn’t just a complaint — it was a window into exactly how badly the product was failing its core users. In that moment I saw support data for what it really is: not a burden, but the clearest possible signal about where to invest next.

Why Product Teams Treat Support Data as a Chore

Most product teams, especially in resource-constrained organizations, treat support tickets as a lagging indicator to skim at the end of a sprint — or a problem to outsource to the customer success team. I’ve been guilty of this myself. When you’re moving fast, the inbox feels like noise.

But treating support data as noise is one of the most expensive misreads a product team can make. It’s where your most motivated users — the ones who cared enough to write in — tell you exactly what isn’t working, in their own words, without anyone asking them to. You can’t buy that signal. You can only neglect it.

Charlie Munger’s inversion mental model is useful here. Instead of asking “how do we improve the product?” ask the inverse: “What would we have to do to guarantee users keep struggling?” The answer almost always lives in the support inbox. Users are already telling you. The question is whether you’re listening.

Support Data as AI Strategy Fuel

In the AI era, support data has become even more strategically valuable — and even more underused. Here’s why: AI tools are exceptionally good at pattern recognition across large text datasets. A human reviewing 500 support tickets per week might catch broad themes. An AI tool scanning those same tickets can surface micro-patterns — clusters of friction around a specific workflow step, a correlation between certain user profiles and specific failure modes, sentiment shifts that precede churn — that no human reviewer would reliably find.

I worked on a curriculum platform serving children’s ministry volunteers where the support inbox was consistently a clearer signal of product-market fit issues than any analytics dashboard we had. One pattern that kept recurring in tickets — volunteers struggling to find resources on spotty rural internet — didn’t appear anywhere in our usage data. It appeared in the inbox. When we ran that pattern through basic text clustering, we found it was the third most common friction category, affecting users we’d never targeted in our discovery work. That insight drove an offline-first redesign that meaningfully improved retention in our rural segment.

The pattern is consistent across every product I’ve worked on: the support inbox knows things your dashboard doesn’t. The teams that build systematic processes to extract and act on that signal have a durable information advantage over teams that don’t.

Building a Support Intelligence System

Turning support data into AI strategy fuel doesn’t require a sophisticated tech stack. It requires a systematic process and a commitment to treating support insights as a first-class input into product decisions — not an afterthought.

The minimum viable version looks like this: someone on the team reads and categorizes every support ticket weekly, tagging by friction type, user segment, and severity. Those categories get reviewed in sprint planning. High-frequency friction categories go on the roadmap; emerging friction patterns trigger user interview follow-up. That’s it. No AI tools required, though they accelerate the process significantly when you have volume.

The more sophisticated version adds AI-assisted sentiment analysis and clustering to your helpdesk workflow — tools like Zendesk’s AI features, Intercom’s categorization, or even a simple export into a text clustering tool. The goal is to reduce the time between “user experiences friction” and “product team knows about it and understands its scope.” The faster that loop closes, the more responsive and credible your product team becomes.

Your Turn: Apply This Today

Whether you have a mature support operation or a shared inbox that nobody owns, here’s how to start turning support data into strategic signal — this week:

• Spend 30 minutes reading raw support tickets this week — not summaries. Read them as a product leader, not as a support manager. You’re looking for the underlying need behind the surface complaint. A ticket about a confusing UI is often a ticket about a missing mental model. What is the user actually trying to do?
• Apply Munger’s inversion. Ask: “What would we have to do to guarantee users keep struggling with this?” Write down the three things your product would have to do to make the support inbox worse. Then check whether any of those things are currently true. The answers will be uncomfortable and useful.
• Tag this week’s tickets by friction type. Even a rough taxonomy — navigation, missing feature, confusing workflow, performance, trust — will reveal patterns in one week that monthly summaries miss. Do it manually first; automate later.
• Pull one raw user quote from the inbox and bring it to your next team meeting. Read it aloud. Ask the team: “What does this user actually need?” One real quote does more to align a team around user reality than three slides of aggregated survey data.
• Add support data review to your sprint planning agenda. Even five minutes — “what did the inbox tell us this week?” — changes the dynamic. Decisions made with fresh user signal are better decisions, and the habit compounds over time.
• Identify one support-informed fix you can ship in the next sprint. Not a big feature — a small, targeted improvement that directly addresses a recurring friction category. Show the team what happens when support data drives prioritization. The results build the habit faster than any process mandate will.

Support data and retention data are closely linked signals. What Retention Data Actually Tells You (And What It Doesn’t) covers how to build a complete picture of user health beyond churn numbers. And Munger’s Mental Models and AI Product Decisions goes deeper on applying inversion and other mental models to product strategy.

Trying to build better feedback loops between your users and your product team? I consult with product leaders on user research systems, data strategy, and the organizational practices that close the gap between what users experience and what gets built. Let’s talk.