At 10X, we've been thinking hard about how to handle risk in product development. One framework that's shaped how we work: not all risks are equal, and conflating different types of risk leads to bad decisions.
Two kinds of risk
The risks a startup faces broadly fall into two categories:
Assumption risk — the risk that your core assumptions about the market, user behavior, or the problem are wrong. This is existential risk. If your fundamental assumptions are wrong, no amount of good execution will save you.
Execution risk — the risk that you won't build the thing well, ship it reliably, or deliver it at the quality users expect. This is important, but it's recoverable. You can improve execution over time.
The mistake many teams make is treating both equally. They spend enormous effort testing and validating execution details while their foundational assumptions go unexamined. Or they move fast on execution without ever stress-testing the assumptions underneath.
Assumption risk first
Before optimizing execution, you need to know what assumptions your business is built on. Not in the abstract — be specific.
For us, the core assumptions included:
- That the pain of meal planning and grocery shopping is significant enough that people will change their behavior for a product that addresses it
- That combining recipe planning with grocery ordering creates meaningful added value over each alone
- That this pain is felt broadly enough to be a real market
Each of these needed to be tested before we committed to building anything substantial around them. And testing means not just "do people say yes in a conversation" but "do people actually change their behavior."
The role of a testing culture
A testing culture isn't about running A/B tests on button colors. It's a mindset — the habit of turning assumptions into explicit hypotheses and then finding the cheapest possible way to validate them.
The cheapest test is often not a product build at all. It might be a landing page, a manual process, or simply a structured conversation with a potential user. Only when you've confirmed the hypothesis enough should you invest in building something.
This sounds obvious, but it's genuinely hard to do. When you're excited about a problem and you have an idea for how to solve it, the natural impulse is to build. Slowing down to explicitly state your assumptions and design a test for each one feels like it's slowing you down. It's not. It's the fastest path.
What we learned from doing this wrong
Early on, we spent months building features we were confident users wanted — based on reasonable logic, some user interviews, and our own instincts. When we shipped them, some worked, many didn't.
Looking back, the failures were almost always traceable to an assumption we hadn't explicitly tested. We had treated something as obvious that wasn't. The build itself was fine; the underlying assumption was wrong.
That experience convinced us to make assumption-testing a first-class activity, not something we do occasionally when we're unsure. Now we ask for every significant decision: what is this decision built on, and have we tested that?
Risk tolerance is contextual
One more nuance: appropriate risk tolerance depends on your stage and resources.
Early-stage startups with little runway need to move quickly and accept that some assumptions will be wrong. You can't test everything — you'll run out of money trying. The art is prioritizing: which assumptions, if wrong, would be fatal? Test those first.
Later, as you have more resources and a product that's working, the calculus shifts. The cost of shipping something flawed rises. Users have expectations. Execution risk becomes relatively more important.
The framework stays the same — separate assumption risk from execution risk, test the former first — but what you can afford to do changes as you grow.
