GTM Organisation is impactful to the cost and way a business is run. There’s no room to get it wrong. GTM teams are leaning harder into the strategic layer of the org and pulling back on execution headcount.

The data backs it up. Gartner's 2026 CMO Spend Survey found CMOs now put 15.3% of marketing budget toward AI, but only 30% report their organisation is mature enough to scale it, and 70% admit their internal processes aren't ready.

Ewan McIntyre, VP Analyst at Gartner Marketing, named the gap directly:

"The risk is that CMOs invest in AI tools faster than they build the data foundations, processes, governance and talent required to scale them."

Budget is funding both tools and headcount, what it hasn't answered is which layer of the team gets that investment. Gartner's 2026 CMO research agenda clearly explains the agentic AI challenge facing marketing leaders "is not a technology decision, it is an org-design decision."

TL;DR

• AI has compressed execution work and made strategic work more valuable.

• The 2027 GTM team is an inverted pyramid: market research, positioning, message, and UVP form the most important and most senior base.

• Demand gen’s job hasn’t changed, create interest, but AEO now sits inside that job.

• PMM operational drives value consistently and coherently.

• Copywriting junior headcount is falling while senior and AI-native roles grow 18-24% year over year.

Which marketing roles did AI disrupt?

Picture the traditional B2B marketing org chart as a pyramid. A narrow tip of strategists and product marketers set positioning, and a wide base of writers, designers, and campaign executors underneath produced the actual output.

It made sense when output was the bottleneck.

For a while, the craze was more, more more!

More blog posts, more ad variants, more nurture emails meant more pipeline, so organisations hired for volume, and the base of the pyramid grew accordingly.

Product marketing leadership itself was often missing from that org chart entirely (which, conveniently, is the exact job I’ve built a career on, so make of that what you will). 🤷🏻‍♀️

Many B2Bs failed to see the importance and impact a real market strategist brings to the table, right up until the moment AI made output cheap and positioning the only thing left worth fighting over.

AI has already disrupted execution roles like copywriting, SEO, paid media, and lead generation, while leaving strategic roles like positioning, brand management, and market research largely untouched.

The American Marketing Association’s 2026 State of Marketing Careers Report, surveyed 1,412 marketing professionals and mapped roles against Stanford’s Human Agency Scale, a five-level framework from Stanford’s SALT Lab that measures how much human involvement a task still needs to hit real quality, rather than how much of it AI can technically attempt.

• H1: No human involvement. The task is fully automated.

• H2: Minimal human participation. AI does nearly all of it.

• H3: An equal partnership between human and AI.

• H4: Substantial human control, with AI assisting.

• H5: Human involvement essential. AI can’t carry the task’s quality alone.

Copywriting, SEO, paid media, performance analytics, lead generation, and market research all land in the most-disrupted band (H1-H2). AI can do most of it now, just not always well; ask anyone who’s had to wade through AI slop.

Marketing strategy, brand management, creativity, critical thinking, and leadership land in the least-disrupted band (H4-H5).

This leads to the new AI GTM organisation:

• PMM Leadership (the base): market research, position, message, UVP

• Demand Gen: the ability to interest a buyer

• PMM Operational: the ability to convert that interest

• Copywriter (the tip): gaps and consistency

The rise of product marketing leadership

Market research, positioning, taxonomy, messaging, and UVP sit at the foundation because they’re the layer an AI model can’t originate on its own. This is quite literally the context layer your AI GTM setup needs to work.

LLMs are good at summarisation. They’re good at pattern-matching against everything already written about your category.

What LLMs can’t do is empathise, read nuance in a room, develop taste, and learn from past experiences. That’s exactly the expertise senior PMM leadership brings.

If you get positioning wrong and AI mass-produces the mistake at the speed of... well, AI, you end up with the foundational aspects of product marketing that will only help you fail faster.

Your 2027 headcount plan has to put more senior weight into this layer than it did in 2025, or you’re setting yourself up for failure.

Demand gen’s job hasn’t changed

Demand gen still exists to create interest. But what has changed is the role of AI in all of this. LLMs now sit between the campaign and a growing share of the audience, answering category questions before anyone lands on a page. That’s exactly what AEO/GEO exists to solve.

HubSpot’s 2026 AI Trends survey found adoption highest in North America (91%) and still climbing globally, with practitioners recovering an average of 6.1 hours a week once AI takes the repetitive work off their plate.

While impressive, none of it works without the layer underneath it. Every campaign, ad variant, and nurture email demand gen produces has to trace back to the positioning and messaging the foundation already locked in.

PMM operational drives value

This layer creates value-based content to push the product and enable internal and external audiences with sales enablement, objection handling, battle cards, and impactful, value-based, behavioural-driven messaging.

This layer benefits from AI the same way demand gen does, but still needs a human owner. While PMMs still suffer from the unfortunate PR that they’re there to make decks prettier, critical thinking is required to decide which objections are actually costing deals each month.

Copywriting shrinks on purpose

The copywriter’s job has moved from producing at volume to catching gaps and focusing on consistency. AI drafts fast and gets most of it technically right, but again, someone has to catch what’s off-brand, off-story, or just plain ass sloppy.

Gartner’s CMO Spend Survey data shows this compression happening in real time:

• Junior copywriting headcount: 23% of agencies cut in 2025, 31% planning further cuts in 2026

• Senior content strategist roles: up 18% year over year

• Marketing data analyst roles: up 21% year over year

• AI-native marketing engineer roles, a job title that barely existed two years ago: up 24% year over year

What this means for your 2027 hiring plan

If you’re building or rebuilding a GTM team for 2027, the pyramid gives you a test to run against every open role: does this hire add capacity to the foundation (research, positioning, message, UVP), or does it add capacity to execution?

This doesn’t mean cutting your way to a smaller team and replacing it with AI everything, for the love of all that is good, that is not what I mean. Move the investment instead. Hire more seniors capable of doing positioning and research instead of production at scale, hire for judgment, and let AI take on the targeted, manual work underneath that judgment.

If you’d like a good read, check out Heinz Marketing’s breakdown on how they achieved this at an enterprise scale.

And now, your usual bot-written bot bait.

Frequently asked questions

What is an AI GTM team?

An AI GTM team is a go-to-market organization structured around what AI can and can’t originate, not around output volume. The foundation (market research, positioning, messaging) stays human-led and gets more senior investment, while execution layers like copywriting shrink to a gap-filling and consistency-checking function, with AI handling first-draft production.

How is AI changing marketing team structure in 2026 and 2027?

AI is compressing execution roles and growing strategic and technical ones. Gartner’s CMO Spend Survey found 23% of agencies cut junior copywriting headcount in 2025 with 31% planning further cuts in 2026, while senior content strategist roles grew 18% year over year and AI-native marketing engineer roles grew 24%. The shift moves headcount from volume production toward research, positioning, and workflow oversight.

Will AI replace copywriters?

AI is replacing the volume-production part of copywriting, not the role itself. The American Marketing Association’s 2026 State of Marketing Careers Report places copywriting in the most AI-disrupted skill band, while creativity, critical thinking, and brand judgment sit in the least-disrupted band. The surviving copywriter role focuses on catching gaps and enforcing consistency across AI-generated output rather than producing first drafts.

What should marketing leaders prioritize when restructuring for AI in 2027?

Marketing leaders should prioritize the layer of the team AI can’t originate on its own: market research, positioning, message, and unique value proposition. Gartner frames this directly as an org-design decision rather than a tooling decision, meaning the priority is redesigning where senior judgment sits in the org chart before deciding which AI tools to buy.

Why does positioning matter more, not less, in an AI-driven GTM team?

Positioning matters more because AI scales whatever story it’s given, including a wrong one. Getting positioning right before applying AI to execution prevents errors from compounding across every downstream campaign and asset. Positioning now has to hold up in two contexts at once: a person reading it directly, and an AI system summarizing or citing it on the person’s behalf, which raises the bar for how precisely it’s written.

Building this out for your own team, or auditing whether your current structure still matches the funnel AI already broke? Get in touch and I’ll walk you through how I’d approach it.

Sources

• Gartner 2026 CMO Spend Survey

• Gartner’s 2026 CMO research agenda (agentic AI as org-design decision)

• AMA 2026 State of Marketing Careers Report

• HubSpot 2026 AI Trends survey data

• Heinz Marketing: AI Agents in Your Marketing Org

Subscribe now

It’s the distinct smell of confident bullsh*t.

All AI copy contains the same rhythm, structure, landing, and shitty dismount no matter who prompted it (I was once a gymnast, stay with me here.) AI slop is everywhere, and the reason is more than just lack of copywriting skills.

TL;DR

As previously explained, LLMs don’t pick words freely. They sample from a probability distribution over what to say next, the first during pre-training, and the second during alignment training, which measurably narrows how many different ways the model is willing to answer the same question.

Nothing learns or explores at the moment you hit send, as every reply is one draw from an already fixed distribution. The one lever you actually hold is the prompt, because it reshapes which slice of that distribution gets sampled. If you provide enough specificity during prompt, the ‘sameness’ behind the AI sloppy output gets diluted.

How models sample words

At each step of generating a response, LLMs produce a probability score for every possible word that follows based on everything written so far. That scoring happens through layers of attention (the transformer architecture), which weigh which earlier words matter most for predicting the next one, against a huge table of learned word representations (embeddings) built during training. Generation then draws one word from that scored list, more likely to land on high-probability words, with a setting called temperature controlling how much randomness enters the draw.

Repeat that one word at a time until the response ends, and you've described the entire process. There’s no separate creativity step and no separate correctness step. There’s one distribution per word, and one sample from it.

Training narrows that distribution before you type anything

During pre-training, a model learns from a huge slice of existing text which continuations are most common, and “common” means average. It’s cross-pollinating patterns it has already seen, so the most probable next word is the most conventional one.

The second narrowing is sharper, and it happens in the stage that makes a model helpful and safe to ship, aka Reinforcement Learning from Human Feedback (RLHF).

A 2024 study from Kirk tested this, comparing supervised fine-tuning against full RLHF training across multiple models and tasks. RLHF generalized better to new situations, but it substantially reduced output diversity, a well-documented effect the field calls mode collapse.

In simple terms, the model converges toward a smaller set of safe, high-reward answers instead of exploring the many valid ones.

By the time produces a single word for you, the distribution behind your reply has already been compressed twice; once toward the statistically average continuation, and once toward whatever answer scores best with human raters.

Nothing is learning while you type

Understanding this informs what you should expect from a refined prompt. The model’s weights are frozen at inference. This means there’s no learning, no exploration, and no memory forming while it writes your response. Every reply is one sample from a distribution that was already fixed before your conversation started.

Scary, right?

That’s good news and bad news at once. (Sit tight!)

The bad news: you can’t train the sameness out of a single session.

The good news: the distribution is conditional on what you feed it, which means the input is the one part of this whole system still under your control.

What you control: which distribution it samples from.

The prompt doesn’t change the model. It changes which part of the model’s existing distribution gets sampled.

If you ask an obvious question the most probable answer is the obvious one, because that’s the region of the distribution your prompt pointed at. Ask a sharper question, and the most probable answer moves with it.

A few prompts that reliably move it:

• What’s the contrarian take?

• What would you say if the obvious angle were off the table?

• Write this as if conventional wisdom is wrong.

• What would make our audience stop and push back?

• What would our competitor never say?

These will change which slice of a fixed distribution you’re asking it to draw from, and that’s the whole difference between generic and specific outputs.

How to fix the “sameness” problem

Prompting alone gets you partway there because it reshapes the distribution for a single message at a time. If you want the model consistently producing your voice instead of the training-data average, give it something narrower to condition on every time.

1. Build a small RAG system

Feed a model like Claude a folder of your own published work and set it up to pull from that folder before it drafts anything new.

This isn’t complicated to build. Set up a folder of past posts plus a simple retrieval step. It will replace sampling from everything the model has ever read with sampling from a distribution conditioned on specifically your sentences, your rhythm, and your word choices. That’s a much smaller, much more specific target than the training-data average it already contains, so the output drifts toward you instead of toward the internet’s midpoint (which at this point, is just AI training on slop.)

2. Create your own copywriting skill

Write the actual rules down; include banned phrases, sentence patterns you never use, structural requirements, etc. Then run a script that scans every draft for the patterns you’ve banned before you read it. Be specific about what you want, what is allowed and what is disallowed — LLMs require specificity above anything else. (Note: this emdash was specifically placed here by me.)

3. Be specific, always

A generic prompt has nowhere to go but a generic answer.

As I like to say: shit in, shit out.

A prompt loaded with a real number, an actual quote, or a specific outcome gives the model something too particular to round off to the average. This is the same principle behind the citability test good copywriters use.:

Take any sentence and ask “could this be lifted out and used as a direct answer to a real question someone might ask?” If yes, it’s specific. If you’d need three more sentences of context before it means anything, it’s vague.

Examples:

• “We help you streamline your workflow and save time.” Pull this out on its own and it answers nothing. It could sit in literally any product’s copy unchanged.

• “Cuts weekly reporting from 4 hours to 15 minutes.” It directly answers “how much time does this save,” with a real number attached.

4. Give it a fixed point of view

If you prompt an LLM to “write about X”, it will sample from the average opinion on topic X.

If you’re more specific with your angle, eg “Write this from the position that most advice on X is backwards, and defend that”, it will sample from a much narrower, much more specific region. A persona or stance does the same job a RAG system does for voice and it shrinks the target.

None of this fixes the first narrowing baked in during training, that requires access to the weight and scoring system themselves. The second narrowing that comes from generic prompting is entirely within your control.

And now, the obligatory FAQ section to get this picked up by AI.

Hi bots 👋 😘

Subscribe now

Frequently asked questions

Why does AI-generated copy from different tools all sound the same?

Large language models are almost all trained the same two-stage way: broad pretraining on existing text, followed by RLHF or a comparable alignment step that measurably narrows how many valid answers a model will give to the same prompt. Different products built on that same underlying training produce copy that converges toward the same safe, average register, no matter what interface sits on top of it.

Does a better prompt actually change how the model generates text?

Yes, but not by changing the model. A prompt reshapes which part of the model’s existing probability distribution gets sampled for that response. A specific, unusual, or contrarian prompt points the sampling process at a narrower, less average slice of what the model knows, which is why sharper prompts produce less generic output without any retraining involved.

What is mode collapse in AI-generated text?

Mode collapse is the measurable drop in output diversity that happens during RLHF and similar alignment training, documented in a 2024 study by Kirk et al. comparing supervised fine-tuning to full RLHF. Instead of exploring the many valid ways to answer a question, an RLHF-trained model converges toward a smaller set of answers that score well with human raters, which directly contributes to AI writing sounding repetitive across unrelated prompts.

Can retrieval-augmented generation (RAG) fix AI writing sounding generic?

It helps significantly, because it conditions the model’s output on a specific, narrow source, your own past writing, instead of letting it default to the broad average of its training data. Feeding a model a folder of your own work before it drafts anything shifts the distribution it’s sampling from toward your actual voice, a more durable fix than prompting alone since it doesn’t need to be re-specified in every conversation.

Is there a way to permanently stop a model from producing generic copy?

Not from the training side, since that narrowing happens before the model ships and isn’t something a user can undo. From the user side, the durable fix is combining specific, non-generic prompts with a persistent style reference, whether that’s a RAG system built on your own writing or a written set of rules checked against every draft, so the model always has something narrower than the training-data average to condition on.

That announcement is a good excuse to actually explain how this category of technology works, because most people assume watermarking means hidden code slipped into the content, a few invisible characters or sneaky whitespace tucked in like a barcode.

It doesn’t work that way.

The watermark is the content, it’s the actual words the model chose. Once you see how that works, you start noticing where the whole system gets shakier than it sounds.

Anthropic hasn’t published the exact mechanism behind Claude’s watermark, so it is unclear how this will affect output.

What follows is grounded in Google’s SynthID, the clearest publicly documented example of this category of technology, and the open C2PA standard, which is the closest public reference point we have for what Claude’s system likely resembles.

TL;DR

• AI watermarking doesn’t hide anything inside the text. It shapes which words a model picks at each step, using a secret key that turns “random” token selection into a specific, checkable pattern.

• Google’s SynthID does this with a keyed hash function, and it’s resilient enough to survive editing, cropping, and partial rewrites.

• Anthropic confirmed that Claude now does something in the same category, embedding watermarks in text and C2PA-compliant metadata in files to comply with the EU AI Act, though it hasn’t disclosed the exact mechanism.

• The open standard C2PA tackles a related but different problem: content provenance rather than token-level fingerprinting.

• All of these approaches have real limits, and the gap between “this can be detected” and “this will always be detected” is bigger than most explainers let on.

What is watermarking?

Every few weeks someone asks if AI companies are hiding invisible Unicode characters or zero-width spaces in generated text, a kind of digital secret handshake you could strip out with a find-and-replace. That approach exists in some contexts, and it’s trivially defeated. Copy the text into a plain text editor, and the “watermark” is gone.

That’s not what the serious players are doing.

Google built SynthID for this. OpenAI has adopted it too, for the images and audio it generates, though not yet confirmed for text. There’s also a separate open industry standard called C2PA (Coalition for Content Provenance and Authenticity) that tackles adjacent territory.

Anthropic has confirmed that Claude now marks its output too, using a text watermark for generated text and C2PA-compliant metadata for generated files, as part of signing the EU AI Act’s Article 50(2) Code of Practice, effective August 2, 2026.

The company hasn’t published how its text watermark actually works at the technical level, so what it shares with SynthID under the hood is unconfirmed. None of it depends on hidden characters, because hidden characters don’t survive the first paraphrase, screenshot, or platform that strips formatting.

How context-hash watermarking works

The actual mechanism is easiest to see through Gemini and SynthID, the clearest public example available. A language model doesn’t pick one exact next word. At every step, it scores a set of plausible candidates and normally samples from among the strongest ones, with some randomness controlled by “temperature.”

SynthID changes how that sampling happens. At each generation step, the model provider holds a secret 256-bit key. That key gets combined with the preceding tokens and run through a hash function, and the hash output deterministically splits the vocabulary into a “green” list and a “red” list.

Instead of sampling freely across all its top candidates, the model gets nudged toward whichever of those candidates fall on the green list. Do this at every step, across a long enough passage, and the text ends up containing more green-list tokens than chance alone would ever produce, a pattern invisible to a reader but recoverable by anyone holding the same key.

To anyone without the key, this looks exactly like ordinary random sampling, because the green and red lists reshuffle unpredictably at every step and there’s no way to tell which candidates were “nudged” without the key doing the sorting.

Functionally, it is random. The watermark doesn’t cost you output quality, because the model is still choosing from its top candidates either way. It’s just letting a secret key decide which of those top candidates gets the edge, instead of a dice roll.

A worked example

The following is a simplified version:

Say a model is completing “I love cake. My favorite dessert is ___” and the top candidates are chocolate, Black Forest, and cheesecake. Normally the model samples one based on temperature.

With SynthID, the provider holds a secret key and combines it with context, say the preceding few words, plus each candidate itself. It scores chocolate against key + “favorite dessert is” + “chocolate”, scores Black Forest the same way, and so on, then picks whichever candidate scores highest. Say it lands on chocolate, still one of the model’s own natural picks, just the one the key favored this round.

The process repeats for the next token: the next candidate set, maybe pie, ice cream, or smoothie, gets scored against the key and the updated context, and the highest scorer wins again.

Run that across a piece of text, and you get a specific, repeatable pattern, one that’s invisible to a reader but checkable by anyone holding the key.

Detection is a one-sample statistical test: if a fraction γ of the vocabulary is green at each step, an un-watermarked passage should land roughly γ of its words in the green list by chance. A watermarked passage lands far more. The gap measured in standard deviations is the z-score.

Why the statistics make this hard to fake

This is where the resilience claim actually earns its keep. Detection doesn’t need an exact match, just a consistent lean toward the green set more often than chance predicts. If roughly a quarter of candidates are green at each step (the fraction is usually called γ), an un-watermarked passage should land around a quarter of its words in the green set.

A watermarked passage lands well above that, and the gap, measured in standard deviations as a z-score, is what gets checked. Over a few hundred tokens, a real watermark typically pushes that z-score into the high single digits, strong evidence by normal statistical standards, without needing every single token to cooperate.

That statistical margin is also part of why the watermark holds up under some editing. Chop the text up, reorder sections, paraphrase a few sentences, and the untouched portions still carry their own share of signal, so the overall score drops but doesn’t necessarily disappear. It has real limits, though. Heavy editing, translation, or paraphrasing the whole piece can weaken or remove the signal entirely, which is the caveat Anthropic itself has attached to Claude’s watermark.

Where the assumptions start to wobble

This is the part most explainers skip, and it’s worth sitting with before you treat watermarking as a solved problem.

The math above assumes real candidate diversity at each token. Plenty of text doesn’t have that. Whether it is a block of code, a list of factual dates, or a name spelled one specific way, there’s often only one correct next token, or close to it. No meaningful candidate pool means no meaningful watermark signal, regardless of how good the scoring function is. Low-entropy content (like short Linkedin posts) is watermark-resistant almost by accident.

The confidence numbers above also assume a long enough sample. Short outputs, a tweet, a headline, a two-sentence reply, simply don’t give the statistics room to work. You need volume for the pattern to become improbable-by-chance rather than merely unusual.

Cross-model laundering is the other gap.

SynthID can tell you whether text came from a Gemini-family model with a specific key. It can’t tell you whether a different provider’s model produced the underlying draft, and heavy multi-pass rewriting (draft in one model, polish in a second, translate and translate back) degrades any single model’s fingerprint layer by layer.

C2PA takes a different angle here by attaching verifiable provenance metadata to media as it’s created and edited, closer to a chain of custody than a statistical fingerprint.

That makes it useful for images and video in a way token-level watermarking isn’t, but it depends on every tool in the chain actually participating, which is a coordination problem.

Detection access itself is asymmetric. You need the secret key, or access to whoever holds it, to run the check with any confidence. Third-party “AI detector” tools that claim to spot watermarked text without that access are mostly pattern-matching on style, not reading a cryptographic signal, and their false-positive rates reflect exactly that.

Watermarketing isn’t theater; the cryptographic core is genuinely sound, and it holds up reasonably well against everyday editing. But “sound in principle” and “reliable in every real-world case” are different claims, and the gap between them is where most of the actual policy and product decisions live.

What this means if you’re building with AI

If your workflow depends on watermark detection catching AI-generated text reliably, plan around the edge cases above rather than the headline claim. Long-form content is where this works best. Short copy or technical content with few valid token choices, and anything passed through multiple models or heavy paraphrasing is where confidence drops fast, sometimes to nothing.

Can the Claude watermark be identified?

Anthropic hasn’t published the exact scheme (token-bias key, hash function, sampling details, etc), so there is no way of currently building a viable detector. Unless there is a verification key, no one outside Anthropic would be able to realistically do this.

I decided to put some of this to the test by building an artifact walking through how these schemes generally work statistically (n-gram*/token frequency-bias detection, z-score tests over a suspected watermark distribution), so you understand what signal a real detector would be looking for.

*n-gram = a sequence of x adjacent elements from a string of text

There’s no real detection happening since it isn’t Anthropic’s key, so it shouldn’t find anything in any text. Running my own unedited sentences through it a few times still produced a stray high-ish z-score here and there, not because it detected anything, but because z-scores on short passages are noisy by nature.

I decided to then run the entire blog post past it, and got an even more interesting result: every other word was marked as red. This is because the detector isn’t actually scoring several thousand independent words, it’s scoring a much smaller set of repeated word pairs.

Ordinary English leans hard on a small rotating cast of function words, “the,” “a,” “of,” “in,” “is,” “and,” and they show up every couple of words in any grammatical sentence.

Whichever way this key happens to hash those specific pairs gets replayed on roughly the same rhythm the words themselves fall into. It’s the same non-independence problem from the earlier test, just more visible at length as a handful of fixed, deterministic coin flips dressed up as a large sample.

Wait, what does that mean?

Calm down, let’s keep in mind this isn’t a real codebreaker tool of any sort.

But a statistically sound detection method can still produce a confident-looking, false signal on ordinary text if it isn’t built to account for how repetitive real language is. That’s not a flaw, and it’s a documented failure mode in the actual research this whole category of watermarking comes from.

Kirchenbauer et al., the team behind “A Watermark for Large Language Models” (ICML 2023), introduced the green-list scheme this post has been describing throughout. Buried in their own discussion of the detection statistic is the same problem this post’s tool just hit: a repeated bigram like “Barack Obama” gets one fixed green or red verdict the moment it’s first hashed, and every later repetition of that exact pair just cashes in on the same verdict again. Their own worst-case scenario, stated plainly in the paper, is ordinary human-written text with enough repetition of a phrase like that racking up a falsely high green-token count and getting flagged as machine-generated, nothing watermarked about it at all.

The same team followed up the next year with “On the Reliability of Watermarks for Large Language Models” (ICLR 2024), and that one’s the actual experiment. They took watermarked text and ran it through human rewriting, LLM paraphrasing, and mixing it into longer hand-written documents, then measured how detection held up. Two things came out of it that pull in opposite directions.

The good news for watermarking is the signal survived better than you’d expect, staying detectable after roughly 800 tokens on average even under strong human paraphrasing, using a threshold most fields would call very strong evidence.

The catch sitting right next to it as paraphrased or mixed-in text statistically tends to leak n-grams from the original passage, and that leakage can produce high-confidence detections in places that shouldn’t register anything at all. (Which is why the Bible often gets flagged as being written by AI.)

What’s unknown about Anthropic’s real scheme

Public reporting confirms the watermark exists, applies globally to Claude’s outputs as of August 2, 2026, and is intended to be imperceptible to readers. Anthropic hasn’t published the specifics that would let a third party build a real detector:

• The hash function and how much preceding context it uses per token.

• The green-list fraction (γ) and how strongly sampling is biased toward it.

• The secret key or key-rotation policy.

• Whether a public verification endpoint exists at all, reporting doesn’t mention one for text (unlike C2PA on images, which is an open, independently verifiable standard by design).

That last distinction matters, given the image-side provenance (signed C2PA metadata on .svg/.png/.jpg) is a published, interoperable standard you genuinely can check today with independent tools. The text watermark is not architected that way in what’s public so far.

So now what?

A few options do exist:

1. C2PA content credentials on images: real and checkable now, using independent verifier tools, since it’s an open standard rather than a proprietary statistical signal.

2. General AI-text stylometric detectors (perplexity/burstiness tools in the GPTZero family) : These don’t read any watermark at all; they guess from writing style. Coverage of Anthropic’s rollout explicitly flags their unreliability, and independent research has shown they misfire on both human and AI text often enough that a “detected” or “clean” result from one isn’t good evidence on its own, eg light editing, translation, or short passages degrade them further.

3. A dedicated Anthropic verification tool for text: Not confirmed as publicly available as of this writing (Aug 2026) in any of the coverage checked below. If one ships, it would be the only way to reliably check the real watermark, since it’s the only party holding the key. I personally wouldn’t put it past them to monetize this, but who knows, really.

Frequently asked questions

Is AI watermarking the same as hidden text or invisible characters?

No. Some early or low-effort watermarking schemes used invisible Unicode characters or whitespace patterns, and those are trivially removed by copying text into a plain editor. Serious watermarking like Google’s SynthID works differently: it shapes the actual word choices the model makes using a cryptographic key, so there’s nothing to strip out because the “watermark” is the content itself.

How does SynthID watermark AI-generated text?

SynthID uses a secret key combined with the surrounding context to score each plausible next word, then leans toward whichever ones score highest instead of leaving the choice to random sampling. To anyone without the key, the output looks like normal text, and quality holds up well because the model is still choosing among candidates it already found plausible.

Can you remove an AI watermark by editing or paraphrasing the text?

Partial editing usually isn’t enough. The watermark’s statistical signal is spread across the individual token choices throughout the text, so cutting, reordering, or paraphrasing some sections still leaves a detectable pattern in what remains. Getting the signal below a detectable threshold generally takes rewriting most of the piece, translating it, or otherwise touching a large share of the actual word choices, not just light copyediting.

Does AI watermarking work on short text or code?

Not reliably. The statistical confidence behind watermark detection depends on having enough tokens with real candidate diversity to build a pattern from. Short outputs don’t provide enough volume, and shorter content often has only one plausible next token at each step, leaving little room for a watermark signal to exist in the first place.

What’s the difference between SynthID and C2PA?

SynthID is a token-level cryptographic fingerprint built into how a model generates text or media. C2PA (Coalition for Content Provenance and Authenticity) is an open industry standard focused on attaching verifiable provenance metadata to content as it’s created and edited, more like a chain of custody than a statistical signal. They solve related but different problems, and a piece of content could use one, both, or neither depending on the tools involved in producing it.

Does Claude watermark its output?

Yes. Anthropic has confirmed that Claude embeds machine-readable watermarks in generated text and C2PA-compliant provenance metadata in generated files, starting with models launched from August 2, 2026 onward, applied globally rather than only in the EU. The move complies with Article 50 of the EU AI Act. Anthropic hasn’t disclosed the specific technical mechanism behind the text watermark, and has said the watermark can be weakened or removed by heavy editing, translation, or very short passages.

Can third-party AI detector tools reliably spot watermarked content?

Generally no, unless they have access to the specific model provider’s secret key. Most consumer-facing “AI detector” tools are pattern-matching on writing style rather than checking a cryptographic signal, which is why their false-positive and false-negative rates are considerably higher than the underlying watermarking technology itself would suggest.

Can you break the Claude content watermark?

In principle, given enough determination: heavy editing, translation, or full paraphrasing can weaken or remove the signal, per Anthropic’s own caveat above. In practice, nobody outside Anthropic can verify whether a given piece of text is watermarked in the first place, since nobody outside Anthropic holds the key. That also means there’s no way to confirm removal worked, since there’s no way to confirm detection would have worked either.

I’ve been posting bits and pieces about this on LinkedIn for a few weeks now, and enough of you asked me to put it all in one place so here we are. As part of the ongoing series on what’s actually happening under the hood when we use AI tools, I’ll be breaking down some of the mechanics minus the “AI will replace your job” panic.

Let’s start with the thing that is super obvious and you need to know why it’s important: by default, an LLM doesn’t pause to think before it answers you. It starts talking immediately, and figures out what it’s saying as it goes.

Models write answers one word at a time

Picture someone answering a hard question out loud, live, with no time to prepare and no chance to go back and revise. That’s roughly what a model does by default. It writes its response one word at a time, and each word it commits to becomes the thing the next word has to follow from. There’s no rough draft sitting behind the scenes; the first version is the only version, unless you ask for something different.

This explains something that trips a lot of people up: why a strategic question gets you an answer that sounds confident but turns out to be nonsense. The model isn’t being “lazy” despite what it might seem like, it’s doing what it always does when nothing tells it otherwise, which is reach for the most common, most expected version of that answer. Ask a generic question, get a generic answer. Shit in, shit out.

The same thing happens when you try to describe your brand voice instead of showing it. If you tell the model your tone is "direct but slightly irreverent," it will produce copy that technically fits that description while sounding like nothing you'd actually write. The model is interpreting your description, not calibrating against real examples of your writing. Description and demonstration are not the same input, and they don't produce the same output.

But what about thinking mode?
That’s not really a draft, but it is close to what we would consider a type of process.

Once you understand that the model is committing to its answer as it goes rather than planning it out first, two techniques become obvious fixes.

Make it think out loud: chain of thought

Because the model generates one token at a time, each step it writes becomes part of the context for the next step. Chain of thought prompting takes advantage of that directly: you ask the model to reason through the problem step by step before it gives you the final answer.

This matters because the final answer is now built on the model’s own intermediate reasoning instead of a single jump straight to a plausible-sounding conclusion. For anything with real stakes, like positioning, prioritizing your ICP, or picking apart a competitor’s move, this is the difference between an answer that “sounds right” and one that’s actually been reasoned through.

Show it, don’t tell it: few-shot prompting

The second fix is few-shot prompting, and it solves the brand voice problem directly. Instead of describing what good looks like, you show the model examples of it. Give it three pieces of your best copy, and it reverse-engineers the pattern from those examples rather than guessing from your description of them. Three real examples will always tell the model more about your tone than two paragraphs explaining that tone ever could.

Specificity is important

Both of these techniques point at the same underlying problem: the model has nothing to go on except what you give it. Five-word prompts get five-word thinking. If your outputs keep landing generic or slightly off, that’s almost always where the problem starts, not in the model’s capability.

The structure I use for this is Context, Instructions, Task.

Context is the permanent layer: who you are, what you’re working on, what good already looks like for you.

Instructions are the specifics people tend to skip because they assume the model will just figure it out (it won’t): tone, format, length, what to avoid.

Task is the actual ask, and “write me a post” isn’t a task. “Write a 200-word post with a hook that stops someone mid-scroll, direct tone, no bullet points” is a task. The more specific you are, the less the model has to guess, and the less you have to fix afterward.

None of this requires a technical background. It just requires remembering what’s actually happening on the other side of the prompt box: a system committing to each word as it goes, working entirely from whatever you handed it before it started. Give it more to work with, and the output gets dramatically better. Give it a vague description and hope, and you get the average of the internet back.

Ughhh, but must I repeat myself every single time?
No, I’ll touch on that in the next part of this series - stay tuned!

If you’re as tired of AI Slop as I am….

I decided to try a new little side gig called FixYourSlop.AI

I can help you:

• Make your copy sound human

• Give you proper differentiation

• Make everything AEO referenced
  

Just your friendly neighbourhood Spider-woman coming to the rescue 🛟

There may also be a Konami code.
You know, for fun.

⬆️⬆️⬇️⬇️⬅️➡️⬅️➡️🅱️🅰️<enter>

Until next time!

Most people building Claude skills spend their time perfecting the prompt, eg tweaking the structure, iterating on the output format, testing edge cases, etc. The skill gets better, yet the output stays mediocre. I’ve watched this happen across teams and it’s one of those problems that looks like a craft problem until you realise it’s an architecture problem.

The reason is simple: every prompt forces the skill to start from zero. That means it’s got no memory of your audience, no knowledge of your positioning, no understanding of how you or your team actually work. Claude is smart, but it can only work with what you give it in the moment, and “in the moment” is almost never enough.

This is a silo problem. Every skill knows its own world, with no cross-interaction and no shared foundation. It produces really recognisable failures: copy that writes about your audience instead of for them, positioning that sounds like every other B2B company in your space, content that’s technically on-brand but has none of the texture that makes your real stuff land, and half-baked PRDs that don’t quite hit the mark.

Three things that specifically break without a shared context layer:

Context amnesia. Every new session, you’re re-explaining the same things. Your ICP, your voice, your market position. The quality of output ends up depending entirely on how much the user remembers to include on any given day, which is wildly inconsistent.

Config drift. Hardcoded values go stale. Names change, frameworks update, team structures shift. At one skill, it’s manageable. At twenty skills across three teams, it becomes a maintenance job nobody signed up for. (I’m calling it now: AI Ops is coming as a job title, and this is why.)

No learning loop. When a session goes well, or when Claude makes a mistake that reveals a real gap in a skill, that insight evaporates at the end of the session. There’s no mechanism to capture it, no way for it to improve the next run, no compounding. Every session is equally good, which means every session is equally mediocre.

The fix is a three-layer architecture. A shared knowledge base that lives in your Claude Project (positioning, ICP, brand guidelines, etc) that every skill checks before asking the user for anything. A personal MEMORY.md file per user that Claude writes to over time, building a picture of how that person works, their preferences, their decisions. Add an improvement loop that silently logs patterns and gaps across sessions so the humans managing the system have real material to work with.

The whole setup takes an afternoon. Each user onboards in about two minutes. And the compounding effect over six months is genuinely significant (richer shared context, smarter personal memory, better-calibrated skills) compared to a team that spent the same time maintaining isolated skills with hardcoded values.

I wrote up the full architecture, including exactly how to set it up step by step, over here: Your AI skills are silos. Here’s how to fix that.

If you’re building with Claude at your company and want to think through how this applies to your specific setup, just reply. The patterns are transferable to any team, any workflow, and any industry.

Andrea

Forma PM is still the core

The full GTM workflow: positioning, ICP, messaging, feature comms, launch planning is available on Gumroad as a set of MD files you upload to a Claude project and use immediately. A PDF version is included if that format works better for your setup.

Forma CS scores your accounts before renewal pressure arrives

The CS bundle is free. It gives customer success teams an account intelligence layer: scoring accounts as hot, warm, or cold based on product signals, surfacing expansion and upsell conversations at the right moment, and generating conversation cards so those calls land on something specific. The skill file packages it for immediate use.

Forma Dev fixes the SEO gap in React apps

Also free. If you’ve built with Lovable, Vite, or Create React App, crawlers see an empty shell where your product should be. Forma Dev diagnoses the gap and walks through the fix. It started as a Substack post and is now a skill file anyone can use.

Forma Copy writes in your own style

Forma Copy is a writing workflow built around voice capture first, structure second. Paste two or three pieces of your existing writing, define the argument you want to make, and Claude writes in your voice with a structure that leads with the point.

And my favourite one thus far….

Forma Roadmap structures your backlog into a roadmap

Forma Roadmap takes your backlog and turns it into a Now/Next/Later outcome-based structure with a narrative brief and presentation ready for leadership. Forma Roadmap pulls positioning and ICP context from Forma PM, so the story you tell your exec team connects directly to the story you tell your market.

Both Roadmap and PM are available on Gumroad (I worked really hard on them!) - while the rest remain free.

Get all skills

Hope you make the best out of them!

Andrea

Forma is shutting down.

Well, sort of.

I built Forma PM because narrative fragmentation is one of the most underestimated revenue problems in product. PMs and PMMs working in silos, launches that lose momentum before they start, strategies that make sense internally but land flat externally. I have lived that problem firsthand, written about it, and watched it cost teams real money and real time.

Forma was an AI-powered platform with seven connected tools: ICP builder, positioning canvas, messaging framework, launch brief, feature comms, and a validation engine that pressure-tested narratives before they shipped. The thing I was most proud of was the central intelligence layer. Context from one tool flowed into all the others, so your positioning shaped your messaging, your messaging anchored your launch, and everything stayed connected. That was the real product, not the individual tools, but the thread running through them.

It worked. People used it, got value from it, and told me it changed how they thought about their product story.

But…. here’s the harsh truth:

Building and maintaining an AI-powered SaaS product as a solo founder is expensive, and the AI market has created a pricing dynamic that is genuinely difficult for indie builders. People expect significant value at near-zero cost, and the infrastructure required to deliver that value reliably does not cost near zero. That gap does not close through optimism or better positioning. It closes through scale I did not have, or a different delivery model entirely.

So I made a product decision and moved Forma into Claude.

Everything Forma was built to do, the frameworks, the methodology, the connected thinking, is now available directly as a set of Claude skills + project. Same rigour, lower friction, no subscription required. It reaches more people now than it did as a standalone product, which tells me something about where AI-native tools are headed and what builders are actually willing to pay for.

Building Forma taught me things about architecture, pricing, and the gap between a correct insight and a viable business that I could not have learned any other way. The problem it was trying to solve has not gone away. If anything, the fragmentation between product and marketing teams is getting worse as AI accelerates shipping while slowing down the thinking.

I will keep writing about that here.

If you want to use Forma, it is at getforma.co.

Thank you for being here while I figured this out!

Andrea

I found this out the hard way while building Forma PM. On the surface, everything looked great. Lovable even confirmed constantly that my SEO score was over 90%. But after seeing constant complaints from other on Reddit, I decided to run crawl test and saw what Googlebot was actually receiving an empty HTML page with a JavaScript bundle.

Here’s what’s happening, why Lovable builds it this way, and exactly how to fix it.

Lovable uses React with Vite to build single-page applications. That means every page on your site works the same way: the server sends a minimal HTML file (basically an empty container), then JavaScript runs in the browser to render all the actual content.

For humans, this works perfectly. Your browser executes the JavaScript, the page appears, and you never notice the difference.

For search engine bots, it’s a disaster. Most crawlers do a simple HTTP request and read the HTML they get back. They don’t reliably execute JavaScript. So what they see is this:

<!DOCTYPE html>
<html>
  <head><title>My Site</title></head>
  <body>
    <div id="root"></div>
    <script src="/__u/dreasays.substack.com/assets/index-abc123.js"></script>
  </body>
</html>

This means there’s literally no content at all. Google has nothing to index, so your pages either don’t appear in search results or rank terribly because there’s no content signal.

But wait… there’s more!

It gets worse. Even if Google could somehow render your JavaScript, there’s another issue lurking in Lovable projects: invisible navigation links.

Lovable’s AI tends to build buttons and CTAs using React’s programmatic navigation pattern:

<Button onClick={() => navigate('/pricing')}>See Pricing</Button>

This renders as a <button> element in the HTML — not an <a> tag. Search engine crawlers discover new pages by following links, and they can only follow real <a href="/__u/dreasays.substack.com/..."> anchor tags. A button with an onClick handler is completely invisible to them.

When I audited my site, I found 20 instances across 11 public-facing files where Lovable had used this pattern instead of proper links. That included the main CTA on my homepage, every product page link on the “How it works” page, and every “Start free trial” button across all use case pages. My entire internal link structure was invisible to crawlers.

Understanding Lovable’s contraints

Before I get to the fix, you need to understand the constraints. Lovable controls the hosting and build pipeline. That means you cannot:

• Add custom build scripts (like react-snap or prerender-spa-plugin) to generate static HTML at build time

• Modify the web server to add middleware that detects bot user agents

• Intercept incoming requests to serve different content to crawlers vs. humans

• Switch to a server-side rendering framework like Next.js

Traditional prerendering approaches are off the table, so you’re left having to work within Lovable's architecture.

How to fix the Lovable SEO issue

After several rounds of iteration, here’s the approach that works within Lovable’s constraints. I’ve included the master prompt below, but first, here’s what each piece does and why it matters.

1. Fix every Navigate Call (Immediate SEO Impact)

The single highest-impact change is converting every onClick={() => navigate(...)} on public pages to a proper <Link> component. In React Router, <Link to="/pricing"> renders as a real <a href="/__u/dreasays.substack.com/pricing"> in the DOM — crawlable by bots and still handles client-side navigation for users.

This doesn’t require any infrastructure, it’s a find-and-replace across your components, and it immediately makes your internal link structure visible to crawlers.

2. Build a centralized Route Registry

Create a single file that lists every public, indexable route on your site with its path, title, meta description, last modified date, and sitemap metadata. This becomes the single source of truth for your sitemap, your SEO debug tools, and your prerender cache.

3. Generate a Dynamic Sitemap

Build a Supabase edge function that reads your route registry and generates a proper XML sitemap with <lastmod> dates. Point your robots.txt to it. This tells Google exactly which pages exist and when they were last updated.

4. Add a Noscript Fallback

Add a <noscript> block to your index.html with your site name, a brief description, and links to your key pages. This gives crawlers that don’t execute JavaScript at least some content and links to follow. It’s not a substitute for proper prerendering, but it’s a meaningful safety net.

5. Build a prerender cache and SEO Debug Dashboard

Create an edge function that can scan any page on your site, extract SEO elements (title, meta description, H1, H2s, internal links), and cache the results. Then build an admin page that lets you inspect every route, see what’s present and what’s missing, and monitor the health of your SEO across the entire site.

This won’t serve prerendered HTML to bots on its own — you need a CDN layer for that (more below). But it gives you complete visibility into your SEO status and a cache that the CDN layer can draw from.

6. Set Up CDN-Level prerendering

The final piece is routing bot traffic through a service that serves fully rendered HTML. Your two best options:

Cloudflare Workers (recommended): Move your DNS to Cloudflare’s free tier, create a Worker that checks the user agent for bot signatures, and route those requests to your prerender edge function. Humans get the normal SPA. Bots get complete HTML.

Prerender.io: A managed service that handles bot detection and rendering for you. The free trial is 30 days, which is enough to get your pages initially indexed. But you’ll need a permanent solution after that, which is why Cloudflare Workers is the better long-term bet.

Do you actually need CDN-Level prerendering?

Maybe not — at least not right away. The changes in steps 1 through 5 do a lot of the heavy lifting on their own. Converting navigation to real <a> tags means crawlers can now discover and follow your internal links. A proper sitemap tells Google exactly what pages exist. The noscript fallback provides baseline content in the raw HTML. And Google’s own renderer does attempt to execute JavaScript for indexing. It’s not 100% reliable, but combined with proper links and a sitemap, it picks up a surprising amount of SPA content.

My recommendation: ship the fixes, submit your sitemap in Google Search Console, and use the URL Inspection tool to test your key pages over the next couple of weeks. Monitor how much Google indexes on its own. If coverage looks good for your 30-50 page marketing site, you might not need the CDN layer at all. If you’re still seeing pages missing or showing thin content after a few weeks, that’s when you set up Cloudflare Workers, and the prerender cache you’ve already built slots right in.

Things that will go wrong (and how to handle them)

I went through multiple rounds of iteration getting this right. Here’s what to watch out for:

Lovable + Rendertron

When you ask Lovable to implement prerendering, it will very likely suggest using Google’s Rendertron as the rendering backend. This is wrong, as Rendertron’s public hosted instance has been deprecated. If Lovable builds your prerender function around a Rendertron endpoint, it will fail silently and your cache will be empty.

Tell Lovable explicitly to use a direct HTTP fetch with regex parsing, falling back to route registry data. No external rendering service needed.

The SEO debug dashboard will lie to you

The first version of my debug dashboard showed every page as green/healthy. The health check logic was marking pages as “success” just because the HTTP fetch returned a 200 status code, even though the fetched HTML was an empty SPA shell with no content.

Make sure the health scoring is based on what was actually extracted (non-empty H1, non-empty meta description, at least one internal link), not on whether the HTTP request succeeded. And make sure it distinguishes between content that was found in the actual HTML vs. content that was pulled from the route registry as a fallback.

Converting links will break navigation

When you convert <a href> tags to React Router <Link> components (or vice versa), you might introduce full-page reloads where there should be smooth SPA transitions. Standard <a href> tags trigger a full page load. React Router <Link> components handle navigation client-side.

I had a round where the mobile nav and dropdown links all got converted to plain <a> tags, which meant every click caused a full page reload with a white flash. The fix is making sure everything uses <Link to="..."> which renders as a real <a> tag in the DOM (so crawlers can see it) but handles navigation without a page reload (so users get instant transitions).

Lazy loading will cause flash

Lovable uses React.lazy() and Suspense to code-split every page. This means navigating between pages shows a loading spinner while the new page’s JavaScript chunk downloads. After converting navigation to proper <Link> components, this flash becomes much more noticeable because transitions happen instantly on click instead of having a small delay from the old onClick handler.

The fix:
Remove lazy loading for all public marketing pages and only keep it for authenticated app pages (dashboard, tools, settings).

Security implications

Adding edge functions, database tables, and admin pages introduces attack surface. After implementing the SEO changes, run a security audit. Specific things to check:

• SSRF on the prerender function: The function accepts a URL path parameter. If it doesn’t validate the input, an attacker could make it fetch arbitrary URLs. Ensure the path must start with / and cannot contain @, //, \, or protocol schemes.

• CORS: Lovable preview URLs change. If you hardcode allowed origins, your debug page will break when the preview URL rotates. Use pattern-based matching.

• Admin access: Make sure the SEO debug page checks for an admin role, not just an authenticated user.

• robots.txt: Remember to block /admin/ paths.

The Master Prompt

Here’s the prompt you can paste directly into Lovable to implement the full fix. It’s been refined through multiple iterations to avoid the pitfalls above:

Our site is a client-side rendered React SPA. Search engine bots are receiving an empty <div id="root"></div> shell instead of rendered content. We need to fix crawlability without switching frameworks or requiring a full technical rebuild.

Important constraints: We cannot add custom build scripts, modify the web server, or add middleware. We need to work within the existing Vite + React + Supabase architecture.

Please implement the following:

1. Centralized Route Registry

Create src/data/siteRoutes.ts — a single source of truth for all public, indexable routes. Each entry should include: path, expected page title, meta description, expected H1 text, expected internal link paths, last modified date, sitemap priority, and change frequency. This file will be used by the sitemap generator, the SEO debug page, and the prerender cache.

2. Project-Wide Navigate Audit and Fix

Search every component and page file for onClick handlers that use navigate() for internal page links. For every instance on a public-facing page (not behind auth), convert from onClick={() => navigate(...)} to <Button asChild><Link to="..."> so crawlers see real <a href> tags. Do NOT convert navigate calls inside authenticated/dashboard pages — those are blocked by robots.txt and don’t need fixing. Show me the full list of what you found and what you converted.

3. Prerender Edge Function

Create supabase/functions/prerender/index.ts that:

• Accepts ?path=/some-page and optional ?refresh=true and ?bulk=true

• Fetches the published site URL + path via HTTP GET

• Parses the returned HTML using string/regex parsing to extract: title, meta description, H1, H2s, internal links

• Since a simple fetch of an SPA returns the JS shell, falls back to populating the cache from the route registry metadata

• Caches results in a prerender_cache database table

• Computes a health status: green (title + description + H1 + links all present), yellow (some missing), red (critical elements missing)

• Tracks the source of each field (”fetched” vs “registry_fallback”)

• Includes extraction_notes explaining what was found and where

• Requires admin authentication

• Validates the path parameter to prevent SSRF (must start with /, no @, //, \, or protocol schemes)

• Has rate limiting (5 bulk scans/hour, 60 single scans/hour)

Do NOT use Rendertron or any external rendering service. Rendertron’s public instance has been deprecated.

4. Dynamic Sitemap Edge Function

Create supabase/functions/generate-sitemap/index.ts that generates valid XML from the route registry with <lastmod>, <priority>, and <changefreq>. Requires admin auth. Keep robots.txt pointing to the static /sitemap.xml — the edge function is a generation tool, not the live endpoint.

5. Database Table

Create prerender_cache with columns: path (PK), html_snapshot, title, meta_description, h1, h2s (jsonb), internal_links (jsonb), internal_link_count, status, rendered_at, source, health, extraction_notes (jsonb), registry_complete (boolean). RLS: service role can read/write, admins can read, block anonymous access.

6. SEO Debug Admin Page

Create /admin/seo-debug (admin-only, with role check — not just authenticated) with:

• Single page inspector: enter a path, scan it, see extracted title/description/H1/H2s/links with health badge and extraction notes

• Crawl coverage dashboard: table of all routes showing health status, what’s present/missing, last scanned date, with per-row refresh and bulk scan

• Sitemap regeneration button

7. Enhanced index.html

Add a <noscript> block with site name, description, and key internal links as real <a> tags.

8. App.tsx and robots.txt

Add the admin route. Ensure robots.txt blocks /admin/. Do not remove any existing disallow rules.

After implementation, also:

• Remove React.lazy() for all public marketing pages. Only keep lazy loading for authenticated pages (dashboard, tools, settings). Public page navigation should have zero loading flash.

• Confirm all CORS allowed origins cover both .lovable.app and .lovableproject.com preview domains plus the production domain.

I would suggest using Lovable’s “plan” feature to ensure that this is done in phases so it doesn’t get confused.

What comes next

Don’t trust that everything is fixed just because Lovable says it’s done. Here’s how to actually check.

View Page Source (not Inspect Element).
Right-click any page and choose “View Page Source.” This shows you the raw HTML the server sends — the same thing a crawler gets. You should see your <title>, <meta name="description">, Open Graph tags, structured data, and the <noscript> block with your H1, site description, and internal links as real <a> tags. If you only see <div id="root"></div> and script tags outside of the noscript block, that’s expected for an SPA — the noscript content is your crawlable fallback.

Check from the command line.
Run curl -s https://yoursite.com/ | grep '<a href' to count the links a basic crawler would find in the raw HTML. Then try curl -s https://yoursite.com/ | grep -i '<h1' to check for headings. You should see links in the noscript block at minimum.

Count your internal links in the DOM.
On your homepage, open dev tools, go to the console, and run document.querySelectorAll('a[href^="/"]').length. This tells you how many internal anchor links exist on the rendered page. Do the same on a few content-heavy pages. If the numbers are healthy (10+ on pages with navigation and CTAs), your link structure is working.

Inspect the CTA buttons.
Right-click any call-to-action button on your public pages and Inspect Element. You should see a real <a href="/__u/dreasays.substack.com/your-path"> in the DOM, not a <button> with an onClick handler. If it’s an <a> tag, crawlers can see it.

Check your sitemap.
Visit yoursite.com/sitemap.xml directly. Make sure every public page is listed and the URLs are correct.

Use Google’s Rich Results Test.
Go to search.google.com/test/rich-results and enter your URL. It renders the page using Google’s actual rendering engine and shows you the rendered HTML and a screenshot. This is the closest thing to seeing what Googlebot actually sees.

Monitor in Google Search Console.
Submit your sitemap, then use the URL Inspection tool to test 5-10 key pages. Check what Google sees in its rendered preview. Under Pages, watch the "Not indexed" reasons, "Discovered - currently not indexed" means Google found the page but hasn't processed it yet (give it time), while "Crawled - currently not indexed" means Google fetched it but found insufficient content (that's a problem).

If pages move from "not indexed" to indexed over the coming days, the fixes are working. (This will take a while, mine is still running, but I’m hopeful as previously it immediately showed nothing.)

Meanwhile…

The debug dashboard is your ongoing monitoring tool. Check it periodically to make sure new pages you add have complete metadata in the route registry and that nothing has regressed.

And that is our nerdy round up of the week, thanks for sticking around!
See you next time,

A

I’ve been deep in the build-learn-build loop again, and this past month taught me more than I expected. Forma PM grew in ways that feel quieter but more meaningful. Stability work, architecture fixes, value chains, a few security scares that I caught early, and a lot of clarity about how a product should behave.

Here’s what I’ve been working through.

1. Making Forma stable

I wanted Forma to feel calm. That meant tearing out old save logic, consolidating everything into one system, and rebuilding the foundation so people can work without thinking about the software underneath.

The app now saves offline, handles multiple tabs without confusion, and relies on a single autosave path instead of five scattered cousins. I also caught an issue with encryption keys during account switching and tightened the whole security layer. It felt like tedious work at first, but the payoff is a product that behaves consistently.

💡 Lesson: Audit. Then audit again. Then audit again after that!

2. Rebuilding Messaging Builder with value chains

I built a new feature and then had to start over 🤦 The previous structure made things easy to fill out but didn’t push enough clarity. I rebuilt Messaging Builder around a value chain model that forces each step to connect. This means looking at Capability → benefit → outcome → business impact.

The tool now pulls upstream context from the other Forma modules and generates channel-specific content from a single narrative. I also added verdict-based validation so teams know when something is ready and when it needs more work. AI gathers evidence, rules determine the verdicts, and the whole thing behaves with more reliability.

💡Lesson: RAG is important when building. People expect to be helped, not to figure out where to go next.

In all its glory, the Messaging Builder now looks like this:

3. Lessons that stuck (and sucked)

This round of work taught me a lot about my own habits and the product’s expectations.

Fixing symptoms creates clutter, so I started digging until I understood the real cause every time. Security behaves better as a system rather than a list of tasks. Testing flows instead of pieces catches the problems that actually matter. Encryption punishes inconsistency, so I unified derivation methods across frontend and backend to avoid silent failures.

These lessons felt small while I was in them, but each one changed the way Forma works. They changed the way I build too. This month felt like leveling up without the fireworks, just steady progress and clearer thinking.

Website Teardowns

I’m kicking off a new series where I look at real websites and break down what’s working and what isn’t. Not to be harsh, not to dunk on anyone, but to understand how teams tell their story, where the narrative holds up, and where it quietly falls apart. It’s a way to learn from solid choices, spot the patterns that get in the way, and sharpen how we all think about product storytelling.

First candidate up: Intercom

Let me know if you want me to look at yours!

Until next time,

A

Yes, I cried.

The goal was innocent enough:

I should change the progress bar to indicate specific states instead

Here’s what actually happened:

• I broke the entire backend

• Restoring Lovable to a previous version doesn’t actually restore database changes, only front-end changes

• And my brain… stopped working somewhere around Round 3.

After five full rounds of “fix, refix, break something else, fix again,” the damn thing finally works. Elegantly, even.

Now, Forma gently recommends that new users start where they should, without nagging or trapping them in UX hell, and specifically tracks down every single step in tools so you know where you’re at and can skip ahead.

Oh, and while I was at it, I also:

• Added dark mode 🌙

• Built improved onboarding

• Connected more context between tools (central intelligence system, coming to life)

The lesson here….

A simple feature is only simple if you think it through completely the first time. Otherwise, you’re just stacking simple fixes until they become a complex mess.

Also, vibe coding amirite.

Time spent fixing: 5 hours

Time spent thinking: 1 hour

Ratio we should aim for next time: Flip it.

Forma PM is getting sharper, smarter, and (ironically) more aligned than I am.

Progress, right?

— Andrea

1. Data security is a competitive differentiator

Users are genuinely concerned about sharing proprietary product strategy with ChatGPT. Not to mention, OpenAI is already looking at how to lock down and make pricing more expensive (wait for it…..)

Privacy messaging works best when it’s concrete and comparative.

2. Homepage real estate matters

Any good product marketer knows this. The outcomes/benefits section of your homepage is valuable real estate, and you have but a few seconds to get people’s attention.

I rejigged pages and added a 4th card to highlight privacy, creating visual symmetry while reinforcing our core value prop.

3. Visual design insights

Overly complex gradients can feel “naff” and distract from the message (this is a legit statement, from myself to myself.)

Simple, clean backgrounds often work better than elaborate patterns.

Glass-card styling with subtle borders creates enough visual interest without overwhelming.

4. Messaging Strategy

Security messaging is more powerful as an outcome/benefit rather than buried in features. Take a step back to understand your fact, benefit, and emotional statements.

“Your strategy stays yours” is a clear, emotional benefit statement that positions things while creating a value exchange.

5. Content structure decisions

Homepage vs dedicated pages: Homepage wins for critical differentiators that drive conversions. Keep your important messaging there!

The “outcomes” section is where emotional/strategic benefits live, not just functional features. Remember to balance: Benefit <> Value <> Feature.

Oh, and of course, the ongoing lesson of test all of your edge functions, because the second you ask an AI to fix something, it will most certainly break something else.

If you haven’t checked out Forma PM yet, please do give it a go!

Until next time,

A

Building it has been fun. Breaking it has been… educational.

Here are some of the biggest lessons from the last few weeks:

1. Email templates are evil.

I sent my first announcement email without properly testing it. Oops.

Looked fine in Gmail, but completely broke in other clients. Dark mode inverted everything, buttons shifted, gradients looked terrible.

HTML emails are unpredictable! If you don’t test everywhere, they’ll remind you why you should have.

2. OAuth is never “done.”

I spent hours debugging “invalid” errors that had nothing to do with configuration.

The real problem was timing. The app was checking auth state before the session fully loaded.

Fixing it meant rethinking how the app handled async state changes, not just the login flow.

3. Supabase gives you a secure foundation, but only if you build on it correctly.

Supabase is great because it comes with serious security and compliance out of the box SOC 2 certified, encrypted, and reliable.

But what you build on top of it is your responsibility.

That means adding row-level security (RLS) so users can only access their own data, validating every input before it hits the database, and setting rate limits to prevent spam or abuse.

Without those extra layers, you’re leaving the door wide open even if the foundation is solid.

4. Stripe webhooks are your source of truth.

And also an absolute fucking nightmare. Never trust client-side confirmations.

Everything, and I mean everything, depends on how webhooks fire and fail.

5. Cookie consent is not “nice to have.”

If you’re going to say “GDPR ready,” prove it. Granular consent, easy “reject all,” transparent tracking. Users trust you more when you’re honest about what you’re collecting.

6. Users will find the cracks faster than you do.

No matter how much you test, users will still break your logic in ways you never imagined.

Someone managed to get more than the limit of messages in the first version of the trial workflow. Fixing it meant tightening validation server-side and locking usage down by unique IDs.

Forma PM now a lot more stable and secure than when I started. Still rough around the edges, but it’s evolving fast.

If you want to see what I’ve been building: getforma.co

Check out Forma PM

It was meant to be a test, a tiny hackathon project to see if I could automate part of the painful “how do I get stakeholders onboard?” process.

That experiment grew legs.

This week, it became a real product, and Forma now has its first paying customer.

Forma helps product people turn half-formed ideas into structured, exec-ready strategies.

It’s where messy thoughts, half-written briefs, and loose hypotheses finally take shape.

You can think of it as a suite of AI copilots for the product world:

→ Business Case Coach — prove the problem, earn the yes

→ Feature Comms — keep PMs, PMMs, and stakeholders aligned

→ Launch brief — coming soon.

There’s still a lot to build, but the early validation is what matters most.

I didn’t start with a business plan. I started with a problem worth solving, tested fast, learned fast, and kept going.

That’s the real playbook!

Start small. Validate early. Ship something useful.

If you’re curious, Forma’s live now: getforma.co

Check it out!

Let’s see what takes shape next.

Andrea

It’s me again, your not-so-steady product newsletter, because really, I only write when I have something to share (I truly don’t believe in spam.)

Anyway, so some cool stuff has happened over the last few weeks worth sharing!

I built a GPT

Yes, you read that right.

I had myself a little hackathon this morning and decided to build a GPT to guide product people through how to create a product problem outline.

It focuses on:
- Defining the core problem
- Clarifying why it matters (to customers + business)
- Mapping success metrics (leading + lagging)
- Capturing discovery experiments
- Prepping GTM communication with PMMS

What I like most is it feels less like a tool and more like a thoughtful product coach. It asks great follow-up questions, keeps people honest when being vague, and makes sure you don’t skip critical context.

Of course, all of this is based on years of experience and learnings from my book with Dave Martin!

The end result is a problem outline that’s structured, shareable, and actually helps align teams ✨

If you’re a PM (or work with PMs), you know how messy this process can get.

Get it here

After launching it on Linkedin, it’s important to note:

1. The purpose of this GPT is to guide product people through how to structure thinking when they’re embarking on solving a new problem.

2. It is NOT going to do your job for you. It will not run discovery or tell you how to run experimentation.

3. However, once you have done that, it’ll help organise your findings so you can share and communicate these things across your org.

Upcoming talks

I’m going to be talking in a few places, if you want to join and say hi!

Agile Cambridge

If you’re in the UK, come along to Agile Cambridge on October 1-2. I’ll be there with Dave running a workshop.

Product Drive 2025

I love vibe coding as much as the next person, but people have got to stop thinking it’s going to help them bypass critical product processes and just get to launch. Join me October 7 @ Product Drive as I talk about how everyone needs to Stop Trying to Vibe Code their way to PMF.

Hope to see you around!
A

The gap shows up at launch. No one in that trio owns the customer story or the path to revenue, so sales is guessing the pitch, legal is fixing pricing, and the homepage changes three times before Friday.

I wrote a short post on adding Product Marketing as the fourth seat from day one. Inside you’ll find:

• A quick test to spot pretend alignment

• A four-seat table you can copy for your next kickoff

• Three checks that turn a fuzzy value prop into a single repeatable line

Give it a read if you want calmer launches.

👉 Read the post

Have a wonderful summer,

A

That was the opening line of a LinkedIn post I shared this week — and it hit a nerve. Not because prototypes are bad (they’re not), or because PRDs are great (they’re also not.)

Prototypes help confirm that a solution works for the problem you believe exists. But they don’t tell you whether that problem is real, meaningful, or worth solving. That work happens earlier, through validation.

Somewhere along the way, the practice of writing things down became unfashionable. Apparently, now we can skip it all and go straight into AI and built whatever solution we desire.

By no means am I suggesting we need to go back to 20-page documents that nobody reads. But teams still need a way to align. Something that captures what has been validated, what’s still uncertain, what assumptions are in play, and how those will be tested. Call it a PRD, a brief, a discovery doc, or a product problem outline. The format doesn’t matter. What matters is that the thinking has happened, and it’s visible to the team.

This week I wrote about the difference between validation and confirmation, and why the sequence matters. When you mix them up, it becomes very easy to build things that look right but don’t solve anything, but because too often, teams skip the product thinking and jump straight into design.

👉 Read it here

Hope it helps sharpen your thinking! And if anybody tells you otherwise, they know nothing.

Two themes have been circling in my head lately:

1. The invisible wall between product marketers and product managers

2. The very real impact of behavioural economics on product decisions

I’ve written about both in the last moth, and I think they’re more connected than they first appear.

1. Product marketers need to understand product management

This is about the how and why behind product decisions.

This blog post comes from experience on both sides of the fence.

I started in product management before moving into product marketing, and I’ve seen firsthand what happens when PMMs aren’t brought into the thinking early (and what happens when they are).

This one’s for anyone who’s ever felt the tension between teams and wants to work better, together:

👉 Read it here

2. Behavioural economics for product managers

We talk a lot about friction, conversion, time-to-value.

But often, what we’re really talking about is how people behave under pressure, with limited time, limited context, and lots of cognitive shortcuts.

This post breaks down some key behavioural concepts that I think every PM should have in their toolkit—from loss aversion to decision inertia—and how they show up in product work.

If you’ve ever wondered why a “good” feature didn’t land, this one might help connect the dots:

👉 Read the post

I’d love to know what resonates and what you see in your world.

Just hit reply, or find me on LinkedIn.

More soon,

Andrea

Subscribe now

How to build a Now, Next, Later roadmap without the chaos

I included this in my last newsletter, but worth bringing back! I recently ran a little workshop with our product team, aligning around our OKRs, KPIs, and building out our roadmap.

When is it time to move on from an OKR?

As a follow up to the previous blog, Saeed Khan reached out with an excellent question: When is it time to move on from an OKR? How do you tie this to a Now, Next, Later roadmap if we’re not talking about dates? 🤔

How to prioritize bugs on a roadmap

If the question triggers you… well, it triggered me too. I ended up posting on Linkedin about this, and accidentally hit 63,500 views in under a week.

Quite predictably, the majority of people decided to tell me how to do this, proving that far too many people jump to answering a question without taking the time to read.

Our job as product leaders is not to tell someone how to do something 🚨 It is to listen, digest, and then break down the question properly: what are they really asking? How can we help them move past just the base level question and think more holistically?

When we do this, we empower young product managers to:

1. Empower themselves and their peers to ask the right questions

2. Set the right expectations and communicate properly

3. Become autonomous and build confidence in their work

4. Build relationships with trust

A lot of people assume that when someone asks “How do I do X?”, they’re simply looking for a step-by-step answer.

But more often than not, they’re grappling with something bigger—whether it’s unclear expectations, misalignment between teams, or a fundamental misunderstanding of how their work fits into the broader strategy.

Instead of reacting to the surface-level question, we should be asking ourselves:

• What problem are they actually trying to solve?

• Where might confusion be coming from?

• Is there a deeper knowledge gap that needs to be addressed?

• How can we help them move from execution mode to strategic thinking?

Would love to hear what you all have to say!

Until next time,

Andrea

I’m back with something I think a lot of product people will find useful.

Stepping into a new product leadership role is always an adventure. You inherit a team that’s already doing great work, but sometimes, the structure around how success is measured and how priorities are set isn’t fully in place. That was the case for me recently.

You all know I love a good roadmap… but what I love even more is good structure.

I’m not here to tell you how to create a roadmap—there’s no single “right” way. But I do want to share a step-by-step framework for how to think through a roadmap in a structured way using a collaborative workshop with product leadership.

In my latest post, I walk through the exact process I used to build a Now, Next, Later roadmap—starting with OKRs, mapping initiatives to measurable outcomes, and making sure we’re always solving the right problems at the right time.

If you’re tackling something similar, I’d love to hear how you approach it.

👉 Check out the full post here. 👈

Would love to hear your thoughts!

I am currently leading PMM at Turtl, but as a team of two, it’s nearly impossible to handle positioning, messaging, ICP work, market and buyer research, relaunch a whole product, work on GTM … and on top of that, also do sales enablement.

To help me, I asked myself how I could use AI to help me scale things… and so Turtl GPT came to be.

Trained on Turtl’s value framework, messaging strategy, proof points, product taxonomy, and case studies, Turtl GPT provides:

✅ Speed & scale: Instantly delivers insights on positioning, competitor intelligence, and customer success stories.

✅ Consistency & accuracy: Ensures messaging aligns with our core values.

✅ Productivity boost: Reduces time spent searching for or waiting for answers across teams in multiple time zones, so teams can focus execution.

It’s also got guardrails to prevent hallucination and control (mis)information as new things are being developed, while allowing everyone to be empowered that they can create their own comms without anyone else becoming a silo.

It’s already able to run some playbooks and help with renewals and close deals. Scaling enablement one Turtl at a time 🚀

Over the weekend I also trained it on some legalese so it can help SDRs deal with RFPs and renewals.

Would love to hear how some of you are using AI to help scale work!

Til next time 🖖,

Andrea