A support program is judged on the companies that come out of it. What comes out depends first on what went in. Everyone agrees with this, and yet in most of the programs I have seen, selection receives a fraction of the care given to content.
I propose the opposite order. Selection is the first deliverable of the design, and the rest of the journey is written afterwards, according to what selection lets in.
What a funnel actually decides
Take an ordinary selection. One hundred applications arrive. Reviewing the files leaves a little over sixty. A deck and a video are then requested, and around forty people actually send them. You look, you set aside, thirty remain. Available resources allow twenty to be supported.
At each of these stages a design decision has been made, and someone made it. Asking for a video screens out people who lack the creativity or the ease to produce one, which is sometimes intended and sometimes not. The step from thirty to twenty is not dictated by the quality of the applications, it is dictated by the program’s means. Twenty is not a quality threshold, it is a budget constraint presenting itself as one.
Naming this plainly changes the conversation with the funder. You stop discussing acceptance rates and start discussing the real cost of serious support and how many people it allows you to serve. I always negotiate a few more places than the funder planned, to stay consistent with a user-centred approach1.
The selection format is an instrument
On a program I designed with partners, selection rested on an equity stake. Seventy applications were received. Four companies entered the support phase, one of which dropped out at the start. Three signed the shareholders’ agreement. The rate looks severe. It corresponds to what the format required, since a company willing to open its capital at that stage submits to scrutiny of a different nature than an application to a free program.
On another program, which I ran for five years, we admitted between fifteen and thirty project holders per cohort, free of charge and over a longer period. Selection had neither the same criteria nor the same function, because the program was not promising the same thing.
These two examples do not contradict each other. They show that selection expresses the contract a program makes with the people it supports. When that contract is not explicit, selection makes it explicit anyway, and rarely in the direction anyone intended.
The question to ask first
Before modules and calendars, I ask a single question: what does this program promise, and to whom? Does it have the means to promise it? The answer determines entry criteria, the number of places, the duration, the format of sessions and the way the journey ends. The rest of the design follows from there, and can be discussed with arguments rather than preferences.
- A user-centred approach is a design practice that puts the needs, expectations and constraints of users at the heart of every stage in developing a product or service, to make sure it is useful and simple to use. ↩