Quick note before we get into it: I'm reworking this newsletter over the next few weeks. More on that soon. For now, here's what's been on my mind.
I recently went back to working alone on Commune. I tried delegating marketing and it didn’t stick. At this stage, marketing is how I learn what users actually need. Doing it myself isn’t just cheaper, it’s the fastest feedback loop I have.
With the money I saved, my first instinct was to hire a developer. But Commune doesn’t need more features right now. It needs more newsletters and more people. And here’s the trap: as developers, we love fixing GTM problems with code. It’s where we feel competent. Shipping a feature feels like progress. Messaging strangers on LinkedIn does not. But no amount of code will make users show up. You have to go find them, talk to them, and invite them in.
So I flipped my priorities. Coding is now scoped to UX improvements and immediate user value. Everything else —outreach, strategy, social— comes first. Which meant I needed a way to juggle all of it without burning out.
Themed days don’t work
My first instinct was to split the week by type of work. GTM Monday, coding Friday, and so on. I’ve tried this before. It fails every time.
- I don’t control when creators are free to chat. If outreach is the priority, I can’t push a call to next Tuesday because it’s “coding day.”
- If I miss a day, I lose a week on that task. Fragile.
- By the time “social media day” rolls around, I have to mentally replay everything valuable that happened earlier in the week. That recall tax is brutal, and usually I just skip the posts entirely.
The reason themed days fail is that I was thinking about context switching wrong.
Context is the goal, not the tool
Context switching isn’t about changing tools or types of work. The context is the goal you’re working toward.
Once I saw that, the solution wrote itself: organize by scope, not by task type.
A scope might be “make the newsletter profile page customizable.” On paper that looks like a coding task. In practice, doing it well means:
- Meeting with creators to understand what they actually want
- Writing the code
- Posting on social so users know it exists
Three kinds of work, one context. I code while the conversations are fresh. I write social posts while the feature is top of mind. The recall tax disappears.
The rhythm
I’m running this in one-week cycles —Shape Up-style bets with defined scope, no cooldowns. Six weeks is too long at this stage. I need faster feedback on whether I’m betting on the right things.
I just wrapped the first cycle. I didn’t finish every item on the list, but I hit every priority by Wednesday. The leftovers were all non-urgent code. Exactly the stuff that should slip first.
Next cycle is two weeks long. I’ll keep posting short updates on Commune as I test this (they probably don’t deserve their own email).
Have you ever caught yourself building features instead of talking to users?
Pst! I see you're not on Commune yet. Click here to join us!
