Product Manager — Sole PM, Solo Builder

Hive

Agentic AI for Product Management
Your PRDs, roadmap, and team context — read and written by AI agents.

A multi-agent system that turns a product team's PRDs, roadmap, and SQL library into structured context AI can act on — making agentic AI a reliable contributor to product development, not a guesser.

3Role-Based Agents
6Domains in PRD Graph
Team-AwareEvery AI Session
Plan-FirstHouse Rule

Why PRDs Fail AI — and AI Fails PMs

Shadowed PMs and engineers on real agent sessions, ran onboarding retros with the last four hires, reviewed the PRD lifecycle, and traced bad AI outputs back to their source.

📄

PRDs Rot When Nothing Reads Them

Specs written for a launch rarely stay authoritative six months later. When only humans read them, drift is invisible. When AI reads them too, drift becomes a bug you can fix.

🗺

Roadmap Drift Is an Information Problem

The roadmap on the wall diverges from what engineers and PMs actually believe. No single agent-readable source keeps them honest.

📝

People Are Under-Planning, Not Under-Prompting

Most bad AI output traced to skipping a planning step, not weak models. Planning is the product.

🎯

Auto-Discovery Fails Silently (~70%)

Implicit agent and tool discovery misses about a third of the time. Explicit invocation and a clear manifest is what makes AI a trustworthy teammate.

Who We Built For

Interviewed all 7 teammates across PM, backend, frontend, QA, and data. Grouped findings into three roles around the PRD lifecycle: author, consumer, and metric owner.

Primary

The Product Manager

PRD author. Drives specs, roadmap, launches — wants an AI partner that actually knows the product.

“Half my bad AI outputs are because I didn't plan — the other half are because the model doesn't know our product.”
  • Draft and edit PRDs with a PM agent that has the domain graph loaded
  • Keep roadmap in sync across PRDs, RFCs and tickets
  • Plan before any multi-step change
Secondary

The Engineer / EM

PRD consumer. Turns specs into shipping software, uses AI coding assistants daily.

3 of 4 recent onboardings flagged “I can't tell which PRD is current” as the top pain.
  • An Engineer agent that reads PRDs, knows the schemas, respects conventions
  • A shared agent layer so one improvement becomes everyone's default
  • Self-serve onboarding via the domain graph
Extended

The Data Analyst

Metric owner. Pairs every PRD with a query and a dashboard.

6 recurring queries kept getting re-derived from chat snippets before Hive linked them to their source PRDs.
  • An Analyst agent that runs reviewed SQL and cites the source PRD
  • Data catalog linked into the domain graph
  • Agents that know the schema, not just the syntax

The Repository Is the Substrate, the Agents Are the Product

If a product team's PRDs, roadmap, and decisions live as structured, linked content in Git, then agentic AI can manage product development work alongside humans — drafting specs, updating the roadmap, answering from source.

Positioning

Not a wiki, not a PM SaaS, not an AI wrapper. Hive is an agentic AI product for PM work, sitting on a repo-native Team OS.

Why Now

Agent-native IDEs are reliable enough to trust on product artifacts. And "context, context window, compaction, thinking room" are now first-class product concerns for any team shipping with AI.

✓ What We Chose

Three-Part Team OS Root

A shared agents/ folder (agents, commands, skills), a product-development/ folder (PRDs/RFCs/roadmap/SQL), and a team/ folder (onboarding, retros).

✗ Said No To

Rich WYSIWYG Editing

Writing happens in the IDE and PR. The app is for reading and running — never for authoring. One surface, one job.

✓ What We Chose

A Root Manifest for Every Agent

At the top of the repo, a manifest that hands every agent a map of the codebase, the team, and the domain graph before any work starts.

✗ Said No To

Real-Time Collab & Comments

Handled upstream in PRs and chat. Duplicating them in-app would fragment attention without earning the complexity.

✓ What We Chose

Role-Based Agents & Plan-First

PM, Engineer, Analyst agents, each built from real team conventions. Every non-trivial write produces a plan file checked into the repo.

✗ Said No To

Auto-Discovery for Critical Skills

~70% hit rate isn't safe for team-wide workflows. Explicit invocation trades a little magic for a lot of reliability.

How We Built It

Prioritization lens: does this change make the next agentic task cheaper — in context tokens, in planning time, in rediscovery? If not, don't ship.

📑 Domain Index as the PRD Graph

A single YAML map from domain → feature → PRD, RFC, plan, SQL, dashboards, tickets. Agents traverse the graph instead of guessing — and the same map anchors every human navigating the workspace.

🤝 Role-Based Agents (PM / Engineer / Analyst)

The PM agent drafts and edits PRDs with domain awareness. The Engineer agent reads PRDs + schemas to plan work. The Analyst agent runs reviewed SQL and cites its source PRD. Each loaded with real team conventions as a system prompt.

📡 Streaming LLM API with SSE

Real-time interaction with live context injected from the loaders layer. Compaction-resistant by design — ground truth lives in files, so any session can be resumed or rebuilt from source.

📚 Plan-First as a House Rule

Every multi-step action starts with a plan file in the repo. The plan is both a review artifact and future-session context — planning stops being overhead and starts being inventory.

📾 PRs Scoped Per Stakeholder

One PR for product review, a separate PR for engineering review. Reviews are faster, history is cleaner, and long agent sessions behave better on the smaller change units.

What We Cut

  • Fuzzy full-text search — the domain index + explicit navigation beat fuzzy search for intent-shaped agent queries
  • Mobile and real-time editing — writing happens in the IDE + PR, full stop
  • Auto-invoking every skill — explicit invocation made AI behaviour predictable across the team

What We Delivered

FasterPRD → Decision Cycle
6/6Domains in PRD Graph
Generic → Team-AwareAI Session Quality
One MapHumans & Agents Share
📖

Plan-First: Optional → Default

Within the first month, plan-first went from a suggested practice to an unspoken team norm — plan files now appear in PRs without prompting.

🤝

Individual Tricks → Team-Wide Agents

The shared agent layer turned one engineer's handy command into every engineer's default on the next pull. Compounding beat any single feature launch.

Smaller, Stakeholder-Scoped PRs

Reviews moved faster, history got cleaner, and long agent sessions held up better because work was chunked the way the review actually happens.

🌐

The Template Other Teams Asked to Copy

The three-part Team OS structure + domain index became the reference other product teams in the org asked to replicate for their own workspaces.

What I Learned

1

Structured Context Is the Product

Once I stopped treating PRDs as deliverables and started treating them as context for the next session (human or AI), every design decision got easier. The PRD isn't the artifact; the agent-readable context it produces is.

2

People Are Under-Planning, Not Under-Prompting

The highest-leverage change wasn't a better model — it was forcing a plan-first workflow. Planning is the product; prompting is just the last mile.

3

Agentic AI Needs a Substrate, Not Just a Prompt

Multi-agent systems only work when the substrate (root manifest + PRD graph + shared conventions) makes the team legible. The agents are the surface; the repo is the engine.

4

What I'd Do Differently

Ship the shared agent layer on day one. Individual agents are nice; a team's shared agents compound. I underestimated how much adoption came from “I pulled main and my tools got better,” not from any single feature launch.