Framework
Stop, Listen, Relaunch
Before rebuilding in a complex domain, spend serious time — months, not weeks — doing nothing but listening to the people who live inside the problem: customers, practitioners, adjacent experts. Technology is the easy part. The hard questions — who do you serve, how do you make money, why does this product deserve to exist — must be answered first. Building before you have those answers is borrowing against a debt you will repay at maximum cost.
How it works
- 1Resh spent $30M and multiple pivots at Mercatus building the right architecture for the wrong understood problem. Two years of listening preceded the Diagnostic MD relaunch.
- 2The failure mode is answering questions nobody asked you. You can know what the technology should do without knowing who it's for, how they'll pay, or why they'd choose you.
- 3Listening is not customer discovery calls or a research deck — it is genuine immersion in the problem space without a product agenda.
- 4The three questions to answer before writing code: who do you serve, how do you make money, why does this exist rather than someone else's product.
- 5The Denver investor benchmark: a good investor shows up with explicit yes/no criteria. A founder should operate the same way — know what a good answer looks like before soliciting input.
Hear it on the podcast
Doctors Aren't the ProblemListen to the episodeMore from this episode
The Whole Person DiagnosticEffective diagnosis requires integrating three data streams that no specialist silo currently combines: longitudinal medical records (what the healthcare system has captured), wearable data (continuous biometrics between clinical encounters), and life story — the mind-body layer of trauma, stress, and relational context that the research literature documents as medically relevant but that EHRs structurally exclude. Consumer ownership of the record is the architectural enabler: the patient integrates across institutions because the institution won't.Rookie SmartsThe best technical hire for a domain-disruption problem is not the youngest engineer or the most experienced one — it is the person who has enough experience to recognize what good looks like, and has genuinely shed prior methodology to relearn with modern tools. This is an epistemological posture, not an age argument. Pair this profile with a senior domain mentor who can pressure-test architecture, and you outperform either alone.
Get the next framework first
One email a week with the frameworks, tools, and founder stories from the podcast. Free.
More frameworks for Finding & Validating Ideas
The Third-Party Truth AuditHave a neutral outsider interview users, observe them using the product, and deliver a prioritized action list of bottlenecks blocking revenue. Founders cannot get honest feedback directly: customers soften criticism to protect the founder's feelings, and founders get defensive and hear what they can manage rather than what is being said. A third party removes both distortions and surfaces the real picture.Pre-MVP Concept ValidationBefore writing code, test the concept: a landing page, a waitlist, a single-function prototype, or direct customer questions. Confirm the problem is real and users want to interact with it the way you imagine before committing engineering resources. Most founders skip this step and build the wrong thing at full cost. Fake it until you make it is not a launch strategy — it is a validation strategy.The Three Checkbox FrameworkBefore building any AI product, three boxes must all be checked: (1) distribution on the cap table — equity to people already inside your target market's networks, (2) defensible IP — proprietary data, SOPs, or formulas that cannot be replicated with another model call, and (3) an industry expert involved. If you cannot check all three, the project does not start. Not pauses — does not start.The Founder's Three GuardrailsBefore investing time in any idea, run it through three filters: Is it fun? Does it make money? Is it of service? Add a fourth: Can I be best in the world at this? If any answer is definitively no, stop and move on.The 10 Uncomfortable Conversations RuleYou do not deserve to write a single line of code until you have survived ten customer conversations where you genuinely tried to be told no. Validation is evidence that bruises — not vibes that confirm what you already believe.The Tight Circle Photo Sharing ThesisPeople share photos freely when the social environment is tight, secure, and trusted — not because the product is good, but because the people around them feel safe.