This edition of Growth Stack Mafia is brought to you by Bright Data.

Bright Data Scraper Studio turns a plain-English description of the data you want into a running scraper API, with proxies, browser rendering, and CAPTCHA solving already handled.

Anyone who has run their own scrapers knows the hard part comes after you write them, when a site changes its markup and the whole thing breaks. Scraper Studio has a self-healing step that repairs the scraper code with AI when the page structure shifts, which is usually the part that eats my weekend.

• Describe the data, get a ready-to-run scraper in about 10 to 15 minutes, then edit it in a hosted IDE

• Runs on Bright Data’s own infrastructure: 400M+ proxy IPs, geo-targeting, retries, unlimited concurrency, and delivery straight to BigQuery, Snowflake, or S3

Free tier is 5,000 page loads a month with no credit card. Build a scraper free

Try Now

Happy Thursday everyone.

We have spent three posts building up to this one. And you’ve waited a long time since I first released parts I, and II. 😅 As a reminder ...

Part 1 covered what data you can actually get on mobile. Part 1.5 was a long detour into the plumbing of web attribution, the UTMs and click IDs and referrer waterfalls and sessionization. Part 2 was about the gap between what people think attribution is and what it can really do for them: telemetry bias, type 1 and type 2 marketing errors, and the hardest lesson in the series, that even with perfect instrumentation you are seeing maybe half the picture.

All of that was groundwork. The point of building the technical acumen was to earn the right to have this conversation, which is the one everybody actually wants to have. What are the methods? How do they work? And when should you use each one?

To do it right I sat down with LONG TIME HOMIE . Pranav runs Paramark, co-hosts GTMN with me every Friday, and spent years doing this at Dropbox, PayPal and BILL before that. He has strong, specific opinions about every rung on this ladder, and a few spicy ones.

What follows are the ideas from that conversation, written up in my words. Where a take is distinctly Pranav’s, I’ll flag it. The rest is me.

That is the frame here. Attribution methods are a ladder. You start at the bottom with basic clicks and impressions, and you climb through HDYHAU, first and last click, MTA, MMM, and finally incrementality and probabilistic modeling. You don’t skip rungs. You climb to the one your stage and your telemetry can actually support.

With that... Let’s climb!

Rung 0: Clicks and impressions

All businesses start at the floor. In practice, this just means ... do the simple and obvious stuff. Slap in a CDP or a tag-enabled tracker. PostHog, Amplitude, Hightouch ... GA 🤢 ... or whatever you like on your site, track page views, and read and categorize your referrers.

If your channel mix is simple, this is close to all you need. Pranav’s own company is the clean example. The primary channel for him is LinkedIn, showing up every day and doing the work and not much else, so when he wants to know if it is working he opens his web analytics and looks at referrals. If LinkedIn shows up right after Google, great. If LinkedIn is not showing up at all, he has a problem.

That is the whole method at this stage. Simple mix, simple tracking, more finding your way on gut and intuition than anything else. The trouble starts later, when you have raised a big round and you are running five or six or ten channels to keep growing, because now you’re trying to answer the question “how do I consider where to allocate resources as f(time, money, people, attention, tokens)”. Not everybody clicks through from every channel, so the referrer only ever sees a slice. Intuition begins to erode as the only significant lever.

Rung 1: HDYHAU

Ah, the promised land. The simple HDYHAU. How Did You Hear About Us. A form field on your conversion action that asks the customer directly. When your mix gets complicated and the referrer starts lying to you, this is where you go, and it is a better tool than most people give it credit for.

I have argued with many dim-witted product operators about the HDYHAU. So let’s put the kibosh on that first. If a PM or anyone else says “well, we can’t have a HDYHAU because it’s another click in the funnel,” then please escort them to Exhibit A with Elena Verna. This is such a simple-minded approach. In a world of decreasing intelligence around attribution this is one of the most powerful, easy tools to deploy. If customers are so disturbed by a single step in the funnel that they bounce then I’d argue you have way bigger problems than the funnel.

In addition to this mistake, many people also build it wrong. Two things matter.

First, the shape of the form. Put your common channels up top as options, and always leave a freeform box at the bottom. The old knock on freeform was that people type garbage like “internet” or “search.” True, but it barely matters now, because grouping and categorizing a pile of freeform answers is a five minute job for Claude against your SQL. So you get the structure of options where it helps and the open box for everything you did not think to list. Add a new channel to the options as you launch it.

Second, do not get cute with your buckets. Nobody thinks in “organic search” versus “paid search,” so just say Google. Nobody remembers whether they saw you in the Instagram feed or in stories, so just say social and put the specifics in parentheses. Keep it to five or six options, max. Fifteen options is fake precision, and every option you add nudges people toward answering the way you framed it.

The reason to run HDYHAU is that it gives you a directional read you cannot fake. You put $50k into TikTok this month. Did even five people say TikTok in the box? If the answer is zero, something is wrong, no matter how many views and comments the channel is throwing off. Views are not the point. Somebody telling you TikTok is how they found you is the point.

Rung 2: First and last click

This is the rung most companies reach at some stage in their journey, and it is the one they implement worst. It’s also arguably the biggest bang for your buck and where most companies should stay for longer (before moving on to advanced methods).

As we covered back in Part 1.5, this method is just capturing first and last clicks and saving them as events and user attributes in your CDP.

The failure in this method is almost never the model. It is that the model was never written down. A team collects utm_campaign, everybody assumes it is last touch, and nothing in the instrumentation says so. Somebody new comes in, looks at the data, and cannot tell whether they are looking at first or last. You have left it to tribal knowledge.

It does not really matter which one you pick. Pick one, and make your telemetry loud about the choice. If you are collecting UTMs on first touch, then label the fields first_utm_source, first_utm_campaign, and so on. Now there is no ambiguity, and if you want to add last touch later you copy the logic and write a bit of code.

There is a real question of where that logic should live, on the client or in SQL, and the answer connects back to a rule from Part 1.5: be clear about where it lives and why. You can hold first and last in the parameter name on the client, or you can derive it at the data layer with a query that lists every channel in a session by timestamp and grabs the first or the last. Either is fine.

What is not fine is the two issues I see constantly. One is teams that force everything into SQL when a little client-side structure would have saved the data team days of work. The other is teams that do zero cleanup on the client, ship a garbage volcano of raw events, and leave analytics to sort out what any of it means.

Something I want to push hard against here is inference. Some tools, and AppsFlyer is the example I dug into, will fill a missing parameter by reaching for another one and stuffing it in. Do not do that. If the parameter exists, collect it and let that be the real, observed state. If you want to infer something on the back end, do it in SQL where everyone can see the assumption, not silently on the way in.

There is a timely reason to care about all this. Meta just changed how it does click attribution, and the head of their marketing analytics said the reason: they wanted to mirror what shows up in Google Analytics. For years a “click” in Meta’s world could mean any engagement with a post. In Google’s world a click means an actual visit. So Meta reversed fifteen years of definition and invented separate labels, engaged-through and view-through, to keep the plain click clean. Take the lesson. Whatever you call a click or a touch should be an actual click or touch. That is the only way your Google Analytics ever reconciles with your internal Looker dashboard, and the reason those two numbers usually disagree is that somebody made up a definition instead of collecting the real one.

One prerequisite sits underneath this whole rung. Do not build any of it unless you are actually running experiments and changing what you do. Telemetry and dashboards that never drive a decision are for show only.

And you can get a long way with almost nothing. Pranav’s version is a plain spreadsheet: spend, impressions, and clicks or the channel equivalent, laid out channel by channel, day over day and week over week, with your conversion metric across the top. No UTMs in it, no click IDs or other fancy shit. Drop it in a browser and you can ask Claude whether your conversions moved when you ramped LinkedIn spend, and it will run the correlation for you. It is so easy to do now that it is strange more marketers are not looking at it every week.

(Maybe we should do a workshop for founding marketers? DM me if you think this would be useful)

Rung 3: MTA

Multi-touch attribution. The promised land everybody wants to reach, and the one I distrust more than any other (Pranav too).

The idea is seductive. You saw an Instagram ad, did not click, and three days later opened your work laptop and typed granola.com and signed up. MTA is the attempt to connect that ad impression to that signup and hand fractional credit to Instagram instead of writing it off as direct or organic.

The trouble is that the system can only ever see the part of your journey that is visible to computers, and that ad on your personal phone left no trail the signup on your work laptop can find. Vendors will tell you they solve this with a Facebook pixel, or identity resolution, or device fingerprinting, or IP matching. Maybe some of them stitch personal and work together some of the time. But then you are left with the harder question anyway: did the ad actually change what that person did, or were they going to type granola.com regardless because a friend told them about it last week?

Then there is a data-construct problem that kills a lot of MTA in practice. Some of your identifiers are deterministic at the user level. Others are anonymous at the campaign level, a big blob of Instagram impressions you cannot tie to a person. To combine them you have to drop everyone down to the least specific version, which means campaignifying the deterministic data too, which defeats most of why you wanted MTA in the first place.

And when you do build it, you pick weights. Every TikTok view counts 10%, every Google click counts 20%, you fractionalize each touch and sum by channel, and out pops a beautiful chart. But you chose those weights, and in any large org that choice is political, because everyone wants their channel to count more. I watched this at a company where partnerships, which was not even a paid channel, spent its energy fighting marketing for credit in the model. That is the environment MTA creates, and it is fine if everyone agrees the tool is just a tool and the output does not decide budgets. It never stays that way. People take the chart and move money with it.

So the verdict is simple. If you are choosing between MTA and HDYHAU across five or ten channels, HDYHAU wins. If you are going to do MTA anyway, keep it to real physical touches, never touch view-through or engage-through, and understand that all it can honestly optimize is the very bottom of the funnel, because a touch by definition happens at the end. The one place it genuinely earns its keep is personalization. If someone clicked through from an email about X, make the landing page about X. That is a good use of session data. It is just not attribution, and we bastardized the word a little when we started calling it that.

You are seeing 50%, not 90%

I guess this is what AI might call a “HARD TRUTH”. Or a “LOAD BEARING ASSUMPTION” 😆 We hit this back in Part 2, but it is the load-bearing one, so here it is again.

Most people think they can track 80 to 90% of their marketing. I think that in the best circumstances, with the best telemetry, you are seeing about 50%. Every digital channel is under attack from privacy, and deterministic tracking that was close to pure around 2019 has been eroding ever since. So even good coverage now often tells you how many people you saw at a campaign level without telling you which people they were.

And all the methods on the lower rungs miss the same enormous category of things: word of mouth, the billboard you drive past, the ad in the subway, the way somebody feels and comes back six months later. With basic tools you are, at best, using data to flip a coin. A Series C running a lot of channels on thin telemetry is better off leaning on intuition and simple tools than on an elaborate MTA build that creates strife and still gets it wrong.

None of that means you give up on being rigorous here... It means you get a leeetttle bit more honest about where rigor is even possible, and you reach for the heavier methods in the specific cases where they can deliver real precision. Frankly, most companies pre-Series C, pre complexity don’t need these tools. They are chasing them because a CMO told them to, or they read something on LinkedIn or they think they have to. Plenty of world class marketing teams operate on the bare minimum for a lot longer than you’d expect.

There is a lovely low-tech version of this. Pranav has a customer advertising on podcasts, where the telemetry is basically nonexistent and the only hard number is spend. So they record their sales calls, query Gong for how often each podcast gets named, and use that as a directional read. If people keep mentioning the show unprompted, it is probably doing something. That does not belong in an attribution model, and it does not need to. It is a reasonable way to justify a decision.

What’s cool about this example is that it’s a nondeterministic method. You could build a claude or codex skill that runs on a cron or routine. You could do this for all your channels, and daily or weekly you get an assessment of “is this working” that is partly numbers (record and distill mentions over time) but a lot more based on conversation which is rich in detail.

Rung 4: MMM

The next rung. Marketing mix modeling. This is where you climb when you want real precision back, and it works in a completely different way from everything below it.

MMM does not touch UTMs or click IDs or touches at all. It looks at the relationship between a channel’s trend line, its spend and impressions and engagement over time, and your output metric, meaning total conversions however you define them internally. When your LinkedIn impressions go up and your signups go up, and they fall together too, over six or twelve months, the model reads a strong relationship. When your TikTok impressions swing around and your signups stay flat, it reads a weak one.

The reason it levels the playing field is that every channel produces a time series. Paid, earned, PR, owned email, outbound, webinars, all of it. There is no channel that cannot be represented, which is exactly what first and last click and MTA could never say.

Mechanically it is more approachable than people expect. Take the common B2B stack, Segment collecting web data into Snowflake, dbt on top, Hightouch downstream. You already have spend and impressions and conversions by day sitting in the warehouse. You go get an open source package, Google’s is Meridian and Meta’s is Robyn, both well documented, and you run it locally on that data frame. It is a Python or R script sitting on top of your source data.

(If you’ve taken some statistics courses, I’d argue you could self run one of these models using AI. but beware of accuracy and interpretation)

Then you configure it, because the out-of-the-box run gets you started but you will need to tune it. Seasonality is the big one. If you know your business spikes hard in Q1 and slides the rest of the year, or peaks in Q1 and again in Q3, feed that in, because the model gets meaningfully better when it knows what you already know.

What comes out the other side is a set of outputs. Some describe the quality of the model itself, statistics like R-squared and MAPE that tell you whether to trust it. If the fit is bad you go figure out why. If it is good, you get your conversions split into incremental and baseline, where incremental is what your marketing investments drove and baseline is the built-up brand equity, word of mouth and organic demand that would have shown up anyway. The incremental piece breaks down by channel. And you get diminishing-returns curves, so you can see whether $50k a month in a channel is still scaling roughly linearly or flattening out. You can DIY a basic version of this at Series A or B. It gets genuinely hard once you layer in pricing and packaging changes or the occasional viral peak.

Rung 5: Incrementality

Everything below this rung is correlation. This is the only rung that attempts to give you causation.

When an MMM hands you an “incremental” number, that is an estimate of incrementality, not observed causal incrementality. The only way to actually get the causal version is to run an experiment. “Incrementality testing,” which is jargon I do not love, just means running experiments, and an experiment has three parts.

You need a control. Think about how many times a team has said “let’s test it” and then just launched something with nothing to compare against. That is not a test, it is a random act of marketing, and by that standard maybe 99% of testing in marketing is not testing.

You need statistical power. Same as an A/B test on your site: know your baseline for the metric, then calculate how much lift, how much budget, and how much time it takes to get a valid answer. There is nothing different about your media mix here. The math is the math.

And you need a real hypothesis with a stake in the ground, which is where you should actually start. “Let’s test Meta” means nothing. “We think we can get an incremental 5% in conversions at a cost per conversion of $50” is a hypothesis. If you cannot even name an acceptable target CAC, you should not be running the marketing team.

The last piece is what tech bros might call “taste”. If a test comes back with no lift, the unsophisticated move is to write off the whole channel: Meta doesn’t work, billboards don’t work, YouTube doesn’t work. That is not what a null result means. It means that particular execution didn’t produce lift. You learn from it and put a better foot forward. You can run five that go nowhere and a sixth that is a smashing success, and you would never have reached the sixth if you quit at the fifth.

Two very different things called “test”

Let’s talk about testing for a second. Because in all of these ladder rungs, there’s this underlying concept of a test or an experiment. You hear it constantly:

“Let’s run a new channel experiment.”

“I want to experiment with marketing.”

“We’re taking a bunch of bets.”

“Test” gets used two ways that people constantly conflate. One is the political version. You have a room of people at equal status, no clear decision-maker, and gridlock. “Let’s run a test” becomes the graceful way to move forward without anyone having to fully commit. This is a real and useful thing to do (and I do it ALLLLL the time; I thank Tanner McGrath for teaching me this implicitly during my time at Runway, where I hit constant hurdles getting people to agree). The other is an actual controlled experiment run for certainty about whether something works.

Both are legitimate tests. The problem is doing the first while believing you did the second, because then you take an outcome that was never designed to be conclusive and treat it as proof. So say which one you are doing upfront and try to be thoughtful about it.

For example, as Pranav notes... At the start of the year, take your annual goal, say a 70% increase in your conversion metric with a $100 CAC guardrail, and build an experiment roadmap from January to December. Treat it like a product roadmap, a learning agenda of your best hypotheses all pointed at that number. That is a much cleaner way to think than running one-off tests to break a political logjam and hoping the results mean something.

The thing under the whole ladder

If you take one idea from this post, I hope you take this ...

When an MMM output tells you Meta drove 10% of your conversions, that is not the real output. The real output is a range, maybe 7% to 12%, and 10% is just the median, because that is the number that fits in a chart.

Every value these models produce is a distribution of possibilities. Some come back with a tight range and some come back wide, depending on how granular your data is, how long you have collected it, and how much it has varied. That is the whole difference from MTA, which confidently tells you the answer is X. MMM tells you the answer is X plus or minus something, and the plus or minus is the honest part.

Okay, some parting advice and wrap ... First, go learn some statistics, and try to narrow learning to three ideas. Probability and uncertainty, the coin-flip intuition of what actually happens when you flip ten coins, then a hundred people flip ten coins each. Correlation, which you can run against your own marketing data all day. And causation. Spend a weekend on those three and you will be materially better at this job than the marketer next to you who never did.

Where this leaves us

Back to where the series started. Attribution is navigation, not GPS. You are reading the stars to figure out roughly where you are, and there is real science in that, but there are things out there you will never see or predict cleanly.

The ladder is not a race to the top rung. It is about standing on the rung your stage and your data can actually hold, and using a few different lenses at once instead of chasing one clean number that does not exist. HDYHAU at the bottom. A well-labeled first or last touch when you start running real experiments. MMM when you want to weigh every channel on the same scale. Incrementality when you need to know something is causal. And under all of it, the humility that you are working with half the picture and a distribution of maybes.

Hope you enjoyed.

If you made it this far, you now know more about attribution than most of the people who will confidently tell you their MTA dashboard is the excellent. Also if you made it this far maybe you are a real person because nobody loves attribution this much.

See you on the next rung.

Additional Reading

The series so far: Attribution Part 1, Part 1.5: Web Attribution, and Part 2: Ignorance to Enlightenment.

The tools we mentioned: the open source MMM packages, Google Meridian and Meta Robyn. And GTMN, the weekly Go-To-Market News show I co-host with Pranav.

Go deeper (one great read each):

• What is Marketing Mix Modeling?. Pranav’s team at Paramark, a clean primer on modern MMM.

• Diversified Marketing Measurement: MTA, MMM & Experiments. Rockerbox on why you triangulate methods instead of picking one.

• How today’s top consumer brands measure marketing’s impact. Lenny Rachitsky’s operator survey of MTA, MMM, and lift studies.

• Your guide to CAC payback period. Kyle Poyar / Growth Unhinged on the unit-economics lens most teams miscalculate.

• All things Peter Fader and probabilistic marketing.

• How Anthropic’s marketing ops team really uses AI (and what I’d do differently)

• Cutting through the “AI brain” hype

• What to actually build, and where to put it

Hellloooo again, everyone 👋 lakeside from Virginia. It’s a beautiful day out here after a run of oppressive, hot days where even the lake water felt like it came out of the hot tap and the air felt heavier than butter.

For some reason, as soon as July 4 hits, it feels like summer is in its waning phase. We have months of good weather ahead - outdoor rides, hikes, pool time, and blissful sunsets - but the mood has shifted. For me, this wind-down into fall is usually a season of reflection and refocusing.

Every year I set a goal list, and because the weather in DC from January through March is so terrible, I tend to overcrank in the first part of the year. Then there’s this brief little blip in July, and a bit of refocusing. Where are we with our goals? What have we accomplished? Are we on target? If not, what adjustments do we make to feel proud of how we tackled the year, come winter?

Today’s newsletter is a bit of a buffet. There’s a lot swirling in the air around martech and AI, and I’ve been doing some of this reflecting out loud:

• Dissecting how Anthropic’s marketing ops team uses AI, and what I’d do differently if I were there

• Unfurling the “AI brain” hype, and how to actually build something useful

• What to actually do for both

Let’s dig in.

Anthropic’s team shares how to marop with AI

First, let’s start with Anthropic’s recent article on their marketing ops AI workflows.

In it, the Anthropic team - Ian Chan and Annabel Custer - walk through their marops workflows on Claude. Neat. They’re effectively using MCPs and connectors inside Claude Cowork to do tasks, then repeating those tasks with routines.

This is a core part of the educational program I’ve been delivering internally at Khosla and to dozens of portfolio companies.

Most of their examples focus on repeated work they have to do anyway: building reports, triaging run-of-the-mill marops tasks across different tools, automating campaigns. Ian’s reporting workflow runs on a three-skill build:

• Prep skill: drives the report assembly, including focus, headlines, and expansion with supporting detail.

• Proofreading skill: checks every number in the draft against a verified source.

• Action-items skill: turns follow-ups into Asana tasks.

Later, Annabel goes deeper on a set of skills that deliver an end-to-end event, like a webinar:

• Dispatcher skill: reads the intake channel and routes each request to the right specialist skill below.

• Event-build skill: drives the end-to-end setup across platforms.

• Webinar-landing-page skill: spins up landing pages for webinars.

• Audit skill: verifies the event-build skill’s output before the task is marked complete.

• Apply-to-attend skill: handles in-flight changes to the registration flow.

• Approval-support skill: handles event approvals and sends the appropriate emails on a schedule.

• Data-import skill: scrubs lists and processes attendee data.

The core idea: take the work you’re already doing and break it into bite-sized chunks Claude can reasonably handle. Each chunk is a skill. Over time, as you do more tasks, you build more skills. As you build more skills, you string them together into workflows. And sometimes you’ll have Claude build skills you never would have thought to write yourself, but which help it become more deterministic.

On skills

What I loved about this article is that they name the AI learning loop I’ve been shouting from the mountaintops:

Turn repeated corrections into skills. When you find yourself correcting Claude on the same thing more than once, that feedback belongs in a skill. You don’t need to build skills, either: Claude can do that for you.

That last sentence is the real sauce. You barely even have to know what a skill is. A skill is just a markdown file. It’s a big blob of text that fixes the age-old (October 2025) problem of copying and pasting the same context over and over to get repeatable outcomes with AI.

Likewise:

Ask Claude to reflect. Claude reads instructions differently than a human writes them, so after the first runs of a new workflow, ask what was difficult about the instructions.

This is one of the skills I’ve hardwired into a /done post-session hook. When I finish work in a session, I run a modified version of Garry Tan’s /skillify skill, which includes a /reflect step. /skillify turns any conversation into a generalized skill anyone can use, making sure it follows MECE, DRY, and sanitization principles.

/reflect is a small prompt that tells the AI to “think about this entire conversation and all the parts that were hard, difficult, or where I had to prod you, or where we got stuck. Imagine we were doing this exact same thing again. How would you do it better and faster? What would you change about the skill? And what would you need from me to make it better, if anything?”

In the beginning, there’s activation energy required to get value out of AI. You have to build skills. But the hard problem isn’t building the skills. It’s sharing them across your peers. If you have a multi-pronged team like Ian and Annabel, they’re both building skills at the same time. It would be great if their AI sessions could “look across” each other’s skills and use them to solve new problems. That’s the AI learning loop.

The loop looks like this:

1. Build something unique with MCPs, connectors, and APIs.

2. Get to an outcome once.

3. Generate a skill with /skillify.

4. Sharpen it the next time with /reflect.

5. Automate it into a cron (in code) or a routine (in Cowork).

The punchline from the article: “Annabel feeds what surfaces back into the skill as part of her broader practice of constantly updating skills.” Rather than doing that maintenance yourself, build a skill that does it automatically.

If you’re using Cowork, that maintenance can take the shape of additional skills. If you’re using Claude Code, it can start as a skill, but eventually it should be a hook.

Validation

Another interesting part of the article, though under-explored, is proofreading:

Build a proofreading skill first. The proofreading skill checks that every number Claude puts in a report traces back to a verified source.

What they’re really getting at is data validation. And here’s the catch: data validation usually runs on code or SQL. This is exactly where skills are weak and tools (deterministic code) are strong.

Think about it like this:

• Non-deterministic work: handling many differentiated parts that don’t require exact precision. Use a skill. Let AI absorb the randomness.

• Deterministic work: making sure a number is correct, that you pulled data from the warehouse the right way. Use a tool.

This has been one of my key learnings, one I first saw clearly at Eight Sleep a few months back, and it keeps creeping into my observations of AI-native teams.

A tool here is something like “get last week’s activation numbers” or “pull the number of weekly signups.” In both cases, the number has to be 100% accurate and reliably pulled. The problem with a skill is that it may not be 100% repeatable. If it’s generating a query on the fly, in any language, the output can drift.

One way to handle this is to instruct the AI to include the exact query inside the skill. But that’s still fragile, because when you /reflect or /skillify, you don’t have total control over what the AI writes back to the markdown file.

So the better solution is to build robust, 100% reliable and accurate SQL queries, encode them as query tools, and manage them in a central place. That way, when anyone on the team “pulls leads from HubSpot,” they pull the same number - not different ones, and not by trusting AI to nail something it can’t promise.

Of course, this only matters when data needs to be perfectly accurate. In plenty of cases, data can be “directionally good enough.” It’s the same distinction humans make between eyeballing a segmentation chart in Amplitude and reporting actuals to the CEO from the warehouse. Skills that work against data are fine when the stakes are low. Tools, especially shared tools, are the right primitive when you and your whole team need to pull data accurately.

Cloud vs local crons

In the last part of the article, another buried nugget:

Lean on scheduled tasks. Work that runs on its own every Sunday night or every hour is work no one has to remember to do.

Routines are simply skills that run on a fixed schedule. They require your computer to be on, connected to the internet, and holding the right permissions. They also require that you have all the relevant MCPs and connectors available.

In essence, this is what we call a “local cron.” A cron is just a task that runs at a specific time. In code, you can build crons to fire at any time. You can set up local crons on your computer using Claude Code. You just can’t visualize them anywhere per se, unless you ask the AI to build you a view, or you build one yourself.

Routines, or local crons, are genuinely valuable, especially for beginner and intermediate AI operators. They turn day-to-day basic tasks into automated work.

For example, I recently helped a team member automate really basic accounting work that used to eat 20 hours a week. First, we built a “ramp triage” skill. Then we improved it. Now it’s running. It’s not perfect, and there are still a few things she has to clean up, but it’s proof that routines take people from “this takes me hours” to “this takes minutes.”

Over the last few months, I’ve seen routines pop up in every department. Routines for invoices, expenses, email follow-up, Slack messages, growth reporting, channel execution. Anything you do more than once can be a routine. The key question is whether the up-front time to build the skill is worth it. Technically, your entire life can be skillified and then routinified. But time is finite, so pick the highest-value surface areas first.

Singleplayer to multiplayer: how do you share AI across a team?

An obvious question falls out of the Anthropic piece. It’s cool to build skills and routines, but how the heck do you share these things?

And the bigger one: how do you build an “AI brain” that shares not only skills and tools, but knowledge?

Everyone is talking about the AI brain. A few months ago I built my own, Taurus, with a local claw in my basement named Gary. It feels like every day I see another post calling for one and asking for help, like this one. I had a long conversation with an operator this week about exactly this, so here’s a recast of where I landed.

What an AI brain actually is, stripped of hype

Taurus is a collection of databases with an MCP wrapped around them. That’s it. Instead of wiring up a separate Gmail MCP, then a calendar MCP, then a Drive MCP every time I start a session, one code word - Taurus - points my AI at everything at once. That single-word-points-to-many-resources trick is a real benefit on its own. Honestly, it can start life as nothing more than a Skillify.

Who it’s actually for. Not someone whose whole life lives on one work machine. If everything you do sits inside one company’s laptop, you don’t need this. The payoff shows up when you have multiple jobs, consulting work, side businesses, or a personal life you want AI to reach across. I told an operator recently that it’s worth building if she ever wants to become a growth advisor and reuse the lessons from one company at the next.

Why I built mine. Two reasons. One, I wanted a single MCP that could search my whole life in one shot instead of ten different places. Two, I wanted a cheap, forever home for a decade-plus of consulting history: emails going back to 2017, downloaded calendars, contacts, Strava, health data, financials. My rule now is simple. Anytime I’m doing something in a non-unique surface area, I ask, “should this just live in Taurus?”

The real value is functional, not the “brain.” The best thing Taurus does is kill subscriptions. I had Claude learn the APIs for every call recorder I’d ever used - Clarify, Granola, Zoom, Grain, Fireflies - pulled all the recordings into my warehouse with vector embeddings, then cancelled every one of them. Same move with Ordinal, a $135/month LinkedIn scheduler, and a $10/month macro tracker left over from Ironman training. Both got rebuilt inside Taurus. Use a tool, pull your data out via its API when you’re done, store it, stop paying. The mono-repo becomes a place to build little micro-services for your life.

Where it’s going. I want these services connected to a cloud environment so the AI has what it needs without me granting MCP authority every single time. I also bought a machine to run a local model over the next few months, so Taurus can eventually do work on its own hardware without depending on OpenAI or Claude for every call.

The honest caveats

Now let me be the skeptic, because most of the AI-brain trend is hype.

• The pretty graph means nothing by itself. The Obsidian “look at my beautiful synthesized graph of connections” thing is not a use case. It’s a screensaver. You have to start from a real problem you’re trying to solve, not from the visualization.

• The graph only pays off with a decade of data behind it. The one person I know who genuinely benefits from that kind of graph is someone like John Cutler, who has been writing prolifically for over a decade in Obsidian and can surface everything he’s ever said on a topic mid-call. The value was the ten years of writing, not the display.

• You can spend more time automating work than doing it. I promised someone a doc on a call recently. Auto-generating it would genuinely be useful, but it’s roughly twenty hours of engineering, it won’t always work, and it burns tokens the whole way. Not worth it yet. That math matters.

• Building can tip into bingeing. This is the AI vampire problem I wrote about a couple of weeks ago. High-functioning people binge on building with AI, then overdose and feel depleted. Building to learn is great. Past a point, build for a purpose, not for the high of building.

And one more, for anyone working inside a company right now. The company you work for is building a version of how you work, whether you like it or not. If you ever leave with no logging strategy of your own, you’re back at zero, rebuilding everything from scratch. So if you’re working with a company’s Claude or Codex, keep a personal one on the side where you build a generalized version of what you make at work. Log how you do the work, so your career compounds instead of resetting every time you switch jobs.

What to actually build

So when someone asks me what to actually build, here’s what I tell them.

Don’t start with GitHub, unless you’re a fully technical team. Most non-technical teams simply can’t use GitHub. It’s messy, it’s complicated, and you have to hand out permissions and access just to get people in the door. The Git-as-knowledge-base idea was pioneered at DoorDash, and it’s clever, but it only works for teams that are already tech-pilled. For everyone else, it falls apart.

So where do the primitives actually live? Notion. A Notion hub, built from pages and databases:

• Pages (and collections of pages) hold written knowledge you can always update.

• Databases hold the repos: one for skills, one for tools.

• Nice to have: learning pages where people can figure out how to use the hub, and where their AI can learn it too.

For a growth team, it might look something like this:

• Hub Home

• AI Wiki - the AI’s index of every page and all the meta-knowledge it needs

  • The skills you use every conversation (/skillify, /reflect)

    • If read-only: how to submit suggestions to update a skill, the library, or the index

  • Team structure, who’s who

  • Domains of expertise

  • Pre- and post-conversation hooks

  • Service tokens: what’s needed for which tools, links by access role, or how to request access

• A maintenance worker: rules and scripts that keep the hub tidy

• Skill Library - a database where each markdown file is a skill, with its required tools and connectors

• Tool Library - a database of raw, sanitized Python, SQL, and other scripts

• Team Meeting Library

• OKR Library

• Knowledge Library

  • Brand guides: style guide, color schema, brand guidelines

  • Voice guides: LinkedIn tone, Substack tone, founder voices

  • Strategy guides: your ICP page

  • Stack guide: tool architecture, vendor selection matrix and criteria, vendor docs, and vendor-specific knowledge about how each tool is set up

Why Notion? Because the out-of-the-box MCP works for almost every non-technical operator. Sharing is a single URL, pre-bundled with everything a teammate needs to be successful. The permissioning model is easy: flip someone between read-only and edit, and their MCP updates by virtue of the access change. Version control is built in, so you can roll back the changes people inevitably make with their AI. And setup is basically turnkey.

It’s not perfect, but it’s the best system I’ve seen work in practice across dozens of AI-native startups.

It’s a great starting place for small teams and folks who want an uncomplicated place to begin. The natural place to graduate is a third-party tool, especially once you want tighter control over documents and which LLM you’re running. Three worth looking at:

1. Runlayer - a control plane and gateway for MCP servers, skills, and agents.

2. Indigo HQ - a shared context layer for teams building with AI.

3. Vector - Mike Molinet’s take on how GTM teams should run (or just email mike@vector.build).

That’s the buffet for this week.

If you’re building any of this - a skill, a routine, a scrappy little AI brain of your own - I’d love to hear what’s working and what isn’t.

Reply and tell me. Thanks for reading. 🙏

• We are so so back!

• Joining Khosla Ventures

• Lessons learned from 90 days and 100 founder convos

• Attention Maxxing

Read more

In this week’s edition…

1. 🔥 New Paid Courses on how to dominate marketing with AI at ClaudeMarketers.com

2. Some more Claude tips for the week

3. Services are Sexy again

4. Good reads, good tools, and good jobs

Read more

Read more

I’m still working on Attribution Part 3.

If you haven’t read Part 1 or Part 1.5 on Web Attribution or Attribution Part 2 yet, go check those out. I think you …

Read more

Mentally and physically, February was exhausting. But this last week, it all turned a corner. More sleep, a stable sc…

Read more

You know, I had spent the last three weeks looking forward to beautiful 60-degree days, sunshine, and runs along the Marina and Presidio.

I’ll still be getting those runs in, but damn, they are going to be cold and damp. Less sunshine than needed after three weeks of brutal ice-escapades in DC.

My mind ha…

Read more

I’ve been on an attribution bender lately, and today we are continuing it.

Why am I focusing on attribution? Well, first of all, it’s like one of the seven Horcruxes of marke…

Read more

Read more

I’m veering from technology a bit this month because fresh perspective and renewal are the themes of January. Countless friends are in the midst of rethinking their careers, so I thought I’d share something I’ve thrown around to a dozen of them.

Below is a structured document you can use to evaluate any opportunity - whether it's full-time…

Read more

If you’re one of the 13,000 readers that joined me last year, I want to thank you. I received so many messages from folks engaging with what I’ve written, asking questions, and supporting my work. It meant the world.

I debated sending this earlier in December, but every t…

Read more

Read more

1. Casey Winters SuperMe and what it means for the future of the expertise economy

2. Hightouch Agents and the move towards the omnipotent marketing platform

3. Reforge Build laying down an epic ad unit and strategy

4. Cursor 2.0 and how we are finally (probably) arriving at the real prospect of a $MM 1 person s…

Read more

1. Nobody gives a shit what you call yourself

2. Lessons from my observations serving 12 founders across 10 years

3. A detailed therapy case from a series C founder building marketing

Read more

1. Forks vs Spoons: how loss changes you.

2. Change is the only constant

3. Life is a random walk: a variant of the fundamental attribution error

4. MDP: Marketing data platforms are becoming in vogue

5. Hiring marops: focus on marketing strategy first, then tools will come.

Hi readers - I skipped the newsletter last week. To be frank, I couldn’t gather the strength to write. The thoughts were there, but when I sat down at my keyboard, my mind could only turn to other things. We had to let our beloved greyhound, Chloe, go the week before.

This wasn’t our first family member we ever lost, and it also wasn’t our first time feeling immense grief. In fact, it felt all too familiar.

In a podcast my wife and I listened to, it was said that most people’s lives resemble spoons. The smooth arc of the spoon representing the journey through life unblemished by hardship. In the beginning figuring out who we are and building lives worth living, and in the end, the slow arc of the spoon representing the inevitable decline.

Spoons get small chips and dents with intended use over time. But they remain smooth. Until they don’t.

Spoons eventually and inevitably become forks. Forks are made from the crucibles life demands of us.

From losing a mother or father far too soon, from seeing brothers lose their lives in the battlefield, seeing your pet slowly die in your arms wondering if you did the right thing, or losing a child to stillbirth when you were expecting a happy ever after.

Loss is loss. These are all losses I’ve heard people share recently as I grapple with my own grief.

Loss creates rough cuts in you that never go away. It changes your perspective, and how you’re able to operate. And yes, sometimes it can dull the fire in your belly, temporarily or permanently.

Loss makes you a fork. And if you’re a fork, it’s easy to spot the forks from the spoons because loss fundamentally alters the way your move through the world.

It’s not a badge of honor, it’s an understanding of life and death and a greater acceptance of our mortality and limits on this earth. It’s an understanding of what deep grief feels like, and how difficult it can be to move through life when it happens. It’s acceptance of the limited control we have over events in our lives.

Managing change

Loss can also be an opportunity to invite change — even if it feels unwelcome at first.

Since 2017, all I’ve ever known is having two greyhounds. Shortly after joining my first startup, Branch, we adopted our first boy, Balou. Then a year later, convinced he was depressed and needed a companion, we welcomed Chloe into our family. Turns out he was just a lazy greyhound, and not depressed. Our lives couldn’t have been more full with the joy they brought us.

In my mind, it feels like yesterday. I have incredibly vivid memories of those early days and the moments over the last 10 years as we transformed from young to full adults. Those ten years would be full of change: We moved apartments, moved across the country, moved jobs, bought houses, experienced loss with them. But there was the constant beat of their presence behind it all. Always something to fall back on. Normal meant coming home to them, daily dog walks, nightly routines.

You don’t realize how much of your happiness is tied to these small habits and rituals and the presence of them until they are gone.

At first the emptiness is unsettling, but over time, it allows you to imagine something new. Change is hard, but its the only constant you can count on.

Managing it? Well, there is a whole lot of rigorous intellectual work around it. My two cents: There is no silver bullet to grief, acceptance, or managing change. There is only one path: to experience it fully, embrace it, deal with it and after days or weeks of not knowing how to continue, you figure out a way to continue.

But to those who might be dealing with unexpected and perhaps unwanted change, I’ll tell you a secret: the best remedy is sharing what you’re going through with others, as terrifying a prospect that might be.

Life is a random walk

This leads me to a meta point I’ve been noodling on lately. Like the stock market, life is more of a random walk than anyone would like to admit. Consider that your life is a function of:

• Where you were born

• Who your parents were

• What genetic traits you inherited

Each of these — which are completely out of your control — controls what eventually becomes you. They are all essentially random events. Cards flipped over from the top of the pile.

The essence of you is created inadvertently by others. However, at some point in your life, you start to gain conscious control of your actions. Well, kinda.

We just established that the foundation of your life was random. Thus, the when, and how of your consciousness is also random. Did your parents read to you? Did they have the resources to put you in that sports program? Did you do your homework or not? All of these events make up what we will eventually call your conscious ability to control events.

But are these conscious choices?

Eventually, they become conscious. You bear responsibility for your actions and you have the capacity to change your life. You can read, you can exercise, you can choose your life partner, you can choose to stay or leave the job. These are not all random events, but actions.

But still, there is the undercurrent of chaos in life that rears its heads to remind you you’re only partially in control.

Did you really choose your partner? Or did you meet the right person at the right time? How much of that choice was luck?

Did you really choose to leave that job, or did you not have the skills and the outcome was inevitable?

You can read everyday, exercise every morning, wake up and be a good human, plan a brilliant life, have kids, love, laugh, be joyful, empower others, lead a great career.

Or you could die unexpectedly.

So what is it: are we in control of our destinies, or not? Life is a random walk because of the very nature of this question. Like the stock markets, you can make money. You can buy low and sell high. You can make choices that enable a better outcome. But you can also fall prey to luck, to chaos, to chance.

That’s why life is as much a random walk as the markets. It doesn’t mean that you should despair, but it does mean that hard work and pulling yourself up by your bootstraps is only a partial picture of what’s happening in anyone’s life. As you consider your own life and what happiness looks like, you have to consider the role that active choice plays vs luck.

Now, some people will look at this as a defeatist view. Since you can’t control luck, why bother even considering it. The answer is simple: it’s impossible to ignore. We are bombarded everyday by reminders of luck without acknowledging its impact. The story of the 18 year old prodigy who created the company, the Christmas cards with your friends big beautiful family, the promotions you see rolling out on LinkedIn daily.

Luck drives outcomes as much as choice. This can be a freeing notion because it allows you to accept that you don’t have full agency. There will be things you can’t control, and that’s okay, even if sometimes it feels like its horrible and not okay. If your life isn’t what you want it to be, you have the ability to change it. But not every life you see around you was created through active choice. A variant of this dilemma and viewpoint is called the fundamental attribution error, where people tend to inaccurately attribute someone’s actions and behaviors to their character as a pose to their circumstance.

The Marketing Data Platform

While life might be a lot like a random walk, the recent trend of building a “marketing data platform” isn’t.

In the last month, it has come up in > 50% of the calls I’ve taken with large enterprise clients. In fact, its central to one Fortune 500’s 2026 plans, and some version of it is central to a leading CDP provider’s future bets.

But… what is a marketing data platform?

If you google the term you won’t find a key vendor that pops up. That’s because it’s vendor agnostic, and currently undefined. There are two versions that I’ve heard recently:

First, a marketing data platform could be an all-in-one solution or platform that combines marketing data with bespoke capabilities, like email, activation, journeys, experimentation and more. Braze, for example, might someday call themselves this. They have a foundation underpinned by Snowflake, they have data flows, they have messaging capabilities, and now with OfferFit they have experimentation abilities. As they add new capabilities and connect them into a journey-like builder, they could reasonably call themselves a MDP or something like a total marketing platform.

Or, a second definition could be a loose collection of data and activation capabilities that enables a business to centrally execute their marketing mission. This to me resonates much more given the distributed and composable nature of CDPs today. The market has bought into the vision that your martech stack is composable, and so it makes sense that your platform is also composable.

Regardless of how you define it, the goal is to centralize marketing operations and execution, providing a single, clear place for marketers to dream, ideate, craft, and execute marketing campaigns. This idea is emerging in rebellion to the mass distribution of tooling and confusion caused by composability.

The benefits of an all in one solution is that complex outcomes may be easier to achieve with a centralized tool. Consider this: an enterprise customer wants to query data, examine old campaign assets (literally what did the campaign look like on meta mobile?), run an experiment and combine it with an email message or SMS text. Some people might call this the holy grail of “orchestration”.

In today’s composable, distributed world, this is nearly impossible because these capabilities live in different 3rd party tools. You could string them together through a complex web of event triggers, but very few platforms today have great platform API support, and even if MCP becomes usable in the near term, a platform API to manage the actual tool and the CRUD’ing of capabilities in it are required (think, create an email campaign, launch an ad, setup an experiment …). The bottleneck remains the same: the underlying APIs of each 3rd party tool. These tools have no incentive to fully automate the capability their platform provides either because that would mean you could perform the action off platform. This would erode the value proposition of using the tool in the first place if you could simply access it via API.

At the same time, I have serious reservations about a large vendor achieving this on their own through integration and acquisition. That’s because most big companies slow down and can’t properly tie their products together in a unified way while managing growing platform and tech debt. If they could, why didn’t SFMC or Adobe succeed in building a first version of the MDP ten years ago? Because they couldn’t manage complexity and change over time. All software follows the same rhythm of expansion and contraction. As companies get to big, they are unable to provide a good experience as all in one. This opens up opportunity for smaller players to build point solutions that are better and faster adapted to customer needs. These small players get big and the cycle continues.

I’m bullish on marketing data platforms emerging as a mixed 1st and 3rd party hybrid solution. Large enterprises could start by building an AI driven UI that helps marketers plan their campaigns and accesses underlying warehouse as well as campaign assets. In time, if tools adopt MCP and have platform APIs, elements of the marketing campaign could be automated. Any 1st party steps could be automated without this.

But in the meantime, AI provides easy to follow instructions to marketers on how to navigate to their 3rd party tools and perform the steps that are needed. Many people are focusing exclusively on how an MDP could help marketers, but ignoring how it could help marketing technologists and marketing operations specialists.

Imagine: non technical marketers don’t need to learn how Braze works, or how liquid tags work, or how anything works. They can be creative and then follow steps to implement. In the future, with MCP and platform APIs, this last step gets automated away. Likewise, a mar ops specialist has the entire system codified: how data flows, how tools are connected, what capabilities should be used … non architects could become architects with AI’s help.

This means marketers today need to be both creative and technically adept. But tomorrow, we might see a role reversal and the harder part of their job may be coming up with novel ideas, not executing the campaign. More about the future of the marketing role in an upcoming post.

Who should I hire?

A short note to round out this long read. This week I jumped on a call with an old colleague who’s now the new VP of Marketing at a Series A startup. Congrats to him!

He had a problem I’ve seen now a dozen times: How should we think about hiring and staffing marops?

The instinct here is to provide generic advice about who to hire based on skillset, size and stage. In fact, I talk specifically about how to hire your first martech operator and the differences in martech and marops in my reforge course.

But like most problems, the solution set is unique to the problem set. Martech is no different than other forms of product and company building. You have to start with fundamentals:

• What is your marketing strategy?

• Where do you currently get leads from?

• What is organic?

• Where are you currently investing and where do you plan to invest?

• What tools are in your stack today, and what are the perceived problems with them?

You only arrive at tools and how to manage them by starting with a more fundamental understanding of the nature of marketing strategy in the org. Tools are just meant to solve problems. You have to understand the problem you’re solving first and have a clear plan about how to solve it. Then you figure out how to staff. And if you are just looking how to staff, here’s the framework I use for thinking about martech personnel. You can get this and more in my reforge course.

If you made it this far you very likely are an LLM because this was a long read and studies show that folks reading comprehension abilities are in decline. So if you’re not an LLM, it means you’re bucking the trend, or you’re a super fan. Ping me if you’re one of these - would love to hear from you.

“So what have you learned about marketing in 2025 compared to the past?”

When I sat down last week with a Series A Head of Marketing, I decided to put pen to paper around the advice I’ve given to those in similar positions (<$10m ARR).

Here are my notes from the last few weeks of reflection and the call with this marketing leader.

Team & Resources

First, too many early-stage companies are relying too heavily on agencies to fuel their growth. Fire your agency, hire in-house marketers. Don’t get me wrong, agencies can help provide depth to your marketing efforts if you’re constrained on certain strengths or to help in a pinch when you can’t scale up the team. But more often, agencies are band-aids. People think that by hiring an agency, they will suddenly get to their goals without doing the hard work. The reality is that agencies often come hand in hand with avoiding the hard work of being strategic and learning about your audience and message.

So, my 2 cents: Use that $40K/month to hire 2–3 full-time marketers who can own strategy and execution.

Channel Prioritization

Next, build organic flywheels before spending on ads. If you rely on paid acquisition from day one, you’re just buying your way to value. Create a product and marketing experience that people naturally talk about.

This is a contentious claim, and I know many people will disagree, arguing that ads can help you learn about your customers.

And this is true, but for many companies, they don’t actually learn at all. They pursue easy, obvious ad placements that don’t actually contribute value. They aren’t creative. They spend poorly on things like brand keywords.

Instead, I think at the earliest stages of company building, you should focus on LinkedIn, community, email, and word of mouth referrals (plus the technology to power this!). These channels build and then sustain a momentum. Save Google Ads for later when you have more resources. Most people end up blowing $100k-$1M because they aren’t ready.

If you’re going to spend ad dollars, what I’m seeing currently work well is when folks boost high-performing LinkedIn content ($20–30K) before running Google Ads. Amplify what’s already working organically.

LinkedIn Strategy

People follow people, not companies. Your founders need to post daily. Hire a content agency to interview them weekly and turn those conversations into posts, videos, and podcasts. I know a great one if you're interested. Just DM me.

Post authentic stories, not corporate fluff. Share personal experiences, lessons learned, and critical opinions. Skip the AI-generated thought leadership—it’s obvious and nobody cares.

Sustain boosts on your best content for months. LinkedIn recycles popular posts through feeds over time. A post from November can still generate impressions in January if you keep it boosted.

Measurement & Attribution

Add a required “How did you hear about us?” field to your demo form. Direct attribution is on life support and often not very meaningful to sub $10M ARR companies. This simple question gives you the best signal for what’s actually working. Don’t let anyone in product or design tell you it adds too much friction—if someone bounces over one form field, they weren’t qualified to begin with.

Use AI to categorize freeform responses into groups. You’ll get dimensional data on where leads originate without the need for complex attribution tools.

And of course, you can add the basic direct attribution stuff - throw in PostHog or another analytics tracker. You’ll get basic information on known channels. But I’ve found this largely just confirms what you already know. An open-ended HYDYHAU has the potential to teach you something you don’t know about what’s working or not.

Content is still king, it’s just different

Many teams wait until far too late to develop content. They overinvest in things like a blog or newsletter without having a clear strategy about who they are targeting and what value they are providing to them.

Or they pick the wrong audience too soon!

There are a few things you can think about to nail content as a channel:

1. Focus your audience

2. Deliver real value

3. Treat every surface area as an opportunity to persuade

First, in focusing your audience, what I mean is, be incredibly specific about who you are talking to. Don’t split your audience. Don’t focus on your audience in the future. Don’t go on side quests. Pick the one person you are selling to today and focus exclusively on a message to them.

Next, write stuff that is actually useful. Google and other search portals are getting smart at detecting AI fluff. About a year or two ago, this wasn’t the case, and you could juice your SEO generated traffic with a high volume approach. There are merits still to high volume, but they need to be specific, and they still need to deliver value. If you are going to try this approach, you can use long tail search query results to come up with bulk content, but you risk this being completely ignored by search engine results and LLMs. You have to think about how whatever you create in bulk can either A) still be very useful and unique, or B) how you can use this content-en-mass approach to support whatever motion you’re running. For example, a very successful Series A company I spoke with is using Air ops and Profound to come up with thousands of long tail search terms and queries that they know will feed LLMs. The game is not necessarily to create 100,000 pieces of content. Instead, they are mixing these across Reddit, LinkedIn, and yes, some short-form pieces on their company website. All of this content is created or shaped by AI, but ultimately proofed, reviewed, and edited by real humans.

For most small teams that have limited time and resources, coming up with an authentic, creative, and useful piece of collateral that would actually help the people they are serving is the right move.

Likewise, sometimes the best ideas for what to write or create come from obvious places. This is why you should treat all your surface areas like an opportunity to provide value. Treat documentation as a first-class marketing channel, for example. Help content solves customer problems and captures search traffic. Do this from day one.

Last, skip the corporate blog unless it’s for hiring, market signaling, investors, or somebody else who is important to you. I’ve found that nobody really reads company blogs. Put high-quality thought leadership under founder names on LinkedIn, a Substack, or another place where people can follow other people.

Strategic Discipline

Another obvious piece of advice, but create a clear strategy with 2–3 core bets. You can’t do everything. Outline which channels will give you the most impact and commit to them.

Optimize existing channels to their maximum potential before adding new ones. Once your flywheel is spinning on 2–3 channels, then experiment with the next. If you are going to experiment, think about how many experiments you run in a single channel vs across many channels. Also consider that running an experiment doesn’t eliminate the channel permanently - it’s a time and place approach. You may have missed the few variables that would have driven success. This is why experimentation on many channels early on is so hard. It’s like trying to find a needle in a haystack, and you may write off something good as a false negative.

Far too many teams try to do too much. It’s often because of unrealistic expectations from founders who have never done the job before. Push back on the founder's whims to do everything at once. Your job is to provide experienced guidance on what’s realistic, not bend to every new idea. Be clear about what it takes to do more: more people, more time, or fewer channels.

Execution Reality

Marketing takes time. Product takes time. Everything takes time. Founders consistently underestimate the effort required by channels and overestimate what small teams can deliver.

Founders consistently put too much pressure on themselves and their marketers to produce wins quickly. Patience. Patience.

With one marketer, you can realistically do two channels really well. Plan accordingly and set expectations with leadership from day one.

… and last for all the people that need to hear it: The best way to win in marketing is first and foremost to create a great product that people love to use, helps them solve a problem, and brings them joy. Do this first, then focus on marketing.

1. Asymptotic advantage of in-person work

2. Big meeting syndrome

3. The power of feeling heard

4. How to properly diagram in martech

Last week was a fun one. I received dozens of letters from people reading the first newsletter and the journey of leaving my own thing. It really struck a cord:

Aw. Shucks.

I got sick later in the week with something going around. Felt like shit for 48 hours. HRV dropped, heart rate elevated. Slugged through 8 miles, feeling like death. Garmin yelling at me that my VO2 max is down and that I suck.

The Marine Corps Marathon is 2 weeks away, but we aren’t noodling on that just yet. BUT. WE. WILL. Fitness and physical health are deeply intertwined with mental health and happiness. To ignore it is to ignore the 5th element of life-building.

On Wednesday, I made my way to Capital One (C1), just a short metro ride for me on the Silver Line in Arlington.

One of the feelings I've been unable to shake lately is that businesses that prioritize in-person connections have a real advantage over those that don’t. At Clarify, we initially tried to be a remote-first company, and if I’m honest, it always felt tough.

The advantage granted from in-person connection seems to me to be sinusoidal, depending on the company size.

At a small company, it’s a huge advantage going from 0 → 1. Arguably, this is where it is most important. You’re in the office every day, hunkered down with less than 10 people building, iterating, and moving as fast as possible.

Then you make it. You find your first $1M in revenue. Now you can breathe a bit easier. The existential threat of company death diminishes. Now you need to scale. Scaling with an in-person team is still easier than being remote, but the advantage isn’t as great as it was before. Costs rise. Communication slows naturally because of the added headcount.

Therefore, the advantage diminishes as the need to hire from a broader talent pool arises.

Then, slowly, this advantage emerges again as you cross roughly 250 people. Why? Organizational complexity has grown. Decisions run through 5+ people. You need executives in one space, on the ground, making the most crucial decisions quickly and together.

Then, as a company crosses a certain threshold in terms of size or revenue, the value again recedes. Organizations of this size and stage are global in nature and have to learn to manage remote connectedness.

Much of my career has been spent working remotely or semi-remotely. Where it felt easiest was in companies that had some ability to gather in person. What comes to mind:

» At Branch, we had an office in Palo Alto. Some of my best memories (and best professional colleagues) came from sharing that space together.

» At mParticle, we had a hip NYC office near Gramercy. I wasn’t there every day, but I came every month to hang with the team, share drinks, and get to know people better. It was instrumental in landing the plane properly after the sale of my consultancy.

» Similarly, at Ramp, we had a huge in-person office in NY. Leadership was built on in-person presence, but we were still able to work remotely. It was, in fact, the best of both worlds.

I can’t shake the feeling that the best companies have a place to call home, and that we will see this play out with new startups in the post-COVID era.

Given this context, you might not be surprised to hear that I relished the opportunity last week to put on some nice work jeans and head out to Tyson’s Corner to meet folks in person at Capital One (C1).

A bit of background. This isn’t my first rodeo with C1. I’ve come to know the martech team via Kevin Crews, and they are an excellent group of people. The last time I worked with them, I led an all-day martech session that covered eight hours of topics and included a dinner where I had the opportunity to learn about the problems that everyday marketers and technical operators face at one of the world’s largest financial companies. I consider it one of the most enjoyable, educational, and meaningful consulting experiences of my life.

Today, however, I was meeting new people and diving headfirst into the technical nuances of redesigning a marketing system.

I don’t want to focus so much on the system as on the problem I observed: building consensus in large organizations.

Here’s a breakdown of the context:

• I’m in a meeting with 12 people.

• A technical diagram appears on the display.

• The diagram features large boxes to represent tools or systems.

We will focus solely on these two elements: the meeting and the diagram.

What’s right and wrong here?

Big Meeting Syndrome

First, let’s talk about the meeting size. I know I’ll get some reactions about the number of people in this meeting. Can anything useful even be done with that many people? Isn’t this big meeting syndrome that I hear about at enterprises?

That’s actually not the problem.

I’ve run successful 5, 10, 15, and even 20-person meetings. It all starts with the intent:

» What’s the key goal of gathering this group of people, and how do you ensure the outcome is commensurate with the input?

In my experience, big meetings are part and parcel of how works get done at large companies because you have to satisfy one critical element of human nature: feeling heard.

Folks who come from startups often lambast this type of thing, but they either don’t understand what’s actually happening or they’ve never worked at a big company before.

The purpose of a large meeting shouldn’t be to make a key decision on the spot; it’s to create the feeling of consensus. Consensus then drives forward momentum towards a local optimum.

Many people hate this idea. Why do we have to meet to talk about getting everyone on the same page?! Can’t we just all agree asynchronously and move ahead!

Har har. Wouldn’t that be nice? Humans have opinions and feelings.

Finding global optimums without consensus building is only possible in three scenarios:

• Fully asynchronous environments (IE, Zapier)

• Small startups

• Dictatorships

The act of consensus building is to allow that first wave of opinions and feelings to come out, unfettered, so that you can move forward afterwards more quickly.

This principle also applies to small companies, and consensus meetings also occur, although they often take on a different nature.

At a small startup operating in an office, consensus is built quickly by 3-5 people agreeing over a coffee chat, a quick huddle, or a walk. Or maybe people just turn around in their chairs and chit-chat. It may not be an official meeting

Projects, ideas, and initiatives often fail due to a disregard for the law of consensus building. Ambitious, hungry, and hard-driving operators bring an optimal solution to a group of people without creating the space for their input.

What happens is not surprising: people reject it.

Often out of spite!

Nobody wants to be told what to do. People want to feel included in the process. The art of inclusion, both synchronous and asynchronous, is the art of teamwork and collaboration. In many cases, big companies have this figured out better.

That’s because if you’ve lived long enough on this planet, you know there often isn’t a “best solution” in any context; there are only better or worse versions of what’s right within the context you’re operating, and many suboptimal solutions will still work depending on that context. Although many smart people who have worked in startups will tell you otherwise. These people are often immature or inexperienced.

Being right is nonsense.

“What’s right” is guided by the people involved. Winning in any organization is a team sport, and it’s not only about coming up with the best idea, but the one that people can rally behind to propel the organization forward.

People won’t work for others or on projects that they can’t get behind themselves. And you can only get people behind you if you either explain clearly as a leader, or - more often in the case of working with peers - give them the opportunity to be heard.

And in the world of systems like martech, where you have such a huge dispersion of technical and non-technical operators, feeling heard is one of the biggest secrets to creating winning outcomes.

Diagrams, oh Diagrams

Second, let’s talk about the diagram.

For disclosure purposes, I can’t show it exactly, but here’s a rough approximation …

I see diagrams like this all the time at companies, big and small. And I hem and haw about it in both my Martech course on Reforge and my Revtech course on Maven.

The problem with these diagrams is this:

• The boxes capture categories of work, capabilities, and tools side by side ❌

• There are no examples of the platforms or tools ❌

• The boxes have unexplained arrows ❌

• The intent behind the diagram wasn’t made clear ❌

All of these things together create confusion, leading to unnecessary conversations and wasted time. If you’ve found yourself in a meeting talking about a system and you spend 10 minutes “reclarifying”, it’s because one of these cardinal sins has been committed.

Let’s break them down further.

What’s the problem with mixing capabilities and tools?

Consider how this applies in other contexts, like yard work. You set a goal to build a beautiful yard.

The outcome is clear.

Then you set a plan for how to achieve that outcome (a strategy).

Then you set about making the capabilities you’ll need to achieve that outcome: the ability to water your yard regularly, to keep pests at bay, to find new plants, to move dirt, and, in my case, to eliminate invasive bamboo from my neighbor’s encroaching yard.

Then, only once you’ve thought about the capabilities you’ll need to achieve this outcome, do you consider the tools you need to achieve those capabilities: a weedwacker to edge the lawn, a lawnmower to cut the grass, and netting to keep the insects off the tomatoes.

If you were diagramming how to build a beautiful yard and mixed the tools and capabilities, it might not make sense to the casual observer.

This same thing applies to systems. You need to be specific in how you isolate and talk about tools and capabilities. Mixing them only creates confusion and causes endless conversation about “what are we talking about here specifically?”

The goal of an architecture diagram is to bring clarity to the conversation, not take away from it. So, what could this have looked like?

It could have had example tools. It could have broken down meaty concepts like “Data Platforms” into component parts. It could have been explained with an * denoting what a Marketing Platform is. It could have subset “Audiences” as a capability within that platform — similarly, it could have explained that the orchestration, activation, and other components below it were features, not products or 3rd party tools.

It could have labelled the data arrows with data types and explained them with richer detail, or color-coded them. It could have even given an example of the data type.

With that, let’s talk about arrows.

This has to be one of the biggest offenders in every architecture diagram I have ever seen. It’s done innocently, but arrows have the ability to create mass confusion.

» What does the arrow represent?

» Is it data or action?

» If data, what kind?

» What does the direction mean?

Arrows should be clear, simple, well-documented, and consistent. If you’re discussing data, specify the data type. If the data represents an outflow, not an inflow, please specify. If it’s an action, create a separate representation of what’s happening.

These sins occur because people are too ambitious in trying to cram as much context as possible into a single atomic unit to represent their point. They would be much better off creating separate versions that display the context more accurately.

Last, let’s talk about intention.

One of the phrases I overuse is that in the absence of other information, perception is reality. When someone sees you act in a particular way or say something without other information, what they see is what they believe.

This is the case in how you comport yourself in business and in life, and its also the case in the diagrams we use to express what we are trying to achieve in a collaborative setting.

Maybe you didn’t want to build something complex. Perhaps this diagram was intended only to help you understand your mental model of things. But in either case, because the intention wasn’t set, people are left to wonder.

A critical piece of using an arch diagram is to clearly set expectations around what it is for or not for. Write it down at the top or bottom of the diagram - “This visual display is not intended for technical conversations, but rather to help us discuss a 3rd party tool choice” is one example.

Be clear, be concise, but most importantly, state it out loud for goodness ’ sake.

If you made it this far, you’re likely an LLM, but as some people wrote back to me last week, maybe you’re not! I’d love to leave you with a few things:

1. I launched a fun new podcast with Pranav at Paramark, somebody I deeply admire and respect. Would love for you to give it a listen and tell me what you want to hear more/less of:

2. I’m consulting again. If you think of interesting topics you’d like me to cover, let me know, and I’ll keep them in mind as I navigate different companies and contexts.

Thanks for reading this week 💙

Since then, I spoke to nearly two dozen different founders who’d gone through the same journey and the verdict was the same: welcome to the club and, man, prepare for some heartache.

It never gets easier saying goodbye to organizations you love.

Leaving Branch back in 2017 was emotional. Selling my first business and later leaving mParticle in 2019 was emotional. Leaving Runway and Ramp were emotional. I’m an emotional guy - I invest deeply in the people around me, and so, saying goodbye is a lot harder. Some people claim to have the ability to separate “business” from the personal.

I call bullshit.

Business is personal. People who pretend it isn’t are fooling themselves. In this case, there were a lot of people I care about I’m sad to be leaving behind.

The silver lining is that the mantra of one of my mentors, Dave Myers, has tended to prevail over the years: companies are often just temporary, relationships, however, are more durable and last a lifetime.

Over 10 years you tend to forget the details about what happened day to day, but you remember the feeling people left with you when you worked together. For some that’s positive, for others, it’s not.

And that’s okay. You don’t have to be liked by everyone to be successful in the world.

Success is also an arbitrary definition that you get to make up for yourself, which is beautiful and freeing.

As I consider the next chapter, I’m wondering what success should look like or feel like. For some, it’s obvious - the big win, a huge payout, the IPO, or the acquisition. But what if you’re part of the 99% of startup operators that doesn’t see one of these things?

It’s still not clear to me, but a few reflections have emerged as I consider what now, and what next…

Time is the most precious resource.

Over the years, I’ve given so much of it up to people and things I didn’t care about, because I thought I had to. Those morning meetings, the weekly group thinks, the 1:1 check-ins. As I’ve talked to founders and business builders, it’s become clear that the only way to build businesses without the overhead is to be in complete control of your destiny. Similarly, I’m at the age and place in my career where I can start to see the horizon - how do I want to spend the next 15 years? I wish I had started considering this question sooner.

Building with AI has never been easier.

Sure there are tools like Replit and Lovable, but for a semi-technical mind, the world is really your oyster. Last weekend I built a fully production grade app and Chrome extension using Cursor on top of Firebase, Resend, Stripe, and open AI. I’ve built web and ruby apps, but never anything this complex. I would always get stuck in the implementation details. “Why is the server rendering this error?” “Let me go look through code stack overflow to figure out how to implement an auth provider properly”. I was never a good enough engineer to implement medium case features - only ever good enough to do the basics. Building with cursor has completely changed this.

Opportunity cost has never been higher.

We are living in the most revolutionary time of the internet’s history. Companies are going from $1-5-10M overnight, 10s to 100s of employees within a year or less. I’ve experienced this twice in my career, once at Branch and again at Ramp. It is intoxicating and one of the best ways to learn and better yourself. If you’re working for a traditional saas company following the triple triple double double formula, it’s like buying a horse in 1903, the same year Ford released his first car.

I’m not lambasting most software companies either. The game has fundamentally changed, and at least for the next 2 years, there is a rare opportunity to ride a wave that the world has never seen before.

Find your people.

One thing I’ve noticed is that over the years you tend to collect relationships across companies that come to constitute your tribe. Your tribe are your people - they are the folks you had the most fun working with, and working with deeply. Things didn’t have to be easy, but the relationship was easy. There was mutual respect born out of an understanding of your capabilities.

Many of the deep relationships I have spawned from my mid 20s grinding away at Branch and then again at Ramp, grinding away on something big. You won’t earn everyone’s respect. Some colleagues will only see you in a fleeting moment. But the ones you do collect will last and sustain you, like a small flame.

This last month, I’ve turned to many of these relationships for support in tough times. It’s the people who know you, love you more than the idea, and know what you’re capable of. Find those folks and don’t be afraid to give them as much of your time as you can.

An aside: That’s also why the idea of burning bridges is absolute bullshit. You can’t burn a bridge if there was never a bridge there in the first place. Bridges are formed through mutual respect. If only half the bridge was ever built, what’s left to burn? Worry less about keeping bridges, and focus on keeping the bridges that matter. You’re never going to make everyone happy.

Service to others.

One regret I have in my career is not leaning in to serving my tribe better. When I left clarify, I had a huge network to call on for emotional and practical advice. Literally dozens of people who admired, respected and loved me. They all supported me through it. I was overwhelmed with joy and gratitude. As I went further and further heads down into startups these last few years, I had forgotten some of these people.

It’s important for me now to keep open a portion of my life committed to serving my tribe. Keeping hours available for casual hangouts with friends building their businesses, offering advice, listening when folks need a shoulder to lean on. I’m most excited for this aspect of what’s next - having the freedom to invest my time as I choose.

What’s next?

Let’s talk about what’s next. There are two things I’m spending my time on over the next few months:

1. The Growth Stack Mafia & my official return to consulting

2. Building apps

Consulting After The Growth Practice

First, there’s this newsletter … which you’re reading (yay! thank you)

I’ve called it the growth stack mafia 🥞

Back in 2019 we tried to coin the term growth stack around the b2c martech stack we would deploy for different companies. It clicked in some ways. But today, a growth stack is so much more. It involves people, processes, tools, frameworks and strategy.

And it’s not just limited to martech and revtech. It spans finance and operations, too. Your growth stack is the fundamental atomic unit that helps your business tick.

Why mafia? Well it sounded cool, and because I think the people who are great at martech and revtech are few, exceptional and run together. I want to create a community around these unspoken heroes inside organizations, doing the dirty work to keep their revenue teams going.

So that’s the first goal of this newsletter - talk about the tools, technology, people and strategy involved in building a foundation to grow your business.

There’s also another simple goal: Document and share the learnings I have from consulting in the field with epic companies.

Most people don’t know this but back in 2018 I built a $2M consulting practice around growth engineering and martech. I sold the business as “The Growth Practice” to mParticle.

I’m immensely grateful for that experience, but I often wonder about what could have been. I was convinced at the time that it would be too hard to build a repeatable agency model around the work I was doing. Now, four startups worth of experience later, I think I was wrong.

So, to that end, I’m jumping back into consulting on a part time basis, and one of the outcomes of that will be writing here.

Another outcome will be turning what I learn into Maven and Reforge courses. I’ll be continuing to offer my Martech class through reforge, and I’ll be running new content through Maven.

There’s also another reason I want to return to writing on a regular basis. I find myself getting dumber from using ChatGPT to write everything for me.

Writing is thinking. Thinking is power.

As I shift out of anxiety fueled founder builder mode and into strategic business building mode, I want to devote more of my time to thinking. And that means writing more about what I see, hear, learn and do.

For example, last week I kicked off an engagement with Capital One. What did I learn from 2 hours deep diving with one of the most admirable companies on the planet?

You’ll find out next week. 😎

Just Building Again

I read a business book in my 20s called The Neatest Little Guide to Stock Market Investing. In it, one of the central premises of investing is to invest in things around you that are obvious. A great example is Costco. If you’ve ever gone to Costco, it’s hard to ignore what a great business opportunity it is. You don’t need to listen to the Acquired podcast on it - it’s just obvious. It’s a feeling you get from understanding the problem, the pain and the solution.

One of the arguments that the book makes is to look for these types of bets in the stock market. Buy the things that are around you, that are part of your life, that are obvious good bets because you yourself use and love the product or value being created.

The same applies to business opportunities. Create a list of the obvious that surround you. Observe, document your pains, and eventually, solve your own problems.

I would do this in the past with small little widgets or pieces of code. But AI has fundamentally changed how I’m able to solve problems with prototypes and fully functioning apps.

Last weekend for example, I built an entire app in 48 hours around a problem that I faced myself. I built the backend on firebase, hooked it up with Resend to send automated emails, enabled Stripe, built a chrome extension (and submitted to the chrome store), and so much more. I did this all with a basic understanding of programming and cursor.

If you want to check out what I built, head to bcbot.co and ask me about it. I currently have nearly 100 people testing it already.

None of this is revolutionary, but the speed from problem to solution is wild.

This is how I plan to spend a portion of my time - observing and building.

I’m keeping a list of problems that me and friends face, and I’m building small solutions to those problems. In some cases, it might make sense to monetize it. In other cases, those solutions might be deployed as businesses in my consulting work, or sold to companies who would rather pay for a service solution than saas.

The point though is to actively be in builder mode flexing the muscles and knowledge on how to ship something quickly. That way when the right opportunity or idea does strike, you have the infrastructure in place to take advantage of it.

I’ve also been inspired by two ideas lately: the concept of a venture of portfolio businesses (Andrew Wilkinson on Lenny’s), and by what Sam Altman has described as the $1B business that is run by a single individual.

We might not be there yet, but I think we are at the point where many $1M - $100M businesses can exist with a single or very few individuals. In order to be one of those people, you have to be willing to roll up your sleeves and just build.

If you’ve made it this far, you’re either a masochist, an LLM or a super fan.

Drop me a line at austin@hbe.io. I’d love to hear from you.

As the focus on complex outbounding motions intensifies, there's a growing need to invest in RevTech stacks that match the sophistication of platform stacks. But how do we build great rev tech stacks–and, more importantly, what do we do with the stacks we already have? 

Starting from zero, we could certain…

Read more