Show Me Your Day, Not Your Org Chart

Most discovery conversations go wrong in the first ten minutes, and they go wrong in a very specific way: the consultant starts explaining, and the client starts describing the company the way they’d describe it to an investor. You get the org chart. You get the mission. You get the tidy, sanitized version of how the work is supposed to flow. And none of it tells you the one thing you actually need, which is where it hurts.

The best question I know is some version of: don’t tell me how the company is organized. Show me your day. Walk me through what you actually did yesterday, hour by hour, including the annoying parts. Because the annoying parts are the entire point. The drudgery is the spec.

“The drudgery is the spec.”

The inbox that became a to-do list

Let me make this concrete with a generalized example that’s stuck with me. I was talking with a professional in a demanding field (high volume, high stakes, lots of deadlines) and instead of pitching, I just asked her to describe how work actually reached her and what she did with it. And out came the real picture: her inbox had quietly become her de facto task manager. Everything arrived there, nothing was triaged, and so she lived in a permanent state of reaction: whatever was loudest and most recent got her attention, and the small things kept getting pushed down.

And here’s the detail that was pure gold, the kind you could never invent from an org chart: the little five-minute tasks, the ones too small to feel urgent, would sink to the bottom of the inbox and get forgotten, until they missed a deadline and detonated into full-blown crises. A five-minute job, ignored because it was small, becoming a blown-up nightmare because it was late. She said it with real frustration, in her own words, and I remember thinking: that’s it. That sentence is the product. You don’t have to guess what to build. She just told you. A system that makes sure the small, easy, deadline-bearing things never sink out of view is the whole value proposition, handed to you, because you asked about her day instead of her department.

That’s the lesson under the lesson. The client’s frustration, in the client’s own words, is your brief. You don’t translate it into consultant-speak and improve on it. You build exactly the thing that makes that specific sentence stop being true.

Count the pain

Pain that’s only described is easy to wave away. Pain that’s counted is undeniable, and quantifying it is half your job in a discovery call.

So I push for numbers, gently. How many of these emails a day? (The answer, often, is a number that makes the room go quiet: hundreds.) When one of these comes in, how many downstream items does it spawn? (One request coming in the front door can fan out into dozens of related tasks nobody sees from the outside.) How many of these matters are you tracking at once, each with its own deadline? (Thousands, sometimes.) Each of those numbers turns a vague “we’re overwhelmed” into a hard, specific, buildable problem, and, not incidentally, into the exact figures that will justify the project to whoever signs the check. The volume is both the diagnosis and the business case. Get the numbers.

Do your homework, then shut up

There’s a balance in these conversations that took me years to get right. You have to show up knowing something: I always research a prospect’s industry beforehand so I can speak their language and not waste their time explaining their own world back to them badly. Walking in ignorant is disrespectful and it shows.

But (and this is the part people get wrong) knowing something is not the same as leading with your theory. My posture in the room is basically: I’ve done my homework, I have a hypothesis about where your pain probably is, and I’m going to keep it in my pocket and let you tell me first. Because the moment you lead with your theory, you contaminate the well. The client starts agreeing with you, or performing the problem you named, instead of telling you the real one. Prepared enough to understand them, quiet enough to let them surprise you. That’s the stance. Your homework is for comprehension, not for the pitch.

Turn the sentence into a spec

So you’ve done it right: you asked about their day, you counted the pain, you kept your theory in your pocket, and the client handed you the golden sentence, the vivid frustration in their own words. Now comes the part people fumble: what you do with that sentence.

The mistake is to take it back to your team and improve on it: to translate their messy, specific complaint into tidy consultant language, abstract it into a “workflow optimization initiative,” and lose the exact thing that made it valuable. Don’t. The sentence is the specification. Your job is to write the success metric as the precise inverse of their complaint and then build exactly that, nothing grander. If the pain was “small deadline-bearing tasks sink to the bottom of my inbox and blow up,” then success is “no deadline-bearing task ever drops out of view,” full stop. Not a reimagined operating model. That one thing, made reliably true.

And here’s the quiet superpower of doing it this way: when you show the client the solution, you show it back to them in their own words. You say, in effect, “you told me the little things sink and detonate: here’s the thing that makes sure they never sink again.” The recognition is instant and total, because you’re not pitching them a vision they have to squint at and trust. You’re handing them their own sentence, solved. The buy-in you’d normally have to fight for over three meetings just… arrives, because there’s no translation gap to cross. They said what hurt, you fixed precisely that, and you described the fix in the exact language they used to describe the wound. That’s the whole art of it. Discovery isn’t gathering requirements so you can go be clever somewhere else. It’s listening closely enough that the client basically writes the spec for you, and disciplined enough that you resist the urge to add anything they didn’t ask for.

Personal, departmental, organizational

One more distinction that keeps me from solving the wrong problem. When someone describes a pain, I try to place which layer it lives on, because the layers don’t share solutions.

There’s the personal layer: this specific human’s daily friction, the inbox that runs their life. There’s the departmental layer: how a team’s work collides at the seams, the handoffs that drop things. And there’s the organizational layer: the company-wide, structural stuff. The trap is hearing a personal-layer complaint and reflexively proposing an organizational-layer overhaul, or vice versa. A brilliant fix for one person’s day might do nothing for the department, and a grand structural initiative might completely miss the individual misery that was the actual reason they took the call. So I keep asking: is this your problem, your team’s problem, or the company’s problem? Usually it’s a tangle of all three, but naming which strand is which is what keeps the eventual solution aimed at something real instead of something impressive.

None of this is complicated, and that’s sort of the point. You don’t need a fancy framework to do discovery well. You need to resist the urge to talk, ask people to walk you through the parts of their day they hate, count the pain out loud, and listen closely enough that when they hand you the exact sentence that describes what to build, you actually hear it. Show me your day, not your org chart. The whole job is usually hiding in the part they apologize for boring you with.