A few months ago, I sat in a product meeting where the team was debating whether to auto-generate personalized devotionals using AI. The product argument was compelling: large user base, clear demand signal, AI capability that could theoretically produce unlimited variations. Fast follow-up, easy A/B test, obvious engagement metric to optimize.
Then someone asked: “Should we?”
That question stopped the room. Not because it was unusual for a product team to ask whether they should build something — that’s good practice in any domain. But because everyone in the room understood that this decision was carrying weight that a standard feature evaluation framework wasn’t designed to handle.
Product decisions always carry more weight than our frameworks acknowledge. We just don’t usually name it.
Why Product Decisions Are Never Just Product Decisions
The standard product evaluation framework — desirability, feasibility, viability — asks whether users want it, whether we can build it, and whether it’s sustainable as a business. Those are necessary questions. They’re not sufficient ones.
Every product decision reflects a set of beliefs about what matters, what humans need, and what technology should and shouldn’t do. Most of the time those beliefs are implicit — held but unexamined. In consumer tech, that implicit belief system usually defaults to “engagement is good, more is better, friction is the enemy.”
That works fine for some products. It’s actively harmful for others.
When you’re building products at the intersection of technology and things people care deeply about — health, relationships, learning, meaning, faith — the implicit framework fails. The question isn’t whether your belief system shapes your product decisions. It does, whether you name it or not. The question is whether you’re examining it deliberately enough to build well.
The Three Product Tensions That Require More Than Standard Frameworks
Engagement vs. Depth: Engagement metrics optimize for return frequency and session length. But for products where the goal is genuine change — learning something, growing in a practice, developing a skill — those metrics can be proxies for the wrong thing. A user who comes back every day for two-minute interactions might be getting less value than one who comes weekly for a focused 30-minute session. If your success metrics are optimized for the former, you’ll build toward it even when the latter is actually better for users.
This is the same tension the best education product designers grapple with: it’s easier to measure engagement than learning, so teams end up optimizing for engagement and calling it a proxy for learning. Sometimes it is. Often it isn’t.
Automation vs. Agency: AI makes it technically possible to automate almost any information-delivery task. The product question is when automation serves users and when it substitutes for something they’d be better off doing themselves. A navigation app that gives you turn-by-turn directions is useful. One that removes your ability to navigate independently over time might not be, even if users prefer it in the short term.
The best product teams I’ve worked with ask not just “can AI do this?” but “what does the user lose if AI does this for them, and is that a trade-off worth making?” The answer isn’t always no — sometimes automation genuinely removes unnecessary friction. But the question should be asked explicitly.
Community vs. Isolation: Features that substitute for human connection — even when users prefer them — can create long-term harm that’s hard to trace back to any single product decision. Social platforms have learned this expensively. The insight was available earlier to anyone willing to ask whether the feature was facilitating human connection or replacing it.
A Framework for the Decisions Standard Frameworks Don’t Reach
When I’m evaluating product decisions in domains where the stakes are higher than a standard desirability/feasibility/viability analysis captures, I add three questions:
Does this build or diminish user capability over time? Not just “does the user like it?” but “is the user better off — more capable, more knowledgeable, more connected — as a result of using this feature?” This is the difference between tools that augment and features that create dependency.
What is this feature implicitly telling users about what matters? Products shape behavior, and behavior shapes belief. A news app that surfaces outrage-inducing content because it drives engagement isn’t neutral about what news is for. A social platform that optimizes follower count shapes users’ implicit model of what community means. Name the implicit message your feature is sending.
Who benefits when the user keeps using this, and does that align with what’s actually good for the user? Business model alignment matters here. Products funded by engagement advertising have structural incentives to maximize usage. Products funded by outcomes their users care about have structural incentives to deliver those outcomes. The incentive structure doesn’t determine the product, but it shapes the gravity you’re working against or with.
What This Looks Like in Practice
Back to the AI-generated devotionals debate. We ended up not building the feature — at least not the way originally proposed. The concern wasn’t technical. It was that the version we could build would likely optimize for content volume and engagement breadth rather than depth and reflection. We couldn’t measure “did this change how someone thinks about their faith?” but we could measure open rates and return visits. And we knew which one we’d end up optimizing for.
Instead we built structured study guides — AI-assisted, but designed around questions that required the user to do intellectual work rather than consume content passively. Harder to build, harder to measure, probably better for users.
This kind of decision doesn’t require faith to make. It requires a belief system — a set of convictions about what the product is actually for and what good outcomes look like that goes beyond usage metrics. Every team has one, implicitly. The teams that build things worth building usually have one explicitly.
This also reshapes how you use discovery frameworks. When you’re clear about what the product is for, opportunity solution trees become more useful — because you’re not just asking “what’s the most elegant solution?” but “what’s the most aligned solution we can actually build?”
If you’re building in a domain where this kind of product ethics question surfaces — health, education, relationships, meaning — it connects directly to the paywall question: what you choose to make free reflects your beliefs about what access to your product should mean. That framework applies here too.
Your Turn: Apply This Today
Product ethics isn’t a separate track — it’s built into how you make decisions. Here’s how to start integrating it:
- Name the second-order effects of your next shipped feature. Before your next launch, run a 20-minute “impact mapping” session. Ask: who benefits from this feature? Who might be harmed, even unintentionally? What behaviors might this incentivize at scale?
- Add “who bears the cost?” to your prioritization framework. For every item on your roadmap, ask explicitly: if this creates value for some users, who absorbs the trade-off? If the answer is always the same group, you have an equity problem in your product design.
- Review your engagement metrics for manipulative patterns. Look at your most-used engagement features. Ask honestly: does this feature make users’ lives better, or does it just make them more active? There’s a difference. Know which one you’re optimizing.
- Build a “values document” for your team. Define three to five explicit values that guide product decisions when the data is ambiguous. Reference them in sprint reviews. They make it harder to rationalize decisions that feel productive but cause harm.
- Bring one ethics question to your next leadership review. Name a decision your team made in the last quarter that had an ethical dimension — and share how you reasoned through it. Normalizing the conversation is how you build organizational muscle.
- Designate a “devil’s advocate” role in major feature reviews. Before shipping anything significant, assign one person to argue the case for the user, community, or market segment that could be negatively affected. Make it a standing agenda item.
Building products in high-stakes domains where standard frameworks don’t fully cover the decision space? I consult with organizations navigating product ethics, mission-aligned product strategy, and the gap between engagement metrics and actual user value. Let’s talk.