How to Shadow a Clinical Workflow as a Founder
Shadowing a clinical workflow means getting permission to stand in a real clinic or unit and watch care happen, unedited, instead of asking someone to describe it from memory afterward. The process is five steps: get facility permission and agree on privacy ground rules, build a narrow observation plan, take structured field notes during the visit, run a short debrief interview immediately after, and synthesize what you saw into a testable problem statement — not a list of impressions.
Quick Answer: Get written permission from the facility (not just one clinician), agree in advance on what you may see and record, watch a single defined workflow end to end, take timestamped notes on actions rather than opinions, debrief with the clinician the same day, and turn the gap between what people said and what you saw into your problem statement.
Interviews are the cheapest research tool a founder has, and they are also the most distorted. People describe their workflow the way they intend it to run, the way it ran on a good day, or the way they think it should sound to an outsider. None of that is dishonest — it is just how memory and self-report work. Shadowing routes around it. You are not asking someone to reconstruct their Tuesday; you are standing next to their Tuesday as it happens. That is also why it is harder to arrange, easier to get wrong, and far more valuable per hour than another round of interviews once you have already done the first few.
One caution before you schedule anything: the clinician whose workflow you shadow is not automatically your buyer. In healthcare, the person who uses a product and the person who pays for it are frequently different people — a workflow pain a clinician feels every day may still fail to produce a sale if administration, a payer, or an employer controls the budget. Shadowing tells you whether the pain is real and how it behaves under real conditions; it does not by itself tell you who will write the check to fix it. Keep both questions open as you observe.
Prerequisites: permission, privacy rules, and consent basics
Before you plan anything, secure two things in writing: the facility's explicit permission to observe, and a shared understanding of what you are and are not allowed to see, hear, or write down. Skip either one and the observation you gain is not worth the relationship you burn.
Facility permission is not the same as clinician permission. A sympathetic doctor who says "sure, come by Thursday" is not authorization — they are one stakeholder in an organization that has its own rules about who can be present around patients, and those rules exist independently of how enthusiastic the individual clinician is. Go through whoever the facility designates: that might be a practice manager, a department administrator, a research or innovation office, or in a hospital setting a formal visitor and observation process. Ask directly who needs to approve this before you schedule anything, and get the answer in writing rather than assuming a verbal yes from one person covers the organization.
Privacy and compliance requirements vary by facility, by what you observe, and by jurisdiction — do not assume a blanket rule. Some observation involving patient contact triggers a facility's own privacy office review or an institutional review board (IRB) process; some does not, depending on how the facility classifies the activity and what data you touch. This is genuinely inconsistent across organizations, and getting it wrong is not a paperwork inconvenience — it can end the relationship and, depending on what was actually exposed, create real liability for the facility. Do not rely on a rule of thumb you read somewhere, including this article. Ask the facility's own compliance, privacy, or research office what applies to your specific visit, and get their answer in writing before you show up.
Consent basics you should expect to agree to, regardless of the specific process:
- No patient-identifying information leaves the room. Names, birthdates, medical record numbers, and anything else that could identify a specific patient stay out of your notes entirely — not anonymized later, never captured.
- No recording devices unless explicitly authorized. Audio, video, and photography are typically off-limits by default; treat "no" as the assumption and get affirmative written permission for any exception.
- Patients present may need to be informed or may need to consent to your presence, depending on the setting and the facility's policy. This is the facility's call to make, not yours.
- You can be asked to leave at any point, by any clinician or by the patient, with no explanation owed. Agree to this before you walk in, not in the moment.
If a facility cannot articulate what their own process requires, that is a signal to slow down, not a green light to proceed informally.
Step 1: Get access — who to ask and what to ask for
Getting access means identifying the right approval path inside the facility and requesting a narrowly scoped visit, not a general "can I hang around" ask. A specific request is easier to approve than an open-ended one, because the person reviewing it can actually reason about the risk.
Start with whoever already has a relationship with the facility — a clinician you have interviewed, a former colleague, an advisor — and ask them who internally handles observation requests. Cold-emailing a hospital's general line rarely works. When you do reach the right person, be precise about scope: name the specific workflow (for example, "medication reconciliation during ED intake" rather than "how the ED works"), the length of the visit (a half-day is usually enough for a first pass), and what you plan to do with what you learn. Vague requests read as higher-risk than specific ones, because the reviewer cannot bound what you might see or do.
Expect this to take longer than an interview to schedule — weeks rather than days, sometimes longer for hospital settings. Build that lead time into your research plan instead of treating access as a step you can compress under deadline pressure.
Step 2: Build an observation plan before you walk in
An observation plan is a one-page document naming the specific workflow you are watching, the questions you are trying to answer, and what you will and will not do while present — written before the visit, not improvised during it. Without one, you default to watching whatever is interesting in the moment, which produces vivid anecdotes and very little you can compare across visits.
Your plan should answer:
- What single workflow are you observing? Not "the clinic" — one defined process, like intake, triage, discharge, or a specific documentation task. Narrow beats broad; you can always schedule a second visit for a different workflow.
- What do you already believe, and what would change your mind? Write your current hypothesis about the pain point down before you observe. Shadowing is most valuable when it can falsify something you thought you knew, and you cannot notice that happening if you did not write the "before" down.
- What will you literally do with your hands? Decide in advance whether you take paper notes, a structured checklist, or nothing until after — and confirm that plan is inside what the facility approved.
- What is your exit trigger? Decide ahead of time what would make you step out or end the visit early — a patient objects, a clinician signals discomfort, an emergency unfolds. Deciding this in the calm of your desk is much easier than deciding it live.
Step 3: Take field notes that capture actions, not opinions
Good field notes record what happened, in the order it happened, with rough timestamps — not what you think it means. The interpretation step comes later, deliberately separated from the observation, because mixing them in real time causes you to notice only the things that confirm what you already expected.
A simple two-column format works well: time on the left, observed action on the right. "9:14 — clinician re-enters same patient info into second system after printout jammed" is a note you can act on later. "9:14 — system seems really inefficient" is a conclusion wearing the costume of a note, and you will not remember what specifically prompted it by the time you write your report.
Specifically capture:
- Workarounds. Any moment someone does something the "official" process does not describe — a sticky note, a personal spreadsheet, a phone call instead of the intended channel — is usually a louder signal than anything said in an interview.
- Interruptions and their cost. Note what interrupted the task, and roughly how long it took to resume. Interruption cost is one of the hardest things to get accurately from a self-report interview, because people underestimate how disruptive interruptions are to their own flow.
- Points of friction with tools. Any hesitation, re-click, switch between systems, or visible frustration with software — logged with enough detail that you could describe the exact screen or step later.
- What did not happen that you expected to. An absence is data. If a step you assumed was standard never occurs, write that down too.
Do not write down anything that identifies a specific patient. If a detail is unavoidably tied to patient identity and matters to your note, describe the workflow moment in the abstract and leave the identifying detail out entirely.
Step 4: Run a debrief interview the same day
A debrief interview is a short conversation with the clinician immediately after the observation, focused on the gaps between what they told you beforehand and what you actually watched. Same-day matters — memory of the specific visit fades fast, and the clinician's own recollection of an unusual moment (a workaround, an interruption) will flatten within a day or two just like anyone else's.
Keep it short — fifteen to twenty minutes is usually enough — and structure it around specific moments you observed rather than general questions. "I noticed you re-entered the same information twice around 9:14, walk me through why" gets a far more useful answer than "how is the workflow going for you." You are asking them to explain something concrete you both just witnessed, which sidesteps a lot of the self-report distortion that makes plain interviews unreliable in the first place.
Ask directly about anything that surprised you: a workaround you did not expect, a step that seemed to take longer than it should, a tool switch that looked awkward. Their explanation — a good reason, a known problem they have flagged before, or something they had not consciously noticed — is itself useful data about how visible the pain point already is inside the organization.
Step 5: Synthesize observations into a validated problem statement
Synthesis means comparing what you saw against what people told you in prior interviews and writing the gap down explicitly as your problem statement — not summarizing the visit as a narrative. The value of shadowing is almost entirely in that comparison; a description of "what happened" without a "compared to what I expected" is a diary entry, not research.
A useful synthesis answers three questions in order:
- Where did observed behavior diverge from described behavior? Name the specific divergence — a workaround nobody mentioned, a step that takes far longer than described, a frustration that surfaced only under observation.
- How often and how costly does the divergence appear to be? One visit does not give you a statistic, but it gives you a directional read — worth flagging as "observed once, appears routine based on how casually staff handled it" versus "observed once, clinician described it as unusual."
- What would a solution actually need to be true to fix this? Translate the gap into a constraint your product has to satisfy, not a feature idea. "Any fix has to work when the primary system is down" is a constraint from an observed workaround; "build an offline mode" is a premature leap to a solution before you have validated the constraint with more than one site.
This is the same discipline Rob Fitzpatrick describes in The Mom Test: what people say in a conversation is weak evidence, and what they do — especially what they do when they think no one is grading them on it — is strong evidence. Shadowing is The Mom Test applied to a workflow instead of a conversation: you are watching for the gap between the polite, coherent story and the messy, workaround-riddled reality, and treating that gap as the actual finding. If you have not yet formalized how you weight self-reported versus observed evidence across your research, the complete guide to customer research for founders covers that evidence hierarchy in more depth, and it is worth doing before you invest in a second shadowing visit.
What interviews miss and what shadowing catches
Interviews and shadowing are not competing methods — they answer different questions, and conflating them is how founders end up over-trusting a single round of conversations. The table below lines up what each method is actually good at, so you can plan which one you need next rather than defaulting to more interviews because they are easier to schedule.
| Signal | Interviews | Shadowing |
|---|---|---|
| Stated priorities and frustrations | Strong — people can articulate what bothers them | Weak — you only see what happens, not what they'd say if asked |
| Actual workarounds in use | Weak — often forgotten, minimized, or seen as too mundane to mention | Strong — visible in real time, including ones the clinician doesn't consciously register |
| Interruption frequency and cost | Weak — self-reported time estimates are notoriously inaccurate | Strong — directly observable and timestampable |
| Historical context and "why this started" | Strong — only a person with tenure can explain the backstory | Absent — a single visit shows you the present, not the history |
| Emotional framing ("this is a huge pain point") | Strong, but overweighted — passion in an interview doesn't equal frequency or cost | Neutral — you see how often it actually occurs, which can support or undercut the framing |
| Edge cases and rare-but-severe events | Strong — people remember and volunteer the dramatic exceptions | Weak — a single visit is unlikely to catch a rare event at all |
| Tool-switching and system friction | Weak — people adapt to friction and stop noticing it enough to mention | Strong — visible even when the person no longer consciously registers it |
The takeaway: interviews are better for history, priorities, and rare events; shadowing is better for frequency, cost, and the workarounds people have stopped noticing. Run both, in that order — interviews to build a hypothesis, shadowing to test whether the hypothesis survives contact with an actual Tuesday. For a broader map of where clinical pain surfaces before you ever get to a facility, where to find clinical pain points is a useful earlier step in the same research sequence.
Mistakes that get you un-invited
The fastest way to lose access — for yourself and for other founders who come after you — is to treat the visit as a casual favor instead of a formal privilege the facility is extending at some risk to itself. A handful of specific mistakes account for most burned relationships.
- Skipping the facility's own process because a clinician vouched for you. A friendly clinician cannot authorize your presence on the organization's behalf. Going around the formal process, even with good intentions, puts the clinician who invited you at risk along with your own access.
- Recording without explicit permission. Pulling out a phone to snap a photo of a workflow diagram or a screen "just for my own notes" is one of the fastest ways to end a visit on the spot, because it is very hard to prove after the fact that nothing identifying was captured.
- Writing down patient-identifying detail because it seemed harmless in context. A first name, a room number combined with a date, a distinctive detail about a case — any of these can be identifying even when no name is attached. Default to leaving it out entirely rather than judging case by case.
- Asking clinical staff to explain things mid-task. Your questions belong in the debrief, not layered on top of live patient care. Interrupting someone to satisfy your curiosity while they are actively treating a patient is a safety issue, not just a courtesy one.
- Overstaying the agreed scope. If you were approved for a half-day observing intake, do not wander into a different unit because it looked interesting. Scope creep during the visit is exactly the kind of thing that makes a facility regret saying yes to the next founder who asks.
- Publishing or sharing what you saw without checking what was actually approved. Even de-identified observations can carry facility-specific detail that was never cleared for external use. Confirm what you can share, in what form, before you write it up anywhere outside your own notes.
Every one of these mistakes has the same underlying fix: treat every boundary — what you can see, record, ask, and share — as something to confirm explicitly rather than infer from a friendly atmosphere in the room.
Key Takeaways
- Facility permission, not clinician enthusiasm, is what authorizes a visit — go through the facility's designated process and get it in writing before scheduling anything.
- Privacy and compliance requirements are facility- and case-specific — ask the facility's own compliance or privacy office what applies to your visit rather than assuming a general rule.
- A narrow, written observation plan beats an open-ended visit — name one specific workflow, your prior hypothesis, and your exit trigger before you walk in.
- Field notes should record actions and timestamps, not interpretations — save the "what does this mean" step for after the visit, done separately from the observation itself.
- The same-day debrief is where the real insight surfaces — ask the clinician about the specific moments you observed, not general questions about how things are going.
- Synthesis means naming the gap between what was said and what was seen — that gap, not a narrative summary of the visit, is your actual problem statement.
- Interviews and shadowing answer different questions — use interviews for history and priorities, shadowing for frequency, cost, and workarounds people have stopped noticing.
- A handful of avoidable mistakes — unrecorded permission, live-task interruptions, scope creep — are what get founders un-invited, and they cost access for whoever asks after you too.
Frequently Asked Questions
Can a startup founder legally shadow a clinical workflow?
Yes, with the facility's explicit permission — there is no blanket law against it, but there is no automatic right to it either. Access is granted at the facility's discretion, typically through a formal request process, and what you may observe, record, or write down is set by that facility's own policies. Always confirm the specific requirements with the facility's compliance or privacy office rather than assuming a general rule applies.
Do I need IRB approval to shadow a clinic?
It depends on the facility and on what you are observing — some observation triggers a facility's institutional review or privacy process, and some does not, based on how that organization classifies the activity. This varies enough between institutions that no single answer is reliable. Ask the facility directly what their process requires for your specific visit before you plan around an assumption either way.
How long should a clinical shadowing visit be?
A half-day is usually enough for a first visit focused on one specific workflow, long enough to see a full cycle of the process without asking the facility for more access than a first visit warrants. If the workflow you care about only occurs occasionally, or you need to see variation across different staff or shifts, a second, separately approved visit is a better approach than trying to extend the first one.
What is the difference between shadowing and a site visit or ride-along?
They largely describe the same activity — observing a real environment with permission — but "shadowing" typically implies following one person's workflow closely, while "site visit" can mean a broader look at a facility or team without focusing on one individual's process. Use whichever term the facility itself uses when you request access, since it signals you understand the scope they are likely to expect.