How to Measure Portfolio Support Outcomes

Measure portfolio support through the founder job requested, the useful return delivered and the evidence of follow-through. Track company outcomes separately and state the limits of attribution. A platform team can demonstrate what it contributed without claiming that a workshop caused a financing, hire or sale.

Start with service definitions, not a large dashboard. A research review, expert match and office hour produce different returns. You can compare reliability across them, but should not pretend each is the same amount of work or has the same business consequence.

1. Define a request and its completion event

Use one record for one founder job. Several emails about the same deck review are not several requests. If the scope changes into a different job, document the split rather than silently inflating demand.

Agree when the request is actionable and when support is complete. A match can be delivered while the resulting meeting is still pending. A workshop can occur without the founder completing its exercise. Preserve these different states.

Techstars' mentor guidance recommends understanding founder goals and their measures of success. Use those goals to define a useful return, not to promise a company result the service cannot control.

2. Choose measures that answer operating questions

Portfolio support scorecard

Measure	Definition	Question
Service awareness or reach	Eligible companies demonstrably reached under a defined method	Do founders know help exists?
Request coverage	Companies requesting help ÷ eligible companies in the period	Who is using the service?
Fulfillment	Requests with the agreed return delivered ÷ actionable requests in the cohort	Does the service finish work?
Reliability	Returns delivered by agreed date ÷ returns due	Are commitments realistic?
Founder usefulness	Useful responses ÷ usefulness responses received	Did the return advance the stated job?
Unresolved work	Open requests by reason and owner	Where does the process stall?

State the cohort, observation cutoff and missing coverage. Do not compare a newly launched service with a mature one using different waiting periods. Report raw counts beside percentages. Small samples are direction for investigation, not proof of superior performance.

3. Worked example: a monthly support cohort

Illustrative example: A platform team has 30 eligible companies this month. Twelve companies make 18 distinct requests. At the review cutoff,15 requests are actionable, two await founder input and one is outside the service scope.

Of the 15 actionable requests,11 have received the agreed return. Three are in progress and one is overdue. Twelve returns were due by the cutoff, and ten arrived on time. Of the 11 completed requests, eight founders provide usefulness feedback; six say the return advanced their job.

Calculated cohort results

Measure	Calculation	Limit
Request coverage	12/30 =40%	Does not show awareness among non-users
Fulfillment	11/15 ≈73%	Cutoff-dependent; open work remains visible
On-time returns	10/12 ≈83%	Uses due returns, not all requests
Reported usefulness	6/8 =75%	Only 8 responses;3 completed requests lack feedback

Do not report 6/11 as “usefulness” without explaining the nonresponses, or treat the three missing answers as negative. Also do not call 18 requests 18 supported companies. The units are different.

Suppose two companies later raise funding. Record that separately, along with any documented role of support, but do not claim a causal conversion rate from these counts. Company quality, market conditions, investors and many other factors influence financing.

4. Use the review to improve one service

Break down open requests by service and reason. If most delay comes from unclear intake, improve the brief. If expert matches stall after introductions, clarify the expected session and owner. If delivered returns are not useful, inspect the mismatch between the requested job and the service provided.

Ask non-users what prevented access without assuming they do not need help. Review whether time zones, language, stage or relationship proximity create avoidable barriers. Avoid exposing sensitive company details while examining patterns.

Choose one change, define the expected operational effect and observe the next comparable cohort. A before/after comparison can show association, but should not claim causality without a design that supports it.

5. Copy the monthly service scorecard

Service and eligible-company definition:
Cohort / dates / observation cutoff:
Unique requesting companies:
Distinct requests:
Actionable / waiting / outside scope:
Agreed return and completion event:
Delivered / in progress / overdue:
Due / delivered on time:
Usefulness responses / useful responses:
Missing feedback and data coverage:
Company outcomes tracked separately:
Largest unresolved reason:
Improvement / owner / expected effect:
Next comparable review:

Measurement traps

• Counting introductions attempted as delivered value: Define the promised return and check what actually happened.
• Summing repeat emails: Keep one request record with its history.
• Using satisfaction as financing impact: Report the different measures separately.
• Changing definitions mid-comparison: Version them and disclose the break.

Completion check: The report states who was eligible, what was delivered, who answered and what remains unknown. It ends with a service decision rather than a claim to own every portfolio success.