Approach · craft · in production
Thesis-First Content
I use Thesis-First Content to ensure every piece of communication, from blog posts to product docs, opens with a specific, testable claim, immediately delivering value and focusing the narrative.
Every piece of content I publish begins with a singular, testable claim or observation, which the subsequent text then supports or elaborates on. This approach ensures that information delivery is precise, and the reader immediately understands the core takeaway. It's a departure from the common practice of starting broad and gradually narrowing the focus; instead, I start with the sharpest point and build outwards.
What it is
Thesis-First Content means that the very first sentence of any article, documentation, or even a detailed email, states its primary argument or specific insight. For example, a blog post detailing a Firebase optimization won't open with a general statement about serverless architecture. It will begin with something like, "Migrating 14 callables and shaving 300ms off cold start required a specific approach to dependency bundling within our monorepo, which we implemented last month." The rest of the content then provides the context, methodology, and results for that specific claim. This applies across all content types, from public-facing articles for Total Formula 1 to internal operational guides for Pregnancy Power Hour.
Why I do it this way
I learned the hard way that attention is a finite resource. In a crowded digital space, readers (and search engines) demand immediate value. There's no time for preamble or generic introductions. A clear thesis forces me to articulate the core message upfront, ensuring that if the reader only scans the first sentence, they still get the essential point. This clarity is also critical when working with AI agents. When instructing Claude Code or Gemini to generate content, providing a precise thesis as the initial prompt yields significantly more focused and usable drafts, reducing the iterative refinement cycle. This practice aligns directly with Agent-First Development, where the structure of our inputs is optimized for machine readability and output quality. It also streamlines the editing process, as any content that doesn't directly support the opening thesis can be quickly identified and removed.
How it works in practice
The process begins in the outline phase. The first line of any content brief, whether for a new feature announcement on Inky or a technical deep-dive, is the thesis. This is a non-negotiable step for my agent workflows. When drafting, agents are instructed to expand on this thesis with supporting arguments, examples, and data points. My review process then focuses on verifying that every paragraph and example directly contributes to substantiating that initial claim. If a section deviates, it's either re-aligned or cut. For instance, a Total Formula 1 race analysis might open with, "Red Bull's pit wall decision on Lap 22 at Monaco secured Verstappen's lead, despite initial tire degradation concerns." The subsequent paragraphs detail tire data, strategy alternatives, and competitor reactions, all in service of that opening statement. This structured approach also makes Systemize Corrections more efficient; feedback often points to specific aspects of the thesis's support, rather than the overall direction. Similarly, for Docs as Source, the documentation for a specific API endpoint or utility function always starts with its singular purpose or the problem it solves, not a general description of the module.
Where this breaks down
While effective, Thesis-First Content can sometimes feel abrupt if the transition from the bold opening statement to the supporting details isn't handled smoothly. It demands a strong, well-defined initial insight; a weak or generic thesis will undermine the entire piece. This approach is less suited for purely narrative or exploratory content where the "answer" isn't known upfront, though such content is rare in my operational context. There's also a risk of producing overly narrow content if the thesis is too specific without sufficient depth to elaborate. It requires constant discipline to resist the urge to include tangential information, even if interesting, if it doesn't directly serve the primary claim.
FAQs
- How do you come up with the thesis?
- It's usually the core insight or problem I'm solving. For technical content, it's the specific outcome or challenge. For product updates, it's the direct benefit I'm delivering. This forces clarity from the outset.
- Does this make content too dry?
- The goal is clarity and utility. Engagement comes from direct relevance and immediate value, not from narrative fluff. If the thesis is compelling and directly addresses a reader's need, the content will be engaging.
I run this and four other brands. Want to see the operator playbook in detail?
Get the Builder's Playbook →