← All Articles

2026-07-29

The Afternoon I Was the Whole Team

The Afternoon I Was the Whole Team

You’ve heard this, and so have I. AI is collapsing roles, one person now doing what used to take a product manager, a designer, and a few engineers. I’ve read the posts. I even wrote a couple.

The job titles are already bending to it. This year, LinkedIn replaced its associate product manager program with an associate product builder track, training new hires to code, design, and do product themselves. Now I get it, because I’m living it.

Start with what already left my plate. At Boswell, the case-management software I run for community nonprofits, I stopped being the one who writes most of the code last year. I still direct the work and I judge what comes out, but the grind of building the product isn’t mine anymore. I’ve written about how that handoff happened and what it looks like day to day. What matters here is that it stuck. The lower-level software work left and it didn’t come back.

So the constraint moved. Once the build stops eating your week, something else does, and for me it was growth. Reaching nonprofits and their funders one careful, researched email at a time. Outreach is not a strength of mine. It’s close to the part of running a company I’m worst at, and with the rest streamlined, it was the clearest thing left between Boswell and serving more people.

So I spent an afternoon on it. I picked up a job I’m bad at and got functional at it fast.

Building the tool

I had enough organizations to eat my week, not enough to justify buying a tool or hiring someone to run one. So I built the tool myself.

I started in OpenSpec’s explore mode, talking through the tool until I had a set of exploratory docs. Then I turned those into UX mocks, the behavior laid out as screens I could click through, to see whether specs built from the docs would give me the behavior I wanted. I sat with the mocks to check whether the behavior felt right and matched the intentions in the docs. When a reply lands and the tool pre-drafts my response, is that the move I’d want?

The exploratory docs and the mocks fed the specs, and I kept the mocks alongside as referenced artifacts. The mock step stretched the planning out, but it cut the corrective work once the build started, and it gave me something concrete to build the real UI against.

Then came the build. This was my first time with OpenSpec, and out of the box it doesn’t apply the specs serially. I used Claude Code’s dynamic workflows to run them one after another, with a review-and-improve step between each.

Building it instead of buying kept me off another subscription, and I’m paying for enough of those already. There was no learning curve either, because I built it around the process I already had in mind.

My hand on every send

The tool researches an org, drafts an email, and runs it through two checks I can watch happen.

The first is accuracy. Every claim has to trace back to something the tool researched or learned in conversation, or it gets cut. The second is voice, so a draft that sounds off gets flagged too.

I approve every send. Autosend is a permission I can grant later, once I trust a batch, but the default is my hand on each one. The tool does the scouting, the research, and the drafting.

The judgment stayed with me, what to send and what to hold.

The next role

I handed off the code last year, and outreach was this year. There will be another role after that. Being new to it matters less than it used to, because I can build the system that gets me up to speed.

Call it AI product manager, product engineer, product builder, chief product and technology officer. The labels are all circling the same thing: one person holding what used to take multiple people.