Early enablement before your first enablement hire: What to build and what to skip

TABLE OF CONTENTs

TABLE OF CONTENT

How to survive the messy middle between founder-led sales and a real sales enablement function

There's a long stretch between founder-led sales and your first enablement hire, where enablement is everyone's job and no one's title. At some companies, this phase lasts years.

Alex and I have both lived it. He went through it at Lattice, where the team scaled from a handful of sellers to a full go-to-market org before anyone considered hiring enablement. And I’ve worked at three early-stage startups as the only marketer and no supporting enablement function.

And at Dock, we're still in it. We're a sales enablement company that doesn't have an enablement person—which is either ironic or instructive, depending on how you look at it.

We've made it work by distributing the responsibilities across a small team, staying deliberately scrappy, and resisting the urge to overbuild.

Here's what we've learned about what actually matters during this messy middle—and what's a waste of your time.

Growth Bytes

Top takeaways:

Tribal knowledge is the right default pre-PMF. When your product, persona, and sales motion are still shifting, writing everything down creates a false sense of permanence.
Start with two things: your pitch deck and your demo environment. That covers 80% of what early sellers need. Everything else can wait.
Hire high-agency reps first. Your earliest sellers need to thrive in ambiguity—not sit around waiting for a battle card.
Enablement is a team sport before it's a title. Distribute it across product, marketing, sales leadership, and ops until the pain of not having a dedicated person becomes undeniable.
Measure enablement by close rate, not content volume. More collateral doesn't mean better enablement. Track whether deals actually convert faster.
The real hiring trigger is ramping pain. You only need an enablement person once you're onboarding so many reps that no one on the existing team has bandwidth to train them.

Tribal knowledge is a feature, not a bug

The instinct when you hire your first handful of sales reps is to document everything. Build a wiki. Write battle cards. Create a formal onboarding program.

If you came from a big company, this instinct is even stronger—you're used to structure, and the absence of it feels like negligence.

Resist it. In the early days, tribal knowledge is the correct operating model. The founder figured out how to close deals, and now they're transferring that knowledge in real time—on calls, in Slack, over lunch. There shouldn't be a playbook yet. Reps should learn by osmosis, watch each other's calls, and share wins on Slack.

Documentation feels productive, but if you haven't nailed product-market fit, you're paving a road you'll soon have to reroute.

"Writing a lot of things down actually starts to become a hindrance rather than something that helps you accelerate growth." — Alex Kracov, CEO of Dock

Lattice started as a goals and OKR product before pivoting to performance reviews—a completely different persona and sales motion. Dock went through a similar shift, moving from a horizontal product with dozens of use cases to a focused sales enablement platform.

If either company had invested heavily in enablement collateral during those early days, all of it would have been thrown out.

There's another reason to stay loose: at this stage, you want your reps selling differently from one another. Different approaches, different personas, different levels of founder involvement—that variability is how you figure out what works.

In a scaled org, enablement drives consistency. But pre-PMF, enforcing a standardized process on a motion you haven't validated is worse than having no process at all.

The only collateral that matters in the early days

So if you're not building a documentation empire, what should you actually produce? The list is shorter than you think.

A pitch deck. This is the first piece of enablement that moves from the founder's brain into a shareable format. It doesn't need to be polished—it just needs to be functional. Keep iterating on it as the positioning evolves.
A demo environment. Most early-stage SaaS companies are selling through product demos. The demo itself is arguably more important than any deck or document. Nail the flow, the story, and the environment so reps can demo confidently.
A follow-up asset. A Loom or Tella recording of the product demo makes a solid post-meeting leave-behind. It gives the champion something to share internally without requiring the rep to be in the room.
Pricing guidance. How you communicate value and price doesn't need to be a polished PDF, but reps need to know how to talk about it.

That's it. That's your early enablement stack.

"If I had said, 'Eric, make a competitive battle card for 90 different competitors,' that would not have been useful." — Alex Kracov

Alex isn't exaggerating—Dock legitimately had around 50 competitors in the early days. Today it's a core set of three or four. If we'd built battle cards for all of them, most would have been obsolete within months.

The same logic applies to detailed sales playbooks, elaborate objection-handling docs, and multi-page buyer personas. If it's going to change in six months, it's not worth formalizing now.

That said, you do want to listen to your reps. If one competitive name keeps coming up on calls, build the battle card for that specific competitor.

The key is to react to patterns rather than try to anticipate every scenario. As Alex puts it, you might not act on a request the first time—but if you keep hearing it, that's a signal.

Hire reps who don't need a playbook

This is worth calling out on its own, because the type of rep you hire in the early days directly determines how much enablement infrastructure you need.

Early-stage selling requires a fundamentally different archetype than scaled selling. You need high-agency reps who can tolerate ambiguity, figure things out independently, and—critically—create their own collateral when it doesn't exist.

If a rep needs a polished battle card before they can handle a competitive deal, they're the wrong hire for this stage.

This flips later. Once you're in scale-up mode and hiring large cohorts, you want more process-oriented reps who can follow a defined playbook with discipline.

Those coin-operated sellers are incredibly valuable at that stage. But they'd struggle—and probably churn—in an environment where the ICP is shifting, and the CRM was an Airtable base six months ago.

The implication for enablement: if you've hired the right early reps, they need less. They'll flag what's actually blocking deals rather than requesting documentation for its own sake.

When they do ask for something, take it seriously—they're close to the customer and not the type to ask for help they don't need.

Four roles, zero enablement hires

When there's no enablement function, the work gets distributed—whether intentionally or not. The question is how to divide it in a way that doesn't burn anyone out or let critical things fall through the cracks.

The way Alex frames it, four roles cover the territory: product, marketing, sales leadership, and operations. Depending on your team size and budget, these might be four people or they might be one founder wearing all four hats.

At Dock's earliest stage, Alex was literally all of them—standing up the CRM, drafting the pitch deck, running product, and coaching the first rep.

At Lattice, the responsibilities were more divided from the start, with Jack Altman (CEO) driving product vision, Alex running marketing, and Lester Lee (Head of Revenue) building out Salesforce and the sales process.

The specific division matters less than two things:

that someone is thinking about each area; and
that the founder stays close to the customer.

"The worst thing you can do as a founder or CEO is get far away from your customers and what they're saying." — Alex Kracov

Alex is no longer on every sales call at Dock, but he reads every support ticket, listens to recorded calls, and regularly asks the team what would make their jobs easier. That proximity is what makes the distributed model work—without it, enablement decisions get made in a vacuum.

For me, the unexpected benefit of owning enablement content as the marketer has been the feedback loop it creates.

When I'm making our case studies, I know exactly which objections to have customers address, because I've seen what comes up in the sales process. When I'm writing website copy, the language is sharper, and the differentiation is better because I've done the competitive research myself.

The enablement work I’m doing puts me closer to the buyer, and that translates back into Dock’s marketing.

The marketer's tension: filling the funnel vs. converting it

There's a real push-pull that comes with marketing owning enablement.

My job title is Head of Marketing, but my actual job toggles constantly between two modes: generating pipeline and converting pipeline.

Early on at Dock, when the average contract was around $1,000 a year, and the model was product-led, most of my energy went to top-of-funnel—SEO, website traffic, getting a million visitors.

But as Dock's average deal size climbed and the motion shifted toward sales-led, the content that mattered most moved down-funnel. Competitor comparison pages, case studies, sales collateral—these became the money content

"Whenever I'm making something in marketing, I'm asking: can this also be used in the sales process? Can this also help us convert more?" — Eric Doty

That dual-purpose test has become my default filter. If a piece of content only serves one stage of the funnel, it better be exceptional.

The comparison pages we write are both SEO plays and competitive enablement. Case studies work for demand gen and for reps sending proof points mid-deal.

Alex's advice for marketers in this position: measure your impact on close rates and time-to-close, not just leads. Pipeline is the glory metric, but revenue is what matters.

And your ACV should dictate where you spend time—if you're selling $50K+ deals, you won't have the luxury of high volume. Each opportunity has to convert.

When the DIY tech stack breaks down

Most companies start enablement on the tools they already have:

Content storage: Google Drive or SharePoint—just a folder where you dump battle cards, decks, and one-pagers.
Content creation: Google Slides or PowerPoint for decks, Figma or Canva for anything that needs to look polished.
Internal wiki: Notion or Confluence, though at this stage it should be barely maintained. (Dock's Notion still is, embarrassingly.)
CRM: Airtable if you're scrappy, HubSpot or Salesforce once you graduate.

This works for a while. Then the cracks show up: Google users can’t share Docs with Microsoft users. You can't tag content or make a single asset discoverable across multiple contexts. Your Drive is a disaster because it's also where you keep internal project docs too. And you have zero visibility into whether anyone is actually engaging with the stuff you've made.

That frustration, incidentally, is what led Alex to build Dock.

"What was frustrating to me at Lattice was—I had a team making all this enablement collateral, and you're just sending it into the void." — Alex Kracov

But the broader point applies regardless of tool: at some point, you need a dedicated layer between "everything lives in Drive" and "we bought Seismic"—something lightweight that gives your revenue team a place to organize client-facing materials.

We've been dog-fooding Dock for this exact purpose, and our deal rooms became the backbone of our enablement practice.

The template started simple—an intro, a lightweight mutual action plan, the pitch deck, and a demo video. As the sales process matured, it grew: business case templates, a case study library, and product pages for different use cases.

The deal room became a living map of our sales process rather than an abstract document somewhere.

As the marketer, having visibility into how our sales team uses that content—and how buyers actually engage with it—has changed how I prioritize. When I noticed prospects were watching case study videos but not reading the written stories, I knew to invest more in video. That kind of signal is invisible in a Google Drive world.

When to finally hire your first enablement person

The honest answer: later than you think. Most companies can run the distributed model for longer than they expect, especially with high-agency reps and lightweight enablement.

The real trigger isn't team size. It's ramping pain.

When you look at next year's revenue plan, realize you need to hire 30 or 50 reps, and nobody on the existing team has the bandwidth to train them, that's the moment to hire—when you physically cannot do this without one.

"You should really only hire people when you feel real pain—when it's a desperate need, when the current team just can't do it anymore." — Alex Kracov

At Lattice, the enablement hire came at the Series B or C stage, when the company was already a couple hundred people. Alex's assessment in hindsight: too late.

The first enablement hires at Lattice brought a curriculum mindset that was missing before. They sequenced what reps needed to know and when, rather than dumping information on them all at once.

That's the thing you can't replicate with a distributed team. A marketer thinks about assets. A sales leader thinks about coaching. An enablement person considers the entire ecosystem—how to take someone from zero to productive as quickly as possible. In a hypergrowth company, there's no higher-leverage activity.

Until you're at that inflection point, though, don't rush it. Build the pitch deck. Nail the demo. Hire reps who can operate in ambiguity. And keep your founder close to the customer. That's the enablement program that carries you further than you'd expect.