How Accelerators Can Review Startup Progress With Comparable Evidence
Run cohort reviews that connect each startup's evidence to a practical support decision. Includes a review sheet, meeting agenda and fictional three-company example.
To review startup progress across an accelerator cohort, ask each company to show what changed, the evidence behind it, what remains uncertain and the help it needs next. Compare the startup with its own starting point and current stage before comparing it with another company.
A useful review ends with a support decision, an owner and the next evidence checkpoint. A shared score or a polished update cannot provide those answers on its own.
Decide what the review needs to change
Start with the decision the program can actually make. Does a team need access to customers, help designing an experiment, a technical specialist or assistance removing a blocker? The review should establish which intervention is justified and who will arrange it.
Keep different kinds of progress separate:
- Program participation: workshops attended, mentor sessions completed and materials submitted.
- Learning: an assumption examined, an explanation revised or an important uncertainty narrowed.
- Business results: customer behavior, commercial commitments or other outcomes relevant to the startup's stage.
Participation helps you understand engagement, but attendance does not establish customer demand. An experiment that challenges a founder's preferred idea may represent useful learning even when it produces no launch announcement.
Also distinguish the company from the individual founder. A founder may improve their sales skills while the company still lacks evidence for its target segment. Both observations can matter, but they support different kinds of assistance.
Nesta's accelerator practice guide discusses how performance measures depend on a program's mission. For an operational review, define the support decision first, then request the evidence needed to make it.
Ask for a short review sheet before the meeting
Give startups a consistent structure without requiring identical business milestones. The sheet should help reviewers prepare, rather than create another reporting project for founders.
| Field | What the startup should provide |
|---|---|
| Current decision | The question the team needs to resolve, such as which customer segment to test next. |
| Starting point | The previous position, its date and the evidence available at that time. |
| Stage and constraints | The current product situation and relevant limits, such as procurement or access to test users. |
| What changed | A specific observation or result since the last review. |
| Supporting evidence | Accessible source references, dates and the relevant population or measurement period. |
| Interpretation | What the team thinks the evidence means, separated from the observation itself. |
| Remaining uncertainty | Contradictory findings, missing information or alternative explanations. |
| Requested support | The specific help needed to resolve the next uncertainty or blocker. |
Founders can complete this in an existing document. The program manager should check important source references before the discussion and flag anything inaccessible, stale or disputed.
For example, “customers want automated reporting” is an interpretation. Notes showing that four interviewees manually compile a report every Friday are observations. The next question is whether those interviewees are the intended users, whether the problem matters enough to change behavior and what evidence would answer that question.
If evidence cannot be shared with every reviewer, agree who can inspect it and what others can see. A review summary should not silently broaden access to a startup's underlying customer or commercial information.
Judge evidence against the startup's current task
Consistent questions do not make every result directly comparable. An early discovery team, a company running its first pilot and a launched product need different evidence.
For a discovery team, examine the problem, the people experiencing it and the assumptions still being tested. Interview counts describe research activity; the content and relevance of those interviews determine what the team can reasonably conclude.
For a pilot, examine what was agreed, what users actually did and which conditions might prevent the result from carrying into normal use. A pilot blocked by procurement needs a different response from a pilot customers used but declined to continue.
For a launched product, inspect measures appropriate to its goal, with clear definitions and observation periods. “Retention improved” is incomplete without knowing who was counted, what counted as returning and whether both groups had enough time to be observed.
When an experiment is central to the review, ask what the team intended to learn before seeing the result. Strategyzer's Test Card makes the hypothesis, test, measurement and success criterion explicit. That structure helps reviewers distinguish a planned test from an explanation constructed afterward.
The broader guide to tracking progress across a venture portfolio covers common stages and portfolio signals. Use that context to support the meeting, while keeping the discussion focused on the company's next decision.
Run the review around questions that lead to action
The following agenda is a suggested operating practice. Adapt its frequency and depth to the program, rather than treating a weekly meeting as a universal requirement.
1. Confirm the change since the last review
Begin with the previous decision or commitment. What was supposed to happen, what happened and what changed in the team's circumstances?
A missed checkpoint may reflect an external dependency, a changed hypothesis or an unclear commitment. Establish which explanation applies before describing the startup as off track.
2. Inspect the evidence that affects the decision
Spend the discussion on disputed or consequential claims. Review the relevant source, its date and its limitations. Check whether the founder's interpretation goes further than the observation supports.
If two reviewers disagree, identify whether they disagree about the evidence, its interpretation or the action to take. These require different resolutions. More data will not necessarily resolve a disagreement about the program's priorities.
3. Identify the next uncertainty or blocker
Ask what would prevent a sensible next step. The issue might be missing customer access, an unresolved technical dependency or insufficient evidence to choose a segment.
Keep an unresolved question visible when the meeting cannot answer it. Replacing uncertainty with a confident status label makes the next review less useful.
4. Agree the support action and responsibility
Separate the startup's next action from the program's commitment. “Improve customer discovery” is too broad. “Program manager introduces the founder to two relevant buyer contacts; founder runs the agreed interviews and brings the notes to the next review” gives both sides something concrete to do.
Where mentor advice is involved, distinguish the recommendation from the founder's decision. Record who accepts the action and who is responsible for supplying the promised assistance.
5. Set the next evidence checkpoint
Define what the next review should examine and what might trigger an earlier discussion. A scheduled date is useful, but a rejected pilot agreement or a newly discovered technical constraint may require attention sooner.
When support capacity is limited, make the trade-off explicit: which blocker the program can address now, which request must wait and what the founder can do meanwhile. This is a support allocation decision, not a ranking of company quality.
Worked example: three startups, three support decisions
The companies and evidence below are fictional. They illustrate review reasoning, not customer results or recommended industry benchmarks.
| Startup and situation | Evidence brought to review | What remains uncertain | Agreed support and next checkpoint |
|---|---|---|---|
| CedarDesk: discovery for a reporting tool | Nine interview notes: five operational users describe reporting delays; four managers emphasize approval errors instead. | Which user and problem the first product should serve. The two groups are describing different needs. | Program manager arranges access to relevant buyers. Founder separates the two hypotheses and brings a narrower test plan to the next review. |
| RoutePilot: first enterprise pilot | A named sponsor has agreed to a pilot, but the procurement process has not cleared the required data access. No users have started. | Whether the pilot can run under the proposed access arrangement. Interest is not evidence of adoption. | Program manager connects the founder with procurement expertise. Founder confirms the permitted pilot scope and returns when the access decision is known. |
| LoomReports: launched product | Two fully observed signup cohorts each contain 40 accounts. Accounts meeting the same day-30 return definition fall from 20 to 12. | Whether the change reflects acquisition mix, onboarding, product behavior or another cause. | Program manager arranges an analytics review. Founder checks source data and segments the cohorts before proposing a product change. |
None of these situations produces a reliable overall winner. CedarDesk needs a sharper test, RoutePilot needs help resolving an operational dependency and LoomReports needs diagnosis before intervention.
The launched product's change is from 50% to 30%, a decline of 20 percentage points. That arithmetic describes the fictional sample; it does not establish the cause or show that the same result applies across the customer base.
The review also creates a commitment for the program manager in each case. If an introduction or specialist session does not happen, the next review should examine that program-side delay rather than attribute every stalled action to the founder.
Record the decision and follow-through
Keep a short note where the founder and responsible program staff can access it. This suggested format can be copied into your existing workspace:
Startup and review date:
Decision or support question:
Evidence reviewed, with source references:
Interpretation accepted for now:
Unresolved question or recorded disagreement:
Founder action and owner:
Program support action and owner:
Requested help that is deferred, and why:
Next evidence checkpoint:
Earlier-review trigger:
At the next meeting, reopen this note before asking for a fresh status presentation. Check both founder and program commitments, then revise the action if circumstances have changed.
Missing evidence should be recorded as missing. An inaccessible file, an overdue update and a negative experiment result are different situations. Ask what happened rather than converting all three into a failure label.
If the program needs a reusable system for storing and querying validation records, the guide to structured venture-validation pipelines covers that architecture. The review note here records the meeting's decision and assistance commitments; it does not replace the underlying research records.
Where ProdStack helps, and what the program must organize
ProdStack's Incubator Plan gives each startup a separate workspace. The founder owns that workspace, and the Program Manager has admin access. Its program overview can show stages, method progress, health, hypotheses and activity, supported by daily AI briefs derived from each startup's own product memory.
Those summaries can help a program manager prepare questions and locate gaps. They do not replace source inspection. The brief does not display a confidence label beside every line, and a count of validated hypotheses does not establish commercial success.
Access expectations are important: while a startup participates in the program, its Program Manager can read its files and threads. Founders cannot hide selected records from that manager, and there is no separate mentor role. Separate startup workspaces protect the boundary between companies; they do not make a founder's records private from their Program Manager.
The product does not provide custom program-level progress-update templates, recurring review scheduling, comments or an Incubator dashboard export. Maintain the review sheet, meeting schedule and support commitments in an appropriate external process. Health scores are not normalized benchmarks across sectors or stages, and method progress is not task completion or revenue growth.
The product stages and capabilities explain the broader scope. Evaluate them against the evidence your program needs to review, while preserving the access rules and the human responsibility for deciding what support to provide.
Keep startup review separate from proving program impact
A cohort review asks what changed for a startup and what assistance it needs next. Evaluating the accelerator itself asks a different question: what difference did the program make?
Nesta's discussion of accelerator impact evaluation explains why selection matters. Startups admitted to a program may differ from those that were not admitted, so their later progress alone does not establish the program's contribution.
Use the review to make support decisions traceable: what the startup needed, what the program agreed to provide, what happened and what remains unresolved. Keep those records available for a separate evaluation suited to the program's goals, without presenting a collection of progress updates as proof of impact.
Prodstack turns thinking like this into shipped, evidence-backed work, from discovery to growth.