Product management is risk management. While most product managers focus on building features users want, success requires navigating four distinct risk types that can derail even promising ideas: desirability, feasibility, usability, and viability risks.
Understanding how to identify, validate, and manage these product development risks separates successful products from expensive failures.
Desirability Risk: Validating Customer Demand
Desirability risk addresses the fundamental question: do customers actually want or need what you’re building? We do not build products for the sake of building products. We build products to address or solve a problem that our users have. This represents the most common cause of product failure, yet teams frequently misread the signals.
Why Products Fail Despite Good Execution
Many product failures stem not from poor execution but from building solutions to problems that don’t exist. Consider Juicero, which raised over $120 million from investors including Google Ventures and Kleiner Perkins. The company built a $699 WiFi-connected countertop machine designed to press pre-packaged pouches of chopped fruits and vegetables into fresh juice. The business model required buying the machine to access a subscription service for the juice pouches, priced at $5 to $8 each. The pitch: busy, health-conscious consumers could get fresh-pressed juice at home without the mess of traditional juicers or the effort of chopping produce.
Unfortunately, Bloomberg journalists discovered that users could simply squeeze the pouches by hand with the same result. The $699 machine that customers were required to purchase added no value at all. The company shut down just 17 months after launching. Juicero had tried to create demand for an expensive solution to a problem that didn’t require that solution. The engineering was impressive, but it solved a problem nobody actually had.
Teams frequently fall in love with their ideas, mistake polite feedback for genuine interest, or confuse what users say they want with what they’ll actually use and pay for.
Distinguishing Real Demand From Polite Interest
Real demand reveals itself through specific behaviors, not general enthusiasm. When someone has a genuine problem, they describe in detail what they currently do to solve it, how much time or money they spend, and what frustrates them about their current approach. They bring up specific scenarios without prompting. They ask detailed questions about your solution because they’re mentally mapping it to their actual workflow.
Polite interest sounds different. Responses stay vague: “That sounds useful” or “We could probably use something like that.” When you ask what they do today, they struggle to articulate a clear process. They don’t ask probing questions because they’re not seriously evaluating whether it solves their problem.
How to Validate Customer Demand
Discovery interviews are your first defense. The critical distinction: you’re not asking if users would like your solution. You’re exploring whether they have the problem you think they have, how painful it is, and what they currently do to solve it. The best validation comes from observing behavior, not collecting opinions.
Prototype testing reveals genuine interest. When you put a realistic prototype in front of potential users, their reactions are more authentic than hypothetical discussions. Look for emotional responses, specific use cases they immediately think of, and willingness to invest time learning more.
Pre-launch indicators like waitlists, pre-orders, or letter-of-intent commitments provide concrete evidence. Money talks louder than survey responses. Even small financial commitments or significant time investments signal genuine interest more clearly than any survey.
Feasibility Risk: Technical Capability and Resource Constraints
Feasibility risk concerns whether your team has the technical capability, resources, and time to build what you’ve envisioned. Can we actually build this? Do we have the skills, the tech, the expertise, to make this happen? A product idea might be highly desirable but impossible to execute given current constraints.
When Technology Promises Exceed Reality
Theranos claimed to have developed technology that could run comprehensive blood tests from a few drops of blood from a finger prick. The company raised over $700 million and reached a $9 billion valuation at its peak. However, the technology was fundamentally flawed. The devices had accuracy and reliability problems, could perform only a limited number of tests, and Theranos was forced to use traditional blood testing equipment for most patient tests. Founder Elizabeth Holmes was convicted of fraud and sentenced to over 11 years in prison for misleading investors about the technology’s capabilities.
Common Manifestations of Feasibility Risk
Technical complexity might exceed your team’s capabilities or require expertise you don’t have. Dependency on third-party APIs, data sources, or partnerships introduces points of failure beyond your control. Timeline constraints might make building a quality solution impossible before a critical market window closes. Resource limitations in engineering capacity, budget, or infrastructure can render ambitious ideas impractical.
Strategies for Addressing Feasibility Risk
Involve engineering early and often. The worst time to discover feasibility issues is after you’ve committed to stakeholders and set customer expectations. Bring engineers into the discovery process, share user insights with them, and collaborate on solution design from the start.
Build technical spikes and proof-of-concepts for the riskiest assumptions. If your product relies on a machine learning model achieving certain accuracy or processing data at a specific speed, validate these assumptions before committing to the full build.
Break large initiatives into phases. Rather than attempting to build the complete vision at once, identify the minimum valuable solution or the MVP that addresses the core problem. This approach reduces feasibility risk and creates opportunities to learn and adjust based on real feedback.
Usability Risk: Can Users Actually Use Your Product?
Usability risk addresses whether users can successfully use your product to achieve their goals. Even if people want your product and you can build it, they might struggle to understand how it works or find it too cumbersome to adopt.
The Snapchat Redesign Disaster
Snapchat rolled out a major redesign in late 2017 that fundamentally changed how users interacted with the app. The redesign mixed Stories with direct messages in a single feed, making them nearly indistinguishable. Stories no longer appeared in chronological order but were ranked by an algorithm. Users struggled to find specific friends and send messages in the cluttered interface. Perhaps most frustrating, Stories disappeared after one viewing, requiring users to manually search for friends’ names to rewatch them.
Nearly 1.3 million users signed a petition asking the company to roll back the update. In countries where the redesign launched first, 83 percent of App Store reviews were negative. The redesign led to Snapchat’s slowest user growth ever, with the company actually losing users in some periods, and user sentiment among the key 18-34 demographic plunged 73 percent. CEO Evan Spiegel eventually reversed major parts of the redesign, acknowledging that combining watching Stories and communicating with friends in the same place made it harder to optimize for both behaviors. The redesign had broken the basic workflows users performed daily, forcing them to relearn fundamental interactions.
Why Usability Problems Surface Late
This risk is particularly insidious because teams immersed in building a product often develop blind spots. What seems intuitive after months of development can be completely confusing to first-time users. Usability problems frequently surface only after launch, when real users encounter your product without guidance or support.
Mitigating Usability Risk
Conduct usability testing throughout development, not just at the end. Watch real users attempt to complete key tasks without help. The moments where they hesitate, misunderstand, or take unexpected paths reveal friction points you need to address.
When you identify friction, prioritize based on impact and frequency. Not every awkward moment needs fixing. Focus on issues that block critical user paths or occur repeatedly across test participants. A confusing advanced feature used occasionally matters less than confusion during initial setup.
Pay attention to onboarding experiences. First impressions matter enormously. If users can’t quickly understand your product’s value and how to get started, they’ll abandon it before experiencing the benefits. A useful heuristic: users should achieve one meaningful outcome within their first session, even if simplified compared to the full product capability.
Monitor behavioral analytics and support tickets after launch. Time-to-value metrics, feature adoption rates, and common support questions all signal usability issues needing attention. If users consistently contact support for the same task, that’s a design problem, not a documentation problem.
Knowing When Usability Is Good Enough
Perfect usability is impossible and unnecessary. The goal is removing friction from critical paths, not polishing every edge case. Ship when users can complete core tasks without assistance and the error rate on key workflows is acceptably low. You can iterate on refinements after validating that the fundamental product experience works.
Viability Risk: Building a Sustainable Business Model
Viability risk examines whether you can build a sustainable business model around your product. A product might be desirable, feasible, and usable, but still fail if the economics don’t work or the business model collapses under growth. If we invest is solving this problem and building this product, will we have a good return on our investmenet (ROI).
The MoviePass Unit Economics Catastrophe
MoviePass originally charged $30-50 per month for unlimited movies but saw modest growth with around 20,000 subscribers. In 2017, after new ownership, the company slashed prices to $9.95 per month while paying full retail price for every ticket. Subscriber growth exploded to over three million users, but the unit economics were catastrophic. The company was losing money on every customer. MoviePass added just four million users in early 2018 before growth stalled completely, and by July 2019 had only 225,000 active users remaining before shutting down permanently. The company kept thinking scale would fix the problem, but growth only amplified the losses. Every new customer they acquired made the business weaker, not stronger.
Evaluating Business Model Viability
Model your unit economics early. Understand the cost to acquire a customer, the cost to serve them, and the revenue they’ll generate over their lifetime. If the math doesn’t work at small scale, growth will only amplify the problem. Pay particular attention to contribution margin per customer and the timeline to payback acquisition costs. Products with negative contribution margins or multi-year payback periods face serious viability constraints.
Think about operational scalability. Some business models work well at small scale but collapse under their own success. High-touch customer success requirements, manual operational processes, or reliance on scarce expertise create scaling bottlenecks. A consulting-heavy implementation model might work for your first 50 customers but becomes unsustainable at 500. Identify which aspects of your business model require linear cost increases as you grow, and determine whether your pricing can support those costs.
Consider regulatory and compliance requirements, competitive dynamics, and market positioning as secondary viability factors. These matter, but getting unit economics and operational scale right comes first. A product with strong economics can navigate regulatory challenges or competitive pressure. A product with broken economics cannot.
Managing All Four Risks Simultaneously
The real art of product management lies in navigating all four risks together. They’re interconnected in complex ways, and addressing one often creates tension with another. Understanding these tradeoffs helps you make informed decisions about where to accept risk and where to mitigate it.
When Risk Mitigation Creates New Risk
Reducing one type of risk often increases another. A CRM company facing technical constraints might remove advanced reporting capabilities to ship faster, reducing feasibility risk. But if reporting was a core reason customers wanted the product, they’ve just increased desirability risk. The simpler solution is easier to build but may not solve the customer problem adequately.
The inverse happens when addressing desirability by adding features. Each additional capability increases development cost, maintenance burden, and complexity. A project management tool might add time tracking, resource management, and budget forecasting because different prospects requested these capabilities. The expanded scope makes the product more desirable but potentially too expensive to build and support profitably, creating viability risk.
Optimizing for usability can conflict with feasibility. The most intuitive user experience often requires sophisticated technical implementation. Real-time collaboration, intelligent defaults, or seamless integrations all make products easier to use but harder to build. Teams must decide whether the usability improvement justifies the technical complexity and development time.
Sequencing Risk Validation
The key to managing these tradeoffs is testing the riskiest assumptions first. This prevents wasting effort on lower-risk areas before validating whether the product concept is viable at all.
When Desirability Takes Priority
For early-stage products, desirability typically represents the highest risk. Most new product ideas fail because there’s insufficient demand, not because of execution problems. Start with discovery research to validate that the problem exists and customers care enough to change their behavior. Only after confirming real demand should you invest heavily in the other risks.
When Feasibility Moves Forward
Feasibility risk moves to the front when you’re working with unproven technology or complex technical challenges. If your product concept relies on machine learning achieving specific accuracy thresholds or processing data at speeds your team hasn’t demonstrated before, validate the technical approach early. Building demand for something you can’t actually deliver wastes everyone’s time.
When Usability Becomes Primary
Usability risk becomes primary when you’re entering crowded markets where user experience is a key differentiator. If competitors already solve the core problem, your ability to provide a superior experience may determine success. In these cases, invest in usability testing earlier and more extensively.
When Viability Deserves Early Attention
Viability risk deserves early attention in capital-intensive businesses or those with complex monetization models. If your product requires significant ongoing operational costs, depends on network effects to work, or faces regulatory uncertainty, model the business case before building extensively. A marketplace that only works at scale needs a viable path to scale before you invest in building the platform.
From Recognition to Action
Understanding these four risks is essential, but knowing they exist isn’t enough. The gap between recognizing risks and effectively managing them comes down to systematic execution: knowing which risks to test first, how to validate assumptions efficiently, and when to escalate decisions versus handle them within the team.
Building Your Risk Assessment Practice
Without structured approaches, product managers end up relying on intuition and reacting to problems as they surface. Discovery interviews become unstructured conversations that confirm biases rather than challenge them. Prototypes get built without clear hypotheses about what you’re trying to learn. Prioritization decisions lack objective criteria, leading to endless debates about what to build next.
Start by establishing a rhythm of risk assessment at key decision points. Before committing to build, explicitly document which risk type poses the greatest threat to your product’s success. Context shapes priorities: B2B products typically face higher technical and business model challenges, while consumer products carry greater market validation and usability risk. For a new product in an unproven market, desirability dominates. For a technically ambitious product, feasibility takes priority. Name the risk, state your assumptions, and define what evidence would change your approach.
Communicating Risk with Stakeholders
Transparent risk communication builds trust and enables better decisions. When presenting product plans to leadership, frame your approach around risk management rather than feature delivery. Instead of “We’re building these five features,” say “We’re addressing our highest desirability risk by validating demand for core workflow automation, then we’ll tackle feasibility risk in the integration layer.”
Be explicit about tradeoffs you’re making. When you ship with known usability friction to capture a market window, explain the reasoning: “We’re accepting this usability risk because our target users (technical operations teams) can tolerate configuration complexity, and missing this conference would cost us six months of market visibility. We’re monitoring support tickets to ensure the friction is manageable.” This transparency helps stakeholders understand that you’re making informed bets, not ignoring problems.
Share your validation approach and decision criteria upfront. Tell stakeholders what evidence would cause you to change course: “If our discovery interviews reveal that fewer than 40 percent of target users express strong interest and can articulate the current pain, we’ll pivot our approach before building.” This creates alignment on decision-making logic and reduces the risk of stakeholders demanding you proceed despite warning signals.
Moving from Understanding to Mastery
The products that succeed aren’t those with zero risk. That’s impossible. They’re the ones where risks were identified early, tested rigorously, and managed intelligently throughout the product lifecycle. Product managers who master this navigation build products that don’t just launch, but sustain.
The most effective product organizations use structured approaches to navigate these risks systematically. Our Building Innovative Products workshop teaches practical frameworks for managing all four risk types, from customer discovery techniques to business model validation.
Related Resources
Want to go deeper on these product risk management concepts? These resources provide practical frameworks and techniques for each risk type:
Understanding Customer Problems:
- Jobs to Be Done Framework – Understand what customers are actually trying to accomplish
- How to Create Personas That Drive Product Decisions – Build research-backed personas that reflect real users
- Top 5 Customer Interview Rules – Conduct discovery interviews that reveal genuine problems
Validating Product Ideas:
- 10 Product Discovery and Validation Techniques – Proven methods for testing ideas before building
- How to Use Design Sprints to Validate Product-Market Fit – Rapid prototyping and testing approach
- Value Proposition Canvas: Essential Guide for Product-Market Fit – Ensure your solution addresses actual customer pains and gains
Building Viable Business Models:
- Business Model Canvas: A Strategic Framework for Product Managers – Map out economic relationships and identify weaknesses
- Business Model Canvas Workshop – Hands-on training to build and validate sustainable business models