Every business model transformation involves uncertainty. These four risk categories help you systematically identify what you don't know, design experiments to reduce uncertainty, and make evidence-based decisions about whether to proceed.
Risk One
"Will customers actually want this?"
Desirability risk addresses whether you're solving a real problem that customers care enough about to change their behavior. It's the most common killer of new business models—teams build something nobody wants. Testing desirability before building anything substantial protects against this waste.
Desirability isn't just "do they like the idea?" It's "will they switch from their current solution?" and "will they pay for it?" Many ideas sound appealing in conversation but fail when customers face actual decisions.
Canvas Blocks at Risk
Deep conversations exploring the customer's world, problems, and current solutions. Focus on behavior, not hypotheticals.
Evidence type: Qualitative insight about problem existence and priority
Create a page describing the value proposition. Measure who clicks, who signs up for more info, who provides email addresses.
Evidence type: Conversion rates showing interest level
Ask customers to commit before the product exists—deposit money, sign a letter of intent, or join a paid waitlist.
Evidence type: Actual financial or contractual commitment
The Hypothesis: Teams want a better way to communicate than email—something faster, more organized, and searchable.
The Challenge: Slack was originally an internal tool built for a gaming company. Before pivoting the entire company to this new product, they needed evidence that other teams would want it too.
The Experiment: Slack recruited friendly companies to use the tool before public launch. They gave it to about 10 companies and watched how they used it. They gathered feedback obsessively. Then expanded to 40 companies, then thousands on a waitlist.
The Evidence: Teams used Slack more than expected. Usage data showed people opening it 10+ times per day. Teams who tried it didn't want to stop. The preview companies became references and advocates. Strong evidence of desirability before major investment.
Preview companies
40+
Daily active use
10+ opens/day
Waitlist at launch
8,000 companies
Decision supported
Pivot entire company
Risk Two
"Can we actually build and deliver this?"
Feasibility risk addresses whether you have (or can acquire) the capabilities to deliver the value proposition. It's about resources, activities, partnerships, and technology. Many business models fail not because customers don't want them, but because the team can't execute.
Feasibility isn't binary. The question isn't just "can we do it?" but "can we do it at the required quality, scale, and cost?" A solution that works in a lab or pilot may not work at commercial scale.
Canvas Blocks at Risk
Bring in technical experts or consultants to evaluate whether the proposed solution can be built with available technology and resources.
Evidence type: Expert judgment on technical possibility
Build a minimum version that proves the core technical challenge can be solved. Focus on the hardest part, not the complete system.
Evidence type: Working demonstration of technical capability
Run a small-scale version of the complete operation to test all activities and partnerships work together at limited scale.
Evidence type: Operational metrics from real delivery
The Hypothesis: We can coordinate international freight forwarding through a software platform, managing carriers and customs without owning ships or warehouses.
The Challenge: Building a full freight management platform would require millions in technology investment and regulatory compliance. How could Flexport test if the operational model would work before building it?
The Experiment: Founder Ryan Petersen started by manually coordinating shipments using spreadsheets and phone calls. He acted as the software—tracking shipments, managing documentation, communicating with carriers. The process was labor-intensive but proved the concept.
The Evidence: Shippers paid for the service. Shipments arrived on time. The manual process revealed what the software needed to do. Only after proving the operations worked did Flexport build the technology platform that now automates these processes.
Core assumption tested
Operations work
Infrastructure required
Spreadsheets + phone
Risk if wrong
Minimal investment
Decision supported
Build platform ($8B valuation)
Risk Three
"Will this generate sustainable profit?"
Viability risk addresses whether the business model math works. Even if customers want it and you can build it, can you make money doing so? This involves revenue streams, cost structure, pricing, and unit economics.
Many businesses that customers love and that technically work still fail because they can't achieve profitable unit economics. The costs of acquiring customers, delivering value, and maintaining operations exceed what customers are willing to pay.
Canvas Blocks at Risk
Use techniques like Van Westendorp pricing or conjoint analysis to understand what customers would pay. Better than asking directly.
Evidence type: Price sensitivity data
Show different prices to different customer groups and measure conversion rates. A/B test pricing on landing pages or in sales conversations.
Evidence type: Conversion rates at different price points
Run a small-scale pilot and meticulously track all costs and revenues. Calculate actual unit economics from real operations.
Evidence type: Actual revenue and cost data
The Hypothesis: People will pay for a tool to schedule social media posts, and we can price it at a level that supports a sustainable business.
The Challenge: Founder Joel Gascoigne didn't know what price to charge or whether the math would work. Building first and figuring out pricing later is risky.
The Experiment: Before building the product, Joel created a landing page with a pricing page showing three tiers: Free, $5/month, and $20/month. Visitors who clicked "Plans and Pricing" saw the options. Visitors who clicked a paid tier were told the product wasn't ready yet and asked for their email.
The Evidence: People clicked through to pricing and then clicked on paid plans. This proved not just desirability ("I want this") but viability ("I'd pay $5-20/month for this"). Joel knew before writing code that the business model could work.
Pricing validated
$5-20/month
Type of evidence
Intent to pay
Code written
Zero
Decision supported
Build at validated price
Risk Four
"Can this survive and evolve as conditions change?"
Adaptability risk addresses whether the business model can survive changes in the external environment: competitor moves, technological disruption, regulatory shifts, economic cycles, and changing customer preferences. It's about resilience and future-proofing.
A business model that works today may be disrupted tomorrow. Testing adaptability means stress-testing the model against plausible futures and building in mechanisms for evolution. This is the least commonly tested risk—and often the one that kills successful businesses.
Canvas Blocks at Risk
Develop 3-4 plausible future scenarios. Test how your business model performs in each. Identify vulnerabilities and adaptation strategies.
Evidence type: Identified vulnerabilities and contingencies
Have a team role-play as a competitor trying to disrupt you. What would they do? How would you respond? Red team your own model.
Evidence type: Defensive strategies and moat analysis
Model financial and operational performance under adverse conditions: 30% revenue drop, key partner loss, technology shift, regulatory change.
Evidence type: Break-even points and survival thresholds
The Situation: By 2010, Microsoft dominated enterprise software with Windows and Office. But cloud computing threatened this model—Amazon Web Services was enabling competitors to build without Microsoft infrastructure. Google Apps challenged Office.
The Question: What happens if enterprises stop buying perpetual licenses and move to cloud-native solutions? Can Microsoft's business model survive?
The Stress Test: Microsoft modeled scenarios where cloud adoption accelerated. The analysis showed that clinging to licenses created existential risk. They would become irrelevant as competitors offered cloud-native alternatives.
The Adaptation: Under Satya Nadella (CEO 2014), Microsoft pivoted to "mobile-first, cloud-first." Azure became the strategic priority. Office 365 replaced perpetual licenses. They cannibalized their own Windows revenue to build cloud dominance. By 2024, Azure revenue exceeded Windows for the first time.
Vulnerability identified
License dependency
Adaptation strategy
Cloud-first pivot
Investment required
$Billions in Azure
Outcome
$3T market cap (2024)
Desirability
Test first—if no one wants it, nothing else matters
Feasibility
Test early—identify technical blockers before investing heavily
Viability
Test once you know people want it and you can build it
Adaptability
Test continuously—the environment keeps changing
Begin with the cheapest experiments that give useful evidence. Only invest in expensive pilots and prototypes after cheaper tests have reduced risk. Save your budget for validating what matters most.
Identify your riskiest assumptions—the ones that would kill the business if wrong—and test those first. Don't waste time optimizing things that don't matter if a fundamental assumption is untested.
One customer paying money is worth more than 100 people saying "I'd buy that." Seek the strongest evidence you can get at each stage. Move up the evidence ladder as your investment increases.
Define success criteria before running experiments. Know what evidence would make you proceed, pivot, or abandon. This prevents post-hoc rationalization and keeps decisions honest.