Working in Ambiguity

Startups ask this constantly, in the form "tell me about a time you had to work with unclear requirements" or "how do you operate when there's no PM". The subtext is direct: there may not be a PM, and the roadmap may be a paragraph in Notion.

Weak answers describe waiting — asking for clarification, escalating, being blocked. Getting clarity is fine as one step, but a whole answer made of it says you need someone else to define your work.

What strong answers show is a conversion process:

Find the actual goal. "Improve onboarding" is not a goal; "get more trial accounts to their first successful API call" is. Ask what would be different if this worked, and for whom. Most ambiguity dissolves when someone insists on a measurable outcome.

Reduce the space cheaply. Look at the data, watch three users, read the support tickets, spend a day on a spike. Ambiguity is often just unpaid research, and the senior move is paying it quickly rather than debating in the abstract.

Write it down and circulate it. A one-page doc — goal, what's in, what's explicitly out, the assumptions you're making, the first slice — converts ambiguity into something people can disagree with. Half the value is that it makes silent disagreement visible before you build.

Ship a thin slice and use it as a question. In genuine uncertainty, a small shipped thing produces better information than another week of analysis. Say what you'd cut first and what would make you stop.

Name the assumptions and the review point. "We assumed self-serve users behaved like the enterprise ones; if that was wrong we'd have known within a week of the beta" is exactly the sentence that reads as senior.

This is close to a definition of the senior role at the target companies: you are handed outcomes, not tickets. It also predicts the practical round, where take-homes are deliberately underspecified and the scoping decisions you make — and write down in the README — are much of what's actually being scored.

• The signal is converting ambiguity into a scoped plan, not obtaining clarity from someone else.
• Start by turning the goal into something measurable; most vagueness is an unstated outcome.
• Buy information cheaply — data, user calls, a one-day spike — rather than arguing in the abstract.
• Write a one-pager with goal, non-goals, assumptions, and the first slice; it surfaces silent disagreement early.
• Explicit non-goals are as valuable as scope, and rarer.
• Ship a thin slice to generate information when the uncertainty is real.
• State assumptions with a review point so being wrong is cheap and visible.
• Underspecified take-homes are testing this same skill; put your scoping decisions in the README.