AI PM Copilot · Productivity · RAG Architecture · Internal Tool
An AI copilot built for product managers — designed to reduce cognitive load and keep PMs in flow, not in context-switching hell.
PM — Product Concept, Architecture Design, Demo Pitch
Client
RocketShip (internal)
Format
5-minute live demo pitch
Stage
Concept to pitched prototype
Methods
RAG Architecture, Prompt Design, User Workflow Mapping, Demo Narrative
The brief
RocketShip needed a way to reduce the time PMs spent context-switching between tools, documents, and communication threads to answer one recurring question: what is the current state of this product?
Juno was the answer. An internal AI PM copilot designed to surface the right context at the right moment — pulling from PRDs, Slack threads, Jira tickets, and meeting notes to give PMs a single, intelligent interface for staying oriented.
My role was to design the product concept, define the technical architecture, and deliver a 5-minute demo pitch to stakeholders.
“PMs don't have a productivity problem. They have a context problem.”
The average PM at a growth-stage startup touches six or more tools in a single workday. Each context switch carries a cognitive cost. By the time a PM has assembled enough context to make a good decision, the meeting has started or the window has closed.
The core insight driving Juno: the information PMs need already exists. It lives in Notion docs, Slack channels, Jira backlogs, and calendar invites. The problem isn't information scarcity — it's retrieval friction.
Juno was designed to eliminate that friction by building a retrieval layer that understood product context, not just keywords.
How Juno Works
01
Juno connects to the tools PMs already use: Notion, Jira, Slack, Google Calendar, and email. Documents, tickets, threads, and meeting transcripts are chunked and indexed into a vector store on a rolling basis, keeping the knowledge base current without manual input.
02
When a PM submits a query, Juno performs semantic search across the vector store to retrieve the most relevant chunks — not just keyword matches, but contextually related content. Retrieval is scoped by product area, time window, and source type to reduce noise.
03
Retrieved chunks are injected into a structured prompt template before being sent to the LLM. The prompt template enforces output format, constrains hallucination risk, and instructs the model to cite the source document for every claim it makes in the response.
04
Juno returns a concise, cited, actionable summary — not a wall of text. Responses are formatted for PM consumption: key context at the top, source citations inline, and a confidence indicator when retrieved content is sparse or potentially outdated.
Prompt design decisions
Every Juno response follows a fixed schema: Summary, Key Context, Open Questions, Sources. Enforcing this in the prompt prevents the model from producing freeform responses that vary in usefulness and require the PM to reorient on every query.
Juno's prompt explicitly instructs the model to answer only from retrieved context and to flag when it cannot find sufficient grounding. This was a deliberate trade-off: slightly lower recall in exchange for significantly higher trust from PM users.
Every factual claim in a Juno response must reference its source document and timestamp. This was the single most important trust-building feature in the pitch — PMs needed to verify answers, not just receive them.
The demo pitch structure
01 · 0:00–0:30
Open with the context-switching problem. Make the pain visceral and specific: “You have 4 minutes before standup and you need to know where the onboarding flow redesign stands. Where do you look first?”
02 · 0:30–1:30
Position Juno as a retrieval layer, not a chatbot. The distinction matters: Juno doesn't generate answers from training data, it finds and surfaces answers that already exist in your team's work.
03 · 1:30–3:30
Walk through a single realistic query: “What are the open questions on the onboarding redesign as of this week?” Show the retrieval in action, the cited response, and the source documents surfaced.
04 · 3:30–4:15
Brief, visual. Show the four-layer stack. Emphasize the augmentation and citation layers as the trust infrastructure that makes Juno safe to rely on.
05 · 4:15–5:00
Quantify the opportunity: if Juno saves each PM 30 minutes of context-gathering per day, a 10-person PM team recovers 25 hours of focused work per week. Close with the ask.
Hypothesis statement
“We believe that PMs who use Juno as their primary context-retrieval tool will spend meaningfully less time searching for product state information across tools — because semantic retrieval over a unified knowledge base is faster and more accurate than manual multi-tool lookup.
We will know this is true when PMs report a 40% reduction in time spent on context gathering during the first 30 days of use.”
What I learned
Designing Juno clarified something important about AI product management: the architecture is the product. The features users see — the query box, the cited response, the confidence indicator — are thin interfaces over a set of deeply consequential design decisions made in the retrieval and augmentation layers.
Getting the prompt schema right took longer than any other part of the design. The output format, the citation requirement, the hallucination guardrail — each one required deliberate trade-off thinking, not just prompt experimentation. That process felt more like systems design than copywriting.
The demo pitch itself was its own product lesson. Five minutes is a constraint, and constraints are clarifying. Every slide and every demo step had to justify its place. Cutting the architecture deep-dive to 45 seconds was the hardest edit — and the right one.