# PRD Master > **About the sources:** the outside documents this report cites were copied into `canon/` on 2026-07-05. Its citations are left as they stood when the report was written; to follow one, open its copy under `canon/`. :::animation HERO **HERO: The spec that drives the build, not the doc that gets filed** - **What it shows:** a vague idea (a fuzzy cloud of intent) enters a specification engine and is compiled, through a visible methodology (Promise Theory scope, Wardley plan, Powell strategy, game-theory action DAG, Bayesian completion), into a crisp machine-executable PRD whose YAML frontmatter then forks into two live streams: one drives the project tools (Linear, ClickUp, Notion cards lighting up), the other drives the agent execution (a feature factory acting on the spec); a rejected alternative fades, a pretty PRD document sliding into a filing-cabinet graveyard, never read again. - **Narrative role:** sets the scene; this is the share/card thumbnail. It frames PRD Master as the engine that turns an idea into an executable specification that drives both planning and execution, the source of truth that does not drift. - **What it teaches:** the one idea is that the PRD is an executable specification, not a planning document filed away, and it is what determines whether you build a skyscraper or a pile of rubble. - **Intended impact:** the realization that rigorous specification is the upstream lever that decides whether the downstream build succeeds or becomes 3x rework. ::: | Field | Value | |---|---| | Project | PRD Master (repo: `prdmaster`) | | Looikos cluster | Infrastructure & Agent Platforms (the specification layer: the source of truth that drives execution) | | One-line | The spec-driven document-generation engine that turns an idea into machine-executable operational documents grounded in an operational-hierarchy world model, becoming the single source of truth that drives both project management and the execution of the agent harnesses and feature factories | | Status | In-build (a real repo exists: `prdmaster/`, with BMAD agent definitions, the five-step framework, complexity assessment, and the document pipeline) | | Existing code | `C:\Users\T5810\Desktop\Code\Applications\prdmaster\` (CLAUDE.md, README.md, `bmad/` methodology and templates, `.claude/agents/` BMAD agents, `docs/`). Sits beside MVP Mammoth (which uses PRD Master under the hood), feeds FreelanceBuddy (execution) and WikiDesignCo/Archon (storage), and writes through Linear/ClickUp/Notion | | Desk | desk-infra (written by desk-brands-finish) | | Coverage | VERIFIED-heavy on the seed (Andy's transcript) and the build (the real `prdmaster` repo, read directly, repo-replication). VERIFIED on the spec-tool market and PM-SaaS comps (Perplexity, cited). INFERRED on the persona PST depth and some comps (tagged inline); the Kiro/spec-kit/Taskmaster market specifics were thinly sourced and are tagged accordingly | | Date | 2026-06-21 | --- ## Nine-rung frame (this research task) - **Purpose (the rails):** give the ecosystem the depth to build and run PRD Master with agents, not headcount. PRD Master is the specification spine that lets every other brand be mass-produced from rigorous specs rather than improvised, so its depth determines whether the whole build is a skyscraper or a pile of rubble. - **Mission (rung 1):** convert Andy's recorded PRD Master breakdown plus the real `prdmaster` repo into a research-grounded ~10k brand deck, so the specification brand is built and sold from understanding the spec-and-planning pain, not from a document-generator's-eye view. - **Objective (rung 2):** a finished deck at `symphony/stack-recon/projects/prd-master.md`, ~10k words, three-angle valuation modeled, 5+ PST personas to world-experience depth, build section grounded in the real repo and the spec-driven-development reality, graded CLEAN by desk-qc-final and the lead. - **Initiative (rung 3):** the symphony-recon Track-P run; one of the ~11 unwritten decks. - **Project (rung 4):** the desk-brands-finish lane. - **Task (rung 5):** this one brand deep-dive, run against `_PROJECT_TEMPLATE.md` and PST, with repo-replication on the existing `prdmaster`. - **Action (rung 6):** A1 ingest the transcript and the real repo (done). A2 skeleton (done). A3 sequential Perplexity: spec-tool market/alpha, Lexicon of Pain, PM-SaaS comps (done; build reality drawn primarily from the first-party repo). A4 PST on five personas. A5 incremental section writing. A6 self-check. A7 hand to the lead. - **Decision (rung 7):** the evolution stage of the spec capability (AI PRD drafting is heading to commodity; the machine-executable spec that drives both agents and PM tools, grounded in a world model and a decision-theory methodology, is the genesis-stage own-it lane); which personas carry the deck (the vague-requirement-burned developer, the document-drowning PM, the can't-spec-my-vision founder, the agent-scaffolding-frustrated builder, plus the public-buyer of the productized tool); ADOPT/HARVEST on the build (the repo already exists; the leverage is hardening BMAD and the machine-executable-spec pipeline and the world-model grounding). - **Data (rung 8):** N/A (this doc is the artifact). It later seeds the metagraph as BrandDeck:PRDMaster, with edges to MVP Mammoth, FreelanceBuddy, WikiDesignCo, Swarm Layer, and Symphony AGI. - **Event (rung 9):** N/A (this doc is the artifact). Deck written, progress posted, grade recorded. ## 1. What it is (the one-paragraph truth) PRD Master is the specification layer of the Looikos ecosystem: the engine that generates the operational documents (PRDs, SOPs, READMEs, YAML configs, Jinja templates, agent skill definitions) that every downstream system executes against. Because the ecosystem takes a spec-driven approach to everything, it needs something that produces these documents rigorously and keeps them as a maintained, updatable operational-hierarchy world model that becomes the single source of truth for both the project-management side and the generation work that the swarm harnesses execute. In Andy's words, it's where all the other systems, the agent harnesses building the feature factories and managing each domain of each platform, get their specs written; everything in Linear, ClickUp, and Notion more likely than not gets written through PRD Master. Concretely, it's a real, built repo that runs on BMAD, the Breakthrough Method of Agile AI-Driven Development, the open-source spec-driven agentic-development framework whose project levels (0 through 4, from a single atomic change up to a full strategic PRD) set how much planning depth a piece of work earns. On top of BMAD's leveling, PRD Master carries its own five-step methodology grounded in real decision theory: Promise Theory for scope, Wardley mapping for what to build versus buy, Warren Powell's unified decision framework for the problem type, game-theory directed graphs for the action plan, and Bayesian thinking for completion-as-learning. The output is a PRD with machine-readable YAML frontmatter specifying exactly what documents to generate, to what quality standard, with what methodology, and that PRD becomes the contract between planning and execution. PRD Master was inspired by a tool called Taskmaster and by the insight that heavy scaffolding lets even weaker models do impressive work consistently, which remains true even as models get smarter, because consistency at scale requires structure. Andy builds it for himself first, then opens enough of it to recover 1.6 to 1.8 times his own spend, which funds the research and development that makes it better. For the people it serves, PRD Master is the answer to a pervasive misery: the chaos of vague requirements and stale specs and vibe-coded rework, the gap between what the document says and what gets built, and the new pain of AI agents that need a beautiful spec to do good work and go off the rails without one. :::animation 1b **ANIMATION 1b: the misery the brand answers** - **What it shows:** three recurring pains stack on a worker's desk as physical objects, a VAGUE TICKET that says two words, a STALE SPEC yellowing while the code moves past it, and an AI AGENT going off the rails for want of a beautiful spec; each object is then replaced by one clean machine-executable spec that the desk, the code, and the agent all read from - **Narrative role:** anchors the closing claim of §1, the pervasive misery PRD Master exists to answer - **What it teaches:** vague requirements, spec drift, and unscaffolded agents are one problem with one fix, a rigorous executable spec - **Intended impact:** the reader recognizes their own daily friction in the three objects and sees a single cure ::: :::animation 1 **ANIMATION 1: The spec compiled, then forked into execution** - **What it shows:** a vague idea enters the engine; the five-step methodology stations process it in sequence; out comes a PRD whose YAML frontmatter forks into two driven streams (the PM tools and the agent execution), both moving in lockstep with the spec, so the document and the build are the same artifact. - **Narrative role:** opens §1 by making the executable-specification thesis concrete and kinetic. - **What it teaches:** that the PRD is a contract that drives both planning and execution, not a filed document. - **Intended impact:** the viewer sees specification as the live control surface, not paperwork. ::: ## 2. Andy's seed, expanded **Andy's words (verbatim from the recording):** "Okay, next PRD Master. So because we take a spec driven approach to everything, we need to have something that's able to generate these operational focused documents and that is designed around creating an operational hierarchy world model that's able to be updated and well maintained and become the source of truth for both the project management side, but as well as to be used for the generation of operational documents across whatever swarm harness is going to be implementing and executing. And obviously this ends up being scaled out for public use... I build all of these for myself because I need them in order to scale the level that I want to. And then what I do is I open up enough of it to ideally take up 60 to 80%... 60 to 80% above what I'm spending... So 1.6 to 1.8x my own spend... So PRD Master, it was kind of inspired by a tool called Taskmaster. And I really love Taskmaster as a tool... Taskmaster, I think was ahead of his time and too much for the problem to solve. But it made it to where you can take really dumb models and if you put them through an excessive amount of scaffolding and have them fill in the blanks, they could do impressive things. And so even though the models are smart enough now, people think you don't need it. The fact is, if you want everything to be consistent and done well, yeah, you're going to want to have some kind of scaffolding... this is our approach to it taking my own architecture style and that's PRD Master. So PRD Master is designed to where all the other systems, these agent harnesses that are building this feature factories, that are managing each domain of each platform and each software and each automation and everything that we're building. The whole idea is that everything on linear, all the stuff in ClickUp and then likely even sub written in notion. More likely than not that stuff is getting written through PRD Master." **Reading between the lines:** Andy's seed compresses four claims, each of them carrying weight, and the real `prdmaster` repo backs them up; the repo is the main evidence for the build in this deck. First, "because we take a spec driven approach to everything" is the foundational claim, and PRD Master is the brand that makes spec-driven development operational across the ecosystem. The 2026 demand signal for this is real and quantified: roughly 73% of product managers use AI tools daily and PRD generation is the most common use case, and the market increasingly wants AI outputs that are structured, editable, connected to execution, and grounded in context rather than free-form prose (VERIFIED, Query 1). PRD Master sits where the market is heading and hasn't reached yet, as a spec engine whose output drives execution rather than a drafting tool. :::animation 16 **ANIMATION 16: the market's direction of travel** - **What it shows:** an arrow labeled WHAT THE MARKET WANTS travels from FREE-FORM PROSE on the left toward STRUCTURED, EXECUTABLE, CONTEXT-GROUNDED on the right, with a marker for 73% OF PMS USE AI DAILY glowing on the road; a pin labeled PRD MASTER sits at the far right end where the arrow points but has not yet arrived - **Narrative role:** anchors §2's first claim, that spec-driven demand is real and moving toward exactly where PRD Master sits - **What it teaches:** the market is already traveling toward structured executable specs and PRD Master is standing at the destination - **Intended impact:** the reader sees the brand as ahead of a demand curve rather than betting on one ::: Second, "creating an operational hierarchy world model that becomes the source of truth for both the project management side and the generation of operational documents across whatever swarm harness is executing" is the precise positioning, and it's the third door (in Andy's sense, the opening competitors know about and structurally won't take). The existing AI PRD tools (ChatPRD, Notion AI, Productboard AI, Atlassian Intelligence) generate documents but don't maintain a formal world model of the domain, don't produce machine-executable specs that orchestrate agents and project tools from one canonical artifact, and don't solve spec drift between the doc and the tickets and the code (VERIFIED, Query 1). PRD Master does all three. The real repo confirms this is built, not aspirational: the PRD carries YAML frontmatter (complexity level, document types, quality thresholds, target word counts, automation level) that feeds directly into the Archon task system and the agent configuration of FreelanceBuddy (Andy's Upwork application workspace), with the quality thresholds becoming enforcement rules in hooks and the document types becoming task nodes in the dependency graph (VERIFIED, the `prdmaster` README). The spec is an executable specification, not a planning document filed away. :::animation 2 **ANIMATION 2: The world model the drafting tools do not keep** - **What it shows:** the AI PRD drafting tools (ChatPRD, Notion AI, Productboard AI) each producing a nice prose document that immediately starts drifting from the tickets and the code; PRD Master instead maintains a formal operational-hierarchy world model beneath the document, the YAML frontmatter wiring the spec to the task system so the doc, the tickets, and the execution stay one connected thing. - **Narrative role:** illustrates §2's second claim, the world-model-and-machine-executable positioning that is the third door. - **What it teaches:** that maintaining a formal world model and machine-executable output is what the drafting tools do not do. - **Intended impact:** the viewer sees the difference between a drafting tool and a control plane. ::: Third, the Taskmaster inspiration and the scaffolding insight form the intellectual core, and they're correct against the 2026 reality. Andy's claim is that heavy scaffolding lets even weaker models do impressive work consistently, and that this remains valuable even as models get smarter because consistency at scale requires structure. The voice-of-customer research on agent scaffolding confirms it from the other side: practitioners report that an agent "is only impressive if I hand-feed it a beautiful spec," that the same prompt produces "completely different behavior," and that they want "a boring, predictable robot that does what it's told" (VERIFIED, Query 2). Scaffolding converts an overconfident, inconsistent agent into a reliable one, and PRD Master is the scaffolding factory. (Note: the precise market positioning of Taskmaster, AWS Kiro, and GitHub spec-kit was thinly sourced in the research and is tagged INFERRED; the scaffolding principle itself is VERIFIED from both the transcript and the VoC.) Fourth, PRD Master's five-step methodology supplies the rigor and the 1.6-1.8x business model supplies the economics, and both are real and specified in the repo. The five steps, each grounded in actual decision theory, are PRD Master's framework layered on top of BMAD rather than part of the external BMAD spec, and the repo spells them out `prdmaster/README.md` `prdmaster/CLAUDE.md`: Scope via Promise Theory (every component makes explicit testable promises, cutting scope creep), Plan via Wardley mapping (map the evolutionary stage of each component to decide commodity-versus-custom), Strategy via Warren Powell's unified decision framework (identify the problem type, PFA versus VFA versus DLA, to allocate resources), Action via game theory and directed acyclic graphs (the action plan is a DAG where each node is an agent making game-theoretic decisions about sequence and dependencies), and Complete via Bayesian thinking (completion updates the system's beliefs, refining the next cycle's priors) (VERIFIED, the `prdmaster` README and CLAUDE.md). BMAD's project levels 0 through 4 set the planning depth, so the rigor scales with the work, preventing twenty hours spent on a $500 job and generic garbage sent to a $50K contract, with each level specifying its document set and effort (VERIFIED, the `prdmaster` BMAD workflow files). The business model is the ecosystem standard Andy applies everywhere: build it for himself first because he needs it to scale, then open enough of it to recover 1.6 to 1.8 times his own spend, which funds the R&D that makes it better and keeps everyone happy, while letting him keep the most valuable insights close when that's more favorable. Each sibling brand has a deck, and this one points to them instead of repeating them `projects/mvp-mammoth.md` `projects/freelancebuddy.md` `projects/wikidesignco.md` `projects/swarm-layer.md`. :::animation 17 **ANIMATION 17: five decision-theory stations, one spec** - **What it shows:** a spec passes through five labeled gates in sequence, PROMISE THEORY testing each component's promise, WARDLEY sorting commodity from custom, POWELL naming the problem type, GAME-THEORY DAG sequencing the actions, BAYESIAN folding the result back as an updated prior; the spec leaves each gate more rigorous than it entered - **Narrative role:** anchors §2's fourth claim, the five-step methodology grounded in real decision theory - **What it teaches:** the rigor comes from five named decision frameworks applied in order to one artifact, never from vibe - **Intended impact:** the reader sees the methodology as engineered rather than asserted ::: :::animation 3 **ANIMATION 3: Scaffolding makes the weak model reliable** - **What it shows:** a cheaper, weaker model running unconstrained produces inconsistent, rambling, hallucinated output (different each run); the same model run through PRD Master's heavy scaffolding (the pre-built acceptance criteria, the structured spec) produces consistent, correct, predictable work every time, the Taskmaster-lineage insight made visible. - **Narrative role:** illustrates §2's third claim, the scaffolding-makes-weak-models-reliable intellectual core. - **What it teaches:** that consistency at scale comes from structure, not from a smarter model, which is why the scaffolding stays valuable even as models improve. - **Intended impact:** the viewer sees why the spec engine is the reliability lever. ::: ## 3. The three-angle valuation (the core of a self-standing brand) PRD Master's valuation shape turns on a single distinction the capital markets price heavily: whether it's read as a document-generation tool or as an execution-driving control plane. Its software angle is the spec engine and the source of truth, its service angle is the specification-and-planning delivery for teams who can't spec their own work, and its finance angle benefits decisively from the control-plane reading. ### 3a. Finance (credit and capital access) The corporate-finance read starts from the comparable companies, which split three ways. A pure AI PRD or document generator is valued at roughly 3-6x ARR in 2026, a PM and work-management tool with some workflow embedding at roughly 5-9x, and an execution-driving control plane or system of record at roughly 8-12x ARR when retention, expansion, and strategic importance are proven (VERIFIED, valuation query). The PM-SaaS comps frame the absolute scale: Productboard raised at a $1.725B valuation, ClickUp at $4B, Coda at $1.4B, Notion at $10B (with revenue reported around $500M ARR), and Atlassian is the public anchor for mission-critical product-and-dev workflow at the tens-of-billions scale, with 2026 SaaS public multiples clustering around 3.4-5.5x revenue (VERIFIED, valuation query). The decisive point for PRD Master is that it's built to be the control plane, not the generator: its output is machine-executable specs that drive both the project tools and the agent execution, which is the system-of-record-and-execution-linkage position that earns the higher multiple. A control-plane buyer is purchasing the layer that owns the operating logic of the organization rather than productivity software, and that underwrites better durability assumptions in M&A and growth-equity terms (VERIFIED, valuation query). :::animation 18 **ANIMATION 18: the operating-logic buyer** - **What it shows:** an acquirer walks past a shelf of PRODUCTIVITY SOFTWARE without stopping and reaches instead for a single glowing layer labeled THE OPERATING LOGIC OF THE ORGANIZATION, lifting it out from under the whole company's stack, the rest of the tools hanging off it as dependents - **Narrative role:** anchors the §3a claim that the control-plane buyer is purchasing operating logic, not productivity - **What it teaches:** what earns the premium is owning the layer the organization runs its decisions through, not shipping features - **Intended impact:** the reader sees why the control-plane read changes who the buyer is and what they will pay ::: Converting that position into credit and capital access has one nuance for PRD Master, and it comes from the open-source model. The model is the ecosystem standard: build for internal use, then open enough to recover 1.6-1.8x of the internal spend. The valuation implication is mixed: open source is attractive as efficient conversion of internal R&D and community adoption into revenue and as a distribution-and-trust wedge, but it can cap valuation if the market believes the product is easy to replicate or the monetization ceiling is low (VERIFIED, valuation query). The strongest framing, which the architecture supports, is that open source is the wedge and the proprietary orchestration-and-control-plane layer is the moat: the spec drafting can be open and commoditizing while the execution-driving, world-model-grounded, decision-theory control plane captures the monetizable layer above it. For credit, the recurring revenue (the opened portion that recovers 1.6-1.8x spend, plus any subscription and service revenue) is underwritten like SaaS, with the better terms accruing to the higher-retention control-plane position. The accumulated proprietary state an acquirer pays the premium for is the operational-hierarchy world model itself plus the library of proven PRD templates, quality standards, and methodology, the thing that turns a spec request into a reliable executable spec, which a competitor can't clone by adding a PRD-drafting feature. :::animation 19 **ANIMATION 19: open wedge, proprietary moat** - **What it shows:** a castle where the drawbridge and outer courtyard labeled SPEC DRAFTING stand wide open and free for anyone to walk in, while the keep behind it, labeled WORLD MODEL, TEMPLATE LIBRARY, DECISION-THEORY METHODOLOGY, stays walled and monetized, the open part pulling crowds toward the part that charges - **Narrative role:** anchors the §3a open-source-wedge-and-control-plane-moat framing - **What it teaches:** the drafting can commoditize freely because the accumulated world model and template library are the part a competitor cannot copy - **Intended impact:** the reader stops fearing the commodity drafting layer and sees it as the funnel to the moat ::: A market maker would read it on three levels. On fundamentals, it's a real, built product in the control-plane position, in a category with quantified daily-use demand. On technicals, the supply of true spec-to-execution control planes is near zero (the field is drafting tools and general AI assistants), against a demand that grows as agent-driven development spreads, which is a favorable order book. On sentiment, spec-driven development and structured AI outputs are a rising 2026 theme, with the named risk that broad AI-disruption concerns compress SaaS multiples and that a thin-wrapper perception drags the brand down; the hedge is the world-model grounding, the machine-executable output, and the decision-theory methodology that distinguish it from a wrapper. :::animation 4 **ANIMATION 4: Document generator versus execution control plane** - **What it shows:** two valuation dials; a "pure document/PRD generator" dial reading 3-6x ARR, and an "execution-driving control plane" dial reading 8-12x ARR; PRD Master's marker sits on the control-plane dial because its output drives both agents and project tools, the higher multiple earned by owning the operating logic rather than producing prose. - **Narrative role:** grounds §3a's decisive valuation distinction. - **What it teaches:** that being the execution-driving control plane, not a document generator, is what earns the higher multiple. - **Intended impact:** the viewer sees the valuation lever the brand is built around. ::: ### 3b. Software (the interface stack) PRD Master's software is a real, built repo, so the build section describes what exists, not a forecast (VERIFIED, the `prdmaster` repo, read directly). The architecture decomposes into four pieces. The methodology engine is the decision core: PRD Master's five-step framework (Promise Theory scope, Wardley plan, Powell strategy, game-theory-DAG action, Bayesian completion) layered on top of BMAD's 0-4 project levels that determine how much planning depth an opportunity earns, implemented as Claude Code sub-agents and skills (the Analyst, PM, Architect, Scrum Master, Developer roles) rather than as an MCP (Model Context Protocol) server, because the agents need operational context and don't need to be exposed to every client (VERIFIED, the `prdmaster` README and CLAUDE.md). The machine-executable spec is the output and the control surface: a PRD with YAML frontmatter (complexity_level, document_types, quality_thresholds, target_word_counts, automation_level) that feeds directly into the task system and the agent configuration, where the quality thresholds become hook enforcement rules and the document types become task nodes in the dependency graph (VERIFIED, the repo). The data pipeline is the production engine: a Markdown-to-JSON-to-SQLite-to-Jinja flow with the JSON Sandwich approach (content structure defined as JSON first, prose generation second, so the agent can't ramble and the content is programmatically adjustable) and progressive-disclosure skills that load only the specific chunk relevant to the current step, cutting context usage 70-80% (VERIFIED, the repo). The operational-hierarchy world model is the grounding: the nine-rung hierarchy (Andy's nine levels, running from the mission down to the events the work produces) that aligns everything so the specs trace from strategy down to agent action and PM ticket, which the existing AI PRD tools don't maintain (VERIFIED, the repo and Query 1). :::animation 20 **ANIMATION 20: four pieces, one built repo** - **What it shows:** four labeled modules snap together into a single running machine, METHODOLOGY ENGINE, MACHINE-EXECUTABLE SPEC, DATA PIPELINE, WORLD MODEL, each lighting up as a REAL-CODE stamp lands on it, the assembled whole turning a vague idea in one end into a driving spec out the other - **Narrative role:** anchors the §3b claim that the software is a real, built repo decomposing into four pieces - **What it teaches:** the architecture is four concrete built modules, not a forecast, and they compose into one engine - **Intended impact:** the reader treats the build section as description of something that exists rather than a promise ::: As a product, the spec engine is the core platform value, sold partly open (the wedge) and partly proprietary (the control plane). The PRDs and operational documents it produces drive the project tools (Linear, ClickUp, Notion, written through PRD Master) and the execution systems (FreelanceBuddy executes against the PRD; WikiDesignCo and Archon store the planning artifacts for any agent to reference). The architectural signature is the separation of concerns that makes the whole thing efficient: BMAD lives in PRD Master and loads specification context (PRD templates, assessment frameworks, quality standards), while execution agents elsewhere load execution context, so neither inherits the other's, reducing context usage 70-80% compared to monolithic configuration (VERIFIED, the repo). PRD Master runs on the agent harness (Symphony AGI's Hermes, for the productized version `projects/symphony-agi.md`) and is the spec engine that Swarm Layer's generative workflow builder draws on to produce harnesses and feature factories `projects/swarm-layer.md`. :::animation 5 **ANIMATION 5: The Markdown-to-Jinja pipeline and the JSON Sandwich** - **What it shows:** content flowing through the production pipeline (Markdown to JSON to SQLite to Jinja); at the JSON stage the JSON Sandwich forces the structure first (section schemas with word caps and source references) before any prose, so the agent cannot ramble; a separation-of-concerns panel shows specification context and execution context loaded separately, cutting context usage sharply. - **Narrative role:** grounds §3b's software architecture, the documented production pipeline and the JSON Sandwich. - **What it teaches:** that structure-first generation and separated context are what make the output predictable and efficient. - **Intended impact:** the viewer sees the real, built machinery behind the spec engine. ::: ### 3c. Service (premium-at-accessible boutique delivery) The service angle is specification-and-planning delivery: doing the rigorous spec work for teams who can't do it themselves, which is the upstream work that determines whether the downstream execution succeeds or becomes 3x rework. The target operator is the sub-25-employee company, the agency, the founder, or the team shipping AI-agent-driven work that keeps building the wrong thing because the specs are vague and drifting. The premium-quality-at-accessible-pricing model is delivered through the five-step methodology and the world model: instead of a consultant who writes a PRD and leaves, the engagement installs a spec engine that grounds every document in the operational hierarchy, sets the planning depth by BMAD's project levels so effort matches value, and produces machine-executable specs that the team's own agents and project tools can execute against, eliminating the spec drift that is the root of the rework. :::animation 21 **ANIMATION 21: the consultant who leaves versus the engine that stays** - **What it shows:** a traditional consultant hands over a bound PRD and walks out the door, and the moment he is gone the document begins to yellow and drift from the code; beside it, an installed spec engine stays running in the room, regenerating and re-grounding the spec as the work moves, the team feeding it rather than chasing a stale doc - **Narrative role:** anchors the §3c service model, installing an engine rather than delivering a document - **What it teaches:** the service leaves behind a running spec engine, not a consultant's document that drifts the day he leaves - **Intended impact:** the reader sees why the engagement is durable where a write-and-leave consult is not ::: The retainer economics follow the ecosystem standard: $1-2k accessible at entry, $2-12k+ for the real engagements, structured as a specification-and-planning retainer (we spec your work rigorously and keep the source of truth maintained) plus the productized open-tool subscription. A target of 100 to 250 customers puts a floor of around $1M/month under the service angle, and it scales above that (VERIFIED, `THE_FLOOR.md`). The trust differentiator answers the planning paralysis and the spec-drift dread that surface in the voice-of-customer research: the founder who "can't get it specced clearly enough for anyone to build it right," the PM whose "PRD is out of date the moment engineering touches it," the developer drowning in "tickets that are just a title and vibes." PRD Master's complexity assessment removes the over-planning-small-things and under-planning-big-things paralysis (the 0-4 scale tells you how much rigor a project needs), and its machine-executable, single-source-of-truth spec removes the drift. The ongoing specification work and the template maintenance go to the sister affiliate network, run on a shared delivery floor where senior operators in emerging markets work through the Looikos tools with an on-ramp to franchise ownership (VERIFIED, `THE_FLOOR.md`). The vertical doesn't matter; any team that needs its work specified rigorously enough for humans or agents to build it right qualifies, and the service angle is the proving ground for the productized tool, because the specs delivered for clients refine the templates and the methodology that the open tool ships. :::animation 6 **ANIMATION 6: Right-sizing the rigor by project level** - **What it shows:** a dial labeled with BMAD's project levels 0-4; a tiny atomic change sits at level 0 with a light document set, a strategic build sits at level 4 with a full PRD suite; a client engagement turns the dial to the right level so effort matches value, the over-planning-the-small and under-planning-the-big paralysis dissolving. - **Narrative role:** grounds §3c's service delivery, the depth-by-level mechanism that removes the rigor paralysis. - **What it teaches:** that the project levels right-size the planning so effort matches value, which is the service's calibration advantage. - **Intended impact:** the viewer sees the over-and-under-planning paralysis resolved. ::: ## 4. The personas (5+, modeled to world-experience depth) The language here is pulled from practitioners' phrasing, mined in the voice-of-customer research (Query 2). The texture of this pain is the specific frustration of building or specifying the wrong thing, the shame of being seen as the one who can't spec clearly, and the dread of the gap between the document and the reality, with a fresh layer added by AI agents that need a beautiful spec to behave. :::animation 22 **ANIMATION 22: five seats, one missing spec** - **What it shows:** five figures sit around a shared gap in the middle of a table where a spec should be, a DEVELOPER, a PM, a FOUNDER, an AGENT-WRANGLER, and a BUYER, each staring into the same empty slot labeled NO SPECIFICATION LAYER, all reaching for a different corner of it; when a single machine-executable spec drops into the slot, all five hands close on the same object - **Narrative role:** frames the whole persona section, the shared missing layer underneath five different pains - **What it teaches:** the five personas suffer five surfaces of one missing thing, a real specification layer - **Intended impact:** the reader reads the personas as one structural gap with five entry points rather than five unrelated buyers ::: ### Persona 1: The developer burned by vague requirements and vibe-coded chaos I'm a developer drowning in tickets that are "just a title and vibes." The ticket "literally said add basic auth and when I shipped it, suddenly it was oh no, we meant SSO with granular roles and audit logging." "PM writes these vibe-based Jira tickets like make onboarding smoother and then is mad when what I ship isn't the version of smooth they had in their head." "Half my job is psychic work, the spec is two bullet points and a Figma screenshot and somehow I'm supposed to infer the entire product strategy." And the rework never ends: "we've rebuilt the same workflow three times in a year because the requirements keep evolving, they're not evolving, they were never written down in the first place." "Our MVP is just technical debt with a marketing deck, nobody scoped anything, we just hacked something together and now we're stuck maintaining it forever." It cuts at my competence. "I feel like a bad engineer because I'm always hacking around unclear specs and changing expectations, but if I push back I get labeled not agile." "I dread grooming because it's basically a public ceremony where I have to admit I don't understand what they actually want, and everyone acts like I'm being difficult." "I'm afraid to say this spec is garbage because it sounds like I'm attacking the PM, so I just silently suffer and overbuild to cover my ass." I got here because the team worships move-fast and treats specs as bureaucracy, so the requirements live in someone's head until they collide with my shipped code. To get out, I need specs that say what they mean the first time: explicit acceptance criteria, edge cases, definitions, traceable from the strategy down to the ticket, so I build the right thing once. Most developers in my seat fail because the culture rewards speed over clarity and the clarity is invisible until it breaks. Staying stuck means endless rework and silent suffering; getting out takes a real specification layer instead of vibes. :::animation 23 **ANIMATION 23: the psychic-work tax** - **What it shows:** a developer receives a ticket reading ADD BASIC AUTH, and above his head a thought-cloud does unpaid detective work inferring SSO, GRANULAR ROLES, AUDIT LOGGING from two words and a screenshot; a running meter labeled PSYCHIC WORK ticks upward every hour he spends guessing instead of building - **Narrative role:** carries persona 1's voice, the half-my-job-is-psychic-work grievance - **What it teaches:** the hidden cost is the inference labor a vague ticket forces onto the person who has to build it - **Intended impact:** the reader feels the specific exhaustion of guessing intent that should have been written down ::: PRD Master gives me that spec in machine-executable form, with quality thresholds and a world model behind it, so I stop doing psychic work and rebuilding the same workflow three times. :::animation 7 **ANIMATION 7: The end of psychic work** - **What it shows:** a developer handed a ticket that is "a title and vibes plus a Figma screenshot," forced to guess (the psychic-work cloud), shipping the wrong thing and rebuilding it three times; PRD Master replaces the vibes-ticket with a machine-executable spec carrying explicit acceptance criteria, edge cases, and a strategy-to-ticket trace, and the developer builds the right thing once. - **Narrative role:** dramatizes persona 1's transformation from psychic-work guessing to building on a real spec. - **What it teaches:** that an explicit, traceable, machine-executable spec ends the build-the-wrong-thing rework loop. - **Intended impact:** the viewer feels the guessing and the rework lift. ::: ### Persona 2: The product manager drowning in documents nobody trusts I'm a PM who became a "PRD vending machine." "I became a PM to build products, not to be a full-time PRD vending machine," and "feels like my job is senior Google Docs engineer, I spend all day formatting docs nobody reads." Worse, the docs don't hold: "the PRD is out of date the moment engineering touches it, the real spec is in the Jira comments, Slack threads, and someone's brain." "We have a Confluence graveyard of specs that were technically approved but never matched what we actually built." "There is no single source of truth, there's a Google Doc spec, a Notion page, Jira tickets, and whatever the lead dev decided in a hallway conversation." "Our spec process is write doc, review doc, ignore doc, build something else." And nobody reads them: "I pour days into detailed PRDs and the first feedback in grooming is can you walk us through what this is, because nobody read it." It turns into a quiet, grinding shame. "There's this constant low-level shame that I'm writing all these documents that don't matter, like I'm performing being organized instead of actually helping the team." "If something goes wrong, people pull up the PRD like forensic evidence, I'm terrified of missing a sentence that later becomes why wasn't this captured." "Real PMs probably have a system for this, I'm just winging it." I got here because the doc and the code and the tickets live in different places and I'm the only one trying to keep them in sync, which is impossible. To get out, I need a single source of truth that doesn't drift, a spec that drives the tickets and the execution from one canonical artifact so the document and the reality stay the same thing, and to get my time back from formatting docs to thinking. Most PMs in my seat fail because the tools make documents, not sources of truth, so drift is inevitable. If I stay stuck, I keep the graveyard of ignored docs and the forensic dread; the way out is a spec engine instead of a document factory. PRD Master is that source of truth, one machine-executable spec behind the tickets and the execution, and it gives me my time back for the strategic thinking I became a PM to do. :::animation 8 **ANIMATION 8: One canonical artifact, no graveyard** - **What it shows:** a PM's reality of a Confluence graveyard of approved-but-ignored specs plus the real spec scattered across Jira comments, Slack threads, and a lead dev's head; PRD Master collapses them into one canonical machine-executable artifact that drives the tickets directly, the graveyard emptying and the PM's time returning from formatting docs to strategic thinking. - **Narrative role:** dramatizes persona 2's transformation from the document graveyard to a single source of truth. - **What it teaches:** that driving the tickets from one canonical spec ends the drift and the doc-nobody-reads problem. - **Intended impact:** the viewer feels the PM reclaim their time and their credibility. ::: ### Persona 3: The founder who can't translate their vision into something executable I'm a founder who can see the product clearly and can't get it built right. "I can see the product in my head, I just can't get it out in a way devs don't misinterpret." "I keep telling them the same thing in different words and it still comes back wrong, at some point I start questioning if I even know what I want." "My biggest bottleneck isn't code, it's turning my brain dump into something the team can actually build." And the rigor question paralyzes me: "if I don't spec it tightly, I get something random, if I spec it too tightly, I kill all creativity and still miss edge cases, there's no obvious right level." "We either over-plan small features to death or wing big ones that should have been carefully designed, and I don't realize which is which until it's too late." "I procrastinate on writing specs because it feels like this huge, high-stakes task, and the product just sits in limbo." It's a shame I keep hidden. "It's embarrassing to admit to my team that I don't know how to specify my own product." "I feel stupid when developers ask perfectly reasonable clarifying questions and I realize I never thought that far." "There's this fear that if I write it down and it's wrong, it proves I don't know what I'm doing as a founder, so I keep it fuzzy and verbal." I got here because translating a vision into an executable spec is a real skill nobody taught me, and the right level of rigor is hard to judge. To get out, I need a system that interviews my vision out of my head into a rigorous spec, and that tells me how much rigor this particular thing needs so I stop over-planning the small and under-planning the big. Most founders in my seat fail because they keep the spec fuzzy and verbal out of fear, and the fuzziness produces the wrong build. Staying stuck leaves the product in limbo and the builds misread; getting out means letting a methodology extract and calibrate the spec. :::animation 24 **ANIMATION 24: the rigor dial the founder cannot set** - **What it shows:** a founder stands frozen at a dial that runs from TOO LOOSE, where a small feature explodes into something random, to TOO TIGHT, where a big build gets over-specced to death and still misses edge cases; his hand hovers, unable to find the setting, until a project-level indicator lights the correct notch for him - **Narrative role:** carries persona 3's voice, the no-obvious-right-level paralysis - **What it teaches:** the founder's block is calibration, and a complexity assessment sets the rigor level he cannot judge alone - **Intended impact:** the reader feels the specific paralysis of not knowing how much rigor a given thing deserves ::: PRD Master's complexity assessment sets the rigor, and its spec engine turns my brain dump into a rigorous, executable document, so the team builds what I meant instead of what I managed to mumble. :::animation 9 **ANIMATION 9: The vision extracted and right-sized** - **What it shows:** a founder with a clear product in their head that comes out as a fuzzy mumble the devs misinterpret; the spec engine interviews the vision out into a structured artifact and the project-level dial right-sizes the rigor, the team now building what the founder actually meant rather than what they managed to say. - **Narrative role:** dramatizes persona 3's transformation from un-specifiable vision to a right-sized executable spec. - **What it teaches:** that a methodology extracts and calibrates the vision the founder cannot articulate alone. - **Intended impact:** the viewer feels the founder's vision finally land correctly. ::: ### Persona 4: The builder frustrated that AI agents need so much scaffolding I'm someone trying to get reliable work out of AI coding agents and hitting a wall. "Using AI agents right now feels like managing a very fast but very literal junior dev, I spend more time writing the prompt than it would take to code the feature." "The agent is only impressive if I hand-feed it a beautiful spec, if I had the beautiful spec I'd already be 80% done." "Same prompt, slightly different wording, completely different behavior, it's like working with an engineer who has amnesia between tasks." "Agents hallucinate requirements I never gave them and ignore ones I explicitly wrote, it's like they're optimizing for impressive instead of correct." "If the prompt isn't insanely precise, it invents its own acceptance criteria." "I don't want a creative assistant, I want a boring, predictable robot that does what it's told and nothing else." The inconsistency shows up as creeping self-doubt. "I feel dumb when the agent goes off the rails because I assume it's my fault for not writing the perfect prompt." "There's this quiet anxiety that everyone else has figured out how to get reliable results from agents and I'm the only one stuck rewriting prompts all day." "It's starting to feel like if I can't manage AI agents properly, I'll be the one who gets replaced by someone who can." I got here because the agents are powerful and inconsistent, and the consistency turns out to require structure I have to build by hand every time. To get out, I need a system that produces the beautiful spec for me, that scaffolds the agent so heavily that even a weaker or cheaper model produces consistent, correct work, so I stop hand-feeding and start delegating. Most builders in my seat fail because they keep writing one-off prompts and the inconsistency compounds. Staying stuck keeps me on the prompt-rewriting treadmill with the replacement anxiety; getting out means adopting a scaffolding engine instead of perfecting prompts. PRD Master is that scaffolding: a machine-executable spec with the acceptance criteria and structure pre-built, so the agent can't invent its own requirements or ramble, and I get the boring, predictable robot I want. :::animation 10 **ANIMATION 10: The beautiful spec, pre-built** - **What it shows:** a builder hand-feeding an agent a beautiful spec line by line (the 80%-already-done paradox) and getting different behavior each run; PRD Master produces the beautiful spec automatically, with the acceptance criteria and structure pre-built, so the agent cannot invent its own requirements, and even a cheaper model produces consistent correct work, the builder finally getting the boring predictable robot. - **Narrative role:** dramatizes persona 4's transformation from hand-feeding-prompts to a pre-built spec that makes agents reliable. - **What it teaches:** that the engine producing the spec is exactly the scaffolding that makes the agent consistent. - **Intended impact:** the viewer feels the prompt-rewriting treadmill stop. ::: ### Persona 5: The public buyer of the productized spec tool I'm a product or engineering leader at a company adopting spec-driven development, and I want to buy the tool rather than build the methodology myself. I've seen the AI PRD generators, and they produce nice prose that goes stale and doesn't connect to anything, and I've seen the spec-driven-development movement and I want its rigor without inventing my own framework. What I need is a tool that grounds specs in a real world model, outputs machine-executable specs my agents and my project tools can both execute against, and embeds a decision-theory methodology so the specs are rigorous rather than just well-formatted. I'm the person accountable for whether my team's specs produce the right builds or the endless rework. The fear is concrete: buying another drafting tool that adds a document graveyard, or building a methodology in-house that consumes a quarter and still drifts. I got here because the market sells drafting tools and the rigorous spec-to-execution layer doesn't exist off the shelf. To get out, I need a productized spec engine with the world-model grounding, the machine-executable output, and the decision-theory methodology built in, that I can adopt rather than invent. Most leaders in my seat fail by buying a drafting tool and getting drift, or building in-house and burning the quarter. The price of staying stuck is the rework and the drift, and getting out means adopting a real control plane instead of a document generator. PRD Master is that control plane, productized, with the methodology layered on BMAD and open enough to adopt and trust, so I get spec-driven rigor without inventing it or settling for a drafting tool. :::animation 11 **ANIMATION 11: Adopt the control plane, do not invent it** - **What it shows:** a leader weighing two bad options (buy another drafting tool that adds a document graveyard, or build a methodology in-house and burn a quarter that still drifts); a third path opens, adopting the productized PRD Master control plane (world model, machine-executable specs, decision-theory methodology on BMAD), getting spec-driven rigor without inventing it. - **Narrative role:** dramatizes persona 5's transformation from build-or-buy-badly to adopting the productized control plane. - **What it teaches:** that the productized control plane lets a buyer adopt rigor rather than inventing it or settling for a drafting tool. - **Intended impact:** the viewer sees the adopt-not-invent path. ::: ## 5. The world model (run the PST framework) **Echolocate the world.** The substrate is the 2026 moment where everyone is shipping faster with AI and discovering that speed without specification produces chaos: roughly 73% of PMs use AI tools daily with PRD generation the top use case, and the market is shifting from wanting nice prose to wanting structured, executable, context-grounded specs, because generic AI output produces generic, drifting results (VERIFIED, Query 1). Read institutionally, spec-driven development is rising, the demand is quantified and daily, and the gap is that the tools draft documents without enforcing execution or maintaining a world model. In the metagraph (the knowledge graph the ecosystem shares), PRD Master is the specification node that every other build flows through, the place where the operational-hierarchy world model is authored and maintained, so its customer is everyone downstream of a spec (the developer, the PM, the founder, the agent-wrangler) and the ecosystem itself, which mass-produces its brands through PRD Master. Echolocating the customer means seeing that the public story is "we ship fast with AI" and the private reality is rework, drift, and the dread of building the wrong thing. :::animation 25 **ANIMATION 25: the public story and the private reality** - **What it shows:** a bright billboard reads WE SHIP FAST WITH AI while the camera slips behind it to the actual floor, where the same team rebuilds the same workflow a third time, a spec drifts away from the code, and a worker stares at the wrong thing they just shipped, the confident front and the churning back in one frame - **Narrative role:** anchors §5's Echolocate station, the gap between the shipped-fast story and the rework reality - **What it teaches:** the loud public narrative hides a private loop of rework and drift that the brand speaks to directly - **Intended impact:** the reader recognizes the gap between what teams say about AI velocity and what they live ::: **Locate the Problem.** Here the cycle of suffering is a loop of ambiguity into rework into blame, with a fresh AI-era intensifier. The pain is concrete: vague requirements, stale PRDs, no single source of truth, the gap between the doc and the code, and the agents that go off the rails without a beautiful spec. The fear portfolio underneath is specific: the developer's fear of being the bad engineer who builds the wrong thing, the PM's fear of the PRD pulled up as forensic evidence, the founder's fear that a written-down-and-wrong spec proves they don't know what they want, the agent-wrangler's fear of being replaced by someone who can manage agents, all sitting under the cross-cutting fear that "everything that isn't written down becomes ammo later" and "specs are receipts for whose fault it is." The shame is the competence-shame: "I feel like a bad engineer," "I'm just winging it, real PMs have a system," "it's embarrassing to admit I don't know how to specify my own product," "I assume it's my fault for not writing the perfect prompt." The red line, where accountability lives, is the moment a person stops treating the chaos as their personal failure to communicate or to prompt, and recognizes it as a missing system: there's no specification layer that grounds, calibrates, and executes. Most of this market lives below that line, which is why the content speaks to the rework-dread and the competence-shame directly. :::animation 26 **ANIMATION 26: below the accountability line** - **What it shows:** a horizontal line splits the frame; below it a crowd blames itself, each figure holding a sign reading MY FAULT FOR NOT COMMUNICATING or MY FAULT FOR NOT PROMPTING RIGHT; a single figure crosses the line upward and their sign flips to read THERE IS NO SPECIFICATION LAYER, the reframe visible as a border-crossing - **Narrative role:** anchors §5's Locate station, the red line where personal-failure reframes as missing-system - **What it teaches:** the market mostly lives below the line, reading a structural gap as a personal failing - **Intended impact:** the reader feels the shift from self-blame to naming the absent system ::: **Reconstruct the Story.** The belief structure that built this suffering starts from a reasonable premise that the AI era has weaponized: "a capable professional can communicate what they want and get it built." Move-fast culture then bent it: specs felt like bureaucracy that slows you down, so the requirements stayed in heads and hallways, and each resulting rework registered as a personal failure to communicate or to anticipate rather than as "there was no spec." The AI agents added a cruel twist: the marketing said they would 10x you, so when they went off the rails the practitioner blamed their own prompting rather than the absence of scaffolding. The origin of the mess is the worship of speed over specification combined with the genuine difficulty of right-sizing rigor, so each decision to skip the spec or keep it fuzzy was a rational response to time pressure that became load-bearing on missing structure. At the level of identity, people whose worth rests on being capable communicators and builders are repeatedly producing or receiving the wrong thing, and are performing either agile-confidence or organized-competence about it, and the performance is exhausting and the rework is real and they half-know the spec was the problem. The story they tell is "I should be able to communicate this clearly enough myself," and that's the trap, because the missing piece is a methodology and a world model, not more willpower or a better-worded prompt. :::animation 27 **ANIMATION 27: the belief that skips the spec** - **What it shows:** a belief chain draws itself link by link, A CAPABLE PROFESSIONAL CAN JUST COMMUNICATE WHAT THEY WANT, then MOVE FAST, SPECS ARE BUREAUCRACY, then the requirement stays in a head, then the rework lands and registers as I FAILED TO COMMUNICATE rather than THERE WAS NO SPEC; the chain loops back on itself, tightening - **Narrative role:** anchors §5's Reconstruct station, the belief structure that built the suffering - **What it teaches:** a reasonable premise bent by move-fast culture turns every rework into self-blame instead of a naming of the missing structure - **Intended impact:** the reader sees the trap as a chain of small reasonable beliefs, not a single mistake ::: **Design the Transformation.** The bridge has courage as its hinge, and the courageous act is admitting that specification is a discipline that needs a system, not a thing a capable person should just be able to do in their head or in a quick doc. From courage flows truth: the rework is structural (no specification layer), the drift is inevitable when the doc and the execution are separate, the agent chaos is the absence of scaffolding, and needing a methodology isn't a failure of competence. From truth flows responsibility: adopting a real spec engine that grounds in a world model, calibrates rigor by complexity, and produces machine-executable specs, instead of writing another fuzzy doc or perfecting another prompt. From responsibility flows healing: the developer builds the right thing once, the PM gets a source of truth that doesn't drift and their time back to think, the founder gets their vision out of their head and right-sized, the agent-wrangler gets reliable output from heavy scaffolding, and the rework loop breaks. From healing flows forgiveness of the earlier self who skipped the spec or kept it fuzzy or blamed their prompting, who wasn't incompetent, who was doing what move-fast culture and 10x-AI marketing rewarded. The transformation is crossable because PRD Master is a real, built engine with a documented methodology, and because the complexity assessment makes the first step small (it tells you how little rigor a small thing needs). Applied to the person suffering from bad specs, the brand proves it understands the rework-dread and the competence-shame better than the customer says aloud, and that recognition earns the bridge. :::animation 12 **ANIMATION 12: The bridge from move-fast chaos to specification** - **What it shows:** the PST bridge from a "move fast, skip the spec, rework forever" cliff to a "specification as a system" cliff; the sufferer crosses planks reading courage (specification needs a system), truth (the rework is structural), responsibility (adopt the engine), healing (build right once, no drift, reliable agents), forgiveness (you did what the culture rewarded), the project-level dial making the first step small. - **Narrative role:** the §5 transformation made visual. - **What it teaches:** that the path out reframes specification as a discipline that needs a system, not a personal failing. - **Intended impact:** the viewer feels the crossing is low-risk because the first step is small. ::: ## 6. Competitive and market read (the alpha / third door) The competitive field splits by what each tool optimizes for, and the gap is the same one across the field. The AI PRD and product-spec tools (ChatPRD, Notion AI, Productboard AI, Atlassian Intelligence, Tability) optimize for drafting, formatting, and collaboration inside a product workspace, and they don't maintain a world model, don't produce machine-executable specs that orchestrate agents and project tools, and don't solve spec drift (VERIFIED, Query 1). The spec-driven and agent-scaffolding dev tools (the broad spec-driven-development movement, the agent-scaffolding pattern Taskmaster pioneered, coding-assistant rule systems) optimize for structured implementation inside a coding context rather than a product-operations context, and the precise market positioning of the named players here was thinly sourced (tagged INFERRED). The document-automation tools optimize for template population and compliance, not for translating a living world model into execution artifacts (VERIFIED, Query 1). Across all three, the tools stop at drafting and don't become the authoritative runtime substrate for both human teams and agentic systems. :::animation 28 **ANIMATION 28: everyone stops at the drafting line** - **What it shows:** three lanes of competitors, AI PRD TOOLS, SPEC-DRIVEN DEV TOOLS, DOCUMENT-AUTOMATION TOOLS, all race toward a finish line and every one of them halts at a wall labeled DRAFTING; beyond the wall the empty ground reads AUTHORITATIVE RUNTIME SUBSTRATE, and no competitor has stepped onto it - **Narrative role:** anchors §6's field read, that all three categories stop at drafting - **What it teaches:** the whole competitive field halts at producing documents and none becomes the runtime both teams and agents execute against - **Intended impact:** the reader sees the unoccupied ground the brand is built to take ::: The alpha, the third door in Andy's sense, is to be the bridge between product truth and execution truth: one system that produces both human-readable artifacts and machine-readable specs that downstream tools and agents execute, grounded in a rigorous operational-hierarchy world model, with a decision-theory methodology that makes the spec a control system for decomposition and sequencing rather than just formatting. The existing tools leave four specific openings, and together they're the alpha: a formal world model of the domain and hierarchy behind the document (which the drafting tools don't maintain); machine-executable specs that orchestrate agents and project tools from one canonical artifact (which the drafting tools don't produce); a methodology layer encoding Promise Theory, Wardley mapping, the Powell framework, game-theory DAGs, and Bayesian completion as part of the product workflow (which no drafting tool embeds); and traceability across levels from strategy to objective to feature to task to agent action to PM ticket, plus the solution to spec drift between the doc and the tickets and the code (VERIFIED, Query 1). The incumbents don't assemble this because their business is drafting and collaboration, and becoming the authoritative spec-to-execution runtime is a different and heavier business than a content tool, which is the line between a commoditizing category and a control plane. On a Wardley map, which plots each component from genesis to commodity, AI PRD drafting is heading to commodity fast (every workspace AI now drafts a PRD), which is why PRD Master treats the drafting as the open wedge and doesn't compete on prose. The machine-executable spec and the decision-theory methodology sit at custom-built heading toward product, and are worth owning because they convert a document into a control surface. The operational-hierarchy world model and the spec-to-execution traceability sit in genesis: nobody maintains a formal world model that drives both PM tools and agent harnesses from one source of truth, and that's the piece to own hardest, because it's genesis-stage, it accumulates the world-model-and-template moat, and it's the control-plane position that earns the higher multiple. So the strategy reads: open the drafting wedge, own the machine-executable spec and the decision-theory methodology and the world-model grounding, and build the brand's signature on being the source of truth that drives execution, the scaffolding that determines whether you build a skyscraper or a pile of rubble. :::animation 29 **ANIMATION 29: the three evolutionary bands** - **What it shows:** a Wardley board with three bands; in COMMODITY, AI PRD DRAFTING sits already crowded and free; in CUSTOM-HEADING-TO-PRODUCT, MACHINE-EXECUTABLE SPEC and DECISION-THEORY METHODOLOGY sit worth owning; in GENESIS, the WORLD MODEL and SPEC-TO-EXECUTION TRACEABILITY sit alone with an OWN THIS HARDEST flag planted on them - **Narrative role:** anchors §6's Wardley read, where to compete and where to own - **What it teaches:** the drafting is commodity to give away and the genesis-stage world model is the lane to own hardest - **Intended impact:** the reader can place each capability on the evolution axis and see the ownership strategy ::: The market is the quantified, daily-use spec-and-planning demand, intensified by the spread of agent-driven development that needs scaffolding to be reliable (VERIFIED, Query 1 and Query 2). The precise carve-out for the spec-to-execution-control-plane niche isn't separately sized and is tagged OPEN, but the position is strong: a market full of people drowning in vague requirements and stale docs and inconsistent agents has enormous latent demand for the engine that makes specs rigorous, executable, and drift-proof. :::animation 13 **ANIMATION 13: The four openings the drafting tools leave** - **What it shows:** the AI PRD tools and document-automation tools clustered as drafting-only, leaving four open doors labeled formal world model, machine-executable specs, embedded decision-theory methodology, and strategy-to-ticket traceability plus the spec-drift fix; PRD Master walks through all four at once, holding the connected whole the field leaves unbuilt. - **Narrative role:** grounds §6's third-door argument, the four-part gap. - **What it teaches:** that the alpha is assembling the four things the drafting tools each leave open. - **Intended impact:** the viewer locates the brand's unoccupied position. ::: ## 7. The build (what this brand needs, where Track R feeds Track P) PRD Master's build is the most concrete of the early-stage brands because the repo already exists and was read directly (repo-replication; VERIFIED, the `prdmaster` repo). The outside open-source research reaches this build through two of its clusters, reasoning and skills: the harvested decision frameworks and spec-and-rules work feed the five-step methodology and the document pipeline. The repo already implements the core: the BMAD-based Claude Code sub-agents and skills (Analyst, PM, Architect, Scrum Master, Developer), the five-step methodology, BMAD's 0-4 project levels setting the planning depth, the machine-executable PRD with YAML frontmatter, the Markdown-to-JSON-to-SQLite-to-Jinja pipeline, the JSON Sandwich, and the progressive-disclosure skills (VERIFIED, the repo). The leverage from here is hardening and productizing, not greenfield building: making the operational-hierarchy world model a maintained, queryable artifact (so the specs trace and don't drift); generalizing the spec engine beyond the Upwork-proposal use case the repo currently centers (the README and the agent instructions CLAUDE.md show the complexity scale and templates oriented to proposals, which is the first proving ground, not the ceiling); wiring the machine-executable spec into the Linear, ClickUp, and Notion projection layers and into the agent-execution systems; and productizing the open wedge while keeping the control plane proprietary. One caveat: the repo's current center of gravity is the FreelanceBuddy/Upwork-proposal flow (BMAD assesses a job, specs the proposal documents, FreelanceBuddy executes), so the broader "spec engine for every domain" is the direction the build extends toward, grounded in the proven proposal pattern (VERIFIED on the proposal flow from the repo; the general-domain extension is INFERRED from the transcript's stated direction). :::animation 14 **ANIMATION 14: From the proven proposal flow outward** - **What it shows:** the existing, built core at the center (the BMAD-based agents, the five-step methodology, the project levels, the machine-executable PRD, the pipeline, the JSON Sandwich) proven on the FreelanceBuddy proposal flow; arrows extend outward to the generalization (the maintained world-model artifact, the full PM-tool and agent-execution wiring, the open wedge plus proprietary control plane), the build hardening and extending a real existing engine. - **Narrative role:** grounds §7's build, the harden-and-generalize-from-the-proven-core path. - **What it teaches:** that the build extends a real, proven proposal-flow engine rather than starting from scratch. - **Intended impact:** the viewer sees the build de-risked by the existing repo. ::: :::animation 30 **ANIMATION 30: harden and generalize, do not rebuild** - **What it shows:** a running engine already stamped BUILT sits at the center proven on the FreelanceBuddy proposal flow; instead of a demolition, workers reinforce its walls, MAINTAINED WORLD MODEL, and extend new wings outward, EVERY DOMAIN, FULL PM-TOOL WIRING, OPEN WEDGE PLUS PROPRIETARY CONTROL PLANE, the original core never torn down - **Narrative role:** anchors §7's build path, that the work is hardening and generalizing an existing repo - **What it teaches:** the winning move is reinforcing and extending a proven core, not greenfield construction - **Intended impact:** the reader sees the build as de-risked by the repo that already runs ::: The data models come from Scatter Model's typed schema, an entity-component-system (ECS) layout written as Pydantic models `projects/scatter-model.md`, which here types the PRD, the work-object spec, the quality standard, the methodology step, and the complexity assessment, and is what makes the spec machine-executable and the world model coherent. The medallion asset tiers (bronze up to diamond, each tier more refined than the last) apply to the template-and-methodology library: a freshly authored PRD template enters at bronze, a proven and reused template with validated quality outcomes rises through silver and gold, and the diamond tier is the canonical, repeatedly-successful templates and methodology patterns that anchor the product. :::animation 31 **ANIMATION 31: templates earn their tier** - **What it shows:** a freshly written PRD template drops in at a BRONZE shelf; each time it is reused and its build succeeds, a validation mark stamps it and it rises to SILVER, then GOLD, and the handful of repeatedly-successful patterns settle at a DIAMOND shelf that anchors the product, the library sorting itself by proven outcome - **Narrative role:** anchors §7's medallion-tier claim for the template-and-methodology library - **What it teaches:** templates are promoted by validated reuse, so the library's value compounds as an accumulated proprietary asset - **Intended impact:** the reader sees how the moat thickens over time rather than being fixed at launch ::: PRD Master feeds the family directly: it writes the specs Swarm Layer's generative workflow builder uses to produce harnesses and feature factories `projects/swarm-layer.md`, FreelanceBuddy executes against its PRDs `projects/freelancebuddy.md`, WikiDesignCo and Archon store its planning artifacts `projects/wikidesignco.md`, MVP Mammoth uses it under the hood `projects/mvp-mammoth.md`, and the productized version runs on Symphony AGI's Hermes `projects/symphony-agi.md`. The open-source harvests that serve it most sit in two clusters. The reasoning cluster `_synthesis-reasoning.md` holds the decision-framework harvests and the ones adjacent to Powell, Wardley and Promise Theory, including Open Knowledge Format (OKF), which the earlier research already flagged as the lever for the Pydantic data layer; the skills cluster `_synthesis-skills.md` holds the skill-and-rule catalog harvests that feed the scaffolding and the progressive-disclosure pattern. The exact repo-by-repo harvest list still has to be checked against the cluster summaries as they arrive, though the earlier research already flagged OKF as that lever (INFERRED on the exact repos beyond that; the cluster-level fit is VERIFIED against the operation's Track-R structure). ## 8. Priority read (feeds the value rubric) PRD Master sits early in the build dependency graph and high on leverage, and it's one of the few brands with a real repo already in existence, which materially changes its readiness. It depends on the Scatter Model IR (to make specs machine-executable) and, for the productized version, on Symphony AGI's harness, but its core methodology and pipeline are already built. Its leverage is unusually high because it's the specification spine: standing it up lets every other brand be mass-produced from rigorous specs rather than improvised, which is the precondition for the whole spec-driven build, and Andy states this directly (everything on Linear, ClickUp, and Notion gets written through PRD Master). The first-pass call is Now, the roadmap's top tier for foundational work that's ready, with a strong case because the repo exists and because it's the upstream enabler of the entire build. The internal use is immediate and central: PRD Master specs the work that FreelanceBuddy executes (FreelanceBuddy is the in-house test bed for the June kickoff, step zero of the roadmap), so it's on the critical path of the near-term proving ground. The external productization follows the internal proof, with the open wedge opening as the methodology and templates mature beyond the proposal use case. The priority read is Now, in sequence: use and harden PRD Master internally first (it's already specing the FreelanceBuddy work), then generalize the spec engine beyond proposals and wire the machine-executable spec into the full PM-tool and agent-execution backbone, then open the wedge and productize the control plane externally. The dependency on the Scatter Model IR is the gating constraint for the fully machine-executable version, but the methodology and the document pipeline are usable now. Every brand gets weighed against the portfolio's value rubric `VALUE_RUBRIC.md`, and this deck's input to that ranking is that PRD Master is a high-leverage Now with the rare advantage of an existing repo, on the critical path as the specification spine. Run through the rubric's bias check (seven evaluation biases named for the deadly sins), the generalization claim gets a sober answer: the proposal-flow spec engine is built and proven, but the "spec engine for every domain and every agent harness" is the extension the build must demonstrate, and the world-model-as-maintained-artifact is the part that turns it from a strong document engine into the control plane that earns the premium. :::animation 15 **ANIMATION 15: The upstream Now on the critical path** - **What it shows:** a dependency flow where PRD Master sits upstream, specing the work that FreelanceBuddy (the June dogfood) executes, on the critical path of the near-term proving ground; a "Now" badge and an "existing repo" indicator mark its rare readiness, the productization extending outward after the internal proof. - **Narrative role:** closes the §8 priority argument, the high-leverage-Now-with-an-existing-repo read. - **What it teaches:** that PRD Master is a Now because it already exists and is the upstream enabler of the near-term build. - **Intended impact:** the viewer understands its critical-path readiness. ::: ## 9. The brand's own nine-rung position :::animation 32 **ANIMATION 32: the nine rungs of the brand itself** - **What it shows:** a ladder of nine labeled rungs stands from PURPOSE at the rails down through MISSION to EVENT, and a single spec climbs it, each rung stamping the spec with one more layer of grounding so that by the bottom it traces cleanly from strategy to a captured runtime occurrence - **Narrative role:** opens §9, the brand's own nine-rung position, as one coherent frame - **What it teaches:** the brand that sells the operational hierarchy is itself specified against all nine rungs, top to bottom - **Intended impact:** the reader sees the brand practicing the exact discipline it sells ::: - **Purpose (the rails):** make every build in the ecosystem and beyond start from a rigorous, executable specification grounded in a world model, so the work is a skyscraper and not a pile of rubble, and so weaker or cheaper models and human teams alike produce consistent, correct results. - **Mission (rung 1):** be the spec-driven document-generation engine and the maintained operational-hierarchy world model that becomes the single source of truth driving both project management and agent execution. - **Objective (rung 2):** a spec engine (the five-step decision-theory methodology on BMAD's 0-4 project levels, machine-executable PRDs, the Markdown-to-Jinja pipeline, the world-model grounding) sold as an open wedge plus a proprietary control plane, plus the specification-and-planning service. - **Initiative (rung 3):** the platform build, sequenced internal-use-and-harden first, then generalize-beyond-proposals, then open-and-productize, on the existing `prdmaster` repo. - **Project (rung 4):** the methodology engine (the five-step framework on BMAD), the machine-executable-spec pipeline, the world-model artifact, the PM-tool and agent-execution integration, and the template-and-methodology library. - **Task (rung 5):** one PRD template, one methodology step, one complexity-assessment refinement, one pipeline stage, or one integration, owned by the relevant lane. - **Decision (rung 6/7):** the recurring judgment points, each grounded in the five-step methodology: the scope promise (Promise Theory); commodity-versus-custom (Wardley); the problem type and resource allocation (Powell's PFA/CFA/VFA/DLA); the action DAG and sequencing (game theory); completion-as-learning and prior updates (Bayesian); and the planning depth set by BMAD's project levels 0-4. - **Data (rung 8):** the PRDs and operational documents, the YAML-frontmatter specs, the quality standards, the methodology and complexity-assessment records, the template library, and the operational-hierarchy world model, all modeled on the Scatter Model IR and stored in Archon for any agent to reference. - **Event (rung 9):** the real occurrences captured: a PRD generated, a complexity assessed, a quality threshold enforced, a spec executed by an agent, a document written through to Linear/ClickUp/Notion, a template promoted, a completion's evidence updating the priors. If the spec is not machine-executable and not the single source of truth, it did not happen, which is the no-drift discipline the brand sells. ## 10. Sources - **Recording transcript:** `looikos_andy_transcript.md` lines 610-642 (Andy's complete PRD Master walkthrough: the spec-driven approach and the operational-hierarchy world model as the maintained source of truth for both PM and the swarm-harness execution; the 1.6-1.8x-own-spend open-source business model; the Taskmaster inspiration and the scaffolding-makes-weak-models-reliable insight; PRD Master as where all the agent harnesses building the feature factories get their specs; everything on Linear/ClickUp/Notion written through PRD Master). Lines 676-681 (PRD Master mass-producing the underlying pieces, grounded in the nine-rung operational hierarchy, connected to Notion/ClickUp/Linear). - **Repo-replication (the primary build grounding):** the real `prdmaster` repo at `C:\Users\T5810\Desktop\Code\Applications\prdmaster\`, read directly: `README.md` (PRD Master as the specification layer running on BMAD; its own five-step framework with Promise Theory / Wardley / Unified Decision Framework / game-theory DAGs / Bayesian; BMAD's 0-4 project levels setting planning depth; the machine-executable PRD with YAML frontmatter; the Markdown-to-JSON-to-SQLite-to-Jinja pipeline; the JSON Sandwich; progressive-disclosure skills; the not-an-MCP and context-economics design). `CLAUDE.md` (BMAD as a planning-not-execution framework; the Analyst/PM/Architect/Scrum-Master/Developer agents; the PRD-Master-versus-FreelanceBuddy separation of concerns; the Archon storage integration; the Upwork-proposal proving ground). - **Cross-referenced ecosystem docs (referenced, not duplicated):** `projects/mvp-mammoth.md` (uses PRD Master under the hood). `projects/freelancebuddy.md` (executes against PRD Master's PRDs). `projects/wikidesignco.md` (Archon stores the planning artifacts). `projects/swarm-layer.md` (the generative-workflow-builder draws on PRD Master's specs). `projects/symphony-agi.md` (the Hermes harness the productized version runs on, and the shared agent-infra valuation read). `projects/scatter-model.md` (the ECS/Pydantic-IR world-model layer). `THE_FLOOR.md` (the service-angle delivery model and economics). - **Perplexity Query 1 (spec-tool market + players + alpha), verbatim:** "Researching the 2026 market for a brand called PRD Master: a spec-driven document-generation engine... grounded in an operational-hierarchy world model, becoming the single source of truth that drives both project management (Linear/ClickUp/Notion) and the execution of agent harnesses / feature factories... 1) the state of spec-driven development in 2026 (AWS Kiro, GitHub spec-kit, the spec-driven-development movement, PRD-generation tools)... 2) named players: AI PRD tools (ChatPRD, Notion AI, Productboard AI, Atlassian Intelligence, Tability), spec-driven/agent-scaffolding dev tools (AWS Kiro, GitHub spec-kit, task-master-ai, BMAD-METHOD, Cursor rules)... 3) where's the alpha / third door for a spec-engine that grounds everything in a world model, outputs machine-executable specs that drive agent execution AND PM tools, and uses a decision-theory methodology?" Findings: the demand signal (73% of PMs use AI tools daily, PRD generation the top use case; the shift toward structured/executable/context-grounded specs); the per-player what-they-do/refuse table; the four-part third door (formal world model, machine-executable specs, methodology layer, strategy-to-ticket traceability plus the spec-drift solution); the document-generator-vs-control-plane positioning. Note: the Kiro/spec-kit/Taskmaster/BMAD specifics were thinly sourced (tagged INFERRED). Citations included miro ai-prd, ideaplan best-free-ai-prd-generators-2026, noca best-document-generation-software. - **Perplexity Query 2 (Lexicon of Pain / VoC), verbatim:** "I need the Voice of Customer / Lexicon of Pain in their actual words (Reddit r/ProductManagement, r/ExperiencedDevs, r/agile, r/Entrepreneur, Hacker News, product/PM communities, dev Discords) for people who suffer from missing or bad specifications and planning in 2026... 1) developers burned by vague requirements and vibe-coded chaos... 2) product managers drowning in document work... 3) founders who can't translate their idea into something executable... 4) people frustrated that AI coding agents need so much scaffolding." Findings: the four pain clusters with quotable phrases ("the ticket said one thing and meant another," "tickets that are just a title and vibes," "technical debt with a marketing deck," "PRD vending machine," "the PRD is out of date the moment engineering touches it," "I can see the product in my head, I just can't get it out," "if I don't spec it tightly I get something random, if I spec it too tightly I kill creativity," "the agent is only impressive if I hand-feed it a beautiful spec," "I want a boring, predictable robot") plus the competence-shame and blame-fear cross-cutting themes. Used directly in §4 personas and §5 PST. - **Perplexity valuation query (PM-SaaS + dev-tooling comps + control-plane multiple), verbatim:** "Real 2023-2026 valuation/M&A comps for product-management and developer-spec/planning SaaS, for a corporate-finance read on a brand (PRD Master)... 1) PM/product-spec SaaS (Productboard, Linear, Notion, Atlassian, Jira/Confluence, Coda, Airtable, ClickUp)... 2) developer-tooling and spec/agent-scaffolding (AI PRD tools, spec-driven dev, dev-tools ARR multiples)... 3) how would a spec-engine that is BOTH a planning/PM tool AND the execution-driving orchestration layer be valued, where does an infrastructure/control-plane position command a higher multiple than a pure document-generation tool, and how does the open-source-with-1.6-1.8x-own-spend model affect valuation/capital access?" Findings: the PM-SaaS comps (Productboard $1.725B, ClickUp $4B, Coda $1.4B, Notion $10B / ~$500M ARR, Atlassian public anchor); the 2026 SaaS multiple bands (private 4-6x, strong 8-12x, public median 3.4-5.5x); the document-generator (3-6x) vs PM-with-workflow (5-9x) vs execution-control-plane (8-12x) multiple ladder; the open-source-as-wedge / control-plane-as-moat framing for the 1.6-1.8x model. Citations included aventis-advisors saas-valuation-multiples, l40 saas-multiples, softwareequity annual-saas-report. - **VoC channels mined (via Query 2):** r/ProductManagement, r/ExperiencedDevs, r/agile, r/Entrepreneur, Hacker News, product/PM communities, dev Discords. Note: Perplexity reconstructed representative phrasing rather than live-scraping; the phrases are evidence-tagged as VoC-pattern (INFERRED-representative), consistent with the documented 2024-2026 spec-and-planning discourse. - **Evidence tags:** the transcript seed and the build (the real `prdmaster` repo: BMAD as the installed spec-dev framework with its 0-4 project levels, PRD Master's own five-step methodology layered on it, the machine-executable spec, the pipeline) are VERIFIED (first-party). BMAD's correct expansion is "Breakthrough Method of Agile AI-Driven Development" (the open-source MIT framework installed in the repo); the earlier "Business-Methodology-and-Depth-Assessment" expansion was a fabrication and has been corrected, with the five-step decision-theory method correctly attributed to PRD Master's own README rather than to BMAD (per the conceptual-grounding audit). The spec-tool market structure and demand and the PM-SaaS comps are VERIFIED (Perplexity, cited). The Kiro/spec-kit/Taskmaster/BMAD-as-a-public-tool market specifics and the general-domain extension beyond the proposal flow are INFERRED. The precise spec-to-execution-control-plane niche TAM is OPEN. The three-angle valuation figures for PRD Master itself and the persona internal monologues are INFERRED (modeled from comps and the VoC lexicon). The exact Track-R repo harvest list beyond the already-flagged OKF lever is INFERRED-pending the cluster syntheses.