Executive summary

Every conversation with a revenue or enablement leader seemed to start the same way: they needed better decks, faster videos, and everything ready before sales kickoff. So naturally, I assumed the fix was better content, made faster. That was a reasonable assumption, and it turned out to be wrong.

Over the past several weeks, we sat down with 28 people actually doing this work as part of our Lighthouse Frontline beta. They’re the people in sales, marketing, and ops who know the work best, and they share it on purpose: to land a launch, get a new hire productive, or get a new region ready.

We heard it against a broader base of 110+ conversations with L&D practitioners, whose work is a different job with its own craft.

Nobody described a content problem. They described a workflow problem wearing a content problem’s clothes.

What one deliverable actually takes

Ask almost anyone doing this job how many tools it takes to turn one piece of knowledge into something a rep or a new hire can use, and they start counting on their fingers. It rarely stops before five: something to draft it, something to design it, something to record it, something to edit it, and something to get it in front of people. That’s five handoffs, and five places for the knowledge to quietly go stale before it ever reaches anyone.

We started calling this the Five-Tool Trap, and the shape of it changes depending on where you’re standing:

One trap, three shapes. Teams need time back. Functions need the burden lifted. The enterprise needs the sprawl brought together. Solve for the wrong one, and the trap just moves.

The scale paradox

One thing surprised us more than anything else. The instinct, when a workflow is too slow, is to add a tool that solves the slowest step. It usually works, for that step. But it also adds a handoff, and every handoff is a place where the original knowledge gets a little less faithful to what the expert actually meant.

More tools was supposed to mean more capability. Instead, it usually just means more places for the truth to erode on its way to the person who needs it.

That’s the paradox: the tools everyone reaches for to fix the Trap are frequently what’s holding the Trap together. One person told us, plainly, that they’d “spent two weeks building a training deck for a product launch that should’ve taken two days.” That wasn’t a slow person. That was five tools and four handoffs, each adding a small tax that compounds by the time it reaches a rep on a call.

What this looked like in our own research

One story from the interviews has stuck with us. A revenue operations director described prepping a hundred-person sales team spread across five regions, every territory needing something slightly different, with no way to build once and adapt without starting over each time. She wasn’t asking for a faster deck tool. She said, almost word for word:

“I need to build something my whole team can use, not just me.

That’s less a content request than a request for architecture. And it’s the same request we heard, at a different altitude, from the frontline manager who needed their onboarding guide to hold up through contact with a new hire’s first week, and from the enablement manager rebuilding the same three-piece bundle every product launch because there was no system to adapt it from the last one.

Across all three altitudes, the underlying ask is the same: stop making me rebuild the wheel through five tools every single time.

The shift that’s already underway elsewhere

This pattern has played out before, in other functions that got flooded with new tools.

Marketing ops used to be the people who pushed the campaign button. Then automation made campaign execution accessible to anyone with a login, and marketing ops became the architects of what the funnel actually measures.

Sales ops used to be the people who pulled the report. Then dashboards got self-serve, and sales ops became the architects of what “pipeline health” even means across a business.

RevOps didn’t exist as a title until the tools multiplied enough that someone had to own the system connecting them, not just operate one piece of it.

The pattern holds:

When tools open up and more people can do a piece of the work themselves, 
the enablement and ops leaders who own this don’t become less relevant. 
They become the architects of how the whole workflow holds together.

The same shift is available to whoever owns enablement inside a revenue team today. The tools for building a deck or a video are more accessible than ever, the volume of “just make me something” requests is only going up, and the people who understand the difference between shipping a deliverable and building a system are the ones positioned to own what comes next.

From building deliverables to building systems

For a long time, the job has been understood simply: someone needs a deck, you build the deck. That model holds fine when request volume is low and the tools are simple. It stops holding the moment a team is fielding requests from teams, functions, and the enterprise at once each needing something structurally different, all funneling through the same five-tool pile-up.

The shift is from building deliverables to building systems, and it builds on instincts most people in this role use every day. If a Team level requester borrowed that instinct, they’d stop optimizing for one more format and start optimizing for reach. If an Enterprise-tier requester borrowed it, they’d stop asking “how do I build this faster” and start asking “how do I build this once.”

The Five-Tool Trap check: three things to try this week

None of these needs a new tool or a budget line. Each one is an act of noticing where the Trap is actually operating, and asking what it would take to build once instead of rebuilding, tool by tool, every time.

A team that’s built to move fast is built to win

What we’re describing is a revenue team where enablement runs as a system, one that already knows what a Starter, a Growth, and a Scale buyer each need, and can produce it without starting from zero every time. The tax of translating expertise into something usable gets paid once, not on every request.

The teams that get this right won’t win because they had better tools. Everyone will eventually have the same tools. They’ll win because they stopped treating the Trap as a speed problem and started treating it as a system problem.