Paradigm-Shift Why-Now Test
Back a familiar need when a technology shift makes a new solution possible.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 97%
The Paradigm-Shift Why-Now Test asks whether a new technology or behavior has reopened an apparently settled market. The evaluator identifies the enabling shift, explains why the solution could not have succeeded earlier, and examines whether incumbents are constrained by architectures or economics built for the old paradigm. Okta's thesis was that cloud adoption created room for a new identity provider, while cloud-native companies such as Snowflake made a deliberately binary architectural bet. The mechanism converts a broad trend into a falsifiable timing thesis: if adoption arrives quickly enough, a new entrant can become the default for the emerging paradigm; if the transition is mistimed, incompatibility with the old world can destroy the company.
Origin
Extracted from Acquired's analysis of Okta, Snowflake, cloud computing, and the classic venture question of why a company should exist now.
Core principles
- 01A settled market can reopen when its enabling technology changes.
- 02Architecture should exploit the new paradigm rather than imitate the old one.
- 03Correct direction is insufficient without correct timing.
- 04Incumbent commitments may prevent an effective response.
How to run it
- 1
Identify the shift
Name the specific change in technology, cost, regulation, behavior, or distribution enabling the opportunity.
Pro tip Use observable evidence rather than a general claim that the future is changing.
Watch out A trend label alone is not a thesis.
- 2
Explain prior impossibility
State why the proposed company would have failed, cost too much, or delivered too little value several years earlier.
Pro tip Look for a concrete removed constraint.
Watch out If it was equally viable before, the timing argument is weak.
- 3
Define the native architecture
Design the product around the new paradigm's capabilities rather than preserving every legacy assumption.
Pro tip Identify what becomes possible only when legacy compatibility is abandoned.
Watch out A superficial rebranding of an old product gains little advantage.
- 4
Locate early adopters
Find users already experiencing the new need intensely enough to switch.
Pro tip Start where the paradigm transition is already operational.
Watch out Enthusiasm from observers is not adoption.
- 5
Test transition timing
Estimate whether the broader market will shift before the company exhausts its capital and patience.
Pro tip Define adoption milestones with dates.
Watch out Being directionally right but years early can still be fatal.
- 6
Assess incumbent response
Determine whether established competitors can adapt without sacrificing their existing products or economics.
Pro tip Look for architectural and channel conflicts.
Watch out Do not assume incumbents are incapable merely because they are large.
In the wild
A startup argues that cloud software adoption requires a new identity layer and that on-premise incumbents will struggle to rebuild around the cloud. The investor evaluates cloud migration as the reason the category is open now.
→ The company establishes a major position in identity as enterprise workloads move online.
A team builds a data warehouse that depends on cloud infrastructure and does not preserve full compatibility with on-premise deployment. Its survival depends on enterprises moving to the cloud quickly enough.
→ The architectural commitment creates differentiation when the timing thesis proves correct.
Common mistakes
Mistaking inevitability for timing
A transition may eventually occur while still arriving too slowly for the company to survive.
Carrying every legacy constraint
Preserving the old architecture can prevent the entrant from capturing the new paradigm's advantages.
Ignoring incumbent adaptability
A compelling shift does not guarantee that established companies are unable to respond.
Is it for you?
Best for
It is best for evaluating startups entering mature categories during cloud, mobile, AI, crypto, or other platform transitions.
Not ideal for
It is not ideal when no identifiable external change makes the proposed solution materially more viable now.
From the transcript
“this is the kind of thing that we loved hearing when there's like a rearranging of the technology paradigms that are used.”
“You had to be binary in your bet and say, like, we believe in this thesis at this timing”
“it was a great why now for Okta. The cloud was changing everything.”
From the episode
Andreessen Horowitz Part II