The First 30 Days Playbook: How I Diagnose Any Organization

Every engagement I take starts the same way — and it looks nothing like the generic “meet stakeholders and learn the product” advice. I’ve done this at Ford, Amazon, Venmo, Blue Cross, and as an independent consultant. The playbook has evolved over twelve years, but the core moves haven’t changed. Here’s the actual methodology.

Step 1: Find the Doers

Not the org chart leaders — the people who actually get things done. Every organization has them. They’re the ones other people go to when something needs to ship. They might be senior, they might be individual contributors. Their titles are irrelevant. What matters is that when you need something to move, these are the people who make it happen.

Finding them early is the single highest-leverage move in the first week. Ask everyone you meet: “Who do you go to when you need something done quickly?” The same names come up fast. Those are your people. Build those relationships first — not the executive sponsors, not the steering committee. The doers.

Step 2: Find Where the Bodies Are Buried

Sit with the people living the problem. Not in a conference room with an interview guide — at their desks, watching them do their actual work. This is where the real problems surface, because people have normalized the pain. They won’t mention it in a meeting. You have to watch it happen.

What you’re listening for: the complaints people make to their neighbor but never put in a feedback form. The workarounds they’ve built that nobody asked them to build. The tools they avoid. The processes they’ve stopped following because the process doesn’t match reality. The real problem is never in the brief — it’s in the gap between what’s documented and what actually happens.

Step 3: Map Personas and Problem Themes

Take everything you’ve heard and group it. Not into user journey maps or fancy research artifacts — into personas and themes. Who are the distinct groups of people affected? What are the 3-5 problems that keep surfacing across conversations?

This synthesis step is where most people stall. They gather inputs forever. The signal to move: when you start hearing the same patterns from different people, you’ve hit what I call the pattern saturation point. That usually happens in week two. If you’re still gathering by week four, you’re hiding behind research.

Step 4: Map Systems and Processes (in Parallel)

While you’re doing the people work in steps 1-3, you’re simultaneously mapping the technical and operational landscape. What systems exist? How do they connect — or don’t? What are the processes, and where have they diverged from what’s documented?

This is the holistic picture. Three parallel investigations — the humans, the workflows, and the systems — converging into one understanding. The people tell you what’s broken. The systems tell you why it’s been hard to fix. The processes tell you where the organization has been trying and failing.

The key is parallel, not sequential. Most playbooks tell you to learn first, then act. I’m learning and synthesizing at the same time, because in a consulting engagement you don’t have the luxury of three months of pure discovery.

Step 5: Understand the Company’s Goals and Vision

Before building your product vision, understand theirs. What does leadership think the company is trying to accomplish? Where does this project fit in that picture? What are the stated priorities, and — more importantly — what are the unstated constraints?

This step keeps your product vision from being technically right but organizationally impossible. The best solution in the world fails if it requires something the organization isn’t willing to give up.

Step 6: Build the Product Vision — With a Prototype

By week three or four, you have enough to build. Not a deck. Not a research readout. A product vision expressed as a narrative — here’s what’s broken, here’s who it affects, here’s the opportunity — backed by a working prototype that makes the vision tangible.

The narrative covers the vision and capabilities. The prototype makes it real. By week four, I have something people can touch and react to — not a wireframe, working code. That’s the deliverable that changes the conversation from “should we do this?” to “how soon can we start?”

When to Adapt the Playbook

This sequence isn’t rigid — it compresses or expands based on context. At Ford, the first time through took months because I was learning an entire industry. By my last role at Amazon, I had the pattern down to weeks. In consulting engagements, the clock is faster and the tolerance for pure learning is shorter.

The one thing that never changes: the people come first. On the knowledge platform, I skipped straight to the systems during my first week — tried to map the architecture before I’d sat with the content authors. I wasted three days drawing diagrams that turned out to be wrong because nobody had told me which systems were actually used versus which ones were officially sanctioned. The doers set me straight. They always do.