The Age of Abundance (and Uncertainty)
When everything becomes possible, the hardest question is not “Can we build it?” but “Should we?”
For decades, Product Managers have operated within the familiar triangle of Usability, Feasibility, and Viability. These three competencies defined the role. Can users accomplish their goals? Can engineering build it? Can we sustain a business? The questions were clear, even if the answers weren’t always easy.
AI changes everything. Not by making these competencies obsolete, but by fundamentally rebalancing them. When you’re building AI functionality into your product, feasibility stops being a bottleneck and becomes an abundance problem. Usability shifts from helping users do things to deciding how much the AI should do for them. Viability expands beyond revenue and costs to include reputational risk and ethical responsibility.
And that’s not all. A fourth pillar emerges: Responsibility. It’s always been there, lurking in legal and compliance conversations, but AI forces it front and center. You can’t build AI products without grappling with bias, safety, transparency, and harm.
This article is for Product Managers who are considering adding AI functionality to their products. Not for those building AI infrastructure or foundation models, but for the majority of PMs who need to decide whether their product should use AI, and if so, how.
Competency #1: The Collapsing Feasibility Constraint
A shift needs to happen:
From: “What’s technically possible given our constraints?”
To: “What should we build when almost anything is possible?”
The paradox of AI feasibility is this: the more technically possible things become, the harder your job gets. When the answer to “Can we build this?” is almost always “Yes,” you lose the natural filter that technical constraints provided. Now you have to be the filter.
What Changes
Feasibility is no longer a bottleneck—it’s an abundance problem. You can integrate natural language interfaces, generate content, analyze sentiment, extract insights, automate workflows, and personalize experiences. The question shifts from “Can we?” to “Which of these hundred possible features actually matter?”
Technical debt evolves into AI debt. You are no longer just managing code dependencies. You are managing model dependencies, API versions, token limits, and latency requirements. When Anthropic releases Claude 5 with better capabilities, do you refactor your prompts? AI debt compounds differently than technical debt, and it moves faster.
The build-vs-buy decision framework expands. It’s no longer just “build custom or buy off-the-shelf.” Now it’s build custom models, fine-tune existing models, use context engineering with foundation models, or skip AI entirely. Each option has different cost structures, maintenance burdens, and capability trade-offs.
What PMs Need to Do
Master the art of strategic restraint. Not every problem needs an AI solution. In fact, most don’t. Traditional solutions are often faster, cheaper, more reliable, and easier to maintain. Your job isn’t to find places to insert AI. It’s to identify the specific problems where AI genuinely creates value that traditional approaches can’t match.
Develop feasibility literacy. You don’t need to become an ML engineer, but you need to understand what LLMs can and can’t do. Know the difference between classification and generation. Understand when fine-tuning makes sense versus when context engineering is sufficient. Recognize the limits of current models so you don’t promise capabilities that don’t exist.
Create clear decision frameworks. Build a structured way to evaluate when to build custom, when to fine-tune, when to use context engineering, and when to skip AI entirely. This framework should consider cost, maintenance burden, performance requirements, and strategic importance. Without it, you’ll make inconsistent decisions based on whoever shouts loudest.
(I offer a decision-making framework in my book “AI for Product Managers”).
Who to Collaborate With
ML Engineers and AI Engineers help you understand what’s truly feasible versus what’s hype. They can tell you when a feature would require custom model training versus when you can achieve it with clever prompting. They understand the performance characteristics and limitations that you need to factor into your decisions.
DevOps and MLOps teams are your reality check on deployment and operations. They’ll tell you about inference costs, latency requirements, model versioning, and monitoring needs. They understand what it actually takes to run AI in production, not just in a demo.
Engineering leadership sets guardrails on tech debt and dependencies. Work with them to establish principles around model dependencies, fallback strategies, and acceptable levels of AI debt. These conversations prevent you from creating a house of cards that collapses when a foundation model changes.
AI Ethics teams bring a new dimension to feasibility decisions. Just because you can build something doesn’t mean you should. They help you identify scenarios where technical feasibility exists but ethical feasibility doesn’t. This collaboration needs to happen early, not after you’ve already committed to a technical direction.
Anti-Pattern: The “Everything Is an AI Problem” Trap
The most common mistake PMs make with AI feasibility is treating it like a hammer looking for nails. They try to shoehorn AI into features where traditional solutions would be better, faster, and more reliable.
Examples: Using an LLM to classify support tickets into five predefined categories when a simple rule-based classifier would be faster, cheaper, and more accurate. Or building a natural language interface for a workflow that users actually prefer to control through explicit UI elements.
The trap is seductive because AI feels innovative. But innovation for innovation’s sake isn’t product management. Your job is to solve real problems in the most effective way possible. Sometimes that means AI. Often it doesn’t.
Competency #2: The Usability Paradox, Agency vs. Automation
A shift needs to happen:
From: “Can users accomplish their tasks?”
To: “How much should AI do FOR users vs. WITH users?”
Traditional usability was about removing friction. You wanted users to accomplish their goals as quickly and easily as possible. The metrics were clear: task completion rates, time on task, error rates. The questions were straightforward.
AI usability is different. Now you’re not just removing friction—you’re deciding how much agency to preserve. Do you automate the entire workflow or give users control at key decision points? Do you show them how the AI reached its conclusion or just present the result? These aren’t just UX questions. They’re questions about trust, control, and what it means for something to be usable.
What Changes
Usability now includes AI UX—transparency, control, and trust become primary considerations. Users need to understand what the AI is doing, why it’s doing it, and how to intervene when it’s wrong. This isn’t optional. Without these elements, users won’t trust the AI, and without trust, they won’t use it.
Non-deterministic behavior breaks traditional usability testing. When you test a button, it behaves the same way every time. When you test an AI feature, it might respond differently to the same input. How do you validate usability for something that’s inherently variable? Your testing methodologies need to account for this uncertainty.
User research must probe deeper questions. It’s not enough to ask if users can accomplish their tasks. You need to understand whether they feel empowered or replaced. When do they want to delegate and trust the AI? When do they want to maintain control? These preferences vary by context, user expertise, and stakes of the decision.
What PMs Need to Do
Map the agency spectrum for every AI feature. Where does the AI assist, where does it automate, and where does it replace human judgment? A support ticket routing system might fully automate for simple requests but only assist for complex ones. An AI writing tool might suggest edits rather than making them automatically. Be explicit about these boundaries.
Design for transparency. Users should understand what the AI is doing, not just what it outputs. This doesn’t mean exposing model internals, but it does mean providing context. Why did the AI make this recommendation? What data did it consider? What confidence level does it have? Transparency builds trust.
Create guardrails UX—clear mechanisms for users to correct, override, or intervene. The AI will be wrong sometimes. When it is, users need easy ways to fix it. This might be an undo button, an edit mode, or a feedback mechanism. Without these guardrails, users feel powerless when the AI makes mistakes.
Test probabilistically. Accept that AI features behave differently each time and design your testing accordingly. Instead of testing whether the AI gives the right answer, test whether it gives acceptable answers within an expected range. Define what “good enough” looks like and measure against that distribution.
Who to Collaborate With
UX Researchers need to develop new research methods for AI products. Traditional usability testing doesn’t capture the nuances of AI interaction. Work with them to create research protocols that account for non-deterministic behavior, measure trust over time, and understand when users want agency versus automation.
UX/UI Designers are your partners in designing for uncertainty, transparency, and user control. They’ll help you visualize AI confidence levels, create intuitive override mechanisms, and build interfaces that adapt to the probabilistic nature of AI. This is new territory for most designers, so expect iteration.
Context Engineers shape the AI’s personality and response patterns. The tone, style, and behavior of your AI directly impact usability. A customer service AI needs different context engineering than a creative writing tool. Collaborate closely to ensure the AI’s behavior matches user expectations.
Accessibility specialists help you understand how AI can exclude users in new ways. AI features might work well for native English speakers but fail for others. They might assume visual ability or specific cognitive patterns. Make accessibility part of your AI usability conversations from the start.
Anti-Pattern: The Invisible AI Problem
The worst usability mistake with AI is making it invisible. You build AI features without clear transparency, leaving users confused about what’s AI-powered and what’s not. They don’t know when to trust the output, how the AI made its decision, or how to intervene when it’s wrong.
Example: An email client that uses AI to categorize messages but doesn’t indicate which categories were AI-generated versus user-created. Users trust the categories implicitly, then get frustrated when they’re wrong, not realizing they can correct the AI’s mistakes.
Transparency isn’t about exposing complexity. It’s about giving users enough context to make informed decisions. When AI is invisible, users can’t build accurate mental models. Without accurate mental models, they can’t use the AI effectively. The solution is clarity, not obscurity.
Competency #3: The Viability Evolution, Ethics Enters the Business Model
A shift needs to happen:
From: “Can we build a sustainable business?”
To: “Can we build a sustainable AND responsible business?”
Traditional viability was about unit economics, customer acquisition costs, and revenue projections. You modeled scenarios, built financial cases, and presented them to stakeholders. The numbers either worked or they didn’t.
AI viability adds new dimensions. Yes, you still need the unit economics. But now you also need to model reputational risk. What happens if your AI gives bad advice? What if it discriminates? What if it becomes a PR disaster? These risks are real, quantifiable, and can destroy more value than your revenue projections ever created.
What Changes
The cost structure changes fundamentally. Traditional software had predictable scaling costs. AI products don’t. You are paying for inference costs that vary with usage patterns, model complexity, and token counts. You are paying for model training or fine-tuning. You are paying for higher latency infrastructure. Your cost per transaction might be 10-100x higher than equivalent traditional features.
Viability expands beyond revenue and costs to include reputational risk, regulatory risk, and ethical risk. A single high-profile AI failure can tank your company faster than missing revenue targets. The “move fast and break things” mentality doesn’t work when breaking things means harming users or violating regulations.
But you still need to prototype and validate rapidly. The solution isn’t to move slowly—it’s to move thoughtfully. Build-in safeguards from the start. Test for edge cases and failure modes. Have kill switches ready. Rapid iteration is still possible, but it requires more planning and different risk management.
What PMs Need to Do
Build viability models that include reputational risk and regulatory exposure. Don’t just model the upside scenarios. Model what happens when the AI fails publicly. Model the cost of regulatory fines. Model the impact on brand trust. These aren’t hypotheticals—they’re real costs that need to be factored into your business case.
Understand AI economics deeply. Know your token costs, latency requirements, and model pricing structures. Understand that these costs are variable and can spike unexpectedly. Plan for model price changes, API rate limits, and compute availability issues. Your financial models need to account for this volatility.
Create ethical viability frameworks. Before launching any AI feature, ask: What happens if this behaves badly? What’s our response plan? Can we detect problems quickly enough? Can we roll back or disable features rapidly? These aren’t nice-to-haves. They’re core viability questions.
Plan for model obsolescence. GPT-5, Claude 5, whatever comes next—these future models will change the game. They’ll be more capable, cheaper, or both. Your product strategy needs to account for rapid capability evolution. Don’t lock yourself into today’s model limitations.
Establish evaluations early and monitor performance over time. Define what good performance looks like before launch. Build automated evaluations that run continuously. Track drift, accuracy, and user satisfaction. Without ongoing monitoring, you won’t know when your AI starts degrading until users complain loudly.
Who to Collaborate With
Finance and Business Operations help you build accurate cost models and ROI calculations that account for AI’s unique economics. They’ll help you understand the true cost per transaction, model scenarios around pricing changes, and create financial projections that account for volatility.
Legal and Compliance teams are essential for understanding regulatory requirements. GDPR, the EU AI Act, sector-specific regulations—these all impact what you can build and how. Involve legal early, not when you’re ready to launch.
Trust and Safety teams help you understand risk exposure. They think about harm scenarios, content moderation, and abuse patterns. They’ll identify risks you haven’t considered and help you build appropriate safeguards.
AI Ethics and Responsible AI teams assess ethical viability. They help you think through fairness, bias, and broader societal impact. They’re not there to say no to everything—they’re there to help you build responsibly.
Customer Success teams understand how AI impacts customer relationships. They’ll tell you when AI features delight customers and when they create friction. They’ll see patterns in support tickets that indicate AI problems before your metrics do.
The Validation Crisis
How do you validate feasibility when foundation models change every six months? You can’t. Traditional product planning assumes stable technology. AI products don’t have that luxury. The models you use today will be obsolete next year. New capabilities will emerge that invalidate your technical decisions.
How do you prove ROI when costs are variable and capabilities evolve? You build ranges, not point estimates. Model best case, worst case, and likely scenarios. Plan for cost volatility. Build flexibility into your commitments.
How do you plan a roadmap in an environment of radical uncertainty? You work in shorter cycles. You build with loose coupling to specific models. You design for replaceability. You accept that your roadmap will change and build organizational processes that support rapid pivots.
Anti-Pattern: The Build-First Ethics-Later Approach
The most dangerous viability mistake is launching AI features without considering harm scenarios. You build fast, ship quickly, and plan to iterate based on feedback. Then your AI gives someone dangerous medical advice, or discriminates against protected groups, or creates a PR nightmare.
Example: A hiring AI that optimizes for candidate quality without considering fairness metrics. It works great in testing, ships to production, and six months later you discover it systematically disadvantages certain demographic groups. The lawsuits, fines, and reputational damage dwarf any efficiency gains.
The solution isn’t to move slowly. It’s to build ethical considerations into your development process from day one. Think about harm scenarios during design. Test for them before launch. Monitor for them in production. Ethics can’t be an afterthought.
The Fourth Competency: Responsibility
The three competencies of Usability, Feasibility, and Viability don’t account for the unique risks of AI. They assume that if something is usable, feasible, and viable, it’s ready to ship. With AI, that’s not enough.
Responsibility sits at the intersection of all three competencies. More than a separate competency, I think it is a lens through which you evaluate feasibility (Can we build this responsibly?), usability (Will users understand and trust this?), and viability (Can we manage the risks?).
This is where many PMs are least prepared. You’ve spent years honing your skills in user research, technical evaluation, and business modeling. Suddenly you’re expected to think about bias, fairness, safety, and societal impact. It’s uncomfortable, but it’s necessary.
What This Includes
Bias and fairness: Does your AI treat all users equitably? Does it perpetuate or amplify existing biases? These aren’t just moral questions—they’re legal and business questions.
Privacy and data governance: What data does your AI use? How is it stored and protected? What are users’ rights regarding their data? GDPR isn’t optional.
Safety: What if the AI gives dangerous advice? What if it’s manipulated by bad actors? What failure modes exist? Medical, financial, and safety-critical applications have especially high stakes. Do we need huma-in-the-middle judgment?
Transparency and explainability: Can users understand how the AI reaches decisions? Can they challenge those decisions? In many contexts, black-box AI isn’t acceptable.
Environmental impact: Training and running AI models consumes significant energy. This has real environmental costs that factor into responsible deployment decisions.
Who Owns This?
Here’s the uncomfortable truth: it’s often unclear who owns AI responsibility. Is it the PM? Engineering? Legal? Ethics team? The answer varies by company and often by feature.
The better question is: Who should own it? The answer is everyone, with the PM as orchestrator. You don’t need to be an ethics expert. You don’t need to understand all regulatory nuances. But you need to know when to escalate, who to involve, and how to facilitate decisions.
Think of yourself as a conductor. You don’t play every instrument, but you ensure they all play in harmony. You bring together ethics teams, legal, engineering, and domain experts. You create space for these conversations. You ensure responsible AI isn’t an afterthought.
(Tip: invite legal/ethics/compliance partners to your “Refinement Meetings” as you ideate and refine the solution you are building)
Who to Collaborate With
AI Ethics or Responsible AI teams, if your company has them, provide frameworks and guidance. They’ll help you think through harm scenarios, evaluate fairness, and design responsible features.
Data Privacy Officers ensure compliance with data protection regulations and help you design features that respect user privacy.
Security teams think about adversarial scenarios—how bad actors might exploit or manipulate your AI features.
Legal and Compliance teams understand the regulatory landscape and potential liabilities.
Domain experts in healthcare, finance, education, or whatever sector you’re in understand the specific risks and requirements of your industry.
The PM role is evolving
You are no longer just the person who decides what to build. You are the person who orchestrates how decisions get made across a much larger and more diverse set of stakeholders.
You are coordinating two to three times more stakeholders than before. ML engineers, context engineers, AI ethics specialists, MLOps teams—these are roles that didn’t exist or weren’t relevant to product decisions five years ago. Cross-functional doesn’t begin to describe it.
The skills you need are changing too. Facilitation and conflict resolution become critical because more stakeholders means more disagreement. You need just enough knowledge across all domains to be effective, but you can’t be the expert on everything. Most importantly, you need humility. The era of the PM as sole decision-maker is over.
Building Your Decision Framework
Every PM needs a decision framework to assess the Feasibility, Usability, and Viability of AI products. You can’t evaluate every opportunity from first principles. You need structure.
One useful tool is the 3 Dimensions of AI Products framework, which assesses the benefits your AI product provides across three dimensions: Accelerate (does it make users faster?), Expand (does it enable new capabilities?), and Simplify (does it reduce complexity?). Strong AI products typically excel in at least two of these dimensions.
(For a free download of the Canvas, visit my website at https://www.5dvision.com/post/the-3-dimensions-of-ai-products/ )
In Conclusion
The three competencies haven’t been replaced—they’ve been rebalanced. Feasibility is now about restraint as much as capability. Usability is about agency as much as ease. Viability is about responsibility as much as revenue.
The fourth competency—Responsibility—is non-negotiable. You can’t outsource it to ethics teams or legal. It needs to be integrated into how you think about every feature, every decision, every trade-off.