Running a platform as a product means treating founders as users. Find out which problems they actually have, ship small programs that solve them, measure who uses each one and what it changes, and cut what doesn't get used. The platform team owns a roadmap and a backlog, the same way a product team does.
A lot of platform programs start the way bad features start. A partner comes back from a conference with an idea, the team builds it, and it launches with a nice email. Then nobody checks whether anyone used it. A year later it's still on the website, still taking a few hours a month, and still producing nothing anyone can name.
You probably know the list already: the perks database nobody opens, the tool the firm bought because another fund had it, the quarterly webinar with six attendees. None of those were bad ideas. They just never had a user in mind, and nobody built in a way to learn whether they worked.
I build software for a living, so I'll admit I'm biased toward the product lens. But it fits platform work well, because both jobs come down to the same question: what does this person need, and did we actually help?
Know your users and the jobs they hire you for
Founders aren't one user. A pre-seed founder with four employees and a Series B CEO with 120 need completely different things from you. Start by splitting the portfolio into a few segments, then write down the job each segment hires the platform for. This is the jobs-to-be-done idea, and it's useful here because it forces you to describe the founder's problem rather than your program.
| Segment | The job they hire you for | What that might look like |
|---|---|---|
| Pre-seed and seed | "Help me find my first customers and hires" | Warm customer intros, early candidate intros |
| Series A | "Help me build a repeatable sales motion" | Sales leader search, peer group of GTM leads |
| Series B and later | "Help me hire executives and raise the next round" | Exec search support, co-investor intros |
| Any stage, in trouble | "Help me get through this month" | Partner time, a specific operator, fast intros |
The segments and jobs here are illustrative. Yours will come from your own portfolio. Then look at your current programs and map each one to a row. Any program that doesn't fit a row is a candidate for the chopping block.
Build the backlog from real asks
A product team keeps a backlog of problems. A platform team should too, and it should fill up mostly from things founders already told you.
Founders ask for help constantly. The problem is where they ask: paragraph four of a monthly update, a line in a board deck, a comment at the end of a call. Those asks die where they land, because the people who could help never see them. So the first job is to collect them in one place and tag each one:
- Type: talent, customers, fundraising, finance, legal, marketing, other.
- Stage of the company.
- Urgency: this week, this quarter, someday.
- Status: open, routed, done, couldn't help.
After a quarter, sort by type and count. If "first sales hire" shows up across eight companies, that's a program. If one founder asked for a podcast studio, that's a one-off favor.
This is where a shared view of each company earns its keep. When updates, decks, email and public news land in one place, the asks and the hiring posts show up without anyone forwarding them. Turn each one into a task tied to the company, and the backlog has an owner.
Ship the smallest version first
Product teams don't build the full feature before they know anyone wants it. Platform teams shouldn't either. Before you launch a CFO network, introduce three finance leads to each other over email and see if they keep talking. Before you build a talent program, send candidates by hand to the next five roles that get posted and see how many get hired.
To choose what to try next, score your backlog with RICE:
- Reach: how many companies in the next two quarters will this help?
- Impact: if it works, how much does it change their outcome? Score 1 to 3.
- Confidence: how sure are you, based on the asks you've counted? Use a percentage.
- Effort: how many platform-team weeks will it take?
RICE score = reach × impact × confidence ÷ effort. A quick illustration with made-up numbers:
| Idea | Reach | Impact | Confidence | Effort (weeks) | Score |
|---|---|---|---|---|---|
| Same-day candidate intros | 10 | 3 | 80% | 2 | 12 |
| Monthly GTM leader peer group | 6 | 2 | 70% | 2 | 4.2 |
| Founder perks database | 25 | 1 | 30% | 4 | 1.9 |
| Annual portfolio summit | 25 | 1 | 50% | 8 | 1.6 |
The math isn't magic. What helps is the argument it forces. Once you write the summit down next to its effort, it's much easier to explain to partners why it's not first.
Measure usage, then outcomes
A product team watches whether people use the thing and whether it changes anything. Do the same for every program, with three numbers:
- Reach: what share of eligible companies used it this quarter?
- Repeat use: did they come back?
- Outcome: what came of it? A hire, a customer, a round, a decision.
Write the definitions down before launch, along with the bar you expect to clear. "We expect at least half of seed companies to use same-day candidate intros in the first two quarters, and at least three hires to come from it." Then you're not arguing about vibes at review time. What VC platform teams should measure has a fuller metric set.
Capture usage from where the work happens: intro threads, calendar invites, the reply to a candidate email. If the measurement depends on someone filling in a sheet on Friday, it won't survive the first busy month.
Distribute where founders already are
A product with no distribution doesn't get used, however good it is. For a platform team, distribution means showing up in email, Slack, WhatsApp and the calls founders already have with you. It doesn't mean a portal. Founders don't log in, and a resource hub with no traffic is just a nicer-looking version of the unused program.
So ship each program as a message, not a destination. "We've got two candidates for your open sales role, want intros?" gets an answer. "Check out the talent section of our portal" doesn't. The case against portals is laid out in do VC platform teams need a founder portal?, and scaling a platform without losing the human touch covers which moments should stay personal.
How do you find out which platform programs founders actually want?
Watch what founders ask for, not what they say in a survey. Pull the asks from updates, emails, board decks and Slack, tag them by type, and count them each quarter. Then run short interviews with five or six founders about their last hard month. Repeated asks are your roadmap.
Surveys tend to produce polite answers. Founders tick "events" and "talent" because they're on the list. An interview about a specific moment gets you real material. Try these questions:
- "Walk me through the hardest week you had last quarter. What were you trying to get done?"
- "Who did you call for help? Why them?"
- "What did you try that didn't work?"
- "If we'd shown up that week, what would have actually helped?"
Don't pitch your programs in these conversations. Just listen and take notes. Patterns show up quickly, often within the first handful of calls.
When should a platform team kill a program?
Kill a program when founders stop using it and nobody can point to an outcome it produced in the last two quarters. Set a usage bar before launch, review every program each quarter against it, and retire the bottom one. Tell founders what you cut and what you'll do instead.
Killing is the hardest part, because every program has a fan somewhere, often a partner. The usage bar you set at launch is what makes the conversation possible. It moves the discussion away from taste and toward the number everyone agreed to: "We said half the seed companies would use it, and two did."
When you cut something, close it out cleanly. A short note to founders works:
Quick update: we're retiring the monthly webinar. Attendance has been low, and your feedback says you'd rather get specific intros than general sessions. So we're putting that time into same-day candidate intros instead. If you ever want a session on a topic, just reply and we'll set one up for your team.
Then put the freed hours on the next item in the backlog, and tell the partners where they went.