Blog · Programmes
Tracking startup outcomes after an accelerator or programme
Tracking startup outcomes means checking, at regular intervals after a programme ends, what has happened to each team: whether it still operates, whether it has raised money, hired, launched or closed. It works when you define the outcomes in advance, keep one stable record per team and store the evidence behind every status.
Why it is hard
On the last day of a programme, the office knows its teams well. Then contact fades. Several things make later tracking difficult.
- Teams change shape. They incorporate, rename themselves, change direction, merge or split. The name on the application form may not be the name in use later.
- Founders move on. The contact address you hold may belong to someone who has left.
- Surveys go unanswered. Response rates fall with each passing cohort year.
- Staff change. The person who knew every team leaves, and the knowledge was never written down.
- The good news finds you and the bad news does not. Teams that are doing well reply to emails and turn up to alumni events. Teams that closed tend to go quiet.
The last point deserves a name: survivorship bias. If you only count the teams you hear from, your figures will look better than the truth. A sound tracking process starts from the full list of teams that took part, and accounts for every one of them, including those whose status is unknown.
Decide what you are tracking
Write the definitions down before you collect anything. Vague terms cause arguments later.
| Outcome | Questions to settle first |
|---|---|
| Still operating | Does a registered but inactive company count? What about a team that carries on as a side project? |
| Funding raised | Do grants count, or only investment? Announced or confirmed? Which currency? |
| Jobs | Do founders count? Part-time staff? Contractors? At what point in time? |
| Revenue | Self-reported or evidenced? Any revenue, or above a threshold? |
| Acquired or merged | Does a sale of assets count, or only a sale of the company? |
| Closed | Formal dissolution, or no sign of activity for a stated period? |
| Intellectual property | Applications filed, or only patents granted? |
There are no universal right answers. What matters is that the answer is written down, applied the same way to every team and kept the same from year to year. If a funder has its own definitions, use those. Impact reporting for funders covers that side.
Two families of evidence
Asking the teams. Surveys, check-in calls, alumni events and mentor contacts. This is the only way to learn things that are not public, such as revenue or headcount in a small private company. Its weaknesses are low response, optimistic answers and the bias described above. Keep surveys short, ask the same questions each time and send them from a person the founders know.
Public records. In general, a programme office can look at the kinds of records that any member of the public can see. Examples include official company registers, published grant awards, patent office records, a company's own website and press coverage. Each has limits. Registers vary a great deal between countries in what they show. News favours large events. A website can stay online long after a company has stopped trading. Public records are good for confirming that something happened and weak at proving that nothing did.
The two families work best together. Public records help fill in for teams that do not reply. Survey answers cover what public records cannot show. Where the two disagree, that is a prompt for a person to look more closely, not for a rule to pick a winner.
Keep one record per team
The practical core is a single, stable record for each team, with its own identifier that never changes. Attach to it:
- Every name the team has used, with the period each applied
- Founders and their roles at the time of the programme
- The cohort and programme it belongs to
- Each status check: the date, what was found, the source and who checked
- A link or stored copy of the evidence
Point four is the one most often skipped. "Operating" in a spreadsheet cell tells a successor nothing. "Operating, confirmed from the official register on this date by this person" can be trusted, or rechecked. This habit is described in data provenance: keeping receipts.
Matching a team to the right public record is a real problem when names are common or have changed. It is a case of entity resolution. Have a person confirm uncertain matches, since attaching another company's funding round to your alumnus is an embarrassing error to make in front of a funder.
Make "unknown" a proper status
Every team should have a status at every check, and "unknown" should be one of the options. It is tempting to carry the last known status forward for ever. Do not. A team last confirmed as operating several years ago is unknown today. Reporting the count of unknowns is a sign of a careful office, and it shows you where to spend effort next.
Pick a cadence you can sustain
Yearly checks suit most programmes. More frequent checks make sense in the first year or two, when most change happens. Whatever you choose, keep each dated check and never overwrite the last one. The history lets you report not only where teams stand, but what changed since last time, which is often what a board or funder wants to hear.
Consent and privacy
Tell teams at intake that you will follow their progress, what you will record and how it will be reported. Decide whether results will be published per team or only as totals. Records about founders are personal data, and privacy law applies in many places. Check your approach with your own legal adviser or data protection officer.
A word on cause
A team that does well after your programme did not necessarily do well because of it. Strong teams are more likely to be selected in the first place. Outcome tracking tells you what happened. It does not, alone, prove what the programme caused. Say "our alumni went on to" and avoid "we created", unless you have a careful comparison to support it.
Where Prism fits
Prism Labs runs a live custom pipeline that tracks 51 real startup teams after their programme ended. How that pipeline works is private, so nothing in this guide should be read as a description of its sources or methods. In general terms, the engine Prism builds follows seven steps: gather, keep receipts, link, review, answer, watch and deliver. A person approves or rejects each finding, and AI answers must cite stored evidence. There is more on the innovation programmes page.