Ijon's question needs some more thought. Reduced to the minimalist statement, the issue might look something like this:
It's good to do "experiments". It's good to "involve communities early". It is not always (or even usually) possible to do both of these things (well) at the same time.
If we set up "involve communities early" as the prime directive, then we are imposing significant, even destructive, burdens on experiments. We would be saying that devs may only conduct an experiment if they involve non-dev communities in it. That increases the costs (not just in money) as well as the likelihood of volunteer time being wasted on failed experiments, volunteers being disappointed by the cancellation of products that they want but which the devs need to abandon, and volunteers learning to ignore development because the cost:benefit ratio is unfavorable to them. We could adopt this, but we need to own the costs of such a position.
But if we encourage experiments, then we will frequently encounter a situation in which communities have no opportunity to be "involved early". We will have successful experiments that are presented "later", and which are rejected by some community members precisely on the grounds that these products began (as experiments) in advance of their involvement. More often, some volunteer communities may feel like discussions with them are merely for appearances, rather than true interest in their views. We could adopt this, but we need to own the costs of such a position.
IMO a better answer is a balance of the two: involving affected communities while the product is in active development, but not always (or even usually) in the experimental stage. There certainly are costs to this position, too: A "balance" means that some people will find out about projects later than they wish, some people will be asked for help much earlier than they wish, and some people will use "not early enough" as an excuse to object when the real problem is that they just don't like it or need it themselves. We could adopt this, too, but we need to own the costs of such a position.
(I also believe that it is inappropriate to have a one-size-fits-all method for involving non-dev communities, but having a process of "use your best judgment to decide when to involve communities" has all of these costs, too.)
There is IMO no perfect answer. However, I beleive we need to directly address this issue, by clearly stating a standard expectation here, regardless of whether that expectation is "You must never spend even 10 minutes thinking about an experiment before holding a formal community consultation" or "Communities can be ignored until 24 hours before the launch of any new product" or something in the sensible center of those extremes. Let's make a decision about what we're going to do, name and truly understand the disadvantages to our choice, try it out, and decide how to adjust our process from there.