← back

minimum viable context

note ·jul 2026

working backwards from a great insight

In one of my first roles after business school, I worked at a Japanese printer manufacturer that used Lean methodology and Toyota production principles. It was a masterclass in operational discipline, systems thinking and continuous improvement.

Of the many ideas I learned and stuck with me over the years, there’s one that is particularly insightful in my GTM engineering journey: the 7 wastes, specifically overproduction.

I thought GTM alpha came from constructing the most elaborate systems using the most sophisticated tools and workflows. This past month, I finished the Clay Alphaforge program where we were shipping 3+ projects a week. By getting this many reps in building GTM workflows, I’ve changed my mind on this. GTM alpha comes from working backwards from a single important insight, that is refined through iteration and experimentation.

data hoarding and just-in-case signals

In Clay, it is easy to mistake a dense table full of enrichments, signals, and AI outputs for a sophisticated outbound system. But over-engineering can be as damaging as under-engineering: it increases credit and token spend, bloats context, complicates QA, and often produces worse emails.

Earlier in my GTM journey, I tried to build the most elaborate campaigns I could. I used as many enrichments and signals as possible, partly because I wanted to prove I could build complex systems.

The result was often a table full of interesting information that never appeared meaningfully in the final email. Sometimes the final prompt ignored most of the context. Other times, it forced too many facts into the copy and made the personalization feel artificial.

the framework

The work begins before opening Clay: define the end goal of the outbound email. Is the goal a booked meeting, a reply, a referral, or simply a useful first conversation? The answer should shape every subsequent enrichment decision.

A well-defined ICP makes this easier, but the discipline is useful even when an early-stage company is still discovering its market. The difference is that early experimentation should be intentional: you may accept some waste while testing positioning, but you should know what you are testing and why.

Next, break the email into atomic parts. Each section should have one job:

Once each part of the email has a job, you can build prompts modularly rather than asking one large prompt to research, reason, personalize, write, and self-edit all at once.

For example, if the goal is a reply from a technical founder, the email may need two things: a specific product signal and an open-ended question that demonstrates an understanding of the tradeoff created by that signal.

A modular workflow lets you inspect each step: Did the release extraction correctly identify what changed? Did the model identify a real tradeoff? Is the proposed question grounded in evidence? Does the final email use only the context that improves relevance?

This makes testing and QA easier. Wherever possible, use formulas, fixed output formats, or deterministic columns for structured tasks, and reserve LLM judgment for tasks that actually require interpretation.

case study: constructing outbound for posthog (product analytics+)

I used this approach in an outbound exercise for PostHog. My target accounts were teams using a PostHog competitor that also showed evidence of active product development through GitHub, release notes, or product-blog activity.

The competitor signal was useful for targeting, but it was not personalization. The useful personalization came from identifying a specific recent release, understanding the product tradeoff it created, and asking a question tied to a product-analytics job that PostHog could plausibly help with.

For example: hi x,

Chroma’s new readlevel control makes the freshness versus speed tradeoff explicit in search. 

how are your engineers connecting that choice to whether search results still help users?

best,
Y

While this email is not particularly revelatory or elaborate, it uses everything perfectly:

honing gtme judgement

I think of this workflow like building a paper model before building a financial model in Excel. Before adding formulas, pivot tables, or automation, you first decide what the finished model must show and which inputs are necessary to produce it.

Clay works the same way. Start with the intended campaign outcome. Break the email into atomic parts. Define the job of each part. Work backward to the minimum context required. Then choose the enrichment, formula, AI prompt, or external API that retrieves that context reliably.

My biggest lesson from Alpha Forge was honing GTM judgment about which signals deserve to be in the final email. That reduces credit and token spend, makes QA more manageable, and—more importantly: creates outbound that is more focused, credible, and useful.

subscribe