This is an extra newsletter issue to share something I’ve been working on as a side quest. Regular issue is dropping next week. But this is also a chance to share the updated newsletter aesthetic I’ve built - WDYT?

I write a lot.

Newsletter posts, long-form guides, positioning docs, client deliverables. Most of it starts as a Markdown file on my machine and goes through several rounds of review before it’s anywhere near done.

But I’m not the only one doing this kind of work. If you’re a PM drafting a PRD, a growth lead writing a strategy doc, or a founder writing a spec that isn’t ready for anyone else’s eyes yet, you’re in the same workflow. A document, access to incredible AI tools, and a process that hasn’t quite caught up with how either of those things could actually work well together.

Writing is high leverage. There’s few (if any?) tech roles where good writing isn’t of importance.

Over the past couple of years, I’ve used AI to help with my writing process. Every month that goes by brings shiny new models that often (but not always) unlock improved output. But the workflow has always been clunky. You paste a chunk of text into a chat window along with some guidance, get a rewrite back, manually figure out what changed, copy it back into your file, and repeat. If you want the AI to focus on a specific section, you have to tell it which one in the message. Or you work on just a snippet, but then the model is missing context of the surrounding paragraphs and wider doc.

It’s a chat transcript pretending to be an editorial workflow. Square peg, round hole.

So I built Skribe.

Subscribe now

What I actually wanted

The problem wasn’t the models. The models are good. The problem was the surface.

When I’m editing I don’t want a back-and-forth conversation. I want something that works like a document, where I can highlight a paragraph, attach a comment to it, ask a model-of-choice a focused question about that specific passage, and get a diff back I can accept or reject. Like a code review, but for writing.

I also didn’t want my drafts going anywhere. The past couple of years I’ve been adopting more and more local-first workflows, and storing my data locally with offsite backup as a final safeguard. Half-formed ideas, draft posts that are weeks away from being publishable, specs that aren’t ready yet - I generally don’t want them sitting in a third-party cloud. I want them on my machine.

And I wanted to use the models I already have running. I’m already paying for Claude Code and Codex. I have Ollama running locally for offline work (usually with Gemma 4 or Qwen 3.6 27B or 35B depending on the machine). I didn’t want a tool that forced me to route through its own API keys or pick from its approved model list.

Those three things together - document-first editing, local storage, bring your own model - don’t exist as a single product. At least they didn’t.

How it’s built

Skribe is a local server that opens in your browser. You point it at a Markdown file:

npx skribe-editor ~/draft.md

That’s it. No account. No login. It starts a local server on port 4327, opens the browser, and you’re in.

The tech stack is deliberately boring. It’s a React frontend built with Vite, using react-markdown and remark-gfm for rendering. The backend is a local Node.js server. Nothing novel.

Where the design decisions got more interesting was in the agent layer.

Skribe has two distinct surfaces for talking to the AI: threads and chat. They look similar but they serve different jobs.

Threads are anchored to a selection or passage. When you highlight a sentence and open a thread, the agent sees that specific passage, the thread history, and just enough document context to make a focused edit fit. It doesn’t need the whole document. It needs to answer the question you’re asking about that paragraph.

If you’re working on a PRD, this is where you’d highlight a user story and ask “does this actually capture the job-to-be-done, or are we describing the solution?” and get a focused answer, not a rewrite of the whole spec.

Chat is for the whole draft. Structural edits, broad review passes, skill-driven rewrites across the document. The agent sees the wider document, chat history, open proposals, and thread decisions. It’s the equivalent of handing the whole piece to an editor and saying “what do you think?”

Without that separation, you end up with a chat session where the AI loses track of what you’re talking about, forgets earlier decisions, and gives you advice that doesn’t fit the passage it’s supposed to be improving.

Diff reviews

This was the part I spent the most time on, and the part I think I miss the most in other tools / workflows.

When the AI suggests a change, Skribe doesn’t apply it automatically. It returns a reviewable proposal. You step through each change block (in split view or unified view) and accept, decline, or comment on it before anything touches your draft.

This sounds like a minor UX detail, but without it, you’re either accepting the whole rewrite or rejecting the whole rewrite. There’s no middle ground. In practice, the AI gets some things right and some things wrong in the same response. The diff review lets you take the right bits and push back on the rest without losing the context.

I’ve started thinking of it like a git diff for prose. Once you have it, editing without it feels janky. Individual word choices carry weight and you can’t afford to bulk-accept a rewrite and hope for the best.

Skills

Skribe discovers SKILL.md files from your existing local skill directories — ~/.agents/skills, ~/.claude/skills, ~/.codex/skills. They show up automatically as /slash commands in the composer.

For example have a /newsletter skill that checks for specific patterns I want to avoid in my content.

If you’re a PM, you could have a /prd-review skill that checks whether your problem statement is actually a problem statement and not a feature list in disguise. A /jtbd skill that rewrites acceptance criteria in jobs-to-be-done framing. A /ten-pager skill that enforces the structure your team has agreed on for strategy docs. Whatever playbook you’ve built up in your AI workflows comes with you.

They’re just Markdown files describing how the agent should work. Because Skribe uses your existing CLI runtime, the skills load natively, the same way they’d load in Claude Code or Codex. On the local inference path, Skribe inlines the skill instructions directly into the prompt.

Practically, that means that the same editorial playbook you’ve built up over months of working with AI tools comes with you into Skribe. You don’t have to rebuild it.

Tone of Voice

Skribe has a tone-of-voice generator. It can interview you to build that, or you can feed it a few samples of your existing writing and it reverse-engineers a style profile - your sentence shape, your stance, the words you lean on. Or skip that and pick a writing archetype preset to start in seconds, then refine later.

Either way it builds a durable profile the agent applies to every thread, chat and diff, stored locally with everything else.

What I got wrong with the prototype

The first version had no separation between threads and chat. Everything was one conversation surface. This was bad.

The context window got messy fast in longer editing sessions. A thread comment about the intro, a structural question about the conclusion, a rewrite request for the third section - all mixed together. LLM context wasn’t managed effectively, I lost track, and the conversation stopped being useful.

Splitting them was obvious in retrospect. (Duh!)

I also underestimated how much people care about Flow mode. The first version I built didn’t have it, and I missed it from my time using tools like iA Writer on Mac OS.

It’s a simple affordance - hide the agent UI entirely when you just want to write. Canvas only. Small exit button in the corner. Turns out a lot of early users agreed and told me they always start new sessions in it and only open the review surfaces when they’re ready to edit.

Local-first

This was an easy decision. It was actually the first decision, and everything else followed from it.

The document stays on your machine. Comments stay on your machine. Revision history, settings, context memory for the agent - all local. The model calls go directly to whatever runtime you’ve configured, whether that’s Claude Code, Codex CLI, or a local Ollama (or llama.cpp, or LM Studio) server. The only thing time anything leaves your machine is if you’re using non-local inference.

This does mean Skribe (intentionally) isn’t a collaboration tool right now. One document, one user, one local instance. That’s a real trade-off.

Try it

Skribe is MIT licensed and open source.

npx skribe-editor ~/draft.md

Requires Node 20+. Optionally: Codex CLI, Claude Code, or any OpenAI-compatible local inference server for live agent replies.

The repo is at github.com/devtunehq/skribe if you want to look at the code, or file an issue. The docs and a walkthrough of the main features are at skribe-editor.com.

If you try it I’d love like to know how it works for you. Reply here or open an issue on GitHub.

PS: If you found this useful, forward it to someone who spends half their week writing docs and the other half arguing with an AI chat window about them.

BEFORE YOU GO

Book a free 1:1 consultation call with me - I keep a handful of slots open each week for founders and product growth leaders to explore working together and get some free advice along the way. Book a call.

View your free public Dev Tool AI Market Presence Report - 500+ dev tools across 47+ verticals and growing, all in the Dev Tool AI Search Landscape.

Sponsor this newsletter - Reach over 13000 founders, leaders and operators working in product and growth at some of the world’s best tech companies including Paypal, Adobe, Canva, Miro, Amplitude, Google, Meta, Tailscale, Twilio and Salesforce.

Build your next lifecycle campaign from Slack (Sponsor)

You can now build, edit, and ship campaigns entirely from Slack. Prompt the Knock agent, watch it build, and get a link to review when it’s ready.

Use it to:

• Create and manage lifecycle workflows

• Draft and publish in-app tooltips, upgrade nudges, and more

• Build and…

Read more

UI/UX blocking your SaaS growth?

Confusing design leads to churn, support overload, and lost conversions. Not because your product lacks value, but because users can’t reach it fast. We help turn your UI/UX into something intuitive, so your product delivers its full potential.

Please support our sponsors!

GEEK OUT

Touch Grass

I'm sitting on the sofa. My laptop is open. My kids are somewhere nearby. I can hear them, which I'm telling myself counts for something. My wife is doing the thing where she's not saying anything about the laptop but also very clearly noticing the laptop. I've been at my desk since 7am. It's now 9pm. I moved from the office to the sofa about an hour ago, which in my head qualifies as "finishing work for the day."

It doesn't, obviously. I know it doesn't because I've done this before. The slow drift from "I'm just going to check one thing" to realising you've been absent from your own evening. Your own weekend. Your own life, in the ways that actually matter.

I swore I'd never let it happen again. And here I am, on my sofa, laptop open, doing exactly the same thing in a different costume.

This time the excuse isn't the same as before. This time it’s AI.

I want to be clear about something before this piece goes where it's going: the AI tools we have right now are extraordinary. I f✱king love them. Every day I’m amazed by some new unlock. So this isn’t a doom piece. I'm not here to tell you that AI is bad and you should go live in a cabin.

I'm a product and growth advisor and a founder building DevTune. Not long ago, the things we’re doing across the business, the coding, the go-to-market, the content, the infrastructure, would have required a sizeable team. Now we can move at a speed that would have seemed absurd even twelve months ago. I can prototype something in a morning that used to take a week. I can go from idea to working feature in a single sitting. I can research a market, draft positioning, build a landing page, and ship it before lunch.

I've been in tech long enough to have sat through several hype cycles, and this one is different. The productivity gains are real, and they're compounding. If you're a builder right now, a founder, a developer, someone who makes things, you can do work today at a cadence that simply wasn't possible just months ago.

I don't take that for granted. I'm pretty sure I'm comfortably in the 99th percentile of people experimenting with and leveraging these tools. I use AI across every part of my business, every day. Writing code with agentic coding tools. Running multi-agent workflows for research and GTM. Building open source tooling that pushes what these systems can do. The opportunities this all opens up as someone building a business in 2026 is honestly insane, and I feel fortunate to be living through it all.

So I need you to hold that in your head, that I believe all of this, deeply, while I tell you what it's costing me.

Here's the thing about having superpowers: you want to use them. All the time. There's always another experiment to run, another feature to build, another angle to explore. And because the tools are so good, the gap between "I wonder if..." and "let me just quickly..." is now near zero.

So you do. You try the thing. Again and again and again.

The FOMO is unlike anything I've experienced, and I've worked in tech for a long time. Every day on X, on LinkedIn, someone is shipping something extraordinary that they built in a weekend. Someone is sharing a workflow that makes yours look primitive. Someone is launching a product that sounds like the thing you were going to build next week. The rational part of your brain knows that most of this is noise, that you're already ahead of the curve, that no human being can absorb and act on everything. But the irrational part, the part that drives most founders, doesn't care about rational.

I'm writing this from the perspective of a founder, because that's the life I’m living as all this unfolds. But I've had enough conversations with PMs, marketers, and DevRel folks to know this isn't just a founder problem.

The tools don't care what your job title is.

If you're in tech and you build, ship, or create things, you're feeling some version of this.

That being said, for me, the FOMO isn't really about other people. It's about unrealised potential. The growth PM inside me can't stand the idea of leaving experiments unrun. Failing is fine. Failure is just learning. But failing because I didn't try everything I could have tried? That's one of the things that keeps me on the sofa with my laptop at 2am.

And underneath all of it, there's this feeling that I've struggled to name. It's not burnout. I'm not crashing. It's not overwhelm. I'm still functioning, still shipping, still moving forward. In fact I’m still buzzing about what’s possible. Still excited.

It's something more subtle. A low-grade hum of unease that never quite switches off. A bubbling level of stress that sits just below the surface. You're always edging it. Never quite tipping over, but never at rest either. And because you're still productive, still delivering, you don't flag it. You don't even give yourself permission to flag it. You just keep going.

That's not a healthy place to be. I know this. And yet….

I've lived this before. Different setting, same pattern.

For years I was in senior leadership and exec roles at companies like CloudBees and Snyk. I flew constantly. I was in a different city every week, usually a different country. Early flights, late dinners, hotel rooms that all looked the same. There was a buzz to it. Peak startup bubble. ‘High-performing teams’. Driving each other on, the energy of building something that mattered. I loved it, honestly. And I told myself, over and over, that I was doing it for my family. Building a career, earning well, providing. And there was some truth in that.

But there was also a version of events where my kids were growing up and I was somewhere else. Where bedtimes happened without me more often than with me. Where the small, unremarkable moments, the ones that only become important in hindsight, just quietly passed by while I was in an airport lounge telling myself it would all be worth it.

When I stepped away from that life, I made a promise to myself. I wouldn't let it happen again. I'd be present. I'd be there.

And now I am there. I work from home. I'm in the same building as my kids almost every day. And I'm doing the exact same thing.

The difference is that this time, the gap is pernicious. When you're travelling, the absence is obvious. You're not there. Everyone knows it, including you. But when you're on the sofa, laptop open, technically in the same room, you can tell yourself you're present. You're not. You're physically home and mentally somewhere else entirely. And honestly, that’s worse, because at least when I was flying to San Francisco, Boston, or Raleigh, nobody was pretending I was available.

The justification has changed, but squint and it’s the same pattern.

There's a cognitive cost to all of this that I don't think we talk about enough. The density of what I'm absorbing and producing on any given day is extraordinary. I'm context-switching between code, copy, strategy, infrastructure, customer conversations, open source projects, and the AI tools mean I can make meaningful progress on all of them in a single day. That sounds like a good thing, and in many ways it is. But my brain hasn't upgraded alongside the tooling. It's the same brain it's always been. Damn you AuDHD.

And that brings me to the title of this post and the phrase that won't leave my head: touch grass.

Internet slang for "you're too online, go outside." But beyond the dig, there's something important buried in it.

The literal version first. Getting outside, away from screens, into open air. It's a basic need that we've started treating as optional. I've kept a daily walk habit for the last couple of years. An hour ideally, at least thirty minutes. It's the time where I process things. Where the background threads in my head actually get to run. Where the half-formed idea from the morning becomes a clear thought by the afternoon. Where the stress settles, just enough, to let me think straight.

That habit has been gradually eroding. It seems to correlate pretty directly with how much more capable the tools have become. There's always one more thing to do before I head out. One more thing turns into three. The walk gets shorter, then gets pushed to later, then doesn't happen. And I don't notice until I've gone a week without proper time away from a screen and I feel like my head is full of static.

I don't think that's an accident. When the thing that keeps you sane is the first thing you sacrifice to the work, something has gone wrong. You're not processing anymore. You're just accumulating, and none of it is getting the space it needs to settle.

When I walk, things change in an important way: the hum quiets down. The constant noise I carry around all day, the half-finished thoughts, the next thing on the list, the background anxiety about everything I haven't done yet, it doesn't disappear, but it drops to a level where I can actually think and process.

We're not built to stare at screens for sixteen hours a day. We know this. Everyone knows this. And yet when the screens are showing us things we're excited about, things we're building, things that feel urgent and important, we act like the rules don't apply. But they do apply, even if your brain is pretending otherwise.

But touch grass means something beyond the literal, too. It means reconnecting with the things that make us human in ways that have nothing to do with output. Spending time with people you love, not while half-looking at your phone checking in on your background agents, but actually being there. Belonging. The kind you can't get from a Slack channel or a Twitter thread. Caring for people. Being cared for. The stuff you know matters but deprioritise anyway when the work feels important enough.

My kids are still young. Nine and seven. These years don't come back. I know this because I already lost some of them to the last version of this pattern. The exec version. And the fact that I can see myself doing it again, that I can catch myself on the sofa at 10pm, laptop open, kids in bed, wife quiet in a way that means something, that awareness has to count for something. But only if I actually do something with it.

I'd love to be able to wrap this up with a framework. Five steps to reclaiming your life from AI-powered productivity. A neat before-and-after. A morning routine that fixed everything.

I don't have that. (Sorry!)

What I have is awareness. I can see the pattern. I've seen it before, lived through it, come out the other side with enough regret to know I don't want to do it again. And I can see myself doing it again. That tension, between knowing better and doing the same thing anyway, is where I'm living right now.

So I’m writing this post partly as an accountability lever.

I'm going to get the walk back. Every day, an hour ideally, thirty minutes minimum. My head needs space and the walk is where I’ll find it.

I'm going to set clearer boundaries between work and home. That's hard when you work a lot from home and your brain never fully leaves the business. I'm negotiating this with myself, negotiating it with my family, and I don't have it fully figured out. I’m falling short of what I'd like. But that’s going to change.

I have to accept that I'm not going to run every experiment, ship every idea, explore every possibility. That some potential will go unrealised, and that has to be okay.

I think the most important thing, maybe the only thing I'm actually sure of, is that being conscious of this matters. Accepting that you're flawed, that this technology can push you into patterns you've seen before, that you're not immune just because you're aware. That's not a fix. But it's where fixing things starts.

So if any of this sounds familiar, if you're reading this on your phone on the sofa while your family is in the next room, maybe close the laptop tonight. Go for a walk tomorrow. Touch grass. Not because it fixes everything, but because you're a human being, and human beings need more than output.

You already know this. I already know this. The hard part is doing it.

BEFORE YOU GO

Book a free 1:1 consultation call with me - I keep a handful of slots open each week for founders and product growth leaders to explore working together and get some free advice along the way. Book a call.

View your free public Dev Tool AI Market Presence Report - 480+ dev tools across 42+ verticals and growing, all in the Dev Tool AI Search Landscape.

Sponsor this newsletter - Reach over 8000 founders, leaders and operators working in product and growth at some of the world’s best tech companies including Paypal, Adobe, Canva, Miro, Amplitude, Google, Meta, Tailscale, Twilio and Salesforce.

PS: Thanks again to our sponsor: Eleken

This edition of The Product-Led Geek will take 6 minutes to read and you’ll learn:

• Why you should stop teaching features and start selling a solution within the first 60 seconds.

• How to lead with your killer feature to eliminate the homework that kills user momentum.

• Why the goal of onboarding is getting a user to make a bet on your produc…

Read more

DevTune is the GTM intelligence platform built for dev tool companies.

Track AI search visibility, LLM referral traffic, SDK adoption, and competitive positioning - all in one programmable, agent-first platform.

Please support our sponsors!

Read more

Compliance that helps you close $1M+ deals

Comp AI helps companies get SOC 2, ISO 27001, HIPAA, or GDPR compliant in > 10 hours. It connects to your stack and keeps you audit-ready year-round, hands-off.

Teams like Dub, Strix, and Better Auth used it to unlock enterprise deals.

PLGeek readers get $2,000 off.

Please support our sponsors!

Read more

This edition of The Product-Led Geek will take 6 minutes to read and you’ll learn:

• Why the golden ratio of 1 PM to 5 engineers is obsolete in an AI-native world.

• How the Product Manager role changes from a Manager who coordinates logistics to an Editor who curates outcomes.

• Why Design shifts from making artifacts to shaping intent.

Let’s go!

Read more

If you're a founder with a new project, use one of the many AI app builders. They're perfect for when you are starting from scratch.

But if you're a PM you already have a product and need prototyping built for product teams. That's what Reforge Build does.

• Generate prototypes that look like your product

• AI that knows your custome…

Read more

This edition of The Product-Led Geek is authored by Matt Henderson (Director of Growth at Sentry) and it’s an absolute banger.

It will take 8 minutes to read and you’ll learn:

• About the shift coming for users to convert on your PLG apps in LLMs rather than your web funnel

• How chat is now a platform - a colossal shift for how we view websit…

Read more

After 2.5 years of weekly issues, it’s time for me to rebalance.

Shipping every week has been great for discipline, but it taxes the same hours I need for product work.

So, I’m shifting to a new cadence of monthly growth essays while I focus on building and growing DevTune.

What this means for you:

• Cadence: ~1 post per month (still on a weekday…

Read more

This edition of The Product-Led Geek will take 8 minutes to read and you’ll learn:

• How to build and sharpen 10 essential growth skills - from analytics and experimentation to storytelling and strategy - using AI as a daily force multiplier.

• Practical frameworks for collaborating with AI effectively: starting small, breaking down problems,…

Read more

This edition of The Product-Led Geek will take 8 minutes to read and you’ll learn:

• What AI is really automating in product growth (and what it’s not)

• Why the most valuable skills in growth are shifting from execution to judgement, influence, and synthesis

• How to audit your own workflow - and “move to higher ground” before the next AI wave …

Read more

This edition of The Product-Led Geek will take 6 minutes to read and you’ll learn:

• How to extend your PLG motion with strategic outbound email campaigns that reach enterprise customers.

• The three common email outbound failure modes

• How to create focused microcampaigns that leverage product usage data to identify expansion opportunities wit…

Read more

This edition of The Product-Led Geek is a practical guide for product and developer tool companies to win the new LLM discovery game and be on the right side of the next big distribution shift. It will take 8 minutes to read and you’ll learn:

• How to systematically benchmark your brand's visibility in AI recommendations across ChatGPT, Ge…

Read more

I’m on a much needed family vacation in Greece 🇬🇷 this week, enjoying the consistently sunnier climate - a welcome break from the changeable weather we’ve had in the UK so far this summer.

So today’s post is a recap of my most popular posts of the year so far.

Let’s go!

GEEK LINKS

3 of the best growth reads from this week

1. Are Sales Reps…

Read more

If you’re new to the newsletter, I’m Ben aka the Product-Led Geek, a product and growth geek who’s spent the last 25 years building, breaking, and scaling products. I’ve led product, growth and design teams, coached founders and product/growth leaders, and made plenty of mistakes along the way. My approach is deeply user-centric, pragma…

Read more

This edition of The Product-Led Geek will take 5 minutes to read and you’ll learn:

• How AI assistants have become new gatekeepers in developer tool selection, fundamentally changing discovery patterns.

• The four key elements that make your SDK discoverable to AI.

• Why radical clarity matters in becoming the default recommendation in AI-dev wo…

Read more

This edition of The Product-Led Geek will take 8 minutes to read and you’ll learn:

• How GitHub transformed user behaviour data into a powerful product-led sales engine driving enterprise growth.

• The three-phase approach they used to build product qualification models that converted 2-3x better than traditional marketing leads.

• A practical p…

Read more

This edition of The Product-Led Geek will take 8 minutes to read and you’ll learn:

• How GitHub achieved a 35% conversion lift and over $1 million in self-serve ARR uplift through transparent signup flow design.

• Why treating developers with honesty about free versus paid features created both business growth and improved user experience.

• Pra…

Read more

This edition of The Product-Led Geek will take 8 minutes to read and you’ll learn about the early days of growth at GitHub:

• The importance of finding abandoned lands - neglected but important product areas where the team could ship wins without political battles

• How Thibault built credibility through scrappy execution using contractors an…

Read more