A 5-question framework for turning a vague feature request into something estimable, asking clarifying questions without sounding like you're stalling, and documenting the clarified requirements back to confirm shared understanding.
Published September 23, 2026
1. WHO is this actually for? (which users, which segment — vague requests often
silently assume an audience that isn't stated)
2. What does SUCCESS look like? (a concrete, checkable outcome, not just a
feature description)
3. What are the CONSTRAINTS? (a deadline, a budget, a technical limitation
that shapes the solution space)
4. What are the EDGE CASES? (what happens when something unusual occurs —
often entirely unaddressed in the original vague ask)
5. What's the PRIORITY relative to other work? (is this genuinely urgent, or
does it just feel urgent to whoever's asking right now)
This mirrors HLD Fundamentals Refresher's insistence on stating requirements explicitly before any design — applied here to a REAL, everyday feature request rather than a system design interview prompt. A request like "add filtering to the product page" sounds clear but is genuinely underspecified against every one of these five questions — asking them explicitly, systematically, turns a vague ask into something that can actually be ESTIMATED (Estimation Techniques) and correctly scoped, rather than guessed at.
Sounds like stalling: "I have a lot of questions before I can even start..."
Sounds collaborative: "To make sure I build the right thing the first time,
a few quick questions: [specific, concrete questions]"
The framing matters as much as the questions themselves — presenting clarifying questions as a DELAY ("I can't start until...") reads as friction; presenting them as an investment in getting it right the first time (avoiding costly rework from a wrong assumption) reads as genuinely helpful. Being SPECIFIC rather than open-ended also helps — "what should happen if a user has zero results after filtering?" is a concrete, quickly-answerable question; "what are all the edge cases?" is vague and puts the burden of thinking through the framework back on the requester.
"To confirm my understanding: this filter applies to [X], success means [Y],
and if there are no matching results we'll show [Z]. Does that match what
you had in mind?"
Asking clarifying questions and getting answers verbally is only half the job — writing the CLARIFIED version back to the requester, explicitly, and getting their confirmation, is what actually closes the loop and creates a shared, checkable record. Without this step, a genuine misunderstanding (the requester meant something subtly different from what was heard) can survive undetected all the way through implementation, discovered only when the finished feature doesn't match what was actually wanted — a far more expensive moment to discover a misunderstanding than during the clarification conversation itself.
Q: What if the person making the request genuinely doesn't know the answers to some of these 5 questions? A: That's itself valuable, actionable information — it means the request isn't actually ready to be estimated or built yet, and surfacing that explicitly ('it sounds like we need to nail down success criteria before this can be scoped') is more honest and useful than either guessing on their behalf or silently building something against an assumption nobody actually confirmed.
Q: How many of these 5 questions need to be asked for every single request, even small ones? A: Scale the rigor to the request's actual size/risk — a small, well-understood tweak might only need a quick confirmation on 1-2 of these dimensions; a genuinely new, ambiguous feature warrants working through all 5 explicitly — applying the full framework mechanically to every trivial request would itself become the kind of unnecessary friction this lesson is trying to avoid.
Q: Does this framework replace the need for a full design document (Design Documents)? A: No — this framework is specifically for CLARIFYING an initial request enough to scope and estimate it; a design document is a separate, later artifact for genuinely complex work, laying out the actual technical approach and trade-offs once the requirements from this framework are already settled.
Q: How does documenting requirements back relate to Status Updates That Lead With Risk, later in this chapter? A: Both are instances of the same broader habit — proactively closing communication loops explicitly rather than assuming alignment; documenting clarified requirements closes the loop at the START of work (confirming what's being built), while risk-forward status updates close the loop DURING work (confirming whether it's still on track) — the same underlying discipline applied at two different points in a piece of work's lifecycle.