AI PM Toolkit

The problem

As corporations adopt AI, PMs are spinning up one-off tools for every use case — a PRD generator here, a deck builder there, a roadmap prompt somewhere else. The result is AI slop: a sprawling collection of half-finished tools where no one can tell which are actually useful. I felt this firsthand and wanted one place that pulled the tooling PMs actually reach for into a single, opinionated workbench.

What I built

A web app with a PRD builder, a deck builder, and a library of practical guides — all powered by the Claude API, all in one consistent interface. Each tool is purpose-built for the artifact it produces, not a chat window dressed up as a feature. The guides sit alongside the tools so a PM can learn a prompting pattern and then run it without leaving the site. I'm excited to see what PMs think — feedback link in the header.

Three product decisions

Decision one — Purpose-built tools over a single chatbot

I could have built one chat interface and let PMs prompt their way to a PRD, a deck, or anything else. I rejected that. The bar for a useful PM tool is that the output is immediately shareable — a structured PRD, a deck outline a stakeholder can read at a glance. A chatbot pushes the formatting work back onto the PM. Each tool in the toolkit constrains the model to a known structure, so the output is usable on the first generation instead of the fifth. The tradeoff: less flexibility, and every new artifact type is its own build.

Decision two — Ship guides alongside the tools, not as a separate product

Most "AI for PMs" content is either tools or a newsletter. I put them in the same place because the friction in PM-AI adoption isn't tooling — it's knowing what to ask. A PM who reads the prompting guide and then immediately tries it in the PRD builder learns faster than one who reads a Substack and never opens a tool. The tradeoff: scope creep, more content to maintain, and the guides have to stay current as model behavior shifts under them.

Decision three — Vanilla HTML over a framework

No React, no build step, no Next.js. The toolkit is a small set of mostly independent tools — each is a form, an API call, and a rendered output. A framework would have added a build pipeline and node_modules for no payoff, and a recruiter cloning the repo shouldn't need npm install to read the source. The tradeoff I accepted: no client-side state across tools (no output history, no saved drafts yet), and refactoring will be harder if scope grows. I'd revisit this when the toolkit actually needs persistent state.

What I'd do differently

Talk to five PMs before writing a line of code. I built on the hypothesis that PMs want unification over one-off tools. That's plausible but unvalidated — some PMs prefer specialist tools they can swap in and out. A handful of 30-minute interviews would have either sharpened the wedge or pointed me at a different one, and either way the v1 would have been more confident.

Pick one success metric upfront. I didn't define what "good" looks like before shipping. Weekly returning PMs? Outputs generated per session? Feedback responses? Without one metric, the easy thing to optimize for is more tools — the cheapest thing to add — instead of one better tool. If I rebooted, I'd instrument for "outputs the PM actually used downstream" from day one.

Proxy the API calls from day one. The client-side Claude API key is fine for a portfolio demo but it's a known-bad pattern, and the polite caveat in the README ("a production version would proxy through a serverless function") is doing a lot of work. A Vercel Edge Function is twenty lines of code. I should have started there instead of treating it as a v2.