Perkins's Technical-to-Business Risk Law
Use technical difficulty to anticipate competitive protection and business risk
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 97%
Perkins's law proposes an inverse relationship between technical risk and business risk. A product that requires a genuine scientific or engineering breakthrough may be difficult and uncertain to create, but success can establish a strong competitive moat because rivals cannot easily reproduce it. A simple product is more likely to be built successfully, yet that same accessibility allows competitors to enter, copy features, and pressure margins. The framework asks decision-makers to evaluate both dimensions jointly instead of celebrating low technical risk as an unconditional advantage. Its output is a balanced thesis: whether the organization can survive the technical challenge and, if it does, whether the resulting product will be sufficiently protected to earn attractive returns.
Origin
Mallaby attributes the idea to Kleiner Perkins co-founder Tom Perkins and illustrates it by contrasting Genentech's artificial insulin challenge with Yahoo's manually assembled website directory.
Core principles
- 01Hard technical problems can create defensible advantages
- 02Easy-to-build products invite more competitors
- 03Technical feasibility and commercial defensibility must be assessed together
- 04Reducing one risk dimension may increase the importance of the other
How to run it
- 1
Assess technical risk
Determine whether the product requires unresolved science, novel engineering, difficult integration, or exceptional execution. Estimate the probability, cost, and time required to solve those challenges.
Pro tip Seek evidence from prototypes and independent specialists.
Watch out Technical novelty alone does not guarantee customer value.
- 2
Assess replicability
Ask how quickly a well-funded rival could reproduce the product after seeing it work. Include access to talent, tooling, data, suppliers, and intellectual property.
Pro tip Model the strongest plausible competitor rather than the average entrant.
Watch out Patents do not automatically create practical defensibility.
- 3
Assess business risk
Evaluate competition, customer acquisition, pricing power, distribution, regulation, and switching costs. Increase scrutiny when the product is straightforward to copy.
Pro tip Look for nontechnical moats when technical barriers are low.
Watch out A large market can attract enough competition to erase attractive economics.
- 4
Balance the risk pair
Decide whether the expected moat justifies the technical uncertainty or whether commercial strengths compensate for easy replicability. Compare ventures across both axes rather than one headline score.
Pro tip Use a two-by-two matrix of technical risk and business risk.
Watch out The inverse relationship is a heuristic, not a guaranteed natural law.
- 5
Design the mitigation plan
For high technical risk, use staged experiments; for high business risk, strengthen distribution, network effects, brand, data, or switching costs. Reassess as evidence changes.
Pro tip Assign a distinct milestone to each major risk dimension.
Watch out Solving technical risk can reveal rather than eliminate commercial risk.
In the wild
Artificial insulin presented Genentech with unprecedented technical uncertainty, but solving it would make imitation difficult and support strong margins. Yahoo's manually compiled website list was much easier to create, leaving the company exposed to competitors capable of offering similar directories or search tools.
→ The comparison reveals why lower build risk can coincide with higher competitive risk.
A team can build a scheduling app in weeks using common components. The low technical risk is attractive, but competitors can copy its features quickly. The team therefore treats distribution partnerships and proprietary workflow data as essential parts of the investment thesis.
→ The company compensates for low technical barriers with deliberate commercial moats.
Common mistakes
Treating difficulty as proof of value
A technically hard product may still solve no important customer problem.
Ignoring nontechnical moats
Brands, networks, regulation, distribution, and proprietary data can protect products that are technically easy to build.
Evaluating only feasibility
A product can be entirely feasible and still produce poor returns because competition destroys pricing power.
Is it for you?
Best for
This framework is best for comparing technically ambitious ventures with easier-to-build software or service businesses.
Not ideal for
It is not ideal as a universal law in markets where regulation, branding, distribution, data, or scale creates the dominant moat.
From the transcript
“technical risk is inversely proportional to business risk”
“if you solve a really hard technical problem, you're not going to face much competition from business competitors because they don't know how to solve…”
“if you've got something which is simple to build, it's just an app um. Then the busines this risk is going to be much more…”
From the episode
Sebastian Mallaby on How Venture Capital Made Silicon Valley
Sebastian Mallaby