The Three Delays Model was first described in 1994 to explain why women die in childbirth in low-resource settings even when care is technically available. The first delay: the decision to seek care. The second: reaching adequate care. The third: receiving care once there.
I came across it when researching MamaReady and it changed how I think about product design permanently. Not because healthcare problems are like software problems. But because the framework is a precise vocabulary for something software products struggle with constantly: the gap between a need existing and that need being met.
Delay 1: The decision problem
In the maternal health context, the first delay is caused by failure to recognise warning signs, cultural norms that discourage seeking care, and household decision-making structures that slow the response. The intervention is education and role-clarity before the emergency.
In software, this maps to: does the user recognise they have a problem your product solves? Do they feel permitted to act on it? Is there friction in the decision-making chain between them and action?
Most software thinks about this as a marketing problem. I've started treating it as a product architecture problem. If a user has to make three decisions before they can do the thing they came to do, you've introduced delay one. Onboarding flows that require email verification before showing value. Settings that live behind administrator approval workflows. Features that require reading documentation before they're usable.
"The first delay isn't the user's fault. It's the product's failure to make the path to value obvious and immediate."
Delay 2: The access problem
In obstetric emergencies, the second delay is transport, distance, and cost. Women who know they need care and want to seek it can't get there.
In software, this is every friction point between intent and action. Payment flows that require a credit card when the user doesn't have one. Apps that require a fast connection when the user is on 3G. Interfaces that require a desktop browser when the user is on mobile. Pricing that requires a USD credit card when the user earns in Naira.
I now explicitly map access delays when designing features. Who is this for? What does their device look like? What's their connection? What's their payment method? Where do they typically use this? The answers create constraints that lead to better design decisions, not worse ones.
Delay 3: The readiness problem
The third delay is the one I find most interesting for software. A woman arrives at a facility on time, with help, having made all the right decisions — and dies because the clinic is out of blood, the anaesthetist isn't there, or the equipment isn't working. The system was ready in principle but not in fact.
In software, this is the backend that times out under load. The payment processor that fails on African-issued cards despite technically supporting them. The feature that works in the demo environment and fails in production. The customer support team that can't actually resolve the issue the product creates.
MamaReady addresses the third delay directly by sending a pre-arrival notification to the facility. The intervention is giving the system time to prepare. In product terms: what would it mean to give your systems — and your team — advance notice before load arrives? What would pre-arrival readiness look like in your context?
Why frameworks from outside software are worth borrowing
Software has a lot of internal frameworks for thinking about products. Funnels, jobs-to-be-done, north star metrics, OKRs. They're useful within their scope. But they were all designed by people who spend their time thinking about software, which means they share the same blind spots.
Borrowing a framework from obstetric emergency care forced me to think about user experience in terms of time-to-intervention and systemic failure modes rather than conversion rates and feature adoption. The vocabulary is different enough to be disruptive. I'd encourage picking up frameworks from medicine, logistics, crisis management, urban planning — anywhere that takes seriously the question of what happens when things go wrong for someone who can't afford for things to go wrong.