Design for the Most Complex Use Case First
Architect for the hardest customer you'll ever have, then choose what to ship first.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 7
- Confidence
- 95%
Jeremy Henrickson's inversion of MVP orthodoxy for companies that already have market validation. Instead of scoping the simplest thing that works, you first model the hardest use case you will ever need to serve (10,000 employees, multi-country, mission-critical), design the architecture to accommodate it, and only then decide which subset ships in v1. The scoping decision stays aggressive; the architectural assumptions do not.
Origin
Developed by Jeremy Henrickson as SVP Product at Rippling, in deliberate opposition to the Lean Startup MVP doctrine popularized by Eric Ries. Henrickson explicitly does not reject MVPs universally — he confines them to pre-validation zero-to-one companies — and argues that for a company with known market demand, an MVP misprices speed against the cost of unwinding architectural assumptions later.
Core principles
- 01An MVP optimizes for speed by minimizing deep product thinking — that is the trade, and it is a bad trade once demand is already proven.
- 02Simple-case-only thinking silently sets architectural assumptions; dozens or hundreds of later decisions get stacked on them.
- 03Architectural assumptions are extremely difficult to unwind after six to twelve months of building on top of them.
- 04Scope and architecture are separable: you can decline to support a case in v1 while still refusing to design it out.
- 05Designing for the hard case costs a little time now and saves far more later.
- 06It is counter-cultural for most hires, so it must be actively taught and enforced with high-touch review during a product's infancy.
How to run it
- 1
Confirm you are past validation
Check whether the market has already told you the product must exist. If you are a zero-to-one company with no market validation, an MVP is the right tool and this framework does not apply. If demand is known (customers are asking, competitors exist as whole categories), proceed.
Pro tip Henrickson's tell: 'the things we're building sort of exist in some form in the industry today' — whole companies do only that one thing. That is validation.
Watch out Do not use this framework as an excuse to skip validation. It is a post-validation tool, not a permission slip to build big.
- 2
Write down the simple case honestly
Describe what the product looks like for the smallest, easiest customer — the two-person company. You still need this; it defines the shipping wedge and stops you gold-plating v1.
- 3
Write down the most brutal case you will ever face
Describe the ridiculously hard use case: 10,000 people globally, mission-critical, regulated, multi-jurisdiction. Push engineers explicitly — 'what about the hospital administration case where it's life-critical?' Make the hard case concrete enough to reason about.
Pro tip Force it into the room by naming a specific brutal customer, not an abstraction. Rippling used six deliberately dissimilar countries rather than 'global'.
Watch out If no one is pushing the engineer on the hard case, the engineer will make simple-case architectural assumptions by default and never mention it.
- 4
Design the technical model that would support the hard case
Do the technical and product design against the hard case. Ask what data model, platform, and configuration surface would be required for the hardest customer to work at all.
Pro tip Look for the 80/20 split: what fraction of the system can be common platform, and what fraction is genuinely case-specific? Rippling landed at ~80% shared global payroll platform, ~20% country-specific.
- 5
Cut scope, not architecture
Make an explicit product decision about which cases v1 will actually support. Ship narrow. But verify that nothing in the build actively prevents reaching the hard case later.
Pro tip Phrase the gate as: 'we are not supporting that case now — does anything we're about to build make it impossible later?'
Watch out This is the step people skip. 'We'll refactor later' is exactly the assumption Henrickson says is extremely difficult to unwind.
- 6
Push the specificity down to non-engineers
Where possible, design the case-specific layer so it is configured rather than coded — compliance and legal staff loading documents and rules into the system instead of engineers changing code.
Pro tip Engineers are the most expensive way to encode local variation. If the hard-case design forces configuration over code, velocity compounds.
- 7
Stay high-touch while the product is an infant
Review designs with senior product leadership every couple of weeks in the early phase. Pressure-test the balance between speed and comprehensiveness, because new people default back to MVP habits.
Watch out Simultaneously demanding 'ship as fast as possible' and 'design for the hardest case' will collapse into MVP thinking unless a leader is actively holding the tension.
In the wild
The fastest path was to copy the US payroll product, change the strings, and launch in the UK. Instead the team decided to launch with six deliberately very different countries, each with different HRIS, employer-of-record, contractor-payment, and payroll requirements, and to build one system that served all six.
→ A global payroll platform where roughly 80% of the system is shared and only ~20% is country-specific — and most of that specificity is configured by compliance and legal staff rather than coded by engineers. Adding a new country became easy rather than another stamped-out replica to maintain.
Rippling's founding insight (Parker Conrad's, pre-company) was that payroll, benefits, device management, and identity each replicate employee data that then falls out of sync. The complex-case answer was one database as the single system of record underneath every product, rather than integrating separate verticals later.
→ Capabilities that are literally impossible for competitors: cross-product permissioning, and trivially answering 'who is this person's manager?' in real time, where other stacks require an exported spreadsheet that is stale on upload.
Common mistakes
Treating MVP as a universal default
The MVP is a validation instrument. Once demand is proven, its speed benefit is real but its cost — shallow product thinking and simple-case architecture — is paid back with interest for years.
Confusing 'design for the hard case' with 'build the hard case'
The framework does not say ship everything. It says design so the hard case remains reachable, then deliberately cut v1 scope. Teams that skip the cut ship late and bloated.
Letting engineers set architecture from the simple spec
If the only cases in the room are easy, the engineer will make architectural assumptions that fit them — and six to nine months of decisions will be stacked on top before anyone notices.
Is it for you?
Best for
Product and engineering leaders at a company with proven market demand who are opening a new product line or entering a new domain, where the eventual customer set includes large, regulated, or multi-jurisdiction users.
Not ideal for
Pre-product-market-fit founders with no market validation, or genuinely disposable experiments where the code is expected to be thrown away.
From the transcript
“a minimum viable product would do a disservice like to both our customers and to like the very team that was building it”
“it's extremely difficult to unwind those decisions once you've built them into the product”
“even if we make like the product decision to say like look we actually don't need to handle that case right now you still build…”
“like solve the most complex use case first right solve the fact that this data all needs to be in the same place”
From the episode
Moving fast and navigating uncertainty
Jeremy Henrickson (Rippling, Coinbase)