Market Saturation and the Funding Countdown Timer
In a previous article on setting tiered funding goals, I briefly brought up an issue which I'd like to expand on in today's article: market saturation. Market saturation is the reflection of a basic reality for any fundraising enterprise: the pool of potential funding is not bottomless. Of the six billion people people on earth who migh potentially donate money to this project, we are realistically dealing with several much smaller subsets: first, those with computers powerful enough to run games; second, people who like city sims; third, people with fifty dollars or more to spend on entertainment; and fourth, people who are convinced that this project's goals are feasible and are willing to risk money on that assumption. Of those four, only the last one is able to be increased by our efforts: at some point, even if we could convince every potential donor to pledge their support, we will run up against the limits of the group defined by these other subsets. How big is that group? There's no way to know.
That's where the market saturation problem pops up: while collecting pledges, how do we know when we've reached a realistic maximum? There is no way to determine whether a dropoff in contributions can be attributed to a need for more fundraising activity, or to having simply run out of city sim fans. The risk in this situation is that we become stuck at a funding level which is short of our goal, but which is still substantial enough to use for a functional game, albeit with fewer features than initially envisioned.
This potential problem is somewhat mitigated by the system of building in iterations as I described previously. But we still face the possibility of encountering this situation between phases and stalling progress. To prevent this happening, I propose that we include a fairly simple mechanism in the system of pledge collecting: a "countdown timer". The "timer" would really be more like a schedule: a stipulation that if a funding goal failed to be met within a certain time, the project would re-evaluate its options to work with what was already available rather than waiting for more pledges.

A rough decision tree for deciding whether to keep trying for more funding, or work with the budget at hand.
As an example of how this might work, imagine that we accept a proposal with a total budget of ten million, which is divided into 5 phases with a two million dollar budget each. Say the first phase is already funded, and work begins; pledges continue to be made for the total budget, but around the seven million mark new pledges start to plateau. With the countdown timer, we could institute a time limit of, say, two years from the beginning of the first phase within which to raise the remainder of the financing. If, in our example above, the timer ran down, the project board would at that point accept that a ten million dollar budget might be impossible, and that we should do what we can with only seven. We would then have to work with the developers to pare down the previously agreed upon specificaitons to something achievable with the smaller total.
Of course, this is all hypothetical, and personally I don't even think it's likely to come up (in my opinion there's more than enough potential funding within the community.) So, why spend a whole article discussing it, and why make it an explicit part of the pledging process? Why not just let the project board make a decision like that on an as-needed basis? Well, the reason lies in the nature of the pledges that will eventually fund the process. Contributors are asked to pledge on the basis of a final, previously agreed upon budget; It's not fair to suddenly change the terms of the pledge midway through without a good reason, and doing so runs the risk of people retracting their support with the idea that the new plan wasn't what they signed up for. It needs to be laid out from the beginning that this kind of decision is a possibility, and give a set of rough guidelines for when the project leadership will consider making it. Without building this kind of transparency into the funding process, we might end up having to choose between the project withering on the vine for lack of funding, or a sudden, arbitrary-seeming change of terms that would leave people feeling betrayed.
The details of the countdown schedule can be decided on later, but I feel it's an important point to add to the pledging system. For now, what kind of time limits do you think would be reasonable, and for how much? Let me know what you think in the comments!
No responses to "Market Saturation and the Funding Countdown Timer"
Post new comment