Pre‑Launch Timeline: Validating a Health Tech Idea in 90 Days

It’s July 1st. You just finished residency. Your hospital badge still works, but your calendar is suddenly…empty. You’ve got a health tech idea you’ve been mulling over on call nights, and you’re staring at a 3‑month gap before your attending job starts or your contract really ramps up.

You’re asking yourself: is this idea actually good, or am I just sleep‑deprived and romantic about startups?

Here’s the plan: 90 days. No code (or minimal). No raising money yet. Just hardcore validation. At each point, you’ll know what you should be doing, what you should have in hand, and what’s a red flag to kill or pivot the idea.

---

High‑Level 90‑Day Map

90 Day Health Tech Validation Timeline

Period	Event
Month 1 - Days 1-7	Problem + hypothesis
Month 1 - Days 8-21	Customer discovery interviews
Month 1 - Days 22-30	Define MVP + success metrics
Month 2 - Days 31-45	Prototype + refine with users
Month 2 - Days 46-60	Willingness to pay + pilot design
Month 3 - Days 61-75	Small pilot or concierge test
Month 3 - Days 76-85	Analyze data + iterate
Month 3 - Days 86-90	Go / no go / pivot decision

Think of this as a sprint, not a side hobby. Treat it like a clinical trial for your idea.

---

Days 1–7: Get Ruthlessly Clear on the Problem

At this point you should stop playing with solutions and force yourself to state the problem like a consult question.

Day 1–2: Write the one‑liner

You’re coming from residency, so you’ve seen a mess of problems. That’s the trap. Too many problems, zero focus.

You want:

• A narrow user: “hospitalist attending at a community hospital,” “RN in outpatient oncology,” “practice manager at a 4‑physician primary care group.”
• A specific problem: “spends 2 hours/night cleaning up prior auths,” “loses 15% of referrals because faxes vanish,” “no‑shows wreck clinic templates.”

Template that actually works:

“I’m building [solution type] for [very specific user] to [relieve painful, measurable problem] so they can **[tangible outcome].”

Example:

• “I’m building a lightweight web tool for community hospitalists to auto‑generate clean discharge summaries from the EHR so they can cut discharge time by 10 minutes per patient.”

If you can’t get this into one line, the idea is still soup. You don’t build in soup.

Day 3–4: Map the current workflow

You know the clinical side. But you probably underestimate the admin guts.

Grab a notebook or whiteboard. Map:

1. Who touches the process (roles, not names).
2. What systems are used (Epic, Cerner, Athena, Excel, paper, WhatsApp—yes, really).
3. Where the friction is: delays, handoffs, double entry, error‑prone steps.

You want a simple, brutal flow:

• Order placed → nurse notified → fax goes nowhere → MA calls → patient confused.

If you haven’t drawn the current workflow, you don’t understand the problem. Full stop.

Day 5–7: Write your initial hypotheses

You’re not guessing forever; you’re guessing to test.

Document:

• Who has the problem (primary user, economic buyer, IT blocker).
• How often it happens (daily, weekly).
• How they solve it now (workarounds, extra staff, spreadsheets).
• What it costs (time, dollars, clinician burnout, penalties).

Then write 3–5 falsifiable statements. Example:

• “Hospitalists at non‑academic hospitals spend >60 minutes/shift on manual discharge summary cleanup.”
• “At least 50% would try a tool that cuts that time in half without extra clicks in Epic.”
• “At least 3 hospitals in my state would pay ≥$10k/year for this if we integrate with their existing print‑to‑fax workflow first, not full EHR integration.”

This is your starting line. Over the next 83 days, you’re trying to break these statements.

---

Days 8–21: Customer Discovery (Talk to Humans, Not Your Laptop)

At this point you should be talking to real users every single day. If this part makes you uncomfortable, good. That’s where most clinician‑founders screw up—they stay in PPT land.

Day 8–10: Build your interview pipeline

You need 20–30 conversations minimum. More is better. How you get them:

• Former co‑residents in other hospitals
• Attendings you worked with
• Nurses, MAs, front‑desk staff you actually know
• Practice managers, medical directors, CMIOs

Send a short, honest outreach:

“I just finished residency and I’m exploring a tool to fix [problem]. You deal with this way more than I do. Can I get 20 minutes to hear how you handle it now? Not selling anything, just trying to not build garbage.”

Book calls over 2 weeks. Aim for 2–3/day.

Day 11–18: Run structured interviews

You’re not pitching. You’re listening. If you talk more than 30% of the time, you’re doing it wrong.

Use a loose script:

1. “Tell me about the last time this happened.”
2. “Walk me through what you did, step by step.”
3. “What sucked the most about that?”
4. “What have you already tried to fix it?”
5. “If I could wave a magic wand and change anything about this, what would it be?”

Do not ask, “Would you use this?” That’s how you get polite lies.

Record calls (with permission) or take fierce notes. After 5–7 interviews, you’ll start hearing patterns. After 20, the story’s either solid or shaky.

Day 19–21: Synthesize and refine your idea

Sit down and synthesize like you’re writing an H&P:

• Top 3 pains that came up repeatedly
• Current workarounds and their costs
• Words they used (this becomes your copy later)
• Any early signs of “I would pay for that” or “we already solved this”

Now revise your one‑liner and hypotheses.

If you discovered they don’t actually care that much about your original issue—but they kept ranting about, say, prior auths for specialty meds—consider a pivot now rather than at Day 80.

---

Days 22–30: Define the MVP and the Scoreboard

At this point you should stop wandering and commit to a first version and clear success metrics.

MVP ≠ “First version of the app”

For the first 90 days, “MVP” is the cheapest way to test behavior, not show off UI.

Options:

• Clickable prototype (Figma, InVision)
• Concierge service: you do the thing manually behind the scenes
• No‑code tool (Airtable, Bubble, Glide)
• Even a spreadsheet + shared inbox

Pick the one that lets you see:

• Do they actually use this?
• Does it actually save time / money / reduce pain?

Define your 90‑day validation metrics

your scoreboard should fit on a post‑it. Examples:

• Engagement: “≥60% of pilot users use it at least 3x/week by Week 3.”
• Value: “Avg time saved ≥10 minutes per discharge summary in pilot.”
• Money: “At least 2 decision makers say, in writing, they’d pay ≥$X/year if results hold.”

Make these numbers uncomfortable but realistic. If your metric is “users like it,” you’ve already lost.

---

Month 2 (Days 31–60): Prototype, Test, and Price Reality

Now you’re out of the theoretical phase. At this point you should be putting something in front of users and asking them to commit, with their time or their budget.

---

Days 31–45: Build a Testable Prototype

You are not building a full health tech product. Not in 2 weeks. If you try, you’ll drown in over‑engineering and never launch.

Pick your weapon:

• Figma prototype for workflow tools: mock screens that simulate the experience.
• No‑code app if you need real data entry and simple logic.
• Concierge / manual backend for anything complex: e.g., they submit data via form, you process in the background and send them results.

Set a hard 14‑day build window. Feature discipline:

• Must‑have: directly tied to top 1–2 pains you heard.
• Nice‑to‑have: everything else. Logged, not built.

If you catch yourself arguing about button color, you’re procrastinating.

Days 40–45: Prototype review sessions

Schedule 5–10 quick sessions with earlier interviewees. Script:

1. Give 30‑second context. That’s it.
2. “Click through this as if you were using it on a real patient.”
3. Shut up and watch.

Look for:

• Where they hesitate or get confused
• Where they say, “But in real life I’d need to do X here”
• Whether they reach the “value moment” (time saved, fewer clicks, clear visualization)

Ask at the end, bluntly:

• “If this existed tomorrow, would you actually try it for a week?”
• “What would need to be true for your team to adopt this?”

Document changes. Iterate once, not forever.

---

Days 46–60: Test Willingness to Pay and Design the Pilot

Here’s where most clinician‑founders chicken out. They’re happy to hear “this is cool,” but they never ask, “Would you pay for this?” You’re not doing that.

Days 46–52: Pricing conversations

At this point you should be talking to buyers, not just frontline users.

Buyers in health tech usually mean:

• Practice managers
• Service line directors
• CMIO / CMO / COO
• Private practice owners

Use your network: “Who actually signs software contracts here?”

Then run short, direct calls:

1. Describe problem in their language: “Your hospitalists are spending X time on Y, costing Z.”
2. Show 1–2 screens or a short walkthrough.
3. Ask: “If this reliably did [outcome], what sort of budget range would even be realistic for a tool like this?”

Push a bit:

• “Is that number a ‘wish it were that low’ number or a ‘this is what we can actually pay’ number?”
• “What other tools do you pay for now in that range? What do they have we’d need to show?”

You’re not trying to close a deal, but you are trying to surface real budget numbers.

Days 53–60: Pilot design

Now you sketch a concrete mini‑trial.

Element	Example Choice
Setting	1 community hospitalist group
Users	8 hospitalists, 2 case managers
Duration	30 days
Scope	Discharges on 1 medical floor
Primary Metric	Minutes saved per discharge
Secondary	User satisfaction (1–5 scale)

Decide:

• Who’s in vs out
• What baseline you’ll measure (time/task before your tool)
• How you’ll measure outcomes (timers, counts, simple forms)
• What “success” is numerically (e.g., ≥8 minutes saved, ≥4/5 satisfaction)

Lock this into a 1‑pager. This is what you’ll use in Month 3 to actually test.

---

Month 3 (Days 61–90): Run a Small Pilot and Make a Hard Call

This is where the idea stops being “interesting” and either becomes real or gets shelved. At this point you should be okay with killing it if the data is weak.

---

Days 61–75: Run a Small, Ruthless Pilot or Concierge Test

If you can’t get a formal pilot in 90 days (fair, hospitals are slow), do a concierge pilot with a very small group using manual methods.

Step 1: Confirm participation and expectations

Email or message your pilot users:

• What you’re testing
• What they’ll have to do (realistically, in <5 minutes per patient/use)
• How long this will last
• What they get: data, maybe a small gift card, early access, whatever

If people hesitate at a 30‑day low‑friction pilot, that’s a signal. They don’t care enough.

Step 2: Set up the measurement

Have a simple way to log:

• Time spent with vs without your solution
• Frequency of use
• Any relevant hard outcomes (e.g., number of fax failures, number of no‑shows, number of incomplete discharges by noon)

Use:

• Short Google Forms
• A simple toggle in your tool
• A shared spreadsheet

You do not need a perfect analytics stack to see if you chopped 15 minutes off a discharge.

Sample Pilot Usage Over 4 Weeks

Category	Value
Week 1	10
Week 2	25
Week 3	32
Week 4	35

You want a trend that goes up or stabilizes at meaningful usage. Flat or declining is bad. Very bad.

Step 3: Maintain contact

Check in weekly:

• “What’s annoying?”
• “What broke?”
• “What did you ignore because you were too busy?”

This is qualitative gold. But treat it as data, not personal criticism.

---

Days 76–85: Analyze Results Like a Clinician, Not a Cheerleader

Now you stop being the proud parent and put on your attending hat. At this point you should decide based on numbers, not narrative.

Step 1: Compare to your original metrics

Pull your original 90‑day hypotheses:

• Did they use it ≥X times/week?
• Did it save ≥Y minutes or produce ≥Z fewer errors?
• Did at least one buyer say, “We’d pay for this” at the price range you heard?

Be brutally honest. “They said they liked it” doesn’t count.

Step 2: Summarize in one concrete page

Write a one‑page “pilot readout”:

• Problem statement
• Who used it (and where)
• Before vs after metrics
• Qualitative quotes (good and bad)
• Your interpretation: Did you hit, exceed, or miss the targets?

If you can’t show a single convincing number on that page, investors and buyers won’t take you seriously later. And they’ll be right.

---

Days 86–90: Decide: Go, Pivot, or Stop

You’ve got data. Now you choose. At this point you should commit, not drag this out another 6 vague months.

Use this simple frame:

Decision	When to Choose It
GO	Strong usage + clear value + real budget signals
PIVOT	Clear problem, weak solution fit
STOP	Weak problem, weak enthusiasm, no real buyer

GO: Green light to build more

Signals:

• Users actually changed behavior. They used it consistently without you begging.
• You hit or came close to your metrics (e.g., 8–10 minutes saved per task).
• At least one buyer said, “If results hold and you integrate with X, we’d pay.”

Next moves after Day 90 if you GO:

• Decide if you’re doing this part‑time with a job or committing full‑time.
• Start exploring technical co‑founders or agencies carefully.
• Tighten the product scope for a v1 that can be sold to 1–3 paying customers.

PIVOT: Same user/problem, different angle

Signals:

• Everyone agrees the problem is real and painful…
• …but your current approach is clunky, too disruptive to workflow, or technically overkill.

Examples:

• They don’t want a “new app,” but they do want a smart template inside their existing email system.
• They don’t care about fancy analytics; they just want automated reminders.

Pivot means you keep:

• Same user
• Same general pain

But you change:

• Solution format
• Entry point (e.g., start as a reporting tool, not workflow automation)

Give yourself another 60–90 days to test the pivot, not another year.

STOP: Respectfully kill it

Signals:

• People are polite but uninterested.
• Real usage never happens, even with you holding their hand.
• Buyers either have no budget or say, “We get that from our EHR vendor” or “our IT team will handle that.”

Killing an idea is not failure. Dragging a bad idea out for 3 years while your clinical career stalls—that’s failure.

If you stop, document what you learned. The next idea will be 10x better because you now know:

• Where budget really sits
• What adoption friction looks like
• How slow health systems move

Outcomes After 90-Day Validation Cycles

Category	Value
Go	25
Pivot	35
Stop	40

And yes, those ratios are realistic. Most ideas should die early. That’s the point.

---

Quick Reality Check: Time and Energy as a New Attending

You’re post‑residency. Maybe you’re moonlighting, maybe starting a job. You’re not a 22‑year‑old with no responsibilities.

So be strategic:

• Block 10–15 hours/week for this 90‑day sprint.
• Use early mornings or one protected day if you can swing it.
• Batch work: one day for interviews, another for analysis, another for prototype tweaks.

If you can’t protect that time for 3 months, you probably can’t run a startup yet. Harsh, but true.

---

The 3 Things That Actually Matter in These 90 Days

Keep this front and center:

1. Talk to ≥30 real users/buyers, not your friends, not LinkedIn randos.
2. Run at least one concrete, time‑boxed pilot or concierge test with measurable outcomes.
3. Make a hard go / pivot / stop decision at Day 90, based on numbers, not vibes.

Do that, and you’ll be miles ahead of most “stealth health tech” projects that live forever in someone’s Google Drive and never touch a patient or a clinic.