Updated: June 18, 2025- 13 min read
You wouldn’t build a house without checking the ground first. Yet, in product development, teams do it all the time.
They pour time, budget, and energy into an idea only to find out too late that no one wants it, it doesn’t solve a real problem, or it simply can’t survive in the market.
Product viability is the equivalent of checking the soil before construction. It’s not the flashiest part of the process, but it’s the one that saves everything else from collapsing. So before you move to wireframes or roadmaps, there’s one quiet but essential question that deserves your full attention: Should this product exist at all?
In this guide, we’ll unpack what product viability actually means and why it’s a critical checkpoint during product discovery and product development process. We’ll dive into who should own it and how smart teams determine whether an idea is viable right before they double down.
Product Discovery Micro-Certification (PDC)
Master the art of product discovery! Learn how to identify real user problems, validate solutions, and ensure your product truly resonates with its target audience.
Enroll for free
What Is Product Viability?
Product viability is the answer to one of the most fundamental questions in product management:
“Should we build this?”
Not “can we build it” — that’s feasibility. Not “how should we build it”—that’s product design and usability. Viability lives upstream. It sits together with desirability and feasibility, and it asks:
If we build this, will it bring value to users and to the business — enough to justify the effort?
This isn’t a one-time assessment. It’s a continuous process that stretches from early idea management all the way through product maturity — and even into sunsetting an end-of-life product.
Let’s break it down with the key product concepts that shape how we think about viability:
Idea management: Separating signal from noise
Every product team is flooded with ideas — feature requests from sales, wild bets from leadership, feedback from support, user suggestions, personal pet projects. Without a structured idea management process, it's easy to confuse volume with value.
Product viability helps filter those ideas. It asks:
Is there a real user pain behind this?
Is this aligned with our product strategy and business model?
Can this idea create a measurable outcome?
Strong idea management helps teams avoid the “build trap ” where you’re shipping features without understanding whether they actually move the needle.
Product discovery: The earliest test of viability
Product discovery is where viability takes shape. At this stage, or with continuous discovery, you’re not just gathering requirements. You’re trying to understand whether the problem is worth solving and whether your potential solution makes sense.
Viability is tested here by:
Talking to real users
Mapping problems to outcomes
Prototyping and pressure-testing ideas early
The best product teams treat discovery as a high-signal, low-cost way to kill bad ideas before they turn into expensive mistakes.
Iterative testing: Viability is dynamic
Viability isn’t something you validate once and assume it holds. As the market shifts, users evolve, and your product scales, what was once viable can become a liability.
That’s where iterative testing comes in. You can think of it as ongoing viability insurance. By constantly experimenting, through A/B tests, small-batch feature releases, or MVPs or prototypes, you keep checking that your product still delivers value at every stage of the product lifecycle.
When iterative testing is baked into your culture, viability becomes less about gut feel and more about a continuous feedback loop.
Idea validation: De-risking before you commit
A crucial cousin to viability is idea validation. It’s the set of techniques used to gather evidence before making a big investment. Whether you’re using smoke tests, waitlists, interviews, or click prototypes — validation is how you avoid the build-guess-pray cycle.
Validation sharpens your viability lens. You’re not just asking, “Is this a good idea?” You’re gathering real signals to back it up. This is especially critical when you’re trying to prioritize an outcome-based roadmap or justify a bet to stakeholders.
Opportunity Solution Tree Template
Branch out and discover something new with the opportunity solution tree. Visualize the product discovery process to build features that matter!
Get the template
Product lifecycle: Viability isn’t just a startup problem
Viability questions don’t disappear after the product launch plan. They evolve.
In the early stages, you’re trying to prove a problem exists and that your product can solve it.
In the growth stage, you’re testing whether the solution scales and creates lasting value.
In the mature stage, you’re watching for signs of stagnation or disruption.
And in the decline phase, you might be asking if it’s time to pivot — or shut it down.
At every point in the product lifecycle, viability means something slightly different, but it always matters.
How to Test a Product Before Launch
Testing your product before launch is how you prevent costly mistakes and validate that you’re on the right track. The earlier you get real signals from the market, the more room you have to pivot, adjust, or double down.
Let’s break down some of the most effective ways to test market viability before launch:
Start with user interviews
It’s simple, but still underrated. Talking to users can uncover whether the problem you’re solving is real, frequent, and painful enough to warrant a solution.
Don’t pitch your idea. Ask about:
How they currently solve the problem
What workarounds they use
What happens if the problem goes unresolved
What “success” looks like to them
Real-world pain tends to show up in recurring workarounds, not in hypothetical enthusiasm.
Use a fake door test
If you want to know whether people are interested in a feature or product, set up a door that leads nowhere, just to measure intent. This one is about quickly validating ideas about feature and product development.
For example:
Add a “Coming Soon” button on your site
Create a landing page with a waitlist form
Offer an upgrade path for a feature that’s not built yet
The point isn’t to trick users. It’s to measure clicks, signups, or expressions of interest before building the actual functionality.
Release a viable prototype with minimal effort
You don’t need a fully built product to test whether your idea holds up in the real world. In many cases, a stripped-down version, a viable prototype (VP), is enough to gather early signals from users.
For startups and small teams, that might mean using no-code tools like:
Typeform + Agentic AI tools + Google Sheets to mimic onboarding
Proddy-awarded tools in Notion or Airtable to manage backend data
Figma for interactive demos that simulate functionality
For larger organizations, releasing a lightweight internal prototype or limited-access beta may feel more appropriate. In regulated or risk-averse environments, you can:
Run controlled tests in sandbox environments
Use existing internal tools to simulate workflows
Pilot with a select group of customers under NDA
The goal is the same across company sizes: test with minimal investment. Whether it’s no-code, low-code, or a lightweight coded prototype, a VP helps you learn fast, without overcommitting resources too early.
Run a concierge test
If you want to see if users actually want the solution, offer it manually before you automate it.
Let’s say you're building a meal planning app. Instead of launching the full platform, have users fill out a form and personally email them their weekly meal plan. If people are willing to engage with the manual version, that’s a good early sign of viability.
This test is useful for validating willingness to pay, stickiness, and user expectations without full product launch overhead.
Measure willingness to pay
An idea isn’t viable if no one’s willing to pay for it or if the monetization model doesn’t support the business.
Try methods like:
Paywalling the MVP
Offering pre-orders
Testing pricing tiers with test pricing pages
You’re looking for a sign that your product solves a big enough problem to justify a transaction.
Track retention of early users
Even in the scrappiest pre-launch phase, user retention is gold. If your early testers come back, use the product, or ask for more, that’s a signal! If they bounce and ghost, that’s a signal too.
Use small cohorts and look at:
Repeat usage
Requests for more access
Feedback that leads to re-engagement
The earlier you learn if people need the product, not just like the idea of it, the better.
Why Product Viability Matters Early in the Process
If product discovery is about reducing uncertainty, then testing for viability early is how you avoid the most expensive kind of failure: building something no one wants or needs.
Too often, teams fall in love with a solution before validating whether the problem is big enough, the market is real, or the business model makes sense. By the time they realize it, they’ve already sunk months of product design and engineering time into something that never had a chance.
Early viability checks shift product development from a hopeful bet to a calculated investment. They help you answer foundational questions before momentum and internal expectations take over. This is especially important in environments where:
Stakeholders expect quick wins
Engineering resources are tight
Product portfolios are already bloated
Teams are juggling discovery and delivery simultaneously
Here’s why validating product viability early really matters:
Prevents wasted resources: Stops teams from over-investing in ideas that don’t have enough market pull or business value.
Improves stakeholder alignment: Gives Product Managers real data to justify decisions and set expectations with leadership early on.
Supports clearer product prioritization: Helps filter the backlog and roadmap based on validated potential, not just internal opinions.
Strengthens customer discovery: Ensures that user research and solution exploration are grounded in viability from day one.
Reduces risk of launch failure: Early signals help you pivot or iterate before going to market with something that’s off-target.
Fuels confident iteration: When you know there’s viability, you can experiment with more confidence in design, product pricing, and growth strategy.
Keeps teams focused on outcomes: Validated ideas are more likely to align with user value and business impact, not just output.
Testing product viability early doesn’t guarantee success—but skipping it almost guarantees waste. It’s not about finding the perfect idea. It’s about quickly identifying the ones that are actually worth building.
Who’s Responsible for Product Viability
It’s tempting to assume that product viability sits solely with the Product Manager. After all, PMs are expected to be the ones asking, “Should we build this?” But the reality is more layered — viability is a shared responsibility across the product trio and beyond.
Think of viability as a lens that every function in a product team should apply through their own expertise:
Product managers drive the conversation by identifying user problems, aligning product ideas with business strategy, and making sure there’s a clear path to value.
Product designers contribute by ensuring the solution is desirable, usable, and actually addresses the problem in a meaningful way. They often surface early friction points that impact long-term viability.
Engineers bring critical insight into feasibility and scalability — vital parts of the viability equation, especially in tech-heavy products or platforms.
But the responsibility doesn’t stop with the product trio. Broader organizational inputs also play a key role in determining product viability:
Marketing helps assess whether there’s enough demand to justify launch and what kind of positioning will resonate in the market.
Sales and customer success teams have direct access to buyer objections, unmet needs, and common patterns that can either reinforce or question the idea’s value.
Finance and leadership evaluate the commercial side — can this product sustain or grow revenue? Will it fit the current business model or require a shift?
The most successful teams treat product viability as a continuous, cross-functional conversation. When PMs own the process, and involve others in shaping it, they create a much stronger foundation for building products that actually succeed in the real world.
How to Determine Who Owns Viability Decisions
Viability is a function of your company’s structure, product maturity, and strategic priorities. Here’s how to think about responsibility depending on your context:
In early-stage startups
Ownership often sits squarely with the founding team or a single Product Lead. At this stage, lines are blurry and decisions are centralized. The PM (or founder-PM hybrid) leads the process — but also acts as a proxy for marketing, support, and design.
Responsibility should be:
PM-led and founder-informed
Lightweight, fast-paced, and driven by direct user feedback
Focused on viability at a problem-solution level
In growing companies with cross-functional teams
Responsibility becomes more collaborative. As dedicated product trios form, each function brings viability considerations into their own lane:
Product managers assess value and alignment with the roadmap
Product designers validate desirability and friction
Engineers surface feasibility and complexity risks
At this stage, product viability is best supported by a shared discovery process and decision-making rituals (like viability reviews or pre-kickoff checkpoints).
In larger organizations with portfolios
Responsibility needs to scale. Multiple PMs, product ops, and specialized roles (like Product Marketing Managers or Growth PMs) may all have a piece of the puzzle.
Here, ownership depends on:
The type of product (core, growth, internal tool)
The stage of the lifecycle (discovery vs. optimization)
The growth strategy (new markets vs. expansion vs. retention)
For example:
A Growth PM may own viability for an upsell experiment.
A Product Marketing Manager might own viability checks for a positioning shift.
A Principal PM or Head of Product may set the framework for how viability is evaluated across teams.
In this environment, clarity of ownership is key. It helps to define:
Who is responsible for gathering and validating evidence
Who is accountable for the final decision
Who contributes input (and when)
RACI frameworks and decision matrices help, but they only work if viability is baked into the team’s mindset, not just a box to check.
By product lifecycle stage
During early discovery, PMs and researchers lead, with strong design input.
During validation and build, engineers and designers are co-owners in testing feasibility and usability alongside business value.
In growth/scale, data teams, marketing, and sales support iteration by surfacing where viability risks emerge in real usage.
In maturity/decline, product leaders and strategy roles reevaluate viability at the product portfolio level, sometimes making tough calls on sunsetting an end-of-life product or pivoting.
Product Viability Is the Decision Before the Decision
Every product you’ve ever admired, whether it took off or fizzled out, had one thing in common: someone, at some point, asked “Is this worth building?”
That’s what product viability is all about. It's a discipline. A way to bring clarity to ambiguity, focus to creativity, and direction to momentum.
Viability helps teams stay honest. It forces you to confront hard truths early before excitement turns into sunk cost, and before roadmaps lock you into something you can’t justify.
So before your team dives into the next sprint or roadmap planning session, ask the hard question: Is this viable?
Because if the answer is yes — truly yes — you’ll build with conviction and success.
Product Experimentation Micro-Certification (PEC)™️
The Product Experimentation Micro-Certification (PEC)™️ introduces you to the essentials of designing and running high-quality experiments.
Enroll now
Updated: June 18, 2025
