Product Manager's Assistant

Every product manager regularly faces consulting-grade questions. Should we build this? What is the real problem behind this stakeholder complaint? Which of these three options do we commit to, and what do we sacrifice? The discipline for answering them well exists - it is exactly what strategy consultants are trained on - but for most PMs it is locked away in expensive engagements, dense books, or the head of that one principal PM everyone queues up to talk to.

I had already converted that discipline into software once: PM-Consultant-Skills, a set of 21 Claude skills that codify the consulting method, each one turning business inputs into a client-ready artifact. But skills have a distribution problem. They only work if you run Claude, install the plugin, and know the skills exist. The Product Manager's Assistant removes all three conditions: it is a single web page where any PM picks a skill, pastes their situation, and gets the structured deliverable streamed back. No account, no install, no Claude subscription.

The Problem: Good Frameworks, Zero Distribution

The discovery question here was not "do PMs need structured thinking tools" - the PM-Consultant-Skills repo had already validated that the artifacts are useful. The question was sharper: why does a working set of 21 skills reach almost nobody?

Three friction points kept coming up:

• Installation friction. Skills live inside Claude. To use them you need a Claude plan, the plugin file, and the confidence to install it via Settings. That filters out most of the audience before the first output.
• Conversation friction. Skills are designed for a dialogue: they ask follow-up questions when context is missing. That is right for a chat session and wrong for a busy PM who wants to paste a paragraph and get an answer, not have an interview.
• Discovery friction. Twenty-one skills is a catalogue. Inside a chat client there is no map of which skill to reach for when you are stuck mid-decision. The phase structure (Diagnose through Measure) existed in the README, not in the product.

The gap: the thinking system existed and worked, but there was no zero-install surface that put the full catalogue in front of a PM, organised by where they are stuck, with the conversation flattened into a single shot. That surface is the product.

Who It's For

• The IC product manager mid-decision. They have a messy situation - a feature request from the biggest customer, a metric that dipped, a roadmap fight - and need to turn it into something structured before the next meeting. They will never install a plugin; they will absolutely paste three paragraphs into a text box.
• The PM who wants to think like a consultant. They know their recommendation docs are weaker than they should be. Running their own situation through Problem Framer or Trade-Off Analyzer teaches the discipline by showing the shape of a rigorous answer to their problem, not a textbook example.
• The consultant or founder without the toolchain. Same jobs to be done as the original skills, minus the Claude setup. For them the portal is the product; the repo is an implementation detail.

The shared need: the deliverable, not the dialogue. That single insight drove the biggest design decision in the build.

The Three Insights That Made It Buildable

Defining the MVP

As with every project in this series, I wrote the goals and non-goals down before touching code.

Goals

Non-Goals (Just as Important)

• No accounts, no history. Nothing is stored. The output belongs in the user's doc, not my database.
• No chat. One query in, one deliverable out. Iteration happens by editing the query, not by conversing.
• No skill editing. The 21 skills are the curriculum; the portal does not let users write their own.
• No agentic chaining. The chain (Problem → Evidence → Options → Recommendation → Roadmap → Value) is a usage pattern the UI encourages, not an automated pipeline. Automating it is a v2 candidate, not an MVP requirement.
• No model picker. One fast default, one env-var override (GROQ_MODEL). Choice here is a distraction.

Architecture: One Route, Twenty-One Prompts

The whole system is deliberately small: a Next.js 14 App Router app with a single API route, a skills catalogue compiled into the bundle, and Groq as the inference layer. There is no database, no auth, and no state beyond the current request.

Browser (vertical tabs, 6 phases / 21 skills)
  ↓  POST /api/generate { skillId, query }
Next.js Route Handler (Vercel serverless)
  ↓  validate request → look up skill in lib/skills.js
Groq API (llama-3.3-70b-versatile)
  system prompt = the skill's adapted SKILL.md
  user message  = the PM's query
  ↓  token stream
Plain-text stream → client renders as markdown

lib/skills.js is the heart of it: an array of 21 objects, each carrying an id, phase, description, and the full system prompt generated from its SKILL.md. Embedding the prompts in the bundle instead of reading files at runtime keeps the API route dependency-free and the cold start minimal.

The six phases give the UI its information architecture, and the skill counts per phase fall out of the source repo:

Takeaway: When the intelligence lives in the prompts, the right amount of application code is almost none. Every layer I did not build (database, auth, session state) is a layer that cannot break.

From SKILL.md to System Prompt

The most interesting engineering in the project is not TypeScript - it is the adaptation of a conversational skill into a single-shot one. Each source skill closes with behaviours that make sense in Claude and fail on the web, so the generation step rewrites the contract:

What survives untouched is the part that makes the outputs good: the role's sharp mandate ("your job is not to summarise options, it is to force a choice"), the fixed five-part output structure, and the quality-gate checks. Those constraints are why the answers read like a consultant's deliverable rather than generic LLM prose.

Takeaway: Prompt assets are portable across surfaces, but their interaction contract is not. Porting a skill from chat to web is 10% plumbing and 90% rewriting what the prompt is allowed to ask of the user.

Tech Stack Decisions

The Groq decision deserves one more sentence, because it is a genuine trade-off. Claude produced noticeably richer prose in side-by-side tests, but at multiple seconds to first token the portal felt like submitting a form. Groq starts streaming almost immediately, and for a tool whose pitch is "structured thinking in seconds", perceived speed beats marginal eloquence. The skills' rigid output structures also do a lot of quality-levelling: with a five-part structure and a quality gate baked into the prompt, the floor on a fast open model is high enough.

What Ships: The User Journey

The chain in step 4 is the quiet centre of the product. A single skill output is useful; the sequence is the actual consulting method. Because every deliverable ends by naming its successor skill and what to feed it, a PM who arrives for one answer gets pulled into the full arc of a decision.

Learnings

• Distribution is a product decision, not an afterthought. The 21 skills were finished and working, and reached almost nobody. Moving them from "install a plugin" to "open a URL" changed the addressable audience more than any improvement to the prompts would have.
• Write prompts as structured documents first. Because each skill already had the Role / Steps / Quality gate / Output anatomy, converting them to system prompts was mechanical. Prompts written as freeform chat instructions would not have ported.
• Constrain the model harder as the model gets cheaper. The rigid output structures matter more on a fast open model than they did on Claude. Structure is what keeps speed from reading as shallowness.
• Non-goals age into roadmaps. Every v2 idea below was first written down as a deliberate MVP exclusion. The discipline of the non-goals list keeps "later" from silently becoming "now".

What's Next

• Auto-chaining. A "continue the engagement" button that carries the current output into the successor skill with one click, turning the six phases into a guided flow.
• Shareable outputs. A permalink for a generated deliverable, so the memo a PM just produced can go straight into Slack.
• Context reuse. Let a user pin their situation description once and run multiple skills against it, instead of re-pasting per skill.
• Model benchmarking. A structured eval of the 21 skills across Groq-hosted models to check whether the default is still the right speed/quality point as new models land.