Shadowing > Interviews
Why watching the work reveals what talking about it hides
This might make me sound nosy. Maybe even invasive. But if you are building anything in startup land, you are already in the business of getting uncomfortably close to how things actually work. That is the job.
If I had to define a startup in one sentence, I would say a startup is a search. A search for a real problem, a working business model, customers, distribution, the right people, and ultimately what actually works. The day that search stops, it starts becoming something else.
Because of that search, one of the first things founders are told to do is interview users. That advice is right. But I have slowly reached a point where interviews alone are no longer enough for me, because some of the most useful information never comes up when people are sitting across from you answering questions. It shows up when they are in motion. It shows up while the work is happening, in the pauses, the workarounds, the handoffs, the interruptions, the unwritten steps, and the small frustrations that have become so normal they no longer feel worth mentioning.
That is why, more and more, I have started to prefer shadowing over interviewing. Not instead of interviews, but often before them, and almost always alongside them.
What the dust taught me
Over the past months, I have found myself in all kinds of places. On a truck or in a tuktuk for hours, collecting more dust than dignity. In offices watching admin teams move piles of documents from one desk to another. Out in the field with sales agents. Following contractors during procurement. Sitting inside workflows that looked simple from the outside and turned out to be messy once you got close.
And almost every time, the information I got from shadowing was more valuable than what I would have learned from a 30-minute or one-hour conversation. Why? Because people are often too used to their own process to explain it properly. They skip details because those details feel obvious. They forget steps because they do them automatically. They leave out friction because they have adapted around it. And sometimes they do not frame the problem as an opportunity, because they are not looking for one. You are. That difference matters.
A worker in the field is trying to finish the task. A founder is trying to understand where value leaks, where friction accumulates, and where something broken keeps pretending to work. Those are not the same lenses. So when you only interview, you mostly get the narrated version of reality. When you shadow, you get reality itself.
The things you actually see
You see the extra call that should not have been necessary. The notebook that is quietly more important than the software. The middleman who seems inefficient until you realize he is holding the whole system together. The delay everyone has normalized. The decision-maker who never appears in the org chart. The workaround that is basically the real product opportunity sitting right there in plain sight.
Paul Graham has a concept he calls schlep blindness, which is the idea that people unconsciously avoid thinking about problems that involve tedious, ugly, or unpleasant work. Your brain will not even let you see the opportunity because the schlep around it feels too painful to deal with. He uses Stripe as an example. Everyone in tech knew that online payments were broken, but nobody wanted to wade into the mess of banks, regulations, and legacy infrastructure required to fix it. The Collisons did, and that is why Stripe exists.
I think something similar happens on the ground when you are doing customer discovery. The people you are shadowing have their own version of schlep blindness. They have lived with the broken process for so long that it has become invisible to them. They have normalized the extra step, the manual workaround, the thing that costs them 20 minutes every day but never feels urgent enough to complain about. When you interview them, they will not bring it up because it does not register as a problem anymore. But when you shadow them, you see it happening in real time. That gap between what people have stopped noticing and what you notice with fresh eyes is where some of the best startup ideas live.
How shadowing makes your interviews better
This is also why I think shadowing sharpens interviews. Because once you have seen the work, your questions improve. You stop asking broad questions like “what is your biggest challenge?” and start asking ones that actually reveal something useful. Questions like “why did you call that person before continuing?” or “why is that step done twice?” or “why do you write this down here if it already exists in the system?” or “what would break if this one step was removed?”
Those questions usually do not come from theory. They come from watching.
Paul Graham has written a lot about talking to users and I agree with that instinct completely. But I would add something to it. Do not just talk to your customers. Shadow them. Observe the task, observe the environment, observe the sequence, observe who else enters the workflow, and observe what people do when no one is asking them to explain themselves.
The art of doing it right
That said, shadowing is not just “go stand next to someone and stare at them” (Just... don't come to me when you get arrested for unsolicited stalking.) It has its own craft. Done badly, it can make people defensive, self-conscious, or performative, and once that happens, you are no longer observing the work. You are observing a staged version of it.
So the how matters. It helps if there is already trust, if the person understands you are exploring the process and not auditing their mistakes. It helps if you ask fewer questions at the start and let the work unfold first, then write notes step by step as things happen. It helps if they introduce you to the other people they depend on, because the most interesting insights are usually at the edges of one person’s workflow where it connects to someone else’s. And yes, sometimes it helps if you make yourself useful instead of just hovering like a suspicious consultant.
The goal is not to interrogate. The goal is to see.
One last thing
If you are trying to solve a problem, even if you think you know the domain well, be careful with assumptions. Domain knowledge can help you notice more, but it can also make you lazy. You start thinking you already understand the workflow, and you start filling in blanks with what you expect to see instead of what is actually there. And very often, the real opportunity is hiding inside the part everyone has stopped noticing, including you if you are not paying attention.
So be patient and be observant. Before you build from what people say, spend time watching what they do. Because interviews tell you what people remember. Shadowing shows you what reality refuses to say out loud.


