As a Product Manager, your highest leverage isn't in shipping features; it's in killing the wrong ones before they consume a single engineering cycle. The entire decision boils down to two questions you must answer with data-backed authority: Can we build this? And should we build this? This is the core of feasibility vs viability.
- Feasibility (The 'Can We?'): This is the technical and operational gut check. Do we have the engineering talent, the right tech stack, the APIs, and the infrastructure to pull this off within a reasonable timeframe and budget?
- Viability (The 'Should We?'): This is the brutal business reality check. Is there a real market for this? Will it generate a positive ROI? Does it align with our strategic goals, or is it a distraction?
Mastering this distinction is what separates junior PMs who manage backlogs from senior leaders who drive business outcomes. Your job is to be the disciplined gatekeeper, protecting company resources from "brilliant-but-bankrupting" ideas. This framework isn't just theory; it's the operational playbook for making high-stakes product decisions at companies like Google, Meta, and Stripe.
The PM's Action Framework: Feasibility vs Viability
Your credibility as a PM lives and dies by your ability to differentiate a technically possible project from a strategically sound one. A study by the Project Management Institute (PMI) shows that robust upfront analysis can boost project success rates by over 30%. This isn't a "nice-to-have"; it's a competitive necessity.
The development methodology you use—whether you're debating Agile vs Waterfall methodologies—directly impacts how you assess these factors. Agile allows you to test viability in small, iterative loops, while Waterfall requires a massive upfront feasibility study before a single line of code is written.
To give you an immediate tool you can apply in your next roadmap planning session, here is a quick-reference framework. Use this to structure your thinking and your conversations with stakeholders. For a deeper dive into how this fits into the broader discovery process, read our guide on balancing agility and effectiveness in product discovery.
Quick-Reference Framework: Feasibility vs. Viability
| Attribute | Feasibility Analysis ('Can We Build It?') | Viability Analysis ('Should We Build It?') |
|---|---|---|
| Core Question | Is this technically and operationally possible with our current resources, skills, and timeline? | Does this solve a valuable customer problem in a way that aligns with our business model and creates sustainable profit? |
| Primary Focus | Technology stack (e.g., Python, React), infrastructure (e.g., AWS, GCP), team skills, legal/compliance hurdles, and timeline. | Market size (TAM/SAM/SOM), ROI, LTV:CAC ratio, pricing strategy, competitive landscape, and strategic alignment. |
| Key Metrics | Engineering story points, required server capacity (e.g., EC2 instance types), compliance checklists (e.g., GDPR, CCPA), API latency. | Profit margin, market share growth, customer retention rate, revenue per user, payback period. |
| Key Stakeholders | Engineering Lead, DevOps/SRE, Legal Counsel, Security Lead. | Head of Finance (CFO), CEO, Head of Marketing, Sales Director, Head of Product. |
| Success Indicator | The product is built on time, on budget, and meets technical specifications without accumulating significant tech debt. | The product achieves product-market fit, reaches profitability, and contributes to the company's long-term strategic goals. |
| Example Blocker | "Our current monolith architecture can't support this service; it requires a full migration to microservices." | "The projected Customer Acquisition Cost of $500 is higher than the Lifetime Value of $450, making this unprofitable at scale." |
This table isn't just a definition; it's a conversation guide. It separates the execution mindset from the market mindset, helping you ensure both are thoroughly vetted.
As a PM, you are the translator. You must translate the business needs driving viability into concrete technical requirements for your engineering team, and then articulate technical constraints from feasibility back into business trade-offs for your leadership team.
How to Conduct a Technical Feasibility Assessment
A proper feasibility assessment is where your product vision collides with reality. Your role as a PM isn't to be a software architect, but you must lead a structured, rigorous inquiry that forces your technical team to move from a vague "it's possible" to a confident "yes, here are the costs and risks" or a well-justified "no, and here's why."
Get this wrong, and you're not just greenlighting a project; you're committing your team to months of painful delays, budget overruns, and a mountain of tech debt that will cripple future velocity. To understand the long-term cost of these early decisions, you need to grasp how to manage technical debt in your product.
Actionable Checklist for Your Next Feasibility Review
Use this checklist to run a structured technical review with your Engineering Lead. This isn't just about code; it's about the entire ecosystem required to build, deploy, and maintain this feature.
1. Technical Resources & Skillset: Do we have the right people and tools?
- Team Expertise: Does our current team have senior-level experience with the required stack (e.g., Go for high-concurrency services, Kotlin for modern Android development)? If not, what's the hiring/training cost and timeline?
- Tech Stack Compatibility: Will this require a new database technology or microservice? How will it integrate with our existing CI/CD pipeline and monitoring tools like Datadog?
- Third-Party Dependencies: Are we relying on an external API (e.g., Stripe for payments, Twilio for messaging)? What are their documented rate limits, uptime SLAs, and pricing tiers at our projected scale? Have we vetted their security compliance?
2. Operational & Infrastructure Capacity: Can our systems handle this?
- Scalability: What is the projected load increase on our core databases and services? Does this require a major infrastructure upgrade (e.g., moving from AWS EC2 T3 instances to compute-optimized C5 instances)?
- Data Pipelines: Does this feature generate or require new data streams? Can our current ETL/ELT pipelines in Airflow or dbt handle the volume and velocity without collapsing?
- Support & Maintenance: Who will be on-call for this new service? What new alerts and dashboards need to be built? What is the estimated ongoing maintenance cost in engineering hours per quarter?
3. Legal, Security & Compliance: What are the hidden deal-breakers?
- Data Privacy: Are we processing Personally Identifiable Information (PII)? Does the architecture adhere to GDPR's data minimization principle and CCPA's user rights requirements? Has our legal team signed off?
- Intellectual Property: Are we using open-source libraries? We must verify their licenses—using a library with a GPL license in a proprietary product has massive legal implications compared to one with an MIT license.
- Security Vulnerabilities: Does this feature introduce new attack vectors (e.g., file uploads, new API endpoints)? Has a preliminary security review been conducted to check for common risks like SQL injection or XSS?
A feasibility assessment is a collaborative diagnostic, not an interrogation. Your role is to ask probing questions that uncover the "unknown unknowns." The output must be a clear-eyed document outlining the effort, risks, and trade-offs in terms of time, money, and people.
Building the Business Case for Product Viability
A technically flawless product that fails to make money is a beautifully engineered waste of time. After confirming your team can build something, your more critical job is to prove the business should build it. This means moving beyond user stories and building a business case grounded in financial models that your CFO will respect.
A credible viability analysis isn't based on optimism. It's a systematic de-risking of the market, cost, and revenue assumptions. This isn't about getting your project approved; it's about ensuring your product becomes a sustainable engine for the company's growth.
Core Components of a Viability Business Case
To build a case that survives scrutiny from leadership, you need to model the business from every angle. This is where top PMs get comfortable with spreadsheets and financial modeling.
Here are the essential pillars:
- Market Sizing (TAM, SAM, SOM): You must quantify the opportunity. What’s the Total Addressable Market (TAM)? From there, what is the Serviceable Available Market (SAM) that your product and sales model can realistically reach? And most importantly, what is the Serviceable Obtainable Market (SOM) you can capture in the first 1-3 years? Use market reports from Gartner or Forrester to back up your numbers.
- Pricing and Revenue Model: How will this make money? Be specific. Is it a per-seat subscription model, usage-based billing, a one-time transaction, or a freemium model? Justify your price point with competitive analysis and customer value metrics.
- Cost Analysis (COGS & CAC): A full cost picture is non-negotiable. This includes Cost of Goods Sold (COGS)—like server costs, third-party API fees, and support staff salaries—and the Customer Acquisition Cost (CAC), including marketing spend and sales commissions.
- Profitability Projections (LTV, ROI, Payback Period): This is the ultimate test. Is the projected Lifetime Value (LTV) of a customer at least 3x your CAC? What is the expected Return on Investment (ROI) of the project over 3 years? And what is the Payback Period—how many months until the initial investment is recouped?
From Short-Term Revenue to Sustainable Profitability
A common trap for junior PMs is mistaking a short-term revenue pop for long-term viability. A new feature might drive initial sales, but if it has high maintenance costs or erodes your core value proposition, it's not truly viable.
To model this accurately, Mastering Excel financial formulas like NPV and IRR is an essential skill for senior PMs. Net Present Value (NPV) and Internal Rate of Return (IRR) are the tools you use to compare the long-term profitability of different strategic investments.
Consider a SaaS company like Salesforce launching a new AI-powered feature, "Einstein Copilot." They wouldn't just project new subscription revenue. Their viability model would meticulously account for the immense ongoing costs of GPU servers from NVIDIA and the salaries of scarce AI talent. By comparing the projected LTV of an enterprise customer upgrading to this tier against the sustained operational costs, they prove its long-term profitability and defend the investment to the board.
A viable product isn’t just one customers will pay for. It’s one the business can afford to build, market, and support profitably over its entire lifecycle.
This is precisely why you start with an MVP. Analyzing famous minimum viable product examples like Dropbox or Zappos shows how they tested viability with minimal investment. They gathered real-world data on customer demand and willingness to pay before committing to a massive, high-feasibility build-out.
Finding the Sweet Spot: The Feasibility vs Viability Matrix
The best products—the ones that define careers and categories—live at the intersection of what is technically possible and what is commercially profitable. Your role as a product leader is to be the steward of this intersection, ruthlessly prioritizing resources toward initiatives that deliver real business impact.
Getting this balance wrong is catastrophic. Juicero, the infamous $400 Wi-Fi juicer, was a masterpiece of engineering—it was highly feasible. But it was commercially absurd—it had zero viability. The market rejected the value proposition, and the company became a Silicon Valley punchline.
Conversely, an idea can be hugely viable but not yet feasible. Commercial space tourism was a viable concept for decades, promising immense profits. But the technology (reusable rockets pioneered by SpaceX) wasn't feasible until very recently.
Visualizing the Trade-Offs
To steer your team away from building the next Juicero, you must master the art of visualizing trade-offs. The chart below contrasts two potential approaches for a new feature, illustrating how a purely feasible path differs from a viable one.
The "Feasible" approach looks tempting with its low initial cost and quick timeline. But the "Viable" approach, while requiring more upfront investment, is the only one that delivers a meaningful return and justifies the use of company resources.
The Prioritization Decision Matrix: Your Actionable Tool
Gut feelings don't survive roadmap meetings with executives. You need a simple, data-driven framework to evaluate initiatives. This decision matrix is a powerful tool for scoring projects and forcing an objective discussion with your stakeholders.
How to Use It:
Score each initiative on a scale of 1 to 5 for both feasibility and viability.
- Feasibility Score (1-5): How easily can we build this with our current team, tech, and budget? (1 = Major R&D needed, 5 = We can ship this next sprint).
- Viability Score (1-5): What is the projected business impact (revenue, retention, market share)? (1 = Negligible value, 5 = Game-changing strategic impact).
| Quadrant | Description | Action Plan for a PM |
|---|---|---|
| High Viability / High Feasibility | Quick Wins: These are your no-brainers. They're easy to build and deliver clear business impact. | Execute Immediately: Fast-track these for the next sprint. Use them to build momentum and deliver immediate ROI. |
| High Viability / Low Feasibility | Strategic Bets: Game-changing ideas that are technically complex (e.g., building an AI co-pilot). | Invest & De-Risk: Don't dismiss them. Allocate budget for a technical spike or a proof-of-concept (PoC) to reduce feasibility risks. |
| Low Viability / High Feasibility | Feature Traps: The "easy to build but nobody needs it" projects. These are a massive drain on morale and resources. | Deprioritize & Educate: Learn to say "no" with data. Use the low viability score to show stakeholders the opportunity cost of building this. |
| Low Viability / Low Feasibility | Money Pits: Hard to build with no clear payoff. These ideas are roadmap poison. | Avoid at All Costs: These should not even be in your backlog. Kill them on sight and clearly document why. |
This matrix transforms your roadmap conversations. Instead of debating opinions, you are facilitating a strategic discussion based on a shared framework. It gives you the power to justify trade-offs and align the entire company around the most impactful work.
Applying Feasibility and Viability in Your PM Career
Knowing the definitions is entry-level. Applying these concepts under pressure is what defines your career trajectory. The scope of your feasibility and viability assessments will expand dramatically as you progress from an aspiring PM to a product leader.
This isn't an abstract exercise; it's the core of your daily work, from navigating case interviews to presenting a multi-year product strategy to the board.
From Tactical to Strategic: How the Questions Evolve
Your altitude as a PM changes the blast radius of your decisions. The core questions remain, but the scale and complexity grow exponentially.
-
Aspiring PM (The Interview Loop): In a case study for a Senior PM role at Google (Average Salary: ~$250k+), you're asked to propose a new feature for Google Maps. The amateur pitches a "cool idea." The pro first establishes viability: "What is the business goal? Are we trying to increase engagement to drive ad revenue, or create a new enterprise monetization layer?" Then, they address feasibility: "What are the data privacy implications? Does this require new machine learning models or real-time data streams that don't exist yet?" This demonstrates strategic thinking over feature-level obsession.
-
Mid-Career PM (The Quarterly Roadmap Battle): You're a PM at a startup like Notion. Your backlog is overflowing. A highly requested feature is a technical beast (low feasibility). Your job is to make a data-driven trade-off. You present to your stakeholders: "We can dedicate our entire engineering pod for Q3 to build this one complex feature. Or, we can ship these three smaller, highly viable features that our analytics in Amplitude suggest will reduce new user churn by 15%. I recommend the latter to improve our core growth loop."
-
Senior PM / Group PM (The Annual Strategy Review): You're a Director of Product at Meta. The discussion is about entering a new market—say, enterprise collaboration to compete with Slack and Teams. The viability is massive, but the feasibility is brutal, requiring new security protocols, data residency solutions, and an entirely new go-to-market motion. Your job is to weigh the immense strategic upside against the multi-year, multi-billion dollar investment and risk.
Modern Viability: Beyond the P&L
In 2024, a product's viability extends beyond its profit and loss statement. Modern product leaders are judged on social, ethical, and environmental sustainability. This is a non-negotiable component of a modern viability assessment.
Consider the ongoing challenges at social media platforms. Features designed to maximize engagement (and thus ad revenue) might look great on a quarterly report. But when internal data reveals they contribute to societal harm or mental health issues, the product's long-term viability is threatened by regulatory backlash, brand damage, and talent attrition. You can see more on how product design balances these factors over at UXPin.
As a product leader, you own the second and third-order consequences of what you build. A product that is financially viable but ethically questionable is a long-term failure in waiting. This broadened perspective is what separates a manager from a true leader.
Common Questions About Feasibility and Viability
Even for seasoned PMs, navigating the trade-offs between what's possible and what's profitable can be challenging. Here are answers to common questions that arise in the real world.
Can a Project Be Viable but Not Feasible?
Absolutely. This is the classic "moonshot" scenario. The business case is incredibly strong (high viability), but the technology, resources, or scientific breakthroughs required to build it don't exist yet (low feasibility).
A prime example is general-purpose quantum computing. The potential to revolutionize medicine, materials science, and finance is astronomically viable. However, the immense technical challenges of building stable, scalable quantum computers make it unfeasible for commercial application today.
For a PM at a company like Google or IBM, the response isn't to kill the idea. It's to fund a long-term R&D initiative (like Google's Quantum AI lab) to systematically de-risk the technical challenges and close the feasibility gap over a decade or more.
How Do I Say 'No' to a Stakeholder's "Not Viable" Idea?
You never say "no" based on your opinion. You facilitate a decision based on data. When a powerful stakeholder pushes for a pet project that you've assessed as not viable, you must build an objective business case against it.
Frame your argument using the company's own goals and metrics:
- Present a Financial Model: "I've modeled this out. Given the small market size and our projected CAC of $200, the LTV would need to be over $600 to be profitable. Our other product lines average an LTV of $350. This project is unlikely to ever deliver a positive ROI."
- Highlight the Opportunity Cost: "This is a great idea, and it's technically feasible. However, it will consume 60% of our engineering capacity for two quarters. For the same investment, we could pursue Project Phoenix, which our research indicates will increase customer retention by 10% and has a 2x higher projected NPV. Which initiative better serves our annual goal of reducing churn?"
This reframes the conversation from a personal disagreement to a strategic business choice based on shared data.
When Are These Analyses Most Important in the Product Lifecycle?
Feasibility and viability assessments are not a one-time gate at the beginning of a project. They are continuous processes, but their emphasis shifts throughout the product lifecycle.
- Discovery & Ideation: At this initial stage, viability is 90% of the focus. You are ruthlessly filtering a wide funnel of ideas down to the few that solve a real problem for a sizable market. Feasibility is a loose check ("Is this science fiction?").
- Planning & Development: As an idea moves toward the roadmap, feasibility becomes paramount. This is when you conduct technical spikes, detailed architecture reviews, and resource planning to get a high-confidence estimate of the cost and timeline.
- Post-Launch & Growth: After launch, you are continuously re-evaluating viability using real-world performance data (P&L, LTV:CAC, churn rates). This data informs whether you should double-down and invest more (because it's highly viable), maintain it, or sunset the product because it failed to prove its long-term viability.
Ready to advance your product career? The Aakash Gupta newsletter offers actionable insights and frameworks used by leaders at top tech companies. Join the largest community of PMs and get the strategies you need to succeed. Subscribe here: https://www.aakashg.com
