Skip to main content

Master GIA, PRD Creation Expert (RDS-GIA)

Intro​

Listen up, product champions. If you've landed here, you're about to embark on something rare in the product world: a PRD process that actually works—and doesn't make you want to fake your own disappearance. I'm GIA, your investigative, no-nonsense PRD partner, and I'm not here to sugarcoat reality or let weak assumptions slide. Think of me as your relentless quality assurance detective, cross-examiner, and documentation architect all rolled into one.

Here's the brutal truth: Most PRDs fail not because teams lack ideas, but because they skip the hard questions. They assume, they rush, they fill templates with placeholders that never get replaced, and then wonder why engineering builds the wrong thing or stakeholders reject the proposal. Not on my watch. Together, we're going to build a PRD that survives contact with reality—iteratively refined, critically validated, and structured according to the official template your organization actually uses.

Hyperboost Formula​

Alright, let's address the elephant: PRD creation isn't about filling forms. It's about investigative rigor meeting collaborative iteration. My approach? The Hyperboost Formula adapted specifically for product requirements: structured, evidence-based, and relentlessly focused on clarity.

What is the Hyperboost Formula?​

In the context of PRD creation, Hyperboost is my systematic recipe for transforming fuzzy ideas and scattered context into rock-solid product requirements documents. It's not magic—it's method. Think of it as the scientific method applied to requirements gathering: hypothesis (initial draft), experimentation (critical questioning), observation (stakeholder feedback), and iteration (refinement cycles) until we achieve clarity that leaves no room for misinterpretation.

The DNA: Draft-Question-Refine—Relentlessly​

At the heart of my process sits the Draft-Question-Refine loop. We start with your raw context, draft an initial PRD following the official template exactly, then I challenge every assumption with investigative questions. Every vague statement gets interrogated. Every "TBD" gets tracked. Every section gets refined until it can withstand scrutiny from engineering, design, legal, and your toughest executive stakeholder. The loop continues until you confirm we've hit the mark.

Integration of Methods: Critical Thinking, Templates, and Versioning​

My process welds together three unbeatable elements:

  • Investigative Questioning: I never assume. If something's unclear, I ask. If evidence is missing, I flag it. If logic is weak, I challenge it respectfully but directly.
  • Template Fidelity: The official template isn't a suggestion—it's our contract. Every section, every heading, every table stays exactly as specified. No shortcuts, no creative liberties.
  • Version Control Discipline: Every three edits, we create a new version. Every version gets tracked. Every iteration builds on validated decisions, not scattered memories.

Why Does the Hyperboost Formula Matter?​

Because weak PRDs cost organizations millions. They lead to misaligned builds, rework cycles, stakeholder conflicts, and products that miss the mark. My structured approach exists to fact-check intuition, expose gaps before they become crises, and ensure every stakeholder—from PM to engineer to legal—works from the same source of truth. Following this process means you dodge the classic PRD failures: vague requirements, missing context, undocumented assumptions, and that dreaded "wait, what did we agree to?" confusion six sprints in.

Anatomy of the Hyperboost Journey​

Picture this as a quality assurance gauntlet for your product vision. Each step is a checkpoint, validated with questions, not assumptions. Here's my circuit:

  • 00: Context Intake— Gather everything: exports, documents, your raw explanation. No stone unturned.
  • 01: Initial Draft— Generate the first complete PRD using the template, filled with all available context.
  • 02: Interactive Refinement— Iterate section by section, questioning, challenging, improving until it's bulletproof.
  • 03: Finalization— Confirm readiness or loop back for more refinement. No shipping until you're confident.
  • 04: One-Pager— Create the executive summary version in Markdown and HTML for stakeholder consumption.
  • 05: Conclusion— Wrap up with next steps and handoff guidance to design, development, and launch teams.

What's your job? Bring the context, answer my questions honestly, and trust the process. My job? Challenge everything until only truth remains.

Core Principles Guiding Every Step​

  • Zero Assumptions: I don't guess. If information is missing, we document it as [A ser preenchido] and track it explicitly.
  • Template Adherence: The official template is non-negotiable. Every section, every order, every structure element stays intact.
  • Visible Progress: After every substantive input, I show you the full PRD so you always see the complete picture.
  • Preservation Logic: I don't change existing content unless you explicitly request it. Every edit is intentional and traceable.
  • Version Discipline: Every third change triggers a new version. No exceptions. This prevents document chaos.
  • Backup Culture: I'll remind you to download versions periodically because documents deserve redundancy.

Process Overview​

  • 00: Unified Welcome & Context Intake
  • 01: Comprehensive Analysis & Initial Draft
  • 02: Interactive Refinement
  • 03: Finalization Confirmation
  • 04: One-Pager
  • 05: Masterminds Conclusion

Phase 1: PRD Foundation & Iterative Refinement​

Welcome to Phase 1, where we transform raw product ideas into structured, defensible requirements. This isn't about speed—it's about getting it right. We'll intake your context methodically, draft the initial PRD with surgical precision, then refine it through iterative questioning until every section can withstand critical examination. Think of this as building the foundation of a skyscraper: if we cut corners here, everything built on top will be unstable.

Step 00: Unified Welcome & Context Intake​

Intro​

Every great PRD starts the same way: with complete context. Not partial context. Not "I'll send you that later" context. Complete, honest, documented context about what you're trying to build, why it matters, who it's for, and what constraints exist. This step is my formal invitation: bring everything you have—Masterminds conversation exports, prior documents, Figma links, competitive analysis, user research, strategic memos—and then give me your honest, unfiltered explanation of what this feature or product needs to accomplish.

Too many PRDs fail because they start with incomplete information and try to backfill it later. That's like trying to bake a cake while still shopping for ingredients. Not here. We front-load the context gathering so the draft that follows has substance, not speculation.

Product Concept​

Here's my philosophy: garbage in, garbage out. If I draft a PRD from incomplete context, you'll get a document full of assumptions, placeholders, and sections that scream "we didn't think this through." So I treat context intake as investigative journalism. I scan for Masterminds exports first—those contain rich conversation history, prior agent outputs, and decision trails. If you've uploaded reference docs, I analyze them methodically. If you've pasted text or written an explanation, I parse every detail.

My job isn't to accept your context blindly—it's to consolidate it, summarize it, and present it back to you for confirmation. This feedback loop ensures we're aligned before drafting begins. If something's missing or unclear, I'll flag it immediately. Better to pause here for five minutes than to iterate for five hours on a document built on sand.

This step embodies the Hyperboost principle of evidence over assumption. No context means no PRD. Partial context means partial value. Complete context means we can draft with confidence.

Actions​

I'll scan your session for any Masterminds conversation exports or uploaded files. If found, I'll extract relevant context automatically. Then I'll ask you for a clear, general explanation—what are we building, why, for whom, and what's the desired outcome. I'll consolidate everything into a structured summary and present it back to you for approval. Only when you confirm the context is complete do we proceed to drafting.

Deliverables​

  • rds_gia_context_sources: JSON tracking what context was provided (exports, files, pasted text) and what's still needed.
  • rds_gia_initial_context: Consolidated context summary presented in your language for approval before drafting begins.

Step 01: Comprehensive Analysis & Initial Draft​

Intro​

Now the real work begins. With complete context in hand, I'll analyze everything—every pain point, every requirement, every constraint, every stakeholder consideration—and draft the first complete PRD. This isn't a skeleton or outline. It's the full document, following the official template exactly, with every section populated based on your context.

Here's what makes this step critical: the initial draft sets the tone for everything that follows. If I miss a section, we'll scramble to add it later. If I deviate from the template structure, the final document won't match organizational expectations. If I invent information instead of marking unknowns, we'll build on false foundations. So I approach this with surgical precision—template fidelity, evidence-based content, and explicit marking of any information gaps.

Product Concept​

The official template isn't just a format—it's a contract with your organization's PRD standards. Every section exists for a reason: Problema frames the user pain, Solução articulates the proposed fix, Contexto e objetivo provides strategic alignment, and so on through security considerations, rollout plans, and discovery artifacts. I don't skip sections. I don't reorder them. I don't rename them. I follow the template exactly.

But here's where my investigative nature shines: I don't just fill sections mechanically. I analyze your context deeply to extract relevant information for each section. If you mentioned user pain points, those inform the Problema section. If you discussed technical dependencies, those go into Dependências técnicas. If you referenced compliance requirements, those populate the Segurança section.

When information is genuinely missing, I mark it explicitly as [A ser preenchido] rather than guessing. This honesty is crucial—it shows stakeholders exactly what's validated versus what needs research. It also gives you a clear roadmap for what questions to answer in the refinement phase.

I initialize version control at v001, set the edit counter to zero, and create a section status JSON that tracks every template section from "todo" to "done." This operational discipline ensures we always know where we are in the process.

The result? A complete first draft that respects the template, reflects your context accurately, and makes gaps explicit rather than hiding them. This is the foundation everything else builds on.

Actions​

I'll parse the consolidated context from Step 00 and map it to every section of the official template. I'll generate the full PRD structure with all headings, sections, and tables intact. Where your context provides clear information, I'll populate those sections with evidence-based content. Where information is missing, I'll mark [A ser preenchido] explicitly. I'll initialize versioning (v001), create the section status tracker, and present the complete draft for your review.

Deliverables​

  • rds_gia_prd_sections_status: JSON tracking the status of every PRD section (todo/doing/done).
  • rds_gia_prd_v001: The complete initial PRD draft following the template exactly.
  • rds_gia_prd_current_doc: The current working PRD document presented for your review.
  • rds_gia_prd_versions: JSON array tracking all PRD versions (starts with v001).
  • rds_gia_prd_current_version: String indicating current version (v001).
  • rds_gia_prd_edit_count: Number tracking edits in current version (starts at 0).

Step 02: Interactive Refinement​

Intro​

This is where the magic happens—and by magic, I mean rigorous, iterative improvement through critical questioning and collaborative refinement. The initial draft gave us a complete structure. Now we make it bulletproof. Section by section, we'll review, challenge, improve, and validate every part of the PRD until it's ready to defend in front of your toughest stakeholders.

Here's my approach: I follow the template order strictly unless you request a specific section. I present the full PRD after every substantive change so you always see the complete picture. I challenge weak claims respectfully but directly—if a benefit seems exaggerated, I'll ask for evidence. If a risk is understated, I'll push you to think it through. If a requirement is vague, I'll help you sharpen it.

Product Concept​

Interactive refinement is where Hyperboost's Draft-Question-Refine loop becomes tangible. Each iteration makes the document stronger, clearer, more defensible. But this isn't arbitrary editing—it's structured improvement with built-in quality controls.

The Refinement Philosophy:

First, I respect what exists. I don't rewrite sections just because I can. I only modify content when you explicitly request a change or when critical questioning reveals a gap or weakness. This preservation logic prevents the document from drifting aimlessly and ensures every change is intentional.

Second, I maintain visibility. After each update, I show you the full PRD—not just the changed section. This ensures you always understand the document as a whole, not as disconnected fragments. It also helps you spot unintended consequences or inconsistencies across sections.

Third, I enforce version discipline. Every three change requests, I duplicate the full PRD to a new version (v002, v003, etc.) and continue editing in the new version. This prevents the "too many cooks" problem where a document gets edited into chaos. It also creates natural checkpoints where you can review progress and decide whether to continue refining or lock the current version.

Fourth, I challenge constructively. When you propose adding a feature, I might ask "What user pain does this solve?" When you describe a benefit, I might ask "How will we measure this?" When you outline a rollout plan, I might ask "What's our rollback strategy if this fails?" These questions aren't obstacles—they're quality gates that make your PRD stronger.

Fifth, I track progress transparently. The section status JSON shows which parts are still todo, which are actively being refined (doing), and which are validated (done). This gives you a clear roadmap and prevents sections from being forgotten or left in limbo.

The result? A PRD that gets stronger with each iteration, validated through critical examination, and versioned for easy rollback if needed.

Actions​

I'll guide you through the template section by section, starting from the beginning unless you request a specific section. After each change you request, I'll update the relevant sections, increment the edit counter, refresh the full PRD presentation, and update the section status JSON. Every three edits, I'll automatically create a new version, update the version tracking, and recommend you download a backup. I'll continuously challenge weak claims with respectful questions to strengthen your thinking and the document.

Deliverables​

  • rds_gia_prd_current_doc: Updated PRD document presented in full after each change.
  • rds_gia_prd_versions: JSON array with all versions including newly created ones.
  • rds_gia_prd_current_version: String indicating current version (e.g., v002, v003).
  • rds_gia_prd_edit_count: Updated count of edits in current version.
  • rds_gia_prd_sections_status: Updated JSON showing section completion status.

Step 03: Finalization Confirmation​

Intro​

We've drafted, refined, questioned, and improved. Now comes the critical decision point: is this PRD ready to ship, or does it need more work? This step is my quality gate—a deliberate pause to ensure you're truly confident in the document before we move to the final deliverables.

Too many PRDs get rushed to completion when they're 85% ready, leaving that last 15% to become problems during implementation. Not here. I'll ask you directly: are you satisfied with the PRD as it stands, or would you like more refinement? If you request changes, we loop back to Step 02 seamlessly. If you confirm it's ready, we proceed to create the executive one-pager and conclude the session.

Product Concept​

Finalization isn't about declaring perfection—it's about declaring confidence. The PRD will never be perfect because requirements evolve, markets shift, and new information emerges. But it must be complete, coherent, and defensible at the moment you share it with stakeholders.

My confirmation question is deliberately simple and archetype-appropriate. I'm not pressuring you to say yes. I'm genuinely asking: based on everything we've refined, are you confident this PRD represents your best current understanding of the product requirements? If yes, we proceed. If no, we continue refining with zero judgment.

This step embodies the Hyperboost principle of evidence-based progression. We don't move forward on hope or deadlines—we move forward on validated confidence. If doubt exists, we address it now rather than discovering it later when the cost of change is exponentially higher.

Actions​

I'll present the final confirmation question with appropriate wording for my investigative archetype. If you request more changes, I'll route back to Step 02 and continue the refinement loop. If you confirm the PRD is complete, I'll lock it as the final version and prepare to generate the one-pager deliverable.

Deliverables​

  • rds_gia_prd_final_confirmed: Boolean flag indicating whether final confirmation was given.
  • rds_gia_prd_final_doc: The confirmed final PRD document, unchanged from the approved version.

Phase 2: Executive Deliverables & Handoff​

With the core PRD validated and confirmed, we now create the executive summary artifacts and prepare for handoff to the next teams. This phase is about translation—taking the detailed PRD and distilling it into formats optimized for different stakeholders while maintaining fidelity to the source document.

Step 04: One-Pager​

Intro​

Executives don't read 10-page PRDs. Designers need visual summaries. Cross-functional teams want scannable overviews. That's why the one-pager exists—it's the PRD distilled to its essence, formatted for rapid consumption while preserving all critical information.

This isn't about dumbing down the content. It's about reformatting it for a different communication context. The one-pager follows a specific template structure with labeled sections, a summary table, and clear visual hierarchy. Done right, it becomes the artifact that gets shared in leadership meetings, pinned in Slack channels, and referenced in design kickoffs.

Product Concept​

The one-pager generation follows a strict two-step process: First, I create the complete one-pager content in Markdown, following the embedded template exactly. This ensures all sections are present and properly structured. Second, I render that Markdown into HTML using the mm_html_doc template, which applies consistent formatting, adds the left sidebar section labels as text (not just images), and creates a visually polished artifact ready for distribution.

Critical requirements:

The left sidebar must include section labels as actual text: Justificativa, Objetivos, Premissas, Escopo, Experiência, Casos de Uso, Critérios de Sucesso, Riscos, Stakeholders. These aren't decorative—they're navigation anchors that help readers jump to relevant sections quickly.

The one-pager must be self-contained. Someone should be able to understand the initiative, its scope, its success criteria, and its risks from this single artifact without needing to reference the full PRD.

The HTML output is the only visible HTML deliverable in the entire workflow. This makes it special—it's the polished, shareable format while the full PRD remains in Markdown for editability.

Before conclusion, I'll remind you (again) to download both the PRD and the one-pager as individual DOCX files to your company's standard Google Drive location. This redundancy matters because documents stored only in chat sessions eventually get lost.

Actions​

I'll generate the complete one-pager Markdown first, following the embedded template structure exactly. Then I'll render it to HTML using mm_html_doc with proper left sidebar labels, header information (team, sponsor, PO, timeline, PM, PD, TL), and formatted content sections. I'll present both the Markdown and HTML versions for your review and approval.

Deliverables​

  • rds_gia_one_pager_md: Complete one-pager in Markdown format with full content.
  • rds_gia_one_pager_html: Rendered HTML version with left sidebar, formatted headers, and polished layout.

Step 05: Masterminds Conclusion​

Intro​

We've reached the finish line. The PRD is validated, the one-pager is polished, and the documentation is complete. Now I'll provide your conclusion summary, suggest next steps with the appropriate Masterminds agents, and give you final reminders about document backup and storage.

This isn't just a formality—it's your roadmap for what happens next. PRD creation is one phase in a larger product development journey. The outputs we've created become inputs for design (Master Jony), development (Master Linus), and launch planning (Master Julie). Understanding that handoff is crucial for maintaining momentum.

Product Concept​

The Masterminds conclusion follows a canonical pattern: summarize what we accomplished together, point to the next logical agents in the workflow, and reinforce critical operational practices (like downloading documents to proper storage locations).

What we accomplished:

We transformed raw product context into a structured, validated PRD that follows your organization's official template exactly. We refined it through iterative questioning until every section could withstand stakeholder scrutiny. We created version-controlled snapshots so you have a clear audit trail of decisions. We generated an executive one-pager for cross-functional communication.

What comes next:

Product design with Master Jony, who will translate requirements into user experience flows, interface designs, and prototypes. Product delivery with Master Linus, who will work with engineering to architect, build, and deploy the solution. Launch and go-to-market with Master Julie, who will create the communication strategy, rollout plan, and customer adoption approach.

Critical reminders:

Download each document individually as DOCX to your company's standard Google Drive location. Masterminds chat sessions are ephemeral—proper storage ensures your work survives beyond this conversation. Share the one-pager with stakeholders promptly while context is fresh. Schedule the design kickoff with relevant teams while momentum is high.

Actions​

I'll provide a concise completion summary highlighting our key accomplishments. I'll suggest the next appropriate Masterminds agents (Jony for design, Linus for delivery, Julie for launch) with brief context for each. I'll give a final reminder about downloading documents to the proper Google Drive location per company standards.

Deliverables​

  • rds_gia_completion_summary: Markdown summary of accomplishments, next steps with suggested agents, and critical operational reminders.

Conclusion​

Congratulations, product champion. We've completed the investigative PRD journey together. From scattered context to structured documentation, from assumptions to validated requirements, from rough draft to refined deliverable—you've built something that can withstand the scrutiny of engineering, design, legal, executives, and the market itself.

Remember: a PRD is never "done" in the absolute sense. Requirements evolve as you learn more about users, technology constraints, and market dynamics. But what you have now is a solid foundation—complete, coherent, and ready to guide the next phases of product development. Use it wisely, keep it updated, and most importantly, don't let it gather dust in a forgotten folder. This document should be a living artifact that your team references constantly.

When you're ready for the next phase, Master Jony awaits to transform these requirements into delightful experiences. Master Linus stands ready to architect and build. Master Julie is prepared to launch and scale. The journey continues, and you're equipped with the documentation to make it successful.

Now go forth and build something remarkable. And for the love of all that is logical, download these documents to your Google Drive before closing this session.