I'm not trying to invent a new method here but these days I think of what I do as either "gap-" or "demand-" driven development.
I started thinking this way some time ago when I facilitated a very painful, but vital, prioritisation session for a large project (dev team = 80ish) where the backlog represented about 6 years work but the budget ran out in 2.
You know how these things work: everyone knows there's not enough capacity but no one wants to kill any of their babies (an authorly metaphor). Despite the reluctance, after two difficult hours we'd grouped our 150 requests into 5 groups. Groups 1, 2 and 3 were all "must haves"; there were about 40 of them. Group 5 were the "won't haves" - and there were about 30 of them. If you are familiar with DSDM's MoSCoW categorisation then you'd expect the 80 requests left on Group 4 were a mixture of "should haves" and "could haves" but those words aren't quite right because (to my mind) they imply priority, but we simply could not priories them. They were the "we-really-won't-know-if-we-need-them-until-we've-gone-live-and-we-see-if-customers-want-them-or-if-our-process-needs-them haves". Not the catchiest name so our sponsor called the "demand driven requests". He was thinking of John Seddons Failure Demand when he said it.
Some of the requests were features which customers might - but might not - desire but we didn't know. Some were processes which might need automating, but might not, since it all depended on capacity and quality issues. For instance, If we got a lot of failure demand in one area then as well as fixing the cause we might need to automate the resolution process. Trouble is, we didn't know if we'd have a lot of failure demand or not.
Likewise, if the product sold well we would prefer to focus on requests which increased our internal capacity. But, if the product didn't sell so well then we'd prefer to focus on features which helped sell the product. We hoped we'd be in the former situation (selling well, yay!) but how could we know that until we tried to sell?
So we had 2 choices: we could either guess how to prioritise the requests - making a bet, basically - or we could wait and prioritized based on actual demand, filing the most important gaps as we went.
Our sponsor, preferring to go live sooner, chose the former.