<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>And/or Labs | Writing</title><description>Essays and explainers on GTM engineering, positioning, and content strategy for AI, adtech, and deeptech founders.</description><link>https://andorlabs.ca/</link><language>en-us</language><item><title>B2B content marketing strategy for startups that hate slop</title><link>https://andorlabs.ca/blog/b2b-content-marketing-strategy-for-startups-that-hate-slop/</link><guid isPermaLink="true">https://andorlabs.ca/blog/b2b-content-marketing-strategy-for-startups-that-hate-slop/</guid><description>Your buyer does 83% of the journey without you in the room. Whatever you published is what turns up in your place, so it had better be able to hold the argument alone.</description><pubDate>Wed, 12 Aug 2026 17:38:28 GMT</pubDate><content:encoded>Your buyer is doing homework at 11 p.m. Four vendor tabs open, a half-built business case in a spreadsheet, and a Slack thread where two colleagues are quietly forming opinions. You are not in that room.

Gartner puts the share of the B2B buying journey that buyers spend meeting with potential suppliers at 17%. Split that across a shortlist and any single sales rep gets 5% to 6%. The rest of the decision happens without you, and whatever you have published is what turns up in your place.

Most founders ask whether content marketing is worth the effort. The better question: can what you publish survive being read while you are not there to explain it?

Most of it cannot. Which is roughly how we got here.

What B2B content marketing actually is

Creating and distributing useful material to attract a business audience, in a way that eventually produces pipeline. That is the entire definition, and the definition was never the hard part.

Think of every published piece as a colleague who takes the meetings you will never attend. It answers the same questions you would answer on a call, well or badly, and you do not get to sit in and correct it. A team that publishes forty of those has hired forty colleagues without interviewing any of them.

That is the frame worth holding. Not &quot;how many posts this quarter&quot; but &quot;who is out there speaking for us, and are they any good&quot;.

Why so much of it turns to slop

Slop is content that is technically about the topic and useless on it. Listicles restating other listicles. Posts that define a term and then stop, as though the definition were the service. Thought leadership containing neither thought nor leadership.

It shows up for three reasons, and each one is a rational response to a bad incentive:

Volume targets. Teams get measured on output, so output is what they optimise. The tell is a content calendar that is full in October and says nothing anyone actually asked.

Competitor mirroring. You audit the top ten results and write the eleventh. Every page in that set now says the same thing, so the set has no winner, only a length contest.

Undirected AI. Models write fluently about topics they know nothing about, which is the trap. Fluent reads finished, so nobody notices the argument was never made.

Buyers have already clocked it. Demand Gen Report&apos;s 2024 benchmark survey found 51% of buyers said content was too generic and irrelevant to their needs, against 38% the year before.

Thirteen points in a single year. Whatever is happening to the median piece of B2B content, it is happening quickly.

If you want the mechanics, why AI writing falls flat and the content decay problem both go deeper than this post has room for.

Why the B2C playbook breaks here

B2C content can be entertaining and impulse-driven. A good social post sells sneakers. B2B has a different shape, and the differences compound:

The cycle runs months, sometimes years. Anything you publish has to still be true and still be findable when the buyer resurfaces in month seven.

The decision maker is a committee of three to ten people, most of whom you will never meet. Your content gets forwarded into that room and has to argue on its own, without you to handle the objection.

The driver is ROI and risk reduction. Delight is welcome. Delight has never signed a procurement form.

So the job is to educate and de-risk, which is slower and less gratifying than entertaining.

Borrow the B2C tactics wholesale and you produce content optimised for a scroll-stop, read by someone assembling a business case. That mismatch generates a fair amount of slop on its own, before AI is anywhere near it.

The four decisions behind a strategy that produces pipeline

Strip the frameworks away and a B2B content strategy is four decisions. Who you are writing for, what stage they are at, which formats you can sustain, and what you actually think.

Start with the audience, not the calendar

Most content calendars start with topics. The better ones start with a person and the specific thing they are stuck on at 11 p.m.

This is not a nice sentiment. CMI&apos;s 2025 research found top performers attribute their success mostly to understanding their audience (82%), ahead of every other factor they were offered.

Startups hold the advantage here and mostly waste it. You are closer to your customers than any incumbent will ever be, and you can out-specific a company fifty times your size. A generic playbook is the one thing your larger competitor can also buy.

Give every asset exactly one job

A post that introduces a concept is not trying to close a deal. A case study is. Map each asset to a stage and hold it to that stage:

Awareness. Answer the question a buyer types before they know vendors exist. It earns nothing directly, and you will be tempted to kill it three months early.

Consideration. Guides, comparisons, original research. This is where most teams are thinnest, because it is the tier that cannot be faked.

Decision. Case studies and proof points. Tedious to produce, and the only assets your sales team will reliably use.

One job per asset. A piece trying to do all three does none of them, and usually reads like a brochure.

Pick two formats and go deep

Lean teams cannot be everywhere, and the answer is not a thin layer of everything:

Blog and SEO attracts search traffic and compounds slowly. It also rewards patience you may not have.

Original research differentiates and earns citations, including from the answer engines. It is expensive once and cheap forever after.

Case studies prove results and de-risk the purchase, assuming you can get a customer to agree to one.

Newsletters keep you present between buying windows, and punish you the moment you have nothing to say.

Webinars educate and capture intent, at a production cost most early teams underestimate.

If you can only do one thing properly, make it original research or a single flagship guide. That is the opposite of checkbox marketing, and it is the only version of this that compounds.

Have something to say

Thought leadership earned its bad name honestly. When it is good, though, it moves people who were not otherwise moving.

In the 2024 Edelman-LinkedIn B2B Thought Leadership Impact Report, 75% of decision-makers and C-suite executives said a specific piece of thought leadership led them to research a product or service they were not previously considering. In the same research, only 15% described the quality of the thought leadership they read as very good.

Those two numbers sit next to each other for a reason. Demand is high and supply is bad, which is the most favourable market condition a small team is ever handed.

Where AI helps, and where it flattens

AI is not the problem. Undirected AI is the problem, and the distinction is operational rather than philosophical.

It earns its place in the parts of the job that are retrieval and shape:

Research. Summarising source material, surfacing patterns, drafting interview questions. It will also summarise a source as saying the opposite of what it says, with total confidence, so check the numbers yourself.

Structure. Outlining, reorganising, stress-testing whether an argument actually holds together.

Repurposing. Turning one long piece into the social posts, emails and summaries you were never going to write by hand.

It flattens the moment you hand over the argument. A model has no point of view, no customer calls, and nothing at stake in being wrong. Feed it thin inputs and it hands them back fluent, which is worse than thin. Thin is visible. Fluent and wrong takes a careful reader to catch.

(If your prompt was &quot;write a blog post about B2B content marketing&quot;, you already know what came back. Now, back to it.)

The guardrail is unglamorous. Ground the thing in real data and real conversations. Customer interviews, proprietary numbers, an actual opinion held by an actual person. For teams that want the execution without the flattening, that is what done-for-you content is for.

Measuring without fooling yourself

Page views and impressions feel like progress. They are also the metrics that survive longest in decks precisely because nobody can disprove them.

Be honest about the difficulty first. CMI&apos;s 2025 research found 56% of B2B marketers struggle with attributing ROI to content efforts. In the same study, 74% said content helped generate demand or leads. The impact is real and the tracking is messy. Both, at once.

Worth noting where the pain actually sits: the most-cited challenge is not producing content. It is creating content that prompts a desired action, named by 55% of marketers, more than any other option.

So measure closer to the deal:

Sourced and influenced pipeline. Did the content appear anywhere in the deal path? Imperfect, and still the number that matters most.

Share of voice in search and AI answers. Increasingly the first impression you get to make, and one you do not control.

Engagement from target accounts, not general traffic. Ten of the right readers beats ten thousand of the wrong ones, and only one of those numbers looks good on a slide.

If the vanity metrics have worn out their welcome, rethinking pipeline metrics is the longer argument. And to see how often you turn up in AI-generated answers, the organic discovery leaderboard is a reasonable place to start.

A lean 90 days

You do not need a twelve-month roadmap. You need enough momentum to learn something:

Weeks 1 to 2. Audience and point of view. Lock the ICP. Interview three to five customers or prospects. Name two or three topics where you can credibly disagree with the consensus.

Weeks 3 to 6. One flagship asset. A piece of original research, a definitive guide, or the comparison your buyers are already building badly in a spreadsheet. Support it with two or three posts that link back.

Weeks 7 to 10. Distribute deliberately. Do not wait for organic traffic to arrive. Put the asset in front of prospects and communities directly, which is the inbound-led outbound motion.

Weeks 11 to 13. Cut what did not work. Which pieces pulled the right readers? Which started conversations? Double down, and be willing to kill a format you liked.

As for when to bring in help: when the strategy is validated and the constraint is execution quality or pace, rather than knowing what to say. Hire before that and you are paying someone to guess at your point of view.

For scale, 29% of B2B marketers describe their content marketing strategy as extremely or very effective. That is the bar you are clearing, and it is on the floor.

Signs you are about to ship slop

The useful test is not whether a piece is finished. It is whether anyone would miss it. Some telltale signs, before you hit publish:

You cannot name the person who will read it beyond a job title.

The outline could have been produced by someone who has never spoken to your customers, because it was.

Every claim traces back to another blog post that traced it back to another blog post.

You would not send it to a live prospect unprompted.

Nobody on the team wants their name on it.

That last one is the whole test. Ship what you would sign.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/4cb429536966885e7bd70745384dfb9c5d8cf3c2-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Resources</category><category>Marketing</category><category>Strategy</category><category>Explainers</category></item><item><title>Fighting the Copilot Tax</title><link>https://andorlabs.ca/blog/the-copilot-tax/</link><guid isPermaLink="true">https://andorlabs.ca/blog/the-copilot-tax/</guid><description>There&apos;s a meme going around that compares AI copilots to coin slot machines. After building 5 products in 6 weeks... I&apos;m starting to see the merit of that…</description><pubDate>Tue, 03 Mar 2026 00:00:00 GMT</pubDate><content:encoded>In my last post, I talked about how the ability to build software is being commoditized to zero. This post is the receipts.

Over the past six weeks, I built a browser game, a Chrome extension, a consulting website, an iOS app, and two Claude Code plugins. Every commit was co-authored with Claude. Some were authored entirely by Claude, no human in the loop at all.

Yes, it made me build things faster. Unfortunately in many cases, it also helped me build the wrong thing faster... something I&apos;m calling &quot;the copilot tax&quot;.

Here are the three most expensive mistakes I made and what I learnt in the process.

Mistake 1: Building before planning

Void Patrol is a browser-based shoot-em-up I built with Phaser 3. I went from v0.1 to v0.70.1 in two weeks. 73 version bumps.

That sounds impressive until you look at what I deleted: a full progression system with upgradeable weapons, branching dialogue with 6 player choices, a debug panel, a Star Wars-style text crawl. All coded, tested, and ripped out.

The game got better every time I removed something. But those deleted features introduced bugs (physics freezes, timer cleanup issues) that took real time to fix.

Same pattern on my consulting site, andorlabs.ca. I went through three content management systems in 10 days. TinaCMS first (pulled after 3 days). Then Sanity (two days fighting build failures before stripping it). The final setup? Local markdown files. The simplest approach. The one I should&apos;ve started with.

The game got better every time I removed something.

AI made adding each CMS trivial. A few minutes of work, every time. But the constraint was never building speed. It was knowing when to stop adding things. For a single-author consulting site, three CMS migrations in 10 days is a sign you&apos;re solving the wrong problem.

The counter-example is Slop or Not, a Chrome extension that detects AI-generated content in LinkedIn feeds. 1,540 lines of vanilla JavaScript. No frameworks, no build step, no API calls. It shipped in a single commit because the scope was clear before I wrote a line of code. Zero copilot tax.

Mistake 2: Compiled ≠ done

Tasky is an ADHD-friendly iOS task manager I built with SwiftUI. Claude turned my spec into a working app in one sitting. It compiled. It ran. And the interface looked like three different apps stitched together: mismatched colors, inconsistent spacing, buttons that didn&apos;t share the same design language.

Same issue with Void Patrol&apos;s pixel art. Every sprite was AI-generated through PixelLab, which sounds simple until you realize telling the AI &quot;top-down view&quot; doesn&apos;t guarantee a top-down sprite. I ended up writing a 415-line production guide just to document which parameter combinations produce usable, consistent results.

The fix in both cases was the same: define the system before generating the output. For Tasky, that meant building a design token system (color palette, spacing scale, typography) and migrating every screen to use it. For Void Patrol, it meant establishing a &quot;style anchor&quot; sprite and generating everything else to match it. And in both cases, I added human checkpoints where I&apos;d visually approve the result before moving on. Because the compiler can&apos;t tell you your app looks generic.

Mistake 3: Scoring opinions vs. knowledge

SaaS Grader is a Claude Code plugin that grades SaaS websites against published academic research. The first version had 6 commands and a subjective 100-point scoring system. &quot;Rate your headline 1-10.&quot; That kind of thing. It was... fine. Not useful. &quot;Your headline scores 6/10&quot; doesn&apos;t mean anything to a founder trying to fix their positioning.

The rewrite stripped it to 2 commands with explicit pass/fail criteria, every check traceable to a published source: Dunford, Moore, MECLABS, or peer-reviewed studies from Stanford, MIT, and Georgetown.

&quot;Your homepage doesn&apos;t name what the customer would use instead. Here&apos;s why that matters. Here&apos;s the research. Here&apos;s how to fix it.&quot; That&apos;s actionable.

The surprising part: the entire plugin is text files. The &quot;product&quot; is structured knowledge and a set of instructions for Claude. Citations aren&apos;t just credibility. They&apos;re the product. Having fewer commands made the tool dramatically better.

What I&apos;d do differently

Use plan mode. Claude Code has a mode that forces the AI to outline its approach before writing anything. I didn&apos;t use it enough early on. When I did, the AI stopped generating code I&apos;d delete an hour later. Planning isn&apos;t slower. Skipping planning is slower.

Build a design system first. Tasky&apos;s UI looked like three apps stitched together because I let Claude generate each screen independently. The fix was a component-based design system: a shared set of colors, spacing, and button styles that every screen pulls from. One source of truth for how the app looks. Every new screen automatically matches.

Review early and often. Code that compiles isn&apos;t code that works. I started adding checkpoints where I&apos;d visually inspect the output before moving on. For Void Patrol, that meant approving every sprite before it went into the game. For Tasky, it meant looking at every screen on a real device. The AI can&apos;t tell you something looks off. You can.

Cut features in the doc, not the codebase. I deleted a full progression system, branching dialogue, and a Star Wars-style text crawl from Void Patrol, all after they were built. Every one of those features introduced bugs while it existed. It&apos;s cheaper to cross something off a planning doc than to rip it out of working code. Be ruthless early.

Find plugins for the specialist work. SaaS Grader went from mediocre to useful when I stopped trying to make Claude do everything and found the right plugins for specific jobs. PixelLab for consistent sprites. Structured research prompts for marketing analysis. The AI is a generalist. For anything that needs domain expertise, find a tool that&apos;s purpose-built for it.

The real bottleneck

The bottleneck was never writing code. Claude Code handled that part well.

The bottleneck was exercising good judgment in what to build, what to cut, and when to stop. Three CMS migrations happened because each one was easy to start. Seventy-three game versions happened because each one was easy to ship. AI-generated design compiled but looked generic until I added human checkpoints.

The expensive part is asking for the right thing.

The copilot tax is what you pay when speed outpaces judgment. The tool will build whatever you ask for. The expensive part is asking for the right thing.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/5b60233e1c16eb1cb7450bc6c7f1e4ecfb143b63-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Tech stack</category><category>lab-notes</category></item><item><title>A doomsday prepper&apos;s guide to the post-software era</title><link>https://andorlabs.ca/blog/doomsday-prepping-for-the-post-software-era/</link><guid isPermaLink="true">https://andorlabs.ca/blog/doomsday-prepping-for-the-post-software-era/</guid><description>The ability to build software is being commoditized to zero. SaaS as we know it is in trouble, but the pain won&apos;t be evenly distributed. Here&apos;s what still…</description><pubDate>Fri, 27 Feb 2026 00:00:00 GMT</pubDate><content:encoded>These days, you can&apos;t scroll a page on any social platform without someone saying that, &quot;Claude Code just killed X&quot;, &quot;Clawdbot just killed Y&quot;, or some such thing.

Meanwhile, Dario Amodei, the CEO of Anthropic, can&apos;t stop grabbing a mic anywhere he goes only to say how the concentration of power in the AI industry and the fact that most software engineering jobs will be gone in the next 12-18 months are making his stomach churn.

Buddy... if it&apos;s making you that uncomfortable, just stop releasing new models.

&quot;Please make somebody stop us before it&apos;s too late...,&quot; appears to be the predominant sentiment that AI company execs are leaking right now through their media appearances and lengthy X posts. Is that to maintain plausible deniability when things really go sideways? Maybe.

Jokes aside, if you&apos;re experimenting with frontier AI models, you&apos;ve probably felt that underneath all the hand-wringing and click-baiting, there&apos;s a kernel of truth.

What is the &quot;post-software era&quot;?

Until recently, making software used to be a hard, time-consuming, and expensive prospect. In addition, there used to be a wide but stable scale of value x quality, depending on the skill, experience, and location of the engineering talent you needed to hire to build the product.

That equilibrium was obliterated when newer AI models started shipping with 1M token context windows and enough training data to reproduce code in any language across the stack. Most engineers that I know are using these tools and have a love/hate relationship with them. It&apos;s like watching a surgeon wield a scalpel they know can fold inward at them at any moment.

A bigger issue is what non-engineers are doing. Anyone who ever had any entrepreneurial aspirations (including me) is out there setting up terminal coding agents, IDEs, GitHub, issue trackers, developer accounts, and shipping working products off into the world.

Software ate too much and is now throwing up... software.

Marc Andreessen saying that &quot;software is eating the world&quot; was a moment. That was the era of software. And that era is now over. Software ate too much and is now throwing up... software. The post-software era means a time when the ability to develop functional software is commoditized to an extent that it completely loses its differentiation and market value.

How screwed is SaaS?

As someone who went from taking 2 weeks to write the C code for a CS50 assignment to building an iOS task management app using Swift, a working Chrome extension, and a browser-based game with 8K lines of code—my personal opinion is that SaaS is very screwed.

Take this post for example. In the pre-GenAI era, I would&apos;ve written it in WordPress. Now, I&apos;m writing this in a markdown editor on my desktop, which will push a commit to GitHub, auto-deploy on Cloudflare, and render on a custom-built site. Running this stack costs me $0 and is well beyond my, let&apos;s say—&quot;standard skillset.&quot;

Even if SaaS is screwed, the screwing will not be uniformly distributed.

Winners and losers

Winners:

Selling proprietary data that can&apos;t be &quot;generated&quot;

Craft-obsessed with a loyal following, e.g., Linear, 37signals, PostHog

Solving foundational AI problems, e.g., Cohere, Blackboard.io

Using AI to solve foundational problems, e.g., Simile AI, Evidenza

Enterprises operating on trust, scale, and reliability, e.g., Shopify, Stripe

Losers:

Anyone whose product is just a UI bolted on open-market LLM APIs

Any late lookalike in a category, e.g., a Replit or Lovable alternative

Any product whose only distinguishable moat is being software

If software isn&apos;t the edge, what is?

Novelty of ideas

This is the true Achilles&apos; heel for generative AI. It can execute great ideas with speed, but you&apos;ll have to supply the idea. This is implicit in how token prediction works. All you get is a regurgitation of ideas already in its training corpus. You can&apos;t get an original tune by remixing.

Speed-to-market

The entire premise of AI coding is unlocking 10x speed. If you&apos;re not running a multi-agent RLHF loop in a Docker container overnight... you&apos;re falling behind. Or at least this is what I&apos;m sensing based on what people keep posting on LinkedIn and X. There are a lot of ways to die in SaaS, and moving too slow with a great idea is just one.

Proximity to capital

AI has nothing on good ol&apos; money. Because SaaS is being downgraded to a lower expected-value bet, institutional capital will flow asymmetrically to the top of the food chain. Think unicorn ex-founders, YC startups, AI model trainers, etc. Startups are now announcing &gt;$100M seeds. Do you know how long they can just... survive?

Being opinionated

Having strong opinions shaped by your personal experience, quirks, and idiosyncrasies can inject differentiation in crowded categories. A lot of founders are pulling this off, but Adam Robinson of RB2B is the first that comes to mind. He&apos;s thrown every decorum rule in SaaS out the window and been rewarded for it.

Positioning savvy

Building and positioning software are wildly different disciplines. Just like you wouldn&apos;t want a positioning expert to write code for you, don&apos;t let whatever Dave felt like writing that one morning become the official messaging for your product. Great positioning is about making your offering undeniable. It&apos;s not a job for a committee.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/49a36e4c9b3a78184b9c4bd6f4dbb94fc4446f35-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>AI</category><category>SaaS</category><category>Strategy</category></item><item><title>Netflixification</title><link>https://andorlabs.ca/blog/netflixification/</link><guid isPermaLink="true">https://andorlabs.ca/blog/netflixification/</guid><description>In a 2023 Wired article, Cory Doctorow coined &apos;enshittification&apos; to describe the inevitable decay of platforms. Netflix is the cleanest case study.</description><pubDate>Tue, 09 Dec 2025 00:00:00 GMT</pubDate><content:encoded>In a 2023 Wired article, Cory Doctorow coined the term &apos;Enshittification&apos; to describe the inevitable decay of two-side online products and services, and it spread like wildfire in tech circles.

When I first heard about Netflix making a bid to acquire WBD, &apos;netflixification&apos; popped into my head—fully formed and ready to use.

It&apos;s a derivative term but they&apos;re not the same things.

The difference is that Netflix actually cares about its users. This is bound to get diluted with the ad-supported tier they now have, but like Amazon... customer centricity is embedded deep into their core identity.

And yet, it is my belief that Netflix went down the wrong path by creating its own production house and having it blend in with independent film production companies. Amazon did the same thing by launching its own house brands for every imaginable product category.

But why? Was there something wrong with the products that predated Amazon lookalikes? Or were the movies produced before Netflix not good enough?

Did the world really need more stuff, or was the cookie jar too lucrative for platform owners? I think the question answers itself.

I can&apos;t speak for all users but I&apos;ve personally never felt excited by the Netflix banner. I love the platform, but have a deep and abiding ambivalence about its media empire.

I think I know the reason why. When DreamWorks or Village Roadshow greenlight a production, they do it because the concept has legs as a standalone entity. Netflix churns out media to keep its users from getting bored. There’s no Darwinian survival pressure.

Those are vastly different goals and they create vastly different production philosophies and processes.

Amazon has its own reasons. No one&apos;s leaving Amazon if it didn&apos;t make tees, kitchen scissors, and USB C cables, but house brands don&apos;t need to pay Amazon for distribution, and so the margin saved is profit. Amazon products don&apos;t need to be the best, they just need to push volume.

Just like enshittification is the inevitable decay of two-sided online platforms caused by misaligned incentives, netflixification is the inevitable decay of aggregators caused by the distribution of self-owned products.

In an ideal world, Netflix wouldn&apos;t be allowed to gobble up other media entities to protect diversity in the creative industry.

Sure, Netflix has produced great movies and television. That&apos;s not the point. A thousand monkeys hacking away at typewriters will eventually reproduce a Shakespeare—it doesn&apos;t make the monkey a playwright.

Great products are built from a desire to build great products. If the product itself becomes a byproduct of some other, secondary goal, it logically follows that you’re likely to end up with a middling product.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/94191e9c5d85f8d5df8238520a30452e66544c91-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Essays</category></item><item><title>How to get started with Claude Code</title><link>https://andorlabs.ca/blog/how-to-get-started-with-claude-code/</link><guid isPermaLink="true">https://andorlabs.ca/blog/how-to-get-started-with-claude-code/</guid><description>How I learned to stop worrying and love my virtual CTO.</description><pubDate>Fri, 07 Nov 2025 00:00:00 GMT</pubDate><content:encoded>At some point, most non-technical people will hit a problem that they can’t fix on their own and need to call in a developer for, like:

Restoring a crashed site

Fixing a broken contact form

Applying a CSS/JS fix

Or… maybe that’s too elementary for you. Maybe—like me—you’ve wrangled enough code to figure out those things and now you want to do more.

Design a landing page without a WYSIWYG builder? Build an app from scratch? Modifying the code that’s running a site? Claude Code is here to help. As a general-purpose coding assistant, Claude Code runs in the terminal (a term I’ll get to later) to help you build whatever you want, wherever you want it.

In this post, I’ll share setup instructions for Claude Code, my initial impressions, pros and cons, and leave you with some ideas on how to put it to use.

Setting up Claude Code

I mentioned that Claude Code can run in your “terminal”, which is the command line interface connected to your OS. As I’ll cover later, doing a native installation and running in the terminal gives it several advantages vs. a web app or specific IDE.

I found the setup to be fairly straightforward—simply a matter of copy-pasting the following commands from the Native Install section in their quick start guide.

macOS, Linux, WSL:

`curl -fsSL https://claude.ai/install.sh | bash`


Windows:

`curl -fsSL https://claude.ai/install.cmd -o install.cmd &amp;&amp; install.cmd &amp;&amp; del install.cmd`


The rest of the installation is guided and includes on-screen instructions. Don’t worry about breaking anything, the worst thing that can happen is a failed installation.

I did run into a snag related to the file structure on my Mac but Claude was smart enough to provide me with the fix as we went through the process.

You’ll either need a Claude Pro plan or an API subscription to get started, I chose the Pro plan because it also gives me access to all of Claude’s integrations and features.

My initial impressions

Interacting with Claude Code in the terminal is fun in a way that the terminal usually isn’t. I like that it injects a little personality into that space with its fun UI, quick shortcuts (/) for help, and playful task progress labels once you get going with a project.

The biggest unlock is that you can just chat with Claude in the terminal. In some ways, it’s the anti-thesis of what “coding” is supposed to look like. You can just show up there with your natural language skills and Claude Code will be your translator.

You can just show up there with your natural language skills and Claude Code will be your translator.

Post the installation, it has access to your local file system, so it can immediately start advising you and developing on any locally-hosted codebase. For my own use case, I had it develop an Xcode project for an iOS app, which has been fun so far.

For complex and distributed projects, you can connect it with your GitHub or GitLab account. Its MCP connector will integrate with Asana, ClickUp, Jira, etc., and then it can read tickets, plan work, commit code, and even close the ticket once the job is done.

Pros and cons

Pros

Language agnostic: Doesn’t matter if your project is written in C, Python, Ruby on Rails, PHP, Swift, or any other language. Claude Code knows them all. If you’re not sure, it will advise you on the pros and cons of development choices.

Platform agnostic: Being in the terminal means that Claude Code will work across your preferred local- or cloud-based IDE. You can use it to develop HTML templates, landing pages, websites, SaaS, mobile apps, etc.

You own the codebase: With other subscription-based vibe-coding tools, you typically need to keep paying in order to keep your project private. Claude Code is more like a hired hand, you keep the assets even if you decide to cancel.

Beginner-friendly: I really like the conversational aspect of Claude applied to development. Other vibe-coding tools, which are geared towards taking your input and head directly to code generation, seem monotone in comparison.

Cons

Code bloat: Claude Code isn’t continuously monitoring your codebase. As a result, after a few cycles, you’re end up with dead code, unused files, and clunky implementation. Asking it to review and refactor the code works well.

Design inconsistency: I had a really hard time getting Claude Code to stick to a standard system of design, which includes things like a colour palette, UI components, animations, spacing, etc. Its tendency is to treat every design request as a “fresh one” and fall back on its training data to generate the spec.

Occasional frustration: Sometimes, it’s hard to get it to create what you’re visualizing. This is a fundamental limitation of using language as a translation layer. You’ll never reach the precise control enjoyed by a human developer.

Hitting usage limits: It’s quite easy to hit the weekly usage limits on the Pro plan. You can mitigate that to some extent with better planning, explicit guardrails for development, and improving your prompts, but Claude Code does make it easy to “go with the flow”, and that’s when you end up being wasteful.

Now, over to you

I really think Claude Code is something that must be experienced. I can tell you all about how it works, but at some point… it’s better to just try the thing.

I’m the type of person who’s more energized about learning something when I know the result that I am working toward. To spark your imagination, here’s a list of things you could potentially try building with Claude Code:

A personal portfolio site to showcase your skills

A browser extension for a use case that interests you

A mobile app that you want… but can’t find

A custom, quiz-style lead generation tool

A SaaS MVP that targets an underserved market

So, what do you want to build? Send me a reply and tell me your idea. I’d be more than happy to share my feedback on whether Claude Code could help you with it.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/67e330692484a0ae240c81ec986f2bfd52b215cc-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Tech stack</category></item><item><title>How to think about effort</title><link>https://andorlabs.ca/blog/how-to-think-about-effort/</link><guid isPermaLink="true">https://andorlabs.ca/blog/how-to-think-about-effort/</guid><description>I recently became acquainted with the idea of “checkbox marketing” via following Brendan Hufford on LinkedIn. It looks something like: “This week, I’ll write 2…</description><pubDate>Fri, 07 Nov 2025 00:00:00 GMT</pubDate><content:encoded>I recently became acquainted with the idea of “checkbox marketing” via following Brendan Hufford on LinkedIn.

It looks something like: “This week, I’ll write 2 blog posts, 3 LinkedIn updates, send the newsletter, and record a podcast episode…”.

Check, check, check, and check.

As a practitioner, I can attest that this is indeed how marketing worked in many places before measurement became cheap, easy, and ubiquitous.

I’ve done my fair share of checkbox marketing, so what follows is not armchair criticism.

The ability to measure things is a double-edged sword. You get instant feedback on the efforts that are driving outcomes and the ones that are not.

So the question then becomes: Why would you invest efforts into something that’s not yielding the outcomes that the business needs?

Applying such Darwinian pressure to work—where anything that does not move the needle is starved of resources—instinctively feels reductive and coarse to many marketers.

For better or worse, I’ve never been in that camp. I detest the idea of being beholden to a business decision or project due to sunk cost fallacy, IKEA effect, confirmation bias, or any of the hundred other cognitive traps that unknowingly cloud our judgement.

I think marketing teams should be on a perpetual search-and-destroy mission to weed out work that either has no expected value or fails short of delivering it. And do it before anyone else gets around to asking.

The reason is simple: Effort is not fungible. At some point, you’ll hit the peak and then exhaust it. The goal is to have converted that effort into value before time runs out. Doing that requires endless pruning and pivoting.

If something doesn’t hurt the business but also doesn’t move it along; it’s a net negative after you factor in the cost of time and effort spent.

The true cost of standing still is that you inch backwards while others get ahead. It’s not just organizational drift, it’s wasted personal potential.

In that light, complete inaction, such as when you sit in a chair and do nothing, is more intellectually honest than filling the hours with work that has no clear payoffs for anybody.

This idea of performative vs. meaningful work bears resemblance to Sartre’s example of the waiter who’s just a little too good at his job (from Being and Nothingness). The spring in his step, the bottomless enthusiasm, the flourish with which he recites the Chef’s special—it’s all pitch perfect. So what’s the problem? Sartre argues that by fully internalizing the socially prescribed role of a waiter, the person behind the mask denies himself the freedom of being.

The same is true of the checkbox marketer. By hiding behind the safety of prescribed activities, he denies himself the freedom to ask the hard questions about value and meaning. (You can extend this analogy to any profession.)

It goes without saying, just because I say all this doesn’t mean that I’ve cracked the code. In a real-world setting, it is impossible to fully optimize effort because the real world is littered with chaos, constraints, edge cases, and exceptions.

Still, the value is in having the mental model and exercising it whenever you can vs. never consciously developing the muscle at all.

Doing that can be as simple as asking, “…but why are we doing this?” And knowing that asking the question is not symptomatic of impertinence, cynicism, or bad faith—but a service you do to yourself and others.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/4625a3cc3a319c691d259249719aacc9d9559db6-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Essays</category></item><item><title>What is GTM Engineering?</title><link>https://andorlabs.ca/blog/what-is-gtm-engineering/</link><guid isPermaLink="true">https://andorlabs.ca/blog/what-is-gtm-engineering/</guid><description>Gather ‘round, folks! I got some ☕️ Once upon a time, in a startup far, far away, there was a growth hacker. What did she do? She did whatever it took for the…</description><pubDate>Fri, 07 Nov 2025 00:00:00 GMT</pubDate><content:encoded>Gather ‘round, folks! I got some ☕️

Once upon a time, in a startup far, far away, there was a growth hacker. What did she do? She did whatever it took for the company to grow, dammit.

Oh, you want more details? Fine—she created hypotheses and ran experiments.

Oooh. Such scientific. Much wow.

Then she went the way of the Dodo. We don’t know why. These things happen.

Some time passed ⏳

Enter RevOps, the elder sibling—methodical, hard-nosed, in possession of a long list of Coursera certificates and the ability to talk to finance using only abbreviations like ROI, EBITDA, and MoM. (The last one is short for “Mother”, I think.)

For eons, RevOps climbed the pecking order unimpeded—companies hired SVPs of RevOps, hosted yacht parties, upscale private dinners, and all manner of extravagant excess. But now, a new family member threatens to upend that order.

It’s the middle child that took a year off after college to travel the world, then returned a decade later—transformed into an autodidactic polymath. Someone who can write poetry like Rilke but also calculate the area of bounded regions on a paper napkin, blindfolded and without a pen.

Drumrolls please 🥁

It’s the GTM Engineer.

I am not someone who gives many fs about titles. If three fs are required in a setting, I am liable to show up with one (or less). So I find the obsession that revenue teams have with the constant reinvention of job titles a little weird.

But, and before this post completely gets away from me… I do recognize the value of what a GTM Engineer signifies.

I have fought vendors, walked off negotiation tables, and broken contractual payment obligations in cases where I felt that my group was being treated as a line item in someone else’s balance sheet.

Working at early-stage startups (as I have) makes you internalize that growth comes from revenue acceleration and reducing wasteful spend. To maximize your chances of survival, you treat those variables as a continuum and not a binary lever.

It almost becomes personal after a while.

I have fought vendors, walked off negotiation tables, and broken contractual payment obligations in cases where I felt that my group was being treated as a line item in someone else’s balance sheet. No regrets whatsoever.

From that lens, the value creation that GTM Engineering promises bodes well with me.

So, let’s talk about that and more.

Who started it?

Clay created the first GTM Engineering team.

If you haven’t heard about Clay, don’t worry, you will—here and elsewhere. Think of it like Excel meets Zapier meets an API marketplace. It is good.

Okay, but why?

First, I think it was an extremely smart employer branding move on Clay’s part, even if unintentional. They wanted a certain type of person to run their GTM Engine… and look—now every Cool, Inc. in the world wants that person.

Second, if you understand how Clay works, a GTM Engineer is the human embodiment of their product. Clay is the Swiss Army knife of SaaS tools. It then makes sense that the people they hired to commercialize the product are, well, the Swiss Army knife of the commercial workforce.

Third, and by far the reason with the most far-reaching and persistent effects, generative AI and the commoditization of enrichment APIs are accelerating the collapse of traditional job roles.

What do GTM Engineers do?

The lazy answer, like growth hackers, is everything, or… whatever it takes.

I’ve personally seen them:

Creating content like a copywriter

Creating collateral like a designer

Building an audience like a marketer

Prospecting like a BDR

Running demos like an AE

Automating processes like RevOps

Integrating/debugging data like a dev

Generally… being a #boss

A GTM Engineer is someone who identifies a problem, weighs the impact of solving it, and then solves it using the most efficient and elegant way, across the entire lifecycle of the revenue process… from sourcing-to-close-to-retention.

Most people are content living inside the first box that happens to fit their size.

Think about what type of person would want to do all that, much less possess the skills? By simple elimination, it will be someone driven, deeply curious, and forward-thinking. It won’t be a junior or mid-career professional working a beat. It will be someone who commands a premium and expects full autonomy to be a non-negotiable.

Most people are content living inside the first box that happens to fit their size. I only write, I only market, I only sell, I only code, I only manage, I only analyze, I only plan, I only lead, ad infinitum.

Time will reveal that those boxes are not success or safety, they are a type of self-created prison.

Should you hire a GTM Engineer?

Yes, without flinching or thinking twice.

A startup should hire them to lay down a strong foundation and for the sheer value. A mid-sized company should hire them to act as a part role model, part agent-of-change to break inertia.

When looking for one, prioritize the trifecta of driven, curious, and forward-thinking over hard skills.

The “Engineering” in GTM Engineer is used loosely, in fact, some are not engineers in the strictest sense. For example, they won’t necessarily need to know how to write Python if they can prompt ChatGPT to write, test, and debug a script to achieve the intended result.

Every business is going to need unfettered, multidimensional problem-solvers like that. The smarter ones will just act on it sooner.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/266270a361231124476ce3a618d1ea358382088d-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Explainers</category></item><item><title>What is inbound-led outbound?</title><link>https://andorlabs.ca/blog/what-is-inbound-led-outbound/</link><guid isPermaLink="true">https://andorlabs.ca/blog/what-is-inbound-led-outbound/</guid><description>If I was a betting man, I would say that no one uttered the words “inbound-led outbound” or “warm inbound” prior to 2024. And now, we have hour-long...</description><pubDate>Fri, 07 Nov 2025 00:00:00 GMT</pubDate><content:encoded>If I was a betting man, I would say that no one uttered the words “inbound-led outbound” or “warm inbound” prior to 2024.

And now, we have hour-long roundtables with multiple panelists dissecting the concept.

It’s one of those things that people come up with to better position their product in the market. “Outbound is dead!”, they’ll say, wanting to trigger the fear-of-missing-out. “What you need is inbound-led outbound.”

So it is a gimmick? I wouldn’t go that far. It is clever positioning, to be sure, but the concept is not without its merit.

For the longest time, at most companies, inbound and outbound demand generation were neatly separated between marketing and sales—both meeting only at handoffs.

Inbound is all about positioning yourself as a magnet for potential buyers by creating engaging content, SEO, SEM, social media, earned media, webinars, etc. What you want is a lead in exchange for all that value.

Outbound is all about the push. There’s a list of companies that the seller (assigned or in territory) engages in cold outreach using multiple channels, until they get a yes or no. That’s reductive—sellers can be far more intelligent on the details, but let’s say it’s that.

In terms of timeline, outbound preceded inbound. Inbound was hailed as the remedy for all the frustration and hostility that buyers had developed towards pushy sales practices.

Inbound worked great for the companies that did it right for a long time. For example, Hubspot’s valuation is built upon the impressive inbound engine they built as an early adopter of the method.

But inbound has a lot of chinks in its armour, some that developed over time and others that merely became apparent with its passing.

To name a few:

Inbound is an infinite game of building and waiting. You can get a pretty good idea of who you’re going after but rarely drill-down to the company or individual.

The onus is on the buyer to signal their intent by sharing their email, phone, function, company, or other data. Before that event, inbound is completely dark.

Even post event, inbound may fail to capitalize on the opportunity. The lead may go into an endless nurture sequence, or at handoff—rejected by sales. There are many traps, delays and bad timing is one.

This is the backstory that creates the perfect landing strip for inbound-led outbound. It’s fairly simple—you pinpoint the strengths of both methodologies and marry them.

Here are some ways in which that might play out in terms of a workflow or process:

Someone visits your website, their identity is revealed by a person-level ID tech, and then an email (or InMail) shoots from the seller that owns that account: “Hey John! Saw you were on our site...”

Cross-reference companies visiting your site against 3P intent signals on those researching your category. The shortlist from that overlap get invited by the assigned sellers to a hyper-personalized webinar tailored for that cohort.

An old inbound lead visited your pricing or demo page but then bounced without taking any action. This event triggers a call from the seller. “Hey John, remember you downloaded our 2024 report? Well, my team told me that you were looking at our pricing and I thought I’d check in…”

There are a fair bit of permutations and combinations that you can patch together to come up with these plays.

Executed thoughtfully and with attention to detail, inbound-led outbound can be a great way for marketing to have a more immediate and tangible impact on sales efficiency.

It is also an excellent example of technology enabling business because some of the intent data, person-level ID tech, and automation systems required to makes these plays work simply did not exist when outbound and inbound first became mainstream.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/4f3d281c9131d25990aef6ec7771ceef88e18796-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Explainers</category></item><item><title>What is vibe coding?</title><link>https://andorlabs.ca/blog/what-is-vibe-coding/</link><guid isPermaLink="true">https://andorlabs.ca/blog/what-is-vibe-coding/</guid><description>I’m deviating from the usual programming to bring you a hot topic of sorts. But first a little background. For a non-engineer, I have a fair bit of history...</description><pubDate>Fri, 07 Nov 2025 00:00:00 GMT</pubDate><content:encoded>I’m deviating from the usual programming to bring you a hot topic of sorts.

But first a little background. For a non-engineer, I have a fair bit of history trying, failing, and trying again to gain a basic grasp of programming.

It started with a FoxPro class in early grade school. I only recall that it had nothing to do with foxes. They tried again in high school, but my friends and I had were too busy cross-connecting keyboard and mouse cables as a prank to stay on the topic.

I then tried doing a Bachelors in Computer Applications. I couldn’t clear the C++ exam, but to my surprise, aced the one on conicoids, conic sections, and the area of bounded regions. My most recent attempt at learning to code is being enrolled in Harvard’s CS50 for three years, never getting beyond the Mario recreation exercise.

I’m sort of over it. Loops, conditions, operators, variables, data types, arrays, algorithms, compile, run, whatever… get it, don’t care. Coding is about muscle memory, which requires attention to train, which I have a short supply of due to how my brain works.

The power of the vibe

A few weeks ago, I landed on Lovable.dev and discovered “vibe coding”—the act of building applications with zero underlying knowledge of the code that powers it.

Here’s where the term comes from:

Andrej is no hobbyist. He’s got a PhD in CS from Stanford, led engineering at Tesla and OpenAI, and innovated in the AI/ML/computer vision space. He bucks the trend of purists despising no-code tools and instead embraces them in his workflows.

In my own experiments with vibe coding, I got farther than anyone with my skill set should be able to. Within half an hour, I had spun up:

A secure, random password generator, including a visual indicator for strength

A webpage that ranked big tech (FANGMA+) based on their personal data practices, with a score assigned to each, and an explanation of the score

A lead gen tool that asks for basic information about your company and provides a risk assessment of how likely you are to be a target of cyber attacks

No matter what I threw at it: It just worked. The experience reminded me of the Arthur C. Clarke quote: “Any sufficiently advanced technology is indistinguishable from magic.”

Do I think these tools will replace the creativity and problem-solving capacity of a human engineer? No. At least not for a while. Just like you’re not going to willingly read a novel written by ChatGPT anytime soon.

To vibe code or not

The latticework of value creation is shifting in ways that few of us imagined. A failure of imagination is common and therefore easy to forgive.

The choice now is whether or not you see these tools for what they are (i.e., efficiency multipliers) and use them to get ahead, or—allow purists and tradition to bog you down.

It has never been easier for non-technical people to bring their ideas to life without spending four years on a CS degree or hiring someone who did. I see that as a net positive for human creativity.

And what of business? Markets don’t care about ideologies and feelings. I think companies that take a tepid or dogmatic view of human vs. AI-assisted building will be slow to innovate and less cost-efficient, losing their edge to others over time.

These are things you run towards, not against.

That’s it for vibe coding, folks. ✌️</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/de3301b70b4710002d691f08b9328f68eafeca15-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Explainers</category></item><item><title>Writing is the worst use of LLMs</title><link>https://andorlabs.ca/blog/writing-is-the-worst-use-of-llms/</link><guid isPermaLink="true">https://andorlabs.ca/blog/writing-is-the-worst-use-of-llms/</guid><description>I’ve been a professional writer for 15+ years. My definition of “professional” is anyone who ever received a check in exchange for some words that they wrote…</description><pubDate>Fri, 07 Nov 2025 00:00:00 GMT</pubDate><content:encoded>I’ve been a professional writer for 15+ years.

My definition of “professional” is anyone who ever received a check in exchange for some words that they wrote. It’s not the highest bar but it’s something.

Everyone writes emails. Not everyone is a professional writer.

I tend to be an early adopter of technology. So, I got my hands on ChatGPT the first time that I heard about it. Over time, I’ve tested the whole range of LLMs, including Claude, DeepSeek, Notebook, Lovable, those embedded in SaaS products, etc.

I have never had a particularly anthropocentrist worldview, and therefore, what I have to say is not a result of anxiety about self-preservation or thinly-veiled defensiveness.

There’s no agenda behind my words. What you’re hearing is what I actually think.

I’ll break down my thoughts for this piece in three parts:

Generating writing does feel like magic

The first time I tried ChatGPT, I was blown away by it.

Filling up pages based on a few words of input? With flawless grammar and punctuation? That is leagues ahead of most human writing.

It’s hard not to consider the possibilities.

Why would anybody do the arduous work of putting one word after another? It doesn’t make any logical or economic sense.

In some shape or form, we need language in both our personal life and in business to get anything done. Want to build an A-team? You better be good at crafting a mission that people will buy into. Selling a product? You can’t do it without clear, differentiated copy.

Even the back of your shampoo bottle needs words that someone wrote in a doc first.

Now, imagine, all of that work… just done for you. Like magic. Why wouldn’t we want that world? Well, this utopia doesn’t work because, as it turns out, the output generated by LLMs fails the primary function of writing.

The real function of writing is holding attention

Writing serves many functions: Educating, entertaining, evangelizing, selling, etc.

However, to do any of that, writing first needs to be able to cut through the noise of all the other writing that exists and hold the reader’s attention.

In that sense, great writing is pretty much the polar opposite of fetching the next most probable word based on a statistical analysis of training data, i.e., what LLMs do. That’s a recipe for performant but ultimately boring writing.

Average writing fills whitespace, great writing breaks patterns.

You’ve likely sensed this firsthand: Coming across a piece of writing that is outwardly polished but no more interesting than a spreadsheet to consume.

This is going to become a genuine problem for any organization that was too quick to disband its brand/creative teams. Once the sterile language starts seeping into products and services, they too will acquire the same dullness of character.

Speed and quality don’t exist in the same space

Tying it all together, I think we’re heading towards a place where counterintuitively: A renewed premium will be placed on human writing.

LLMs don’t have a monopoly over churning out dull, lifeless copy. Substandard writing has always existed. The ability to generate text at 100x the speed has no correlation to its latent potential in the real world.

This disillusionment won’t be universal of course. LLMs will find their spot in the marketplace of creative services. However, founders, builders, and leaders who obsess over craft, quality, and genuine human connection in business will not be buying it for long.

The truth is en route: LLMs produce mediocre work at frightening speeds.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/6eb5d88f67500bc5594dabfc77e7124b7a2e1433-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Marketing</category></item><item><title>Death of the MQL</title><link>https://andorlabs.ca/blog/death-of-the-mql/</link><guid isPermaLink="true">https://andorlabs.ca/blog/death-of-the-mql/</guid><description>Before you bring out the pitchforks, I didn’t dream this up. Just Google “MQL is dead” and you’ll find page after page after page of experts saying the same...</description><pubDate>Thu, 06 Nov 2025 00:00:00 GMT</pubDate><content:encoded>Before you bring out the pitchforks, I didn’t dream this up. Just Google “MQL is dead” and you’ll find page after page after page of experts saying the same thing.

For the uninitiated, MQL means “Marketing Qualified Lead”. In marketing-land, the term is ubiquitous, pretty much like the air we breathe.

So, what happened? Why the coup d&apos;état against an old and established framework?

To understand that, let’s quickly revisit what MQLs mean.

Defining an MQL

The idea behind MQLs is that marketing, through all the initiatives it undertakes, such as organic search, paid media, earned media, and online and offline events—generates leads. Some of those leads, based on a commonly shared understanding of suitable attributes, become MQLs, which are then handed off to the sales team.

Depending on the quality and relevance of the lead, the sales team may then convert the MQL into SQL (Sales Qualified Lead), and eventually the SQL into a deal or opportunity. As with most things, the success of this framework depends largely on how closely marketing and sales teams are (or are not) aligned.

Conversion ratio as an indicator

If you have a really low MQL-to-SQL conversion ratio, it means the alignment is poor and marketing is unfortunately spending a large chunk of its time and resources on channels that don’t materialize into new revenue for the business.

To be honest, that’s a bit of an oversimplification, there are factors that can lead to a lower conversion ratio, for example, if the qualification thresholds are too high or specific. If all you want a lead to do is pay you $10/month for a product or service, that’s a low bar. Anyone with a credit card is a potential SQL. But if you sell inventory management software, to agriculture equipment companies, with a minimum annual spend of $200k—well, a low single-digit ratio is perhaps the best you could hope for.

Anyone with a credit card is a potential SQL.

In the latter case, marketing would be far better off tossing the idea of “leads” altogether, and instead thinking in terms of shared target account lists, buying committees, number of touches, and influenced pipeline—in short, an ABM strategy.

Quality and processing delays

MQLs are also more often than not the classic definition of a vanity metric. Depending on the underlying quality, 10 MQLs could outperform 100 MQLs in terms of revenue (potential or materialized). To take the previous example, landing a John Deere could generate more revenue compared to landing 10 small, agri-tech startups.

Finally, lead qualification usually has processing delays. The sales team may take too long to engage an MQL. Or someone downloads an eBook from your website, but your team is unsure whether or not that counts as a “buying” signal. Or an integration breaks and leads go stale before it’s identified and fixed. And so on. Things like these happen everywhere, all the time, with everyone (present company included).

Beyond the MQL

This isn’t to say that MQL/SQL/Opp is a useless framework. At least I don’t think it is, despite the recent tirade against it. I think that having some framework is an improvement over no framework, but I also think that it can be reductive.

Before we go further, let me just say that the proof is in the pudding. If this framework works for your organization, by all means, keep pressing forward. But I’m assuming that if you’ve read this far, its apparent weaknesses resonate with you at some level.

So, how do you measure marketing’s contribution, if not MQLs? Here are two ideas:

Conversion-ready (CoRe) leads

Dave Ewart, Oracle’s head of digital marketing and demand generation was told by the SVP of Sales at Oracle that he didn’t want his team working on qualifying MQLs because it was a waste of valuable time.

Though Dave was new to Oracle at the time, he made a counter-offer: “How many conversation-ready leads would you accept?”

To this, the SVP of Sales said: “100%”

Over the next few years, Oracle re-tooled its GTM processes to focus on the newly termed conversation-ready (or CoRe) leads, distinguished from non-core leads as “qualified responses with intent to have a conversation”. The result? Oracle reduced the amount of leads they sent over to BDR and the sales team while increasing results in terms of opportunities, pipeline acceleration, and conversion rates.

Oracle reduced the amount of leads they sent over to BDR and the sales team while increasing results in terms of opportunities, pipeline acceleration, and conversion rates.

Of course, you don’t have to call them CoRe leads. In fact, perhaps your existing definition of MQL already includes that key qualifier, i.e., intent to have a conversation. In which case, congrats on being a step ahead of the curve.

Marketing-influenced revenue

While conversation-ready leads are an improvement over the standard definition of MQLs, which often factor in an internal scorecard of checks instead of the readiness of the buyer—it fails to provide a holistic picture of marketing’s contribution to the revenue pipeline. Why? Because CoRe would, much like MQLs, give you a number.

This is where marketing-influenced pipeline and revenue come in. By tagging deals or opportunities and customers that are sourced by marketing, marketing teams can track their revenue contribution through the entire lifecycle of the business. Showing this impact can give marketing the leverage to ask for more resources and invest more in channels where the revenue is coming from—not just where MQLs are coming from.

I’ll sum it up by saying that, unlike sales, generating revenue is not the only job that marketing has. By necessity, marketing teams have to work on things that don’t always scale and can’t always be measured, this is just the nature of the beast. But at the end of the day, revenue is the lifeblood of any business. For mature B2B companies, with good product-market fit and marketing-sales alignment, a 25-30% marketing-contributed/influenced pipeline is an often-quoted benchmark.

If you start measuring this today, you may realize you’re not quite there. Maybe you’re at 5% or 10%, but since you can only improve what you measure, the first step is to have adequate processes and controls in place to start the measurement process.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/839d83d9e2a4ec1f22ff05de263a2e1329bae1c8-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Marketing</category></item><item><title>You don’t need A/B testing</title><link>https://andorlabs.ca/blog/you-dont-need-a-b-testing/</link><guid isPermaLink="true">https://andorlabs.ca/blog/you-dont-need-a-b-testing/</guid><description>&quot;Should we A/B test that?&quot; I dare you to come up with a more spiteful question to type into Google Meets, as you take the last bite out of your donut, with the…</description><pubDate>Wed, 05 Nov 2025 00:00:00 GMT</pubDate><content:encoded>&quot;Should we A/B test that?&quot;

I dare you to come up with a more spiteful question to type into Google Meets, as you take the last bite out of your donut, with the mic and camera decidedly turned off.

The question is followed by awkward silence until someone steps in and grudgingly says, “Sure, we can do that.” And then they make a note of one more thing to do amidst their pile of work because, well, it sounds like the smart, objective thing to do.

Truth is most things don’t need to be A/B tested. That’s because most things don’t have the scale required for a meaningful impact on conversions.

There are exceptions.

Say you are an FMCG brand running a multi-million ad campaign and need to optimize the CTA—by all means, test the colour of the “I’m in” button.

Or if you have a B2C product with millions of users, then yes, split testing components will have a meaningful impact on your results.

Even so, there’s plenty of research that you can lean on instead of reinventing the wheel. For example, a red CTA button is shown to drive 21% more conversions than a green one in totally identical conditions. So maybe you don’t actually need to repeat the exercise in many cases and a few Google searches will do the trick. But I digress.

It’s when B2B companies that get 10,000 page views a month to their website try to A/B things when you enter murky territory.

In my experience, this is usually suggested for one of the following reasons:

You don’t understand the business and the unit economics well enough to not make such a proposition

You want to sound smart and feel like you’re making a meaningful contribution

You personally don’t like the font size, colour, or placement that is presented as the default and assume that most other users have the same sensibilities as you

Or the worst reason of all: You don’t like the person leading the project and just want to create roadblocks in their way

Whatever the reason may be, you need to understand the business context and the available scale before proposing to A/B test things.

A/B testing shouldn’t be used as a crutch to settle arguments. In the vast majority of cases, it doesn’t actually matter if you pick Serif or Sans-serif, or the colour blue or orange, or the size 14px or 16px.

Marketing leaders should rely on their intuition and good sense to make these calls based on the medium and the established brand identity.

Of course, A/B testing companies have been around for a long time now. They have spent a lot of time finding all the different users they can potentially sell their solution. I bet many have a user persona template for Brian the B2B marketer.

So, before you suggest A/B testing anything, think about how useful it’s likely to be, given the unique situation you are in and the associated scale.</content:encoded><enclosure url="https://cdn.sanity.io/images/2b9cfqwh/production/b40acecccad26d0a6248de2b52dbac3e1567fb8e-1600x900.png?w=1200&amp;h=630&amp;fit=crop&amp;fm=jpg" type="image/jpeg"/><category>Field notes</category><category>Marketing</category></item></channel></rss>