Claude, Shipping — The Product Plugin

People tend to assume the product plugin decides what to build next for you. It doesn't. What it actually does is narrow the options, and understanding that distinction matters more than it might first seem, especially if you're building solo with more ideas than time to build them.

The missing product manager

Big teams have someone whose job is to ask who a feature is for, what problem it solves, and what's deliberately not being built. Build solo, and nobody asks those questions unless you build the habit of asking them yourself. The product plugin is that discipline installed. Picture the typical solo builder: ten ideas on sticky notes, a few hours a week to build, and a steady pull toward whatever feels most fun to work on. Left alone, that pull wins, and you end up chasing the interesting feature instead of the one that actually moves the product. The plugin's job is pulling you back toward the second one.

It works as a structured thinking partner rather than a yes-machine. It pushes back, asks the awkward question, and makes you justify a plan before you sink a week into building it, using four questions a good product manager always asks: who is this for, what problem does it solve, how will you know it's working, and what are you deliberately not building, and why.

From a rough idea to a real spec

That discipline lands as five concrete kinds of output: feature specs, user stories, feedback synthesis, a roadmap, and release notes. These aren't paperwork for its own sake, they're artifacts meant to keep you from building blind. Give it a rough idea, something like "add booking to my site, people pick a slot and get a confirmation," and it returns an actual spec covering what the feature does, who it's for, the user flow, the edge cases, and how you'll know it's done. That spec is where the real value shows up: it forces edge cases, like what happens when two people try to book the same slot, out into the open before you're halfway through the code and blindsided by them.

From there, one broad want fans out into small, testable stories: see the open slots, pick one, enter details, get a confirmation, reschedule if needed. Each story is buildable in a single focus session, and written out this way it reads like a checklist you can actually execute against, one story per line, each with a clear definition of done. You build story by story, testing as you go, and the feature accretes from small wins instead of arriving as one risky, all-or-nothing launch.

Ranking feedback without rewarding volume

The real bottleneck for a solo builder is usually simple arithmetic: ten features, a fixed and limited number of hours a month to build them. Something has to go first, something has to wait, and something probably shouldn't get built at all. Pointed at months of feedback, emails, surveys, support tickets, the plugin reads all of it and ranks the patterns by how often they come up and how much they hurt, rather than by how loud any single voice is. That distinction matters because a folder of feedback is a wall of voices, and the loudest one always feels like the most urgent thing to fix. The plugin counts instead of listening for volume, surfacing the quiet pattern a dozen users independently share, the kind of signal that's easy to miss while straining to hear the shout. Optimize for loud and you build for a handful of people; optimize for common and you build for the many.

It applies the same reframing to release notes. A note that says "optimized the rendering pipeline" means nothing to anyone outside your own head. Rewritten from the user's side, "your dashboard now loads in under a second," the same change reads as something a user actually felt, so a quiet bug fix lands as "they actually heard me."

Writing down the why

For bigger technical decisions, like building your own login system versus using an outside service, it lays out tradeoffs, cost, complexity, flexibility, upkeep, in one clean comparison so you can make the call with the reasoning visible. Six months later, when you're wondering why you went a particular direction, the reasoning is written down rather than something you have to reverse-engineer from memory.

What it does, and what it deliberately doesn't

Being precise about the plugin's actual job matters here: it gathers feedback, structures specs, ranks options, and drafts release notes, four kinds of grunt work done fast and done well. But ranking is not deciding. It can tell you a feature scores higher on impact and feasibility, but it can't know your particular bet, your users, or your gut sense of where the product is heading. Of the ten hypothetical ideas, it narrows the field, but the pick is still yours. It hands you a shortlist, not a verdict, and that caveat isn't fine print, it's the entire point of how the tool is designed to work.

Key takeaways

• The product plugin narrows options rather than making the final build decision; that call stays with the person at the desk.
• It ships five concrete outputs: feature specs, user stories, feedback synthesis, a roadmap, and release notes.
• Turning a rough idea into a real spec forces edge cases into the open before you're deep into building.
• Feedback gets ranked by frequency and severity rather than volume, so a handful of loud requests don't drown out a quieter, more common need.
• Release notes get rewritten from the user's perspective, turning technical changes into outcomes people actually notice.
• The plugin explains tradeoffs and documents the reasoning behind technical decisions, so the "why" isn't lost months later.

Try it yourself

If you're building solo and have more feature ideas than time, try this directly in Claude: list the features you're considering this quarter, how many hours a month you actually have to build, and who your users are, then ask it to sort them into what to build first, what can wait, and what's a distraction dressed up as a good idea, with a reason for each. Then push back on its ranking, since the argument itself is the point. The code for this walkthrough is available in the Humanitarians AI YouTube GitHub repository under the Claude Basics playlist.