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:

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:

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:

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:

  1. 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.
  2. 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."
  3. 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.

SignalInterviewsShadowing
Stated priorities and frustrationsStrong — people can articulate what bothers themWeak — you only see what happens, not what they'd say if asked
Actual workarounds in useWeak — often forgotten, minimized, or seen as too mundane to mentionStrong — visible in real time, including ones the clinician doesn't consciously register
Interruption frequency and costWeak — self-reported time estimates are notoriously inaccurateStrong — directly observable and timestampable
Historical context and "why this started"Strong — only a person with tenure can explain the backstoryAbsent — 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 costNeutral — you see how often it actually occurs, which can support or undercut the framing
Edge cases and rare-but-severe eventsStrong — people remember and volunteer the dramatic exceptionsWeak — a single visit is unlikely to catch a rare event at all
Tool-switching and system frictionWeak — people adapt to friction and stop noticing it enough to mentionStrong — 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.

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

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.