Definition Workflow

pbhq-lite

ProductBuildersHQ Lite: the smallest spec set that keeps product, technology, plan, and roadmap distinct — PRD (what), TRD (how), PLAN (sequencing), ROADMAP (tracking). The four stay separate because they answer different questions and change on different cadences; merging any two couples their churn. Built to keep velocity high and development consistent across one-person, multi-repo initiatives: minimal ceremony keeps the loop turning fast, and the same four files committed alongside the code in every repo let humans and agents navigate any initiative the same way. This is the minimal set for the building phase — getting to shipped with verifiable success criteria; growth-phase product execution (GTM plans, growth experiments) adds artifacts or graduates to a heavier workflow rather than stretching these four.

A ProductBuildersHQ original — the workflow PBHQ runs in VisionStudio to build its own products: PlexusOne.dev, AIStandards.io, ProductBuildersHQ itself — and VisionStudio, built with VisionStudio.

The Four-Quadrant Minimum

One document per quadrant: Definition vs. Execution crossed with Narrative vs. Structured. The same split that keeps the PLAN’s story separate from the ROADMAP’s checklist also separates product judgment (PRD) from machine-consumable contracts (TRD).

Narrative — for human judgment

Structured — for machines & agents

Definition
what should exist

PRD The what & why — problem, goals, stories, success metrics changes on learning

TRD The how — architecture, contracts, APIs, data models changes on architecture

Execution
getting it shipped

PLAN The narrative of the sequence — why this order, phases, dependencies changes on re-planning

ROADMAP The checklist — machine-readable RMI ledger with stable IDs & status changes every session

Change cadence increases toward the bottom-right ↘ — the separations keep slow documents out of fast documents’ churn.

Specs in This Workflow

PLAN Required execution Implementation plan - the narrative of the sequence: why this order, dependencies, phases, milestones. Deliberately separate from ROADMAP so the plan's story is not churned by status flips

PRD Required source Product Requirements Document - defines the what: problem, goals, non-goals, user stories, functional requirements, and required success metrics (outcome targets with baselines and measurement method — the Product Loop's verification criteria)

ROADMAP Required execution Execution tracking - the checklist: a machine-readable RMI ledger (stable IDs, status, progress) committed with the repo. Deliberately separate from PLAN so per-session status churn never touches the narrative

TRD Required technical Technical Requirements Document - defines the how: architecture, components, APIs, data models, security considerations

Synthesis Rules

How downstream specs are generated from upstream ones.

PRD +TRD PLAN

Sequence implementation based on dependencies from TRD and priorities from PRD. Break into phases with clear deliverables.

PLAN ROADMAP

Create RMI entries for each plan item. Use stable IDs (RMI-REPOSLUG-NNN). Track status alongside code commits.

PRD TRD

Derive technical approach from PRD requirements. Include architecture decisions, component boundaries, and API contracts.

Feeds Execution Via

PBHQ Lite → Spec-Kit A lightweight PBHQ Lite definition produces a reconciled spec; Spec-Kit's /speckit.specify consumes it (or it is merged into specs/<feature>/spec.md), after which plan → tasks → implement proceeds.

Included Assets

4 document templates · 4 LLM-as-a-Judge rubrics — embedded in visionspec.