diff --git a/src/docs/contributor/feature_requests.diviner b/src/docs/contributor/feature_requests.diviner
index a64afee26e..9a1fd40c45 100644
--- a/src/docs/contributor/feature_requests.diviner
+++ b/src/docs/contributor/feature_requests.diviner
@@ -160,6 +160,47 @@ If you only describe the solution and not the problem, we can't generalize,
 contextualize, merge, reframe, or offer alternative solutions or workarounds.
 
 
+Hypotheticals
+=============
+
+We sometimes receive hypothetical feature requests about anticipated problems
+or concerns which haven't actually occurred yet. We usually can't do much about
+these until the problems actually occur, since the context required to
+understand and properly fix the root issue won't exist.
+
+One situation where this happens is when installs are thinking about adopting
+Phabricator and trying to guess what problems users might encounter during the
+transition. More generally, this includes any request like "if users do **X**,
+they might find **Y** confusing", where no actual users have encountered
+confusion yet.
+
+These requests are necessarily missing important context, maybe including the
+answers to questions like these:
+
+  - Why did users do **X**?
+  - What were they trying to do?
+  - What did they expect to happen?
+  - How often do users do this?
+
+The answers to these questions are important in establishing that the issue is
+really a problem, figuring out the best solution for it, and prioritizing the
+issue relative to other issues.
+
+Without knowing this information, we can't be confident that we've found a good
+solution to the problem, can't know if we've actually fixed the problem, and
+can't even know if the issue was really a problem in the first place (some
+hypothetical requests describe problems which no users ever encounter).
+
+We usually can't move forward without this information. In particular, we don't
+want to spend time solving hypothetical problems which no real users will ever
+encounter: the value of those changes is zero (or negative, by making the
+product more complex without providing a benefit), but they consume development
+time which could be better spent building much more valuable features.
+
+Generally, you should wait until a problem actually occurs before filing a
+request about it.
+
+
 Create a Task in Maniphest
 ==========================