Go-to-market articles and insights

Trelliswork wasn't the plan. Buying a business was.

Before we had a single client of our own, we spent months trying to buy a business we thought we could turn around. Roughly $25 million in revenue with Blue-chip enterprise clients. A book of business built over decades, a software asset that was dated but operational, and a list of operating problems that made it less attractive to larger buyers looking for a simple tuck-in. On paper, exactly the kind of company we were looking for.

We got all the way to diligence. Multiple rounds with the management team, deep on the financials, learning the day-to-day.

What we found became the reason Trelliswork exists.

The business we almost bought

Good clients. Real margins. A platform that, while aging, still worked. Everything checked out, on paper.

Then we asked the one question that actually mattered. How does this business find and win customers?

The founders. They had built the entire book on their own relationships, and after years of carrying it they were ready to walk away. Nothing sat behind them. No marketing function, no repeatable way new business found its way in the door. A few people, a spreadsheet, and no plan for what happened when they stepped back.

We didn't read that as a reason to pass, we read it as the plan.  

Our plan was to fix exactly that

Our whole thesis for the deal was closing that one gap. We were going to install a modern GTM system and run it with focus and consistency, so new business no longer lived or died on a handful of relationships. Buy the company, build the engine, scale the model. That plan was the reason we wanted it.

The deal came apart over value. We couldn't line up with the seller on what the business was worth. That happens. The plan survived it.

The pattern was everywhere

Once we saw it clearly in that deal, we couldn't stop seeing it everywhere else.

Founder-led businesses, mid-market businesses, even smaller enterprises tend to look the same under the hood. Real expertise, loyal clients, real revenue, and a growth engine that begins and ends with a founder, or a trusted few. It isn't a flaw specific to distressed companies or bad operators. It's what happens when you build a business the way most people build one. You sell it yourself because you're good at it, and you never stop, because nothing else is in place to take over.

We've seen it from the other side of the table since, helping a private equity client evaluate an acquisition target of their own. We walked them away from that deal for the same reason.  
‍

That gap doesn't only cap how fast a business grows. It caps what the business is worth, and eventually, whether anyone will buy it at all. No acquirer wants to pay for a business that will crumble when the key rainmakers leave.

So we built the thing we couldn't buy

We didn't go find another acquisition target. We took the system we designed to turn that one business around and offered it as a service, to companies carrying more GTM work than their team can execute.

That system became Trelliswork built around what we call the 10/80/10 model. You own the first 10%, the strategy and the calls only you can make. We run the 80% in the middle, the production and the execution. You own the last 10%, review and approval.

‍

Then we started delivering

The work taught us things we couldn't see from the outside.

We built Trelliswork for founder-led businesses first, the ones with all the right ideas and nobody behind them to execute. Running the model pulled us into the mid-market, and then further up, into companies with real budgets and real teams that still move slower than they should. The system doesn't get less useful as a company grows. It gets more useful.

Delivering the work also changed how we think a services firm should be built. That's its own piece, and we'll write it.

If your GTM has to move faster than your team can

That's the constraint we built for. Trelliswork is the GTM execution partner for B2B companies between $50 million and $500 million in revenue whose marketing has to move faster than the team allows. We bring the GTM system and get going in days, versus most large agencies that take three to four months to onboard.

‍

Being lazy just got harder

That is a good thing. Becuase AI slop is out of control.

Don't believe me? Open LinkedIn and scroll five posts.

Four of them are 100% AI.

Claude's text now carries a watermark you can't see. Anthropic built it on SynthID, a technique Google DeepMind published in 2024, and it costs nothing in writing quality. Copy the text into another document, another platform, another email, and the mark usually survives the trip. It doesn't say who used Claude. It only says Claude was involved. Anthropic is also shipping a way to check: run any piece of text against the Claude API and get back the odds that Claude wrote it.

Until now, the main way to catch AI writing was to spot the tells: the tics, the rhythm, the phrasing that gives it away. That method is crude, and it doesn't scale across platforms. LinkedIn already has an "AI slop" button people can hit to flag a post, and every flag trains its detection model a little more. A watermark changes the game. Platforms no longer have to guess from style. They can check directly, gain greater confidence in their detection accuracy, and take direct action.

Here's the full rundown on the watermarking approach from Anthropic.

Here's where we'll feel it

Content rankings will start to move first.

LinkedIn, Google, Reddit, and others will start testing what happens when they quietly down-rank content that keeps tripping the watermark. Posts and pages that read as more human climb instead.

Inboxes come next.

Spam filters already weigh dozens of signals, and AI-content detection is a natural one to add. A team running the same lightly-touched AI sequence across a thousand contacts could watch its deliverability quietly slide, with no idea the watermark is why.

Then it gets personal for agencies.

Once a client can run the check themselves, they will. "Was this written by AI?" stops being a hypothetical and starts being a question in a kickoff call or an end of week summary report. A team with a real editing process answers it without flinching. A team without one starts explaining itself.

None of that is really about the technology. It's about who gets rewarded. The teams doing the harder work, using AI but still holding the bar high, become worth more over time than the teams pumping out raw model output and hoping nobody checks.

That's the standard to strive for. Every piece has to solve a real problem, and every piece has to carry an actual human team's opinion, not a smoothed-out average of one. Expertise and trust don't come from anywhere else. My personal hope for where we're at? As detection gets better, that gap should only widen, and human-led work should start winning again.

Raising the bar

We're optimistic about where this goes: An internet that isn't drowning in unoriginal, interchangeable AI text. One where a person's actual ideas carry more weight than they have in years, once you can finally hear them over the noise.

Here's the comparison I keep coming back to: DeepMind's advances in Go a few years ago. Move 37 didn't just prove the AI could win. It made every human still playing the game better. That's the shape of what's coming for marketing content. The human-made kind most of all.

And this isn't a mutiny on all things AI, to be clear. We use AI every single day in the work we do for clients. Our clients expect it. The difference is whether your agency is bringing anything to the table 'besides' the easy button. Our approach is anchored in our 10-80-10 model, which you can read about here.

It's easy to generate slop.

It's harder to think critically, solve problems, expand your perspective, have an opinion, review with a client, improve the position, create a supporting visual, on brand, ship to production, and wake up and do it all again.

What's the call to action? Save the internet. Don't be lazy.

Do the hard work.

Most teams adopting AI for delivery are optimizing for one thing: speed of adoption. Pick a tool, build it into your workflows, and move. It feels fast because you are moving fast. But nobody stops to ask the harder question. What happens when a tool in your new workflow doesn't show up for work?

Or worse: what if the platform you run those tools on is just having a bad day and calls in sick?

We found out yesterday.  

Claude is our primary work surface. We run most of our client delivery through it, both Claude Cowork and Claude Code, and it has done a lot to make a messy pile of client workflows feel like one place to work. Then, on a heavy delivery day when we needed Claude to show up, our team got the ominous service outage notice.

‍

Claude was down. And this time, it felt like half our company didn't show up for work.

If you use Claude as often as we do, you know outages aren't uncommon. To their credit, they are shipping at a crazy pace, and it would be even wilder if there was never a disruption! But as we scale the codebase our delivery system runs on, those outages hit harder. We rely on the platform more every month, and that reliance has created a new risk surface.

For an AI-native business like ours, a single work surface like Claude is now, besides our people, the most consequential operational risk we carry.

The real cost isn't downtime. The cost is going backward.

When people picture an AI outage, they picture work stopping. In real life, and as an agency operating in this mode everyday, you don't stop; you fall back to the old way of working.

Once you’ve run at the pace these tools allow, the old way is genuinely painful. The whitepaper that took a morning is back to a week of copy-paste and formatting. The ICP you would normally call up in seconds turns into a hunt through Google Drive. The article you would have shipped by lunch waits. Your clients' expectations don't reset because your tool had a bad day. The turnaround they now count on was set by the fast version of you, and on the slow morning you still owe it. That gap between the speed you built the business around and the speed you can hit without your stack is the cost. You feel it in every deliverable that used to be quick.

And the exposure runs deeper than the tool you work in. There are two layers here, and most teams have a backup for neither.

The first layer is the harness, the surface you actually do the work in (think Claude Cowork, chatGPT, etc). The second is the connectors, the pipes into the systems where the work lands. Webflow. Granola. HubSpot. Your CMS and CRM. Those connectors are not resilient in themselves, and they’re constantly changing. This morning, Webflow would not connect from Claude Cowork at all, while it worked fine from Claude Code and from every other AI tool we tried. Same company, same login, one path broken and the rest fine. A connector failure drops you back to the old way just as fast as a harness failure. You are only as portable as your weakest layer.

How we got back up in fifteen minutes

We recovered fast, and not by luck. We recovered because of how the stack was built.

Everything we do is a skill. A skill is a markdown file with instructions, a saved recipe the AI follows. Brand voice, ideal customer profile, whitepaper generation, each one is its own file. Those skills are grouped by client into plugins. The plugins live in a marketplace, and the whole thing is managed in code in GitHub. Our delivery stack is, in effect, a codebase. It is built on an open standard for defining a skill, not on anything proprietary to a single vendor.

That one design choice is what saved the morning. Because the stack was code and the format was open, we pointed it at a different engine. We took the same GitHub repository into Grok, then into Codex, launched it from the same folder the same way we would in Cowork, and ran the same client skills. There was some translation to get another engine to read a stack we had first shaped for Claude, but the assets themselves moved cleanly. From dark to running took about fifteen minutes.

The swap was natural because we were already multi-tool by choice, not just in a crisis. Claude is home base, but we run Grok and Codex for the workflows they handle better. Different engines are genuinely better at different jobs, so we already reached for the right one per task. The outage just proved that the same portability we used for fit, we could use for survival.

Think portable, single sources of truth

The reason the move worked is not the specific tools. It is that we treat marketing delivery the way an engineer treats a codebase, and one principle carries most of the weight. A single source of truth.

In our world, that means every process, standard, and reference we reuse lives in exactly one place, as a skill. A skill packages the knowledge of a workflow, a brand standard, a data mapping, or a template, with its own inputs and outputs. When a delivery surface needs that knowledge, it references the skill. It does not copy it.

That one rule shuts down the two failures that turn AI adoption into chaos. The first is replication: a dozen versions of the same messaging framework scattered across delivery folders, each drifting a little further from the last, and a token tax paid every time someone hunts for the right file. The second is reinvention: two people rebuilding the same ICP or the same whitepaper process from scratch because neither knew the other had already done it. Single-sourced skills remove both. Improve the skill once and every workflow that calls it improves with it.

The payoff is composability. Skills stack into plugins, plugins are organized by client account, and a workflow gets assembled from single-sourced parts instead of rebuilt by hand. That is what lets us run our execution engine as code. It is also the difference between a pile of disconnected Claude chats each improvising and one organized, efficient, AI-native delivery motion.

Here is what that looks like in practice. Take an ideal customer profile. One approach is to write it up, save the document in the client's delivery folder in Google Drive, and move on. It works until you try to use it. Now someone has to remember where it lives, point the AI at it, and spend tokens loading it every single time. Worse, if your work is scoped to a subfolder, the tool may never look up the tree to find it at all. The ICP is right there and still out of reach.

The better version is to promote that finished ICP into a skill. Once it is a skill, it behaves like an imported library. You call it from anywhere, it loads on demand, and it reads the same every time. That is the difference between a filing cabinet and a system. It is the same property that let us move our entire stack into a new engine overnight. The ICP-as-skill and the fifteen-minute recovery are the same principle at two sizes.

Thinking like an engineer inside a marketing team is what pays off here. Same discipline, applied to a different kind of output.

Your over-reliance on Claude risk won’t go away on its own

It is tempting to treat all of this as temporary. Pick whichever model is winning, wait for it to pull ahead for good, and skip the hassle of staying portable. That bet misreads the moment.

We are not heading into a winner-takes-all world where one model rules them all. The lead changes every few months. The engine that is best at long reasoning today gets passed on coding next quarter, then leapfrogged again. That is exactly why we already run Claude, Grok, and Codex side by side, each for what it does best. Betting your delivery on one model winning permanently is betting against the one thing you can count on right now, which is that things keep changing.

And here is the part that holds even if you disagree. Say one model did win outright and stayed ahead. You still would not want your whole company wired to a single vendor's uptime, pricing, and roadmap. Over-dependency is a weak position even when the thing you depend on is excellent. Great today does not owe you great, available, and affordable tomorrow.

Change is constant right now. That makes a backup plan cheap insurance, and it makes skipping one an expensive mistake to get wrong, because the alternative when it breaks is the painful, slow way of working you already left behind.

What it costs to skip this

If you don't build this way, you are one bad morning away from being dragged back to the old pace. And the trigger is not yours to pull. It belongs to a vendor.

You will have rebuilt your business around a speed you cannot reliably hit. Every asset trapped in one tool or buried in a folder is a dependency you cannot see until it snaps you backward. Teams that skip this keep reinventing the same deliverables, and they keep getting surprised when a company they don't own decides how fast they get to move that week.

Redundancy here is not overhead. It is what protects the pace your client promises now depend on.

Oh, and just in case you need this later: https://status.claude.com/

‍

Earlier this month Chris and I got to spend time with a graduate-level marketing class at the University of Washington. It was a fun group, and the goal was simple: give them an honest look at what day-to-day marketing actually feels like inside a GTM agency like Trelliswork, and where the work seems to be heading. We talked through how much has shifted, and we kept circling back to one idea that matters more now than at any point in our careers: the way you learn marketing has to change too.

Here is what we walked through.

Marketing has changed

The fundamentals still hold. Know your audience, tell a clear story, earn attention. But the surface area of the job is bigger now. A marketer touches data pipelines, automation, AI tools, and code on a normal Tuesday. The role looks less like a campaign planner and more like a combination of builder and air traffic controller, making the thing and directing everything moving around it.

It's more technical than ever

You no longer hand off the technical work and wait. The people producing the best output are the ones who can open a terminal, wire up a tool, and ship the thing themselves. Comfort with technical work is becoming the difference between a good marketer and a stuck one.

You have to jump in headfirst

You don't learn this from a syllabus. You learn it by staying curious, trying new tools and approaches before you feel ready, and looking for better ways to work along the way. The students who get ahead will be the ones who stop waiting for permission and start experimenting.

Everyone is relearning

Everyone is learning the new tools at the same time, so on the technical side the gap between a student and a veteran is smaller than it has ever been. But experience matters more than ever. Judgment, taste, and knowing what good looks like are valued above anything else, because the tools change but the ability to point them at the right problem does not. That is the opportunity: pair fast learning with real judgment and you become hard to replace.

Think in code

Code is becoming the medium for now, not just the back end. I say for now because coding may not stay as important as it is today. But in this moment, code gives you more control over the models than any other interface. When you can describe what you want and build it directly, you skip the handoffs, the misread mockups, and the version sprawl. It also lets you get to discrete points in the creative process, returning to any version or branching from it instead of working off one file that keeps changing under you. You stop decorating slides and start shipping work.

The tools have all changed

The stack you learn on today will not be the stack you used a few years ago, because most of it did not exist yet. Claude, RB2B, Granola, Clay, Gemini, Riverside. These tools enable more than 80% of the work we deliver for clients, and none of them existed five years ago. Learning a fixed set of tools is no longer the goal. Learning how to pick up new ones fast is. We evaluate new tools on an almost daily basis. The only real choice is to keep adapting and evolving. And to be fair, it is exhausting trying to keep up.

What this looks like in practice

To make it concrete, we showed the class three whitepapers we built for three different clients. Every one was created and published entirely in code, from a terminal. No design tool, no page editor, no dragging pixels around a canvas.

The point was not that the work built itself. It was that we got to rethink the whole process. When the document lives in code, a round of feedback is a change in the source, not a manual rebuild. A revision that used to mean a designer, an export, and a reformat became a single pass. So the cycle time went from days or weeks to minutes.

That is the shift. Not a faster version of the old process, but a different process altogether.

The takeaway

Marketing rewards people who build. If you are early in your career, that is good news. The tools are new enough that effort and curiosity can outpace tenure, but the point is not to beat experience. It is to gain it faster. Curiosity is the bridge. It lets you take on real work sooner, see more reps, and build judgment years ahead of schedule, and experience will always be what matters. Open the terminal, make something, learn from it, and do it again.

‍

For most of my career, writing was how I thought. Not a way to communicate ideas I'd already formed — the actual mechanism for forming them. Sitting down to write forced clarity. It revealed the gaps in an argument, surfaced the assumptions I hadn't examined, and turned vague instincts into something I could actually defend. Writing is thinking. I built a lot on that foundation, and I still believe it.

But something has shifted. And the more I sit with it, the more I realize it's simply a latency problem.

The ideas that matter most in a content program aren't the ones you schedule time to develop. They're the ones that surface in motion — on a call, between meetings, in the ten minutes after a conversation where something clicked. By the time you've cleared space to write, the latency has already done its damage. The moment has cooled. What you produce is a reconstruction: technically accurate, but missing the charge the original idea carried.

I've tried the usual fixes. Notes apps, calendar blocks, drafting on my phone. None of it addressed the real issue, which is that writing — even when you know exactly what you want to say — puts translation cost between the idea and the output. Attention, word selection, structure. You're spending cognitive load on the container instead of the content, and the gap between when you had the thought and when you finally sit down to write it widens that cost further.

That's what pushed me toward video capture. Not as a content format, but as a mechanism for closing that gap. Talk through the idea the moment it exists, in your own voice, before it flattens into something more considered and less alive.

What I found on the other side of that shift — for us and for the clients we've built this with — is a simple reframe:

The content problem isn't really a writing problem. It's a capture problem.

Start with the capture, not the content

Most teams approach content creation backwards. They decide what they want to publish, then go looking for someone to produce it. That model works fine when you have dedicated content staff. For everyone else, it creates a dependency loop: the subject matter expert is already overcommitted, the content request sits in a queue, and the moment passes.

Flip it. Make capture the habit, not publishing.

When an idea surfaces — a customer question, a pattern you're seeing in deals, a reaction to something happening in the market — spend two minutes on camera. Don't script it. Don't overthink the framing. Just talk through the core point like you're explaining it to a colleague. That's it. The recording goes to a content workflow, and the downstream pieces get produced from there.

This works because the barrier to hitting record is close to zero. Writing a LinkedIn post from scratch takes 20 to 45 minutes if you want it to be good. Talking through an idea takes two minutes, and the quality of insight is actually higher because you're not spending all your cognitive load on word selection.

The goal is to get that barrier as close to zero as possible. Riverside's mobile app gets you most of the way there — pull it out in the parking lot after a call ends, record while the conversation is still fresh, and put your phone back in your pocket. No desk required, no setup, no scheduling. The idea stays alive because you captured it at the moment it existed, not an hour later when you finally had time to sit down.

The workflow: capture to content

Once you have a recording, the rest follows a predictable path.

Your capture tool generates a transcript automatically. Don't clean it up too much — you want the natural language and rhythm intact. That transcript is your source material. Everything else gets built from it.

From there, pull the core argument. What's the one thing this capture is really about? That single point becomes your anchor for every downstream piece.

Then remix. A single capture maps to multiple content types:

• A LinkedIn post (the punchy, direct version of the core point)
• A website article or blog post (expanded context, practical guidance, SEO-ready)
• A newsletter section (shorter, more personal, written for subscribers who already know you)
• A short video clip (if the capture quality supports it, used natively on LinkedIn or in outreach)
• A graphic or visual asset (quote card, stat, or framework visual)

You won't produce all five from every capture. But you'll consistently get two or three, and the effort stays roughly the same regardless of output count because the hard part — the idea — already exists.

The tool stack

You don't need much. The goal is fewer tools in the chain, not more.

Riverside is the best option we've found for this workflow. It handles async recording with no scheduling required, generates a clean transcript automatically, and includes basic editing tools for shareable clips. It replaced a whole cluster for us: Zoom for recording, Otter for transcription, Descript for editing, a separate clip tool, and a scheduler. One platform. The mobile app extends all of it to wherever you are, so capture happens when the idea surfaces, not when your calendar allows it.

For teams that want to go further, we set up dedicated recording studios for our clients — a physical space in the office with a camera, a clean background, good lighting, and Riverside already open. No configuration, no fumbling with settings. You walk in, hit record, walk out. The setup effort happens once. After that, the only thing standing between an idea and a captured asset is the decision to walk into the room. That's what point-and-capture looks like in practice: a system where the bottleneck is the idea itself, not the infrastructure around it.

On the content production side, the transcript feeds into whatever writing workflow you already use. A content team works from it directly. AI-assisted tools take it as input. Either way, the raw material is specific and real, which produces better output than prompting from scratch. Connect your standard publishing tools on the back end — CMS, LinkedIn, email platform — build a simple queue, and the pipeline runs.

Why we like Riverside

We're not affiliated with Riverside. We just use it, and it's earned its place.

The capture piece gets all the attention, but what keeps us on it is everything else that comes with the recording. Audio leveling handles the difference between someone who's three feet from their mic and someone who's on a laptop speaker across a noisy office. Filler word removal cleans up the ums and ahs before the transcript hits your workflow, which matters more than you'd think when you're using that transcript as raw content material. Auto captioning means your clips are ready to post natively — no extra step, no third-party tool. Brand kits let you apply consistent visual styling across clips without touching a design tool every time.

For a two-minute capture, that's a lot of production value baked in before a content person ever touches the file.

Is it perfect? No. The organization layer is honestly a bit of a mess right now — finding older recordings, managing projects across multiple contributors, keeping things tidy at scale — it's not where it needs to be. They know it, and from what we're told, it's being worked on. In the meantime, the dedicated Studios feature (available on the Business tier) does a lot of the heavy lifting. It gives you a structured home base for captures, keeps contributors working in a defined space, and reduces the "where did that recording go" problem that tends to crop up as usage grows.

The production quality you get out of a two-minute phone capture is genuinely good. Good enough that we've used raw clips directly in client content without any additional editing. That's the bar we needed to clear, and Riverside clears it.

Better results with less busywork

More content, produced faster — that part is obvious. The structural fix underneath it is less talked about.

Most content programs die from coordination overhead. You need a meeting to brief the subject matter expert. You need a follow-up to get their review. You need another round to reconcile their edits with the brand voice. By the time the piece publishes, the moment it was relevant has passed.

Video capture kills most of that coordination. The subject matter expert contributes raw material in two minutes with no dependencies. The content workflow runs downstream from there. You're not chasing people for drafts — you're processing what they already gave you.

The other thing it fixes is access. When capture friction is low enough, the people who actually know the customer start contributing consistently. That's where the best content comes from — not content teams writing in a vacuum, but the people having the real conversations.

Getting started

You don't need to build the full system before you start seeing value. Start with three things.

Pick your capture tool and set it up for async recording. Establish a simple habit — record when an idea hits, not when you have time to produce content from it. And designate someone to run the downstream workflow, whether that's a content team member, an agency, or an AI-assisted process.

Run it for 30 days. Measure how many captures you produce versus how many content pieces ship. Adjust from there.

The teams that get this right aren't the ones with the biggest content budgets. They're the ones who found a way to make showing up consistently easier than not showing up. Video capture is how you get there.

Trelliswork helps B2B teams build content systems that scale without scaling headcount. If your content program is stuck on consistency, let's talk.