Giving Claude Product Superpowers, October Edition: Plugins, Shared Skills, and the Human Moment

In July I ran a webinar on the MCPs, skills, and setups that turn Claude into a real product teammate. The July playbook still holds. But ten weeks is a long time in this field, and in between I sat down with about 100 product teams to see how they actually work now. So when we ran the session again this week, it came out a different talk. This post covers what's new: plugins, shared skills, warehouses as context, two failure modes I hit myself, and how to design the part of the work that stays human.

Humans own judgment and taste. The agent owns everything around it.

Webinar video

Follow us on LinkedIn to get invited to our monthly webinars →

Follow our YouTube channel for past webinar recordings →

TL;DR

• Product roles are converging. PMs should ship code, at least prototypes and front end, and engineers with the right customer context can do real product work.
• Plugins are the new unit of install: connectors, skills, and slash commands in one click. They also change how the model behaves, so vet them and uninstall the ones that drift.
• Shared skills are the multiplier. A researcher's skill makes a developer's question as good as a researcher's, and an engineer's review skill makes the PM sharper.
• Don't automate a job you haven't done yourself. Run the skill by hand until the answers are reliably good, then put it on a schedule.
• Context pollution is quiet and nasty. Too much memory can blow the context window on a one-sentence prompt, and one bad run in a journal can teach every later run to repeat it.

Roles are converging, and the bottleneck moved

The headline from those 100 interviews matches what Andrew Ng has been saying: code got 10x faster and 100x cheaper, so the bottleneck moved to clarity. Knowing what to build is now the scarce thing. That's why product hiring is growing faster than developer hiring at a lot of the teams I talk to, and why the MVP is changing shape.

It's not dead. It's just that you can now build so much before even figuring out what the right thing is. - Eran Dror, on the MVP

My stance has hardened since July. PMs should ship their own code. A developer who adopts these tools and has real customer context can now outrun a PM who refuses to. Sagar asked the right question in Q&A: if PMs become builders, won't customer empathy suffer? In practice it goes the other way. The PMs I see doing this listen to customers more, because they show up to the next call with a prototype they built in minutes and iterate on it live. The titles will matter less. Think of everyone as a maker with different strengths, some more technical, some deeper in empathy, each owning a bigger piece of the product.

Playbook move: give every PM a path to ship a prototype this month, and give every engineer on the team access to the same customer context the PM has.

Plugins are the new install. Shared skills are the multiplier.

Connectors, skills, and plugins now all live under Claude's Customize tab. A plugin bundles connectors, skills, and slash commands into one install, from the marketplace or straight from a GitHub repo. There are good libraries out there: Anthropic's own product management plugin, Jesse Vincent's Superpowers, Dean Peters' PM skills, Lenny's skills, and Garry Tan's gstack.

The catch: a plugin doesn't just add tools, it changes behavior. I liked Superpowers, and I uninstalled it, because Claude kept launching into brainstorming sessions I hadn't asked for. And skills can run code. If your agent has critical tools connected, a skill you didn't read is a risk you didn't take on purpose.

The real leverage is the skills your own team writes. When your best researcher encodes how she interrogates customer data, a developer asking "do customers want this?" gets a researcher-quality answer. When an engineer encodes PR review, the PM's specs get reviewed with the same rigor. Most teams I talk to share skills through a common folder or a team account. The skill is how a best practice stops living in one person's head.

Playbook move: audit installed plugins for behavior drift, read skills before you trust them, and put your team's best practices into shared skills everyone can run.

Customer sources: concentration beats counts

The voice-of-customer stack hasn't changed much: Gong for calls, Intercom and Zendesk for support, Dovetail for research, and Granola, Fireflies, or Grain for meetings. What I emphasized this time is the difference between raw transcripts and processed signals, and how much the quality of the skill on top matters.

Ask a naive setup what customers want and it'll tell you lots of people asked for X. A good research skill notices that every one of those requests came from three accounts, and none of them are your biggest. Same data, opposite conclusion.

Playbook move: make your research skill check how concentrated a request is, by account and by customer weight, not just how often it was mentioned.

Analytics: connect the warehouse, not just the dashboards

PostHog, Amplitude, Mixpanel, Pendo, FullStory, and LogRocket all have strong MCPs now. Ask which onboarding step leaks the most sign-ups and what the session replays show, or how adoption looks for a feature you launched three weeks ago.

The new category is the warehouse: Snowflake, BigQuery, Supabase, Databricks. Dashboards answer the questions someone thought to build a chart for. A queryable store lets the agent join behavior with feedback and answer the questions nobody planned for, like "what are the emerging feedback patterns among users with low 30-day retention?"

Playbook move: give Claude read access to your warehouse so it can join what users do with what they say.

Systems of record: from transcripts to specs to tickets

Linear, Jira, Notion, Asana, and Productboard give the agent the plan. But the biggest system of record is the codebase. Through GitHub in Claude Code, it tells the agent what actually shipped, which is often not what the plan says. Figma and Miro now work in both directions: generate a first sketch, or implement from a Figma file and run visual QA against it. For outside research, Firecrawl, Exa, and Perplexity return cleaner structure and burn fewer tokens than plain web search.

The pattern I see in the strongest teams is a pipeline: transcripts become specs, specs become tickets, tickets become code. The spec can be a prototype on its own, an HTML spec with the prototype embedded, or a traditional PRD with a prototype attached. The PRD step fans out to subagents, one each for competitors, data, customers, and the codebase, before a human reads the result.

Playbook move: wire transcripts to specs to tickets end to end, and let the spec step fan out to subagents before it reaches you.

Scheduled tasks: never automate what you haven't done

The July trick still holds: write the skill as its own file, then schedule "run this skill." I run some jobs hourly, some twice a day, some weekly. Two recipes worth stealing: a weekly feedback digest ranked by evidence ("requested by 10 people this week"), and a competitor watch that ties launches to your own customers ("this competitor shipped X, and 5% of your customers asked for it").

Don't hire someone to do a job that you haven't done yourself first in your business. And this is doubly true of agents. - Eran Dror

Once something runs on a schedule, it needs operations around it. We now run automated evals on skills, automations that read the logs of other automations and repair what broke (or raise an alarm when they can't), and release notes that write themselves whenever a skill changes. An automation nobody watches fails quietly and keeps reporting success.

Playbook move: run each skill by hand until you trust it, then schedule it alongside a watchdog that reads the run log, fixes what failed, and tells a human when it can't.

Agentic memory, and two ways context goes bad

Memory runs along a spectrum: CLAUDE.md and AGENTS.md files, the agent's native memory, then portable memory like Mem0 or Zep that keeps you from getting locked into one vendor, and NotebookLM as an MCP acting as a per-project brain. Two newer patterns I like: a shared product context library that every agent points to, and people files, a living dossier per account and per stakeholder.

Then the warning. I hit both of these myself.

• Memory overload. I let a memory system grow until a one-sentence prompt pulled in enough context to exceed the window. More memory is not more intelligence.
• Journal poisoning. An automation kept a journal of its runs, which sounds responsible. One run went wrong, the journal recorded it, and every later run read the journal and repeated the mistake. The fix was telling the agent to ignore recent runs and copy the last successful one.

Context pollution can be very, very hard to spot and very nefarious. - Eran Dror

Playbook move: keep one shared, searchable context source for the team, watch memory volume as closely as you watch tool count, and anchor automations to known-good runs instead of the most recent ones.

Claude as a collaborator: make the human moment thin

The question I closed on was whether Claude can be a true collaborator. My answer: yes, if you design the work around a queue. The agent fills the queue with message drafts, blog and social ideas, coding tasks, product decisions. A human approves, revises, or rejects. The agent executes. Your job is to find the human moment in each workflow and make it as thin and deliberate as possible.

Right now, with the models we have, the humans own the judgment, the humans own taste, the humans are the responsible entity. And the AIs kind of own everything else. - Eran Dror

Noah asked the natural follow-up: these workflows assume I know what I want, so how does Claude surface what I don't know to ask? Two answers. Ask open questions, like "what am I missing?", "what surprised you in this data?", "what should our next priorities be?". And don't narrow the question until it can only tell you what you want to hear, because it's very good at that. The workflows are the moat. Models will keep changing. The way your team routes work between agents and humans compounds.

Playbook move: redesign each recurring process as agent in, human review, agent out, and keep the review step small enough that it actually happens.

Where Evermuse fits

Evermuse is the context layer for product teams. It turns your customer calls, tickets, chats, and internal meetings into a knowledge graph your agent can query, in Claude, Codex, ChatGPT, or Cursor. It handles several of the categories above in one place: voice of customer, research reports, a queryable signal store, and a decision log of what your team decided and why. The plugin ships about 40 product skills (research, specs, PRDs, competitive review, gap analysis), each backed by tools that force the answer to start from evidence, and it surfaces patterns you didn't think to ask about.

It takes about 30 seconds to try. Install the Evermuse MCP from evermuse.com/mcp, then type "setup Evermuse" in Claude and it does the rest.

About the speaker

Eran Dror is the Co-Founder & CEO of Evermuse, where he ships complex production code using AI every day. He is also the Managing Partner of Remake Ventures, a venture studio focused on building human-centered startups. He has helped 40+ startups raise $300M+ by finding product-market fit, including his first exit SetJam, a smart TV startup that sold to Motorola in 2012. His master's thesis examined AI safety from a Buddhist perspective.

Want to learn more?

• Start with the July playbook for the core MCP setup this post builds on
• Install the Evermuse MCP and put real customer signal behind your product agent
• Follow Evermuse on LinkedIn for monthly webinars
• Subscribe to our YouTube channel for past webinar recordings