A doctor who diagnoses you from a questionnaire will find what the questionnaire asks about. A doctor who watches you walk across the room will find something else.
Companies work the same way. Ask people what's going on and you get what they believe is happening. Sit in the standups, the customer calls and the code reviews for a month and you get what is.
Founders usually think they have a roadmap problem. Sometimes they do. More often it's a strategy problem, a team problem or a feedback-loop problem that shows up looking like a roadmap problem. Watching is how you find out which.
A composite month
What follows is a composite: a set of patterns that show up often, with made-up details to show the shape. No single company looks exactly like this.
Picture a startup of a few dozen people, with the founder still making every roadmap call.
Week one is what everyone says the problem is. Engineering is too slow. Sales is promising things that don't exist. The founder wants a head of product "to take this off my plate."
Week two is what the calendar says. Standing roadmap reviews that never end in a decision. A couple of senior engineers spending most of their time on one big customer's requests. A design team that hasn't talked to a customer in weeks.
Week three is what the data says. A big share of new accounts never finish setup, and nobody owns that number. Engineering is split across more priorities than it has teams, every one of them marked "top." That's what slow looks like from the outside.
Week four is the read. It usually comes down to two or three decisions, not twenty:
- Decide what the product is for this year. One sentence the whole company can repeat. Everything that doesn't fit waits.
- Give the setup problem an owner and a number. Fixing it is worth more than half the roadmap.
- Put the big customer on a contract that pays for their roadmap, or say no politely.
None of the three is "engineering should go faster." The thing everyone named in week one was a symptom. That's normal. Patients describe where it hurts, which isn't always where the problem is.
If parts of that sound familiar, they should. The founder who makes every call and the big customer quietly bending the roadmap each get an essay of their own ("The founder is still the roadmap" and "Don't become one customer's private chef").
The questions to start with
The walk across the room still needs a chart. These are the questions worth carrying into the first couple of weeks, grouped by area.
- Strategy. Can three people on the leadership team describe the product strategy the same way, without notes? Is there a written list of things we've decided not to do?
- Customers. When did anyone in product last talk to a customer who isn't happy? What reasons do customers give for leaving, how often does each come up, and who owns acting on them?
- Portfolio and product. What would we sunset tomorrow if no one would complain? What's the path a new user takes to get value, and where do they drop?
- Team and operating model. Who decides what gets built, who decides how, and is that written down? Are designers in the room when problems are framed, or only when screens are needed?
- Delivery. What share of last quarter's roadmap actually shipped? Where does work wait? (It's always waiting somewhere.)
- Measurement. What are the few numbers the product org answers for? When a launch underperforms, what happens next?
A question asked in a meeting gets the answer people believe. The same question held up against a month of calendars, tickets and call recordings gets the other answer. The roadmap question is the clearest example. Ask it and you'll hear "most of it." Count it and you'll often find something much smaller.
Start with the calendar if you start anywhere. The standing meetings, what they're called and what they're for, tell you a lot about a company before anyone has explained it to you. When the meetings multiply and the decisions don't, the company is drifting. ("Look for the drift" goes further into that.)
What the month should end with
A month of watching should end in a short, plain read and the two or three moves that matter most, ranked. Not a hundred-slide deck. Most companies already have one of those in a drawer somewhere. What they're missing is someone who sat in the room long enough to say which two things matter.
And the read has to be argued with before it's handed over. The people who'll carry out the decisions should push on it, the founder first. If nobody pushes back, either it's obvious or nobody read it closely.
Where the metaphor breaks
A doctor's patient wants to get better and mostly holds still for the exam. A company keeps moving while you watch it. Quarter-end lands in week three, a big deal closes, a key engineer resigns. The month you watch is never a typical month, so part of the job is knowing which of what you saw was weather and which was climate.
And the doctor writes the prescription and leaves. Here, the people who have to take the medicine are in the room for the read, and the founder is usually one of them. A diagnosis nobody in the building agrees with is just an opinion with a chart attached.
Try this
- Pick the five questions from the list that make you most uncomfortable.
- Answer each one in a sentence, from memory.
- Then check each answer against something real: a calendar, a ticket count, a call recording, last quarter's roadmap next to what shipped.
- Score each of the six areas from 1 to 5 on what you found, not what you wrote first.
- Start with anything at 2 or below.
Where do you land?
