Structure GTM support in tiers. Give every company a programmatic base of peer groups, shared resources and buyer intros matched by ICP, then add bespoke help only when a company hits a specific go-to-market moment. Match the help to stage, name one owner per company, and track every intro and session to an outcome.
GTM support usually comes in one of two versions. In the first, the platform team runs a monthly sales webinar series, and attendance drops every month until it's the same four founders. In the second, one partner who used to run sales jumps into every big deal personally, and by spring they're burned out and half the portfolio never got a minute of their time.
Neither is wrong, exactly. The webinar team picked scale, and the partner picked depth. The problem is they picked one and called it a strategy. GTM is the area where founders ask for help most and where help is easiest to measure (a meeting happened, a deal closed), so it's worth designing on purpose.
Three tiers: base, triggered and deep
Think of GTM support as three tiers. Every company gets the first. Companies move into the second and third when something specific happens.
| Tier | Who gets it | What it includes | Platform time per company |
|---|---|---|---|
| Base | Every portfolio company | Peer groups, shared templates, buyer intros matched by ICP | An hour or two a quarter |
| Triggered | Companies showing a GTM signal | A pipeline review, a pricing session, candidates for a first AE | A few hours over a month |
| Deep | Two or three companies at a time | A multi-week project with an operator, or an embedded platform person | Many hours a week |
The time column is illustrative. What matters is that the deep tier is small and capped. If a two-person platform team has eight companies in "deep" at once, nobody is really in deep. Pick the two or three where your help will change the outcome most this quarter, and rotate.
For deep help, an outside operator who has done the job before is usually worth more than the platform team doing it themselves. Your expert advisor network is where those people come from. And if a platform person embeds directly, the rules for embedding in a portfolio company apply.
Use signals to move companies between tiers
The hard part of tiered support isn't the tiers. It's knowing when a company should move up. Founders rarely send an email saying "we need GTM help now." They say it sideways, in places nobody routes.
Some signals worth watching:
- A founder posts the company's first account executive role on LinkedIn.
- A monthly update says pipeline "softened" two months running.
- The company announces a first enterprise logo, which means a reference customer and a security review are next.
- A board deck shows the sales cycle doubling.
- A founder asks in a peer channel how others priced their enterprise tier.
Each one is a trigger: signal → owner reaches out → company moves to the triggered tier for a month. Say a seed company posts its first AE role. The owner sends a note that day with two or three candidates from the talent network, a sample comp plan (the post on first GTM commission plans covers how to advise on that), and an offer to connect the founder with another portfolio founder who made the same hire last year. That's a few hours of platform time, delivered when the founder actually cares.
Silence from a founder doesn't mean nothing is happening. Usually the signal is already public or sitting in an update nobody read closely.
Name one GTM owner per company
When GTM help is everyone's job, founders get pinged by three people from the same firm in one week, or by nobody for six months. Name one owner per company. That person doesn't do all the work. They decide what help the company needs and route it.
A simple split for a fund with partners and a small platform team:
- Deal partner: owns the relationship and the big strategic calls, such as when to hire a VP Sales.
- Platform owner: watches signals, runs the base tier, pulls in operators and buyers.
- Operators and advisors: do the deep work on specific projects.
Write it down in the same place you track portfolio companies. If someone asks "who's helping this company with sales?" there should be one name.
Run the programmatic layer where founders already are
The base tier lives or dies on whether founders use it. I'm not a fan of building a GTM resource hub and emailing everyone the link. Founders don't go there. They're in Slack, WhatsApp and email, and that's where the base tier should run too.
What tends to work:
- Function-specific peer groups. A channel or group chat for founders who sell to enterprises, and another for founders running product-led growth. Founders answer each other faster than the platform team can.
- Small pipeline reviews. Four or five founders, one hour, each shares one stuck deal. Run it monthly, with an operator leading the session.
- Templates sent when they're needed. The sales comp template goes out the day a company posts an AE role, not in a newsletter six months earlier.
- Buyer intros matched by ICP. After every corporate conversation, ask which portfolio companies the buyer should meet. The method is in building buyer networks.
Track it like a pipeline
GTM support is easier to measure than most platform work, so measure it. Every buyer intro gets a row: intro → meeting → pilot → contract. Every pipeline review gets a note on what the founder changed afterward. Every deep project gets a before-and-after on the one number it targeted.
Over a year, that becomes a log you can show partners and LPs: this many customer intros, this many became pilots, this many became revenue. It also tells you which tier is earning its time. If the monthly pipeline reviews lead to real changes and the webinars don't, stop the webinars.
The findings from diligence should feed this too. If the team flagged a weak sales motion before the investment, that becomes the first item in the company's support plan, which is the handoff covered in the platform team's role in GTM diligence.
If you're tracking 40 companies with two people, catching the signals is half the job. Route every signal to a named owner. A new AE posting or a softening pipeline in an update should land with the person who runs that company's GTM support, not sit unread in a shared inbox.
Should GTM support be programmatic or bespoke?
Both, in layers. Programmatic support covers the problems every company hits, such as first sales hires, pricing and pipeline reviews, at a low cost per company. Bespoke support is for the moments that decide a company's path, like a first enterprise deal or a stalled expansion. Run the program by default and spend bespoke hours on purpose.
The mistake I see is drift. A team starts with a program, a few founders ask for more, and within a year the platform lead is doing bespoke work for whoever asks loudest. Review the deep tier every quarter. Ask whether each company still needs it, and whether a quieter company needs it more.
What GTM help does a seed company need versus a Series B company?
Seed companies need help finding a repeatable way to sell: first customers, founder-led selling, early pricing and the first sales hire. Series B companies need help scaling what already works: sales leadership, segmentation, forecasting and new channels. The platform's job shifts from opening doors to connecting leaders with operators who've scaled the same motion.
| Stage | Typical GTM problem | Most useful platform help |
|---|---|---|
| Seed | No repeatable sale yet | Design partner and first-customer intros, pricing feedback, first AE candidates |
| Series A | A motion that works for the founder only | Hiring the first sales leader, comp design, pipeline reviews |
| Series B | Scaling, forecasting, new segments | Operator peers at the VP level, channel and partner intros, enterprise buyers |
A seed founder wants a meeting with a buyer next week. A Series B head of sales wants a call with someone who took a team from 10 reps to 40 and can say what broke. Same category of help, very different intros. If your support menu looks the same for every stage, it's probably built for nobody in particular.