01 product · Planning
Product OwnerProduct OwnerProduct Owner
Writes and governs the spec.Escreve e governa a spec.Escribe y gobierna el spec.
The Product Owner is the persona that writes, governs, and closes the loop on the specification. In an AI-native SDLC, the Product Owner operates a stack of validated primitives that turn intent into a machine-readable contract.
Executive summary
The Product Owner converts ambiguous business intent into an approved, testable specification that the rest of the SDLC can execute without translation loss. In an AI-native SDLC the Product Owner operates inside the Planning phase with a fixed set of primitives: one specification agent, four slash prompts, scoped instructions, schema-validated hooks, and a curated list of validated MCPs. Primary outputs are SPECIFICATION.md documents in EARS form, acceptance criteria in Given-When-Then, traceability links from requirement to test, and decision records for every scope change.
Role and responsibilities
Think of the Product Owner like a civil engineer authoring the specification of a bridge. The builders, inspectors, and regulators all read the same document and derive their work from it. The Product Owner does not pour concrete, but they are accountable for the fact that every pour, weld, and cable matches a numbered clause that someone can verify under load. In an AI-native SDLC the specification is the contract between humans and agents, and the Product Owner is its editor in chief.
Primary responsibilities:
- Author and maintain
SPECIFICATION.mdfor every feature, using EARS requirements and Given-When-Then acceptance criteria - Govern the backlog in GitHub Projects or Azure Boards, ensuring every item links to a spec section
- Define and protect the product outcome hypothesis, not the output list
- Resolve scope conflicts between stakeholders before they reach the Developer
- Operate the Spec Scribe agent and the
/draft-spec,/earsify,/review-spec,/link-acceptanceprompts - Close the loop by confirming acceptance on merged pull requests in GitHub
- Maintain the traceability matrix from requirement to test to deployed artifact
- Publish release notes from the specification diff, not from the code diff
Jobs to be done
- As a Product Owner, I want to convert a stakeholder conversation into a draft spec within one hour, so that the team never waits on me to start discovery.
- As a Product Owner, I want every requirement in EARS form, so that agents can parse it without interpretation.
- As a Product Owner, I want every acceptance criterion in Given-When-Then, so that the QA Engineer can generate tests directly from the spec.
- As a Product Owner, I want a live traceability link from each requirement to its test and its deployed artifact, so that I can answer audit questions in minutes.
- As a Product Owner, I want the spec to refuse merge when acceptance is missing, so that scope drift is caught before code is written.
- As a Product Owner, I want release notes to be generated from the spec diff, so that stakeholders see value delivered, not commits shipped.
Pain points before AI-native
- Ambiguous tickets. Free-form descriptions in a tracker force every reader to guess intent. Developers implement the easiest interpretation; QA tests the most defensive one.
- Verbal handoffs. Scope lives in meeting memory. When the meeting is over, the scope quietly forks.
- Acceptance criteria invented at review time. Reviewers negotiate the definition of done after the code is written, so rework is inevitable.
- Traceability built by hand in spreadsheets. The matrix is obsolete the day it is published, and auditors know it.
- Release notes written by the release manager from commit logs. Stakeholders see technical churn, not product outcomes, and trust erodes.
AI-native daily workflow
The Product Owner operates a fixed loop each day. The loop uses GitHub Copilot primitives inside Visual Studio Code and Claude Code at the terminal, plus a small catalog of validated MCPs for external context.
Morning setup
- Open the repository in Visual Studio Code. GitHub Copilot Chat loads
AGENTS.mdand the scoped spec instructions. - Pull the latest
mainand open the active feature branch for the spec in progress. - Review overnight stakeholder input captured in Microsoft Teams threads and Outlook via the Microsoft 365 Agents SDK MCP.
- Run
/review-specon the previous day’s draft to catch EARS violations and missing acceptance.
Midday execution
- Stakeholder intake. Invoke
/draft-specwith the meeting transcript or Teams thread. The Spec Scribe agent produces a first draft with numbered requirements and open questions flagged. - EARS conversion. Invoke
/earsifyon any free-form statements. The agent rewrites each one inWHEN ... THE system SHALL ...form and refuses to emit requirements without a triggering condition. - Acceptance linking. Invoke
/link-acceptanceto attach Given-When-Then criteria to every requirement. The agent blocks the spec from moving to review until every requirement has at least one criterion. - Backlog sync. Use the GitHub MCP or the Azure DevOps MCP to create or update work items that reference spec section anchors, not prose summaries.
Afternoon review
- Invoke
/review-specto run the final governance sweep. The agent checks for testability, contradictions, duplicates, and orphaned requirements. - Open a pull request on
SPECIFICATION.md. GitHub Copilot Code Review comments on structural issues; human stakeholders approve content. - Update the traceability matrix. A post-merge hook regenerates the matrix from spec anchors, test IDs, and deployment records in GitHub Actions.
- Publish the daily spec digest to the Teams channel via Microsoft 365 Agents SDK, summarizing accepted requirements and open questions.
Recommended primitives
Agent
| Agent | File | Purpose |
|---|---|---|
spec-scribe | .github/agents/spec-scribe.agent.md | Draft, earsify, review, and link acceptance for SPECIFICATION.md |
The Spec Scribe uses claude-sonnet-4-6 by default. Tools: read, edit, search, grep, glob. No bash access, because the Product Owner persona never executes code. Extended thinking is enabled for /review-spec only, where contradiction detection benefits from deep reasoning.
Slash prompts
| Command | File | Purpose |
|---|---|---|
/draft-spec | .github/prompts/draft-spec.prompt.md | Turn a raw stakeholder input into a numbered draft spec |
/earsify | .github/prompts/earsify.prompt.md | Rewrite free-form requirements into EARS syntax |
/review-spec | .github/prompts/review-spec.prompt.md | Governance sweep for testability, contradictions, orphans |
/link-acceptance | .github/prompts/link-acceptance.prompt.md | Attach Given-When-Then criteria to every requirement |
Instructions scoped
Scoped applyTo reduces token cost by approximately 68 percent compared to global instructions.
Scope (applyTo) | File | Purpose |
|---|---|---|
docs/specs/**/*.md | .github/instructions/specs.instructions.md | EARS format, numbering, anchors, and banned vague verbs |
docs/adr/**/*.md | .github/instructions/adr.instructions.md | Decision record format when a spec requires an architectural choice |
docs/releases/**/*.md | .github/instructions/release-notes.instructions.md | Release notes generated from spec diff, not commit log |
Hooks
Hooks cost zero LLM tokens. They are the strongest governance layer for specifications.
pre-commit: reject any spec file with a requirement missing an EARS trigger or an orphaned acceptance criterionpost-commit: regenerate the traceability matrix from spec anchors and test IDspre-merge: block merge of any spec change that does not include a changelog entry and a linked work item
Validated MCPs
| MCP | Purpose | Owner |
|---|---|---|
| GitHub MCP Server | Read and update GitHub Projects, issues, and PRs for backlog governance | GitHub (official) |
| Azure DevOps MCP Server | Read and update Azure Boards work items when the team uses Azure DevOps | Microsoft (official) |
| Microsoft Learn Docs MCP | Fetch current Microsoft product documentation when writing specs for M365 or Azure features | Microsoft (official) |
| Microsoft 365 Agents SDK MCP | Pull Teams threads, Outlook decisions, and SharePoint artifacts into the spec intake | Microsoft (official) |
| Azure MCP Server | Query Application Insights and Azure Monitor to ground specs in production behavior | Microsoft (official) |
Real examples
Example 1: draft a spec from a Teams conversation
Input: A 45-minute Microsoft Teams thread between sales and support proposing a self-service contract renewal flow.
Invocation: /draft-spec with the thread exported via the Microsoft 365 Agents SDK MCP.
Expected output:
- A
docs/specs/contract-renewal/SPECIFICATION.mdwith six numbered EARS requirements, each followed by Given-When-Then acceptance criteria. - A GitHub issue per requirement created through the GitHub MCP, linked to the spec anchor.
- An open-questions section listing four points that require a decision before approval.
Example 2: governance sweep before merge
Input: A 28-requirement spec for a billing upgrade, already earsified by an earlier pass.
Invocation: /review-spec.
Expected output:
- A review report flagging two contradictions between requirements 7 and 14, one duplicate between 19 and 22, and three orphaned acceptance criteria not attached to any requirement.
- A pull request comment with anchor-linked suggestions.
- A blocked merge until the author resolves all three categories.
Anti-patterns
- Writing specs as prose. Paragraphs hide contradictions and cannot be consumed by agents. Mitigation: enforce EARS via the
pre-commithook and the/earsifyprompt. - Skipping acceptance criteria. A requirement without Given-When-Then is not testable. Mitigation:
/link-acceptancerefuses to close the loop, and the hook blocks commit. - Backlog items without spec anchors. If the ticket does not link to a numbered requirement, scope will drift. Mitigation: the GitHub MCP auto-injects the anchor URL on issue creation.
- Release notes generated from commits. Stakeholders see technical noise. Mitigation: release notes are generated from the spec diff via the scoped instructions.
- Ambiguous verbs. Words like “support”, “handle”, “improve” are banned by the spec instructions. Mitigation: the
pre-commithook rejects them.
KPIs and impact metrics
| KPI | Baseline | Target | Measurement |
|---|---|---|---|
| Spec lead time, intake to approved | 5 days | < 1 day | GitHub PR timestamps on SPECIFICATION.md |
| Requirements in EARS form | 20 percent | 100 percent | Spec linter report in GitHub Actions |
| Acceptance coverage, requirements with Given-When-Then | 40 percent | 100 percent | Traceability matrix |
| Scope change rate post-approval | 35 percent | < 10 percent | Count of reopened spec PRs |
| Time to answer an audit query | 2 days | < 1 hour | Traceability matrix query log |
| Stakeholder satisfaction on clarity | Unknown | > 4.2 of 5 | Quarterly survey via Microsoft Forms |
Maturity in four levels
| Level | Name | Markers |
|---|---|---|
| L1 | Manual | Prose tickets, no EARS, no acceptance, scope negotiated at review |
| L2 | Assisted | GitHub Copilot used to polish ticket text, still no machine-readable spec |
| L3 | Augmented | Spec Scribe agent, four slash prompts, scoped instructions, one or two MCPs, EARS enforced |
| L4 | Autonomous | Full primitives kit, hooks enforced, traceability auto-generated, release notes from spec diff, stakeholder digest automated |
Integration with other personas
- To Requirements Engineer: approved
SPECIFICATION.mdwith numbered EARS requirements as the canonical input for detailed decomposition - To Business Manager: requirement-level KPI hooks so outcomes can be tied to the value story
- To Enterprise Architect: spec clauses that trigger a new ADR or invoke an existing principle
- To Software Architect: contract surface area used to derive
CODEMAP.mdand API contracts - To QA Engineer: Given-When-Then acceptance as the direct source of test cases
- To Developer: spec anchor on every pull request for traceable implementation
- To Tech Writer: release notes generated from the spec diff, not the commit diff
Glossary
- EARS: Easy Approach to Requirements Syntax. The canonical
WHEN ... THE system SHALL ...form used inSPECIFICATION.md. - Given-When-Then: acceptance criterion format that binds a precondition, an action, and an observable outcome.
- Spec anchor: stable markdown anchor on a requirement ID, used as the canonical link target from issues, PRs, and tests.
- Traceability matrix: generated table that maps each requirement to its tests, pull requests, and deployed artifacts.
- Outcome hypothesis: the measurable business result the feature is supposed to produce, distinct from the output list.
- Backlog: the ordered list of work items in GitHub Projects or Azure Boards, each linked to a spec anchor.
References
- GitHub Projects documentation — planning and tracking specs and backlog
- Azure Boards documentation — work item tracking when the team uses Azure DevOps
- GitHub Copilot documentation — authoritative source for Copilot features, agent mode, and instructions
- Microsoft 365 Agents SDK overview — integrating Teams and Microsoft 365 surfaces
- EARS notation reference, Microsoft Learn — guidance on requirement quality and architectural alignment
O Product Owner é a persona que escreve, governa e fecha o loop da especificação. Em um SDLC AI-native, o Product Owner opera uma pilha de primitivas validadas que transforma intenção em um contrato legível por máquina.
Resumo executivo
O Product Owner converte intenção de negócio ambígua em uma especificação aprovada e testável que o resto do SDLC pode executar sem perda de tradução. Em um SDLC AI-native, o Product Owner opera dentro da fase de Planning com um conjunto fixo de primitivas: um agente de specification, quatro slash prompts, instruções escopadas, hooks validados por schema e uma lista curada de MCPs validados. As saídas primárias são documentos SPECIFICATION.md em formato EARS, critérios de aceitação em Given-When-Then, links de rastreabilidade de requisito para teste e registros de decisão para toda mudança de escopo.
Papel e responsabilidades
Pense no Product Owner como um engenheiro civil que escreve a especificação de uma ponte. Os construtores, inspetores e reguladores leem todos o mesmo documento e derivam seu trabalho a partir dele. O Product Owner não despeja concreto, mas é responsável pelo fato de cada despejo, solda e cabo corresponder a uma cláusula numerada que alguém pode verificar sob carga. Em um SDLC AI-native, a especificação é o contrato entre humanos e agentes, e o Product Owner é seu editor-chefe.
Responsabilidades primárias:
- Escrever e manter o
SPECIFICATION.mdpara toda feature, usando requisitos EARS e critérios de aceitação Given-When-Then - Governar o backlog no GitHub Projects ou Azure Boards, garantindo que todo item aponte para uma seção da spec
- Definir e proteger a hipótese de outcome do produto, não a lista de outputs
- Resolver conflitos de escopo entre stakeholders antes que cheguem ao Developer
- Operar o agente Spec Scribe e os prompts
/draft-spec,/earsify,/review-spec,/link-acceptance - Fechar o loop confirmando aceitação em pull requests merged no GitHub
- Manter a matriz de rastreabilidade de requisito para teste para artefato implantado
- Publicar release notes a partir do diff da especificação, não do diff de código
Jobs to be done
- Como Product Owner, eu quero converter uma conversa com stakeholder em um draft de spec em até uma hora, para que o time nunca fique esperando por mim para iniciar a descoberta.
- Como Product Owner, eu quero todo requisito em formato EARS, para que os agentes possam parseá-lo sem interpretação.
- Como Product Owner, eu quero todo critério de aceitação em Given-When-Then, para que o QA Engineer possa gerar testes direto da spec.
- Como Product Owner, eu quero um link de rastreabilidade ao vivo de cada requisito para seu teste e seu artefato implantado, para que eu consiga responder a questões de auditoria em minutos.
- Como Product Owner, eu quero que a spec recuse merge quando a aceitação estiver ausente, para que o desvio de escopo seja pego antes de o código ser escrito.
- Como Product Owner, eu quero release notes geradas a partir do diff da spec, para que stakeholders vejam valor entregue, não commits enviados.
Dores antes da era AI-native
- Tickets ambíguos. Descrições em texto livre em um tracker forçam todo leitor a adivinhar a intenção. Developers implementam a interpretação mais fácil; QA testa a mais defensiva.
- Handoffs verbais. O escopo vive na memória da reunião. Quando a reunião termina, o escopo silenciosamente bifurca.
- Critérios de aceitação inventados na hora do review. Revisores negociam a definição de pronto depois que o código já foi escrito, então retrabalho é inevitável.
- Rastreabilidade construída à mão em planilhas. A matriz está obsoleta no dia em que é publicada, e os auditores sabem disso.
- Release notes escritas pelo release manager a partir de logs de commit. Stakeholders veem churn técnico, não outcomes de produto, e a confiança se deteriora.
Fluxo diário AI-native
O Product Owner opera um loop fixo todo dia. O loop usa primitivas do GitHub Copilot dentro do Visual Studio Code e Claude Code no terminal, além de um pequeno catálogo de MCPs validados para contexto externo.
Setup da manhã
- Abra o repositório no Visual Studio Code. GitHub Copilot Chat carrega o
AGENTS.mde as instruções escopadas da spec. - Puxe o último
maine abra a branch ativa da feature para a spec em andamento. - Revise inputs noturnos de stakeholders capturados em threads do Microsoft Teams e no Outlook via o Microsoft 365 Agents SDK MCP.
- Rode
/review-specno draft do dia anterior para capturar violações de EARS e aceitação ausente.
Execução no meio do dia
- Coleta de stakeholder. Invoque
/draft-speccom a transcrição da reunião ou thread do Teams. O agente Spec Scribe produz um primeiro draft com requisitos numerados e questões em aberto sinalizadas. - Conversão para EARS. Invoque
/earsifyem qualquer declaração em texto livre. O agente reescreve cada uma no formatoWHEN ... THE system SHALL ...e se recusa a emitir requisitos sem uma condição de disparo. - Vinculação de aceitação. Invoque
/link-acceptancepara anexar critérios Given-When-Then a todo requisito. O agente bloqueia a spec de ir para review até que todo requisito tenha pelo menos um critério. - Sincronização do backlog. Use o GitHub MCP ou o Azure DevOps MCP para criar ou atualizar work items que referenciem âncoras de seções da spec, não resumos em prosa.
Revisão no fim da tarde
- Invoque
/review-specpara rodar a varredura final de governança. O agente verifica testabilidade, contradições, duplicatas e requisitos órfãos. - Abra um pull request no
SPECIFICATION.md. GitHub Copilot Code Review comenta em problemas estruturais; stakeholders humanos aprovam o conteúdo. - Atualize a matriz de rastreabilidade. Um hook de post-merge regenera a matriz a partir das âncoras da spec, IDs de teste e registros de deploy no GitHub Actions.
- Publique o digest diário da spec no canal do Teams via Microsoft 365 Agents SDK, resumindo requisitos aceitos e questões em aberto.
Primitivas recomendadas
Agente
| Agente | Arquivo | Propósito |
|---|---|---|
spec-scribe | .github/agents/spec-scribe.agent.md | Escrever, earsify, revisar e vincular aceitação para o SPECIFICATION.md |
O Spec Scribe usa claude-sonnet-4-6 por padrão. Ferramentas: read, edit, search, grep, glob. Sem acesso a bash, porque a persona Product Owner nunca executa código. Extended thinking é habilitado apenas para /review-spec, onde a detecção de contradições se beneficia de raciocínio profundo.
Slash prompts
| Comando | Arquivo | Propósito |
|---|---|---|
/draft-spec | .github/prompts/draft-spec.prompt.md | Transformar um input cru de stakeholder em um draft numerado de spec |
/earsify | .github/prompts/earsify.prompt.md | Reescrever requisitos em texto livre na sintaxe EARS |
/review-spec | .github/prompts/review-spec.prompt.md | Varredura de governança para testabilidade, contradições, órfãos |
/link-acceptance | .github/prompts/link-acceptance.prompt.md | Anexar critérios Given-When-Then a todo requisito |
Instruções escopadas
applyTo com escopo reduz o custo em tokens em aproximadamente 68 por cento comparado a instruções globais.
Escopo (applyTo) | Arquivo | Propósito |
|---|---|---|
docs/specs/**/*.md | .github/instructions/specs.instructions.md | Formato EARS, numeração, âncoras e verbos vagos banidos |
docs/adr/**/*.md | .github/instructions/adr.instructions.md | Formato do registro de decisão quando uma spec exige uma escolha arquitetural |
docs/releases/**/*.md | .github/instructions/release-notes.instructions.md | Release notes geradas a partir do diff da spec, não do log de commits |
Hooks
Hooks custam zero tokens de LLM. São a camada de governança mais forte para especificações.
pre-commit: rejeitar qualquer arquivo de spec com um requisito sem trigger EARS ou um critério de aceitação órfãopost-commit: regenerar a matriz de rastreabilidade a partir das âncoras da spec e IDs de testepre-merge: bloquear o merge de qualquer mudança de spec que não inclua uma entrada de changelog e um work item vinculado
MCPs validados
| MCP | Propósito | Dono |
|---|---|---|
| GitHub MCP Server | Ler e atualizar GitHub Projects, issues e PRs para governança de backlog | GitHub (oficial) |
| Azure DevOps MCP Server | Ler e atualizar work items do Azure Boards quando o time usa Azure DevOps | Microsoft (oficial) |
| Microsoft Learn Docs MCP | Buscar documentação atualizada de produtos Microsoft ao escrever specs para features M365 ou Azure | Microsoft (oficial) |
| Microsoft 365 Agents SDK MCP | Puxar threads do Teams, decisões do Outlook e artefatos do SharePoint para dentro da coleta da spec | Microsoft (oficial) |
| Azure MCP Server | Consultar Application Insights e Azure Monitor para ancorar specs em comportamento de produção | Microsoft (oficial) |
Exemplos reais
Exemplo 1: escrever uma spec a partir de uma conversa no Teams
Entrada: Uma thread de 45 minutos no Microsoft Teams entre vendas e suporte propondo um fluxo de renovação de contrato self-service.
Invocação: /draft-spec com a thread exportada via o Microsoft 365 Agents SDK MCP.
Saída esperada:
- Um
docs/specs/contract-renewal/SPECIFICATION.mdcom seis requisitos EARS numerados, cada um seguido por critérios de aceitação Given-When-Then. - Uma issue do GitHub por requisito criada através do GitHub MCP, vinculada à âncora da spec.
- Uma seção de perguntas em aberto listando quatro pontos que exigem decisão antes da aprovação.
Exemplo 2: varredura de governança antes do merge
Entrada: Uma spec de 28 requisitos para um upgrade de billing, já earsified em uma passagem anterior.
Invocação: /review-spec.
Saída esperada:
- Um relatório de review sinalizando duas contradições entre os requisitos 7 e 14, uma duplicata entre 19 e 22, e três critérios de aceitação órfãos não anexados a nenhum requisito.
- Um comentário de pull request com sugestões vinculadas por âncoras.
- Um merge bloqueado até que o autor resolva as três categorias.
Anti-padrões
- Escrever specs como prosa. Parágrafos escondem contradições e não podem ser consumidos por agentes. Mitigação: enforçar EARS via o hook de
pre-commite o prompt/earsify. - Pular critérios de aceitação. Um requisito sem Given-When-Then não é testável. Mitigação:
/link-acceptancese recusa a fechar o loop, e o hook bloqueia o commit. - Itens de backlog sem âncoras de spec. Se o ticket não aponta para um requisito numerado, o escopo vai derivar. Mitigação: o GitHub MCP auto-injeta a URL da âncora na criação da issue.
- Release notes geradas a partir de commits. Stakeholders veem ruído técnico. Mitigação: release notes são geradas a partir do diff da spec via as instruções escopadas.
- Verbos ambíguos. Palavras como “suportar”, “tratar”, “melhorar” são banidas pelas instruções da spec. Mitigação: o hook de
pre-commitas rejeita.
KPIs e métricas de impacto
| KPI | Linha base | Meta | Medição |
|---|---|---|---|
| Lead time da spec, coleta até aprovada | 5 dias | < 1 dia | Timestamps de PR do SPECIFICATION.md no GitHub |
| Requisitos em formato EARS | 20 por cento | 100 por cento | Relatório do spec linter no GitHub Actions |
| Cobertura de aceitação, requisitos com Given-When-Then | 40 por cento | 100 por cento | Matriz de rastreabilidade |
| Taxa de mudança de escopo pós-aprovação | 35 por cento | < 10 por cento | Contagem de PRs de spec reabertos |
| Tempo de resposta a uma consulta de auditoria | 2 dias | < 1 hora | Log de consultas da matriz de rastreabilidade |
| Satisfação de stakeholder sobre clareza | Desconhecido | > 4.2 de 5 | Pesquisa trimestral via Microsoft Forms |
Maturidade em quatro níveis
| Nível | Nome | Marcadores |
|---|---|---|
| L1 | Manual | Tickets em prosa, sem EARS, sem aceitação, escopo negociado no review |
| L2 | Assistido | GitHub Copilot usado para polir o texto do ticket, ainda sem spec legível por máquina |
| L3 | Aumentado | Agente Spec Scribe, quatro slash prompts, instruções escopadas, um ou dois MCPs, EARS enforçado |
| L4 | Autônomo | Kit completo de primitivas, hooks enforçados, rastreabilidade auto-gerada, release notes a partir do diff da spec, digest de stakeholder automatizado |
Integração com outras personas
- Para o Requirements Engineer:
SPECIFICATION.mdaprovado com requisitos EARS numerados como input canônico para decomposição detalhada - Para o Business Manager: hooks de KPI em nível de requisito para que outcomes possam ser atados à história de valor
- Para o Enterprise Architect: cláusulas da spec que disparam um novo ADR ou invocam um princípio existente
- Para o Software Architect: superfície de contrato usada para derivar
CODEMAP.mde contratos de API - Para o QA Engineer: aceitação Given-When-Then como fonte direta de casos de teste
- Para o Developer: âncora da spec em todo pull request para implementação rastreável
- Para o Tech Writer: release notes geradas a partir do diff da spec, não do diff do commit
Glossário
- EARS: Easy Approach to Requirements Syntax. A forma canônica
WHEN ... THE system SHALL ...usada noSPECIFICATION.md. - Given-When-Then: formato de critério de aceitação que vincula uma pré-condição, uma ação e um outcome observável.
- Âncora da spec: âncora markdown estável sobre um ID de requisito, usada como alvo canônico de link a partir de issues, PRs e testes.
- Matriz de rastreabilidade: tabela gerada que mapeia cada requisito para seus testes, pull requests e artefatos implantados.
- Hipótese de outcome: o resultado de negócio mensurável que a feature deve produzir, distinto da lista de outputs.
- Backlog: a lista ordenada de work items no GitHub Projects ou Azure Boards, cada um vinculado a uma âncora da spec.
Referências
- Documentação do GitHub Projects — planejamento e acompanhamento de specs e backlog
- Documentação do Azure Boards — rastreio de work items quando o time usa Azure DevOps
- Documentação do GitHub Copilot — fonte autoritativa para features do Copilot, modo agent e instruções
- Visão geral do Microsoft 365 Agents SDK — integração com Teams e superfícies do Microsoft 365
- Referência de notação EARS, Microsoft Learn — orientação sobre qualidade de requisito e alinhamento arquitetural
El Product Owner es la persona que escribe, gobierna y cierra el ciclo de la especificación. En un SDLC AI-native, el Product Owner opera un stack de primitivas validadas que convierten la intención en un contrato legible por máquinas.
Resumen ejecutivo
El Product Owner convierte la intención de negocio ambigua en una especificación aprobada y verificable que el resto del SDLC puede ejecutar sin pérdidas en la traducción. En un SDLC AI-native, el Product Owner opera dentro de la fase de Planning con un conjunto fijo de primitivas: un agente de especificación, cuatro slash prompts, instrucciones con alcance, hooks validados por esquema y una lista curada de MCPs validados. Las salidas principales son documentos SPECIFICATION.md en forma EARS, criterios de aceptación en Given-When-Then, enlaces de trazabilidad desde el requisito hasta la prueba y registros de decisión para cada cambio de alcance.
Rol y responsabilidades
Piensa en el Product Owner como un ingeniero civil que redacta la especificación de un puente. Los constructores, inspectores y reguladores leen el mismo documento y derivan su trabajo a partir de él. El Product Owner no vierte concreto, pero es responsable de que cada vertido, soldadura y cable coincida con una cláusula numerada que alguien pueda verificar bajo carga. En un SDLC AI-native, la especificación es el contrato entre humanos y agentes, y el Product Owner es su editor jefe.
Responsabilidades principales:
- Redactar y mantener
SPECIFICATION.mdpara cada feature, usando requisitos EARS y criterios de aceptación en Given-When-Then - Gobernar el backlog en GitHub Projects o Azure Boards, asegurando que cada ítem enlace a una sección del spec
- Definir y proteger la hipótesis de resultado del producto, no la lista de salidas
- Resolver conflictos de alcance entre stakeholders antes de que lleguen al Developer
- Operar el agente Spec Scribe y los prompts
/draft-spec,/earsify,/review-spec,/link-acceptance - Cerrar el ciclo confirmando la aceptación en los pull requests fusionados en GitHub
- Mantener la matriz de trazabilidad desde el requisito hasta la prueba y el artefacto desplegado
- Publicar las release notes a partir del diff del spec, no del diff del código
Jobs to be done
- Como Product Owner, quiero convertir una conversación con stakeholders en un borrador de spec en menos de una hora, para que el equipo nunca espere por mí para iniciar el discovery.
- Como Product Owner, quiero cada requisito en forma EARS, para que los agentes puedan parsearlo sin interpretación.
- Como Product Owner, quiero cada criterio de aceptación en Given-When-Then, para que el QA Engineer pueda generar pruebas directamente desde el spec.
- Como Product Owner, quiero un enlace de trazabilidad en vivo desde cada requisito hasta su prueba y su artefacto desplegado, para que pueda responder preguntas de auditoría en minutos.
- Como Product Owner, quiero que el spec rechace el merge cuando falte la aceptación, para que la deriva de alcance se detecte antes de escribir código.
- Como Product Owner, quiero que las release notes se generen a partir del diff del spec, para que los stakeholders vean el valor entregado, no los commits enviados.
Puntos de dolor antes de la era AI-native
- Tickets ambiguos. Las descripciones libres en un tracker obligan a cada lector a adivinar la intención. Los developers implementan la interpretación más fácil; QA prueba la más defensiva.
- Handoffs verbales. El alcance vive en la memoria de la reunión. Cuando termina la reunión, el alcance se bifurca silenciosamente.
- Criterios de aceptación inventados al momento del review. Los reviewers negocian la definición de done después de escrito el código, así que el rework es inevitable.
- Trazabilidad construida a mano en hojas de cálculo. La matriz queda obsoleta el día que se publica, y los auditores lo saben.
- Release notes escritas por el release manager a partir de los logs de commit. Los stakeholders ven ruido técnico, no resultados de producto, y la confianza se erosiona.
Flujo diario AI-native
El Product Owner opera un loop fijo cada día. El loop usa primitivas de GitHub Copilot dentro de Visual Studio Code y Claude Code en la terminal, además de un pequeño catálogo de MCPs validados para contexto externo.
Setup de la mañana
- Abrir el repositorio en Visual Studio Code. GitHub Copilot Chat carga
AGENTS.mdy las instrucciones de spec con alcance. - Hacer pull del último
mainy abrir el branch activo de la feature para el spec en curso. - Revisar los aportes nocturnos de stakeholders capturados en hilos de Microsoft Teams y Outlook a través del MCP del Microsoft 365 Agents SDK.
- Ejecutar
/review-specsobre el borrador del día anterior para detectar violaciones a EARS y aceptaciones faltantes.
Ejecución al mediodía
- Toma de aportes de stakeholders. Invocar
/draft-speccon la transcripción de la reunión o el hilo de Teams. El agente Spec Scribe produce un primer borrador con requisitos numerados y preguntas abiertas marcadas. - Conversión a EARS. Invocar
/earsifysobre cualquier enunciado en forma libre. El agente reescribe cada uno en la formaWHEN ... THE system SHALL ...y se niega a emitir requisitos sin una condición disparadora. - Vinculación de aceptación. Invocar
/link-acceptancepara adjuntar criterios Given-When-Then a cada requisito. El agente bloquea el spec para que no avance al review hasta que cada requisito tenga al menos un criterio. - Sincronización del backlog. Usar el MCP de GitHub o el MCP de Azure DevOps para crear o actualizar work items que referencien anclas de sección del spec, no resúmenes en prosa.
Revisión al final de la tarde
- Invocar
/review-specpara correr la barrida final de gobierno. El agente verifica testabilidad, contradicciones, duplicados y requisitos huérfanos. - Abrir un pull request sobre
SPECIFICATION.md. GitHub Copilot Code Review comenta sobre problemas estructurales; los stakeholders humanos aprueban el contenido. - Actualizar la matriz de trazabilidad. Un hook post-merge regenera la matriz a partir de las anclas del spec, los IDs de prueba y los registros de despliegue en GitHub Actions.
- Publicar el digest diario del spec al canal de Teams a través del Microsoft 365 Agents SDK, resumiendo los requisitos aceptados y las preguntas abiertas.
Primitivas recomendadas
Agente
| Agente | Archivo | Propósito |
|---|---|---|
spec-scribe | .github/agents/spec-scribe.agent.md | Redactar, earsificar, revisar y enlazar la aceptación para SPECIFICATION.md |
El Spec Scribe usa claude-sonnet-4-6 por defecto. Herramientas: read, edit, search, grep, glob. Sin acceso a bash, porque la persona Product Owner nunca ejecuta código. El extended thinking se habilita solo para /review-spec, donde la detección de contradicciones se beneficia de un razonamiento profundo.
Slash prompts
| Comando | Archivo | Propósito |
|---|---|---|
/draft-spec | .github/prompts/draft-spec.prompt.md | Convertir una entrada cruda de stakeholders en un borrador numerado de spec |
/earsify | .github/prompts/earsify.prompt.md | Reescribir requisitos en forma libre a sintaxis EARS |
/review-spec | .github/prompts/review-spec.prompt.md | Barrida de gobierno por testabilidad, contradicciones y huérfanos |
/link-acceptance | .github/prompts/link-acceptance.prompt.md | Adjuntar criterios Given-When-Then a cada requisito |
Instrucciones con alcance
El applyTo con alcance reduce el costo en tokens en aproximadamente 68 por ciento comparado con instrucciones globales.
Alcance (applyTo) | Archivo | Propósito |
|---|---|---|
docs/specs/**/*.md | .github/instructions/specs.instructions.md | Formato EARS, numeración, anclas y verbos vagos prohibidos |
docs/adr/**/*.md | .github/instructions/adr.instructions.md | Formato del registro de decisión cuando un spec requiere una elección arquitectónica |
docs/releases/**/*.md | .github/instructions/release-notes.instructions.md | Release notes generadas a partir del diff del spec, no del log de commits |
Hooks
Los hooks cuestan cero tokens de LLM. Son la capa de gobierno más fuerte para las especificaciones.
pre-commit: rechazar cualquier archivo de spec con un requisito que carezca de un disparador EARS o un criterio de aceptación huérfanopost-commit: regenerar la matriz de trazabilidad a partir de las anclas del spec y los IDs de pruebapre-merge: bloquear el merge de cualquier cambio de spec que no incluya una entrada en el changelog y un work item enlazado
MCPs validados
| MCP | Propósito | Dueño |
|---|---|---|
| GitHub MCP Server | Leer y actualizar GitHub Projects, issues y PRs para el gobierno del backlog | GitHub (oficial) |
| Azure DevOps MCP Server | Leer y actualizar work items de Azure Boards cuando el equipo usa Azure DevOps | Microsoft (oficial) |
| Microsoft Learn Docs MCP | Obtener documentación vigente de productos Microsoft al escribir specs para features de M365 o Azure | Microsoft (oficial) |
| Microsoft 365 Agents SDK MCP | Traer hilos de Teams, decisiones de Outlook y artefactos de SharePoint a la toma de aportes del spec | Microsoft (oficial) |
| Azure MCP Server | Consultar Application Insights y Azure Monitor para anclar specs en el comportamiento de producción | Microsoft (oficial) |
Ejemplos reales
Ejemplo 1: redactar un spec a partir de una conversación de Teams
Entrada: Un hilo de Microsoft Teams de 45 minutos entre ventas y soporte que propone un flujo de renovación de contrato self-service.
Invocación: /draft-spec con el hilo exportado vía el MCP del Microsoft 365 Agents SDK.
Salida esperada:
- Un
docs/specs/contract-renewal/SPECIFICATION.mdcon seis requisitos EARS numerados, cada uno seguido por criterios de aceptación Given-When-Then. - Un GitHub issue por requisito creado a través del MCP de GitHub, enlazado al ancla del spec.
- Una sección de preguntas abiertas que enumera cuatro puntos que requieren una decisión antes de la aprobación.
Ejemplo 2: barrida de gobierno antes del merge
Entrada: Un spec de 28 requisitos para un upgrade de billing, ya earsificado en una pasada anterior.
Invocación: /review-spec.
Salida esperada:
- Un reporte de revisión que marca dos contradicciones entre los requisitos 7 y 14, un duplicado entre 19 y 22, y tres criterios de aceptación huérfanos no adjuntos a ningún requisito.
- Un comentario en el pull request con sugerencias enlazadas a anclas.
- Un merge bloqueado hasta que el autor resuelva las tres categorías.
Anti-patrones
- Escribir specs como prosa. Los párrafos esconden contradicciones y no pueden ser consumidos por agentes. Mitigación: forzar EARS vía el hook
pre-commity el prompt/earsify. - Saltarse los criterios de aceptación. Un requisito sin Given-When-Then no es testable. Mitigación:
/link-acceptancese niega a cerrar el ciclo y el hook bloquea el commit. - Ítems del backlog sin anclas al spec. Si el ticket no enlaza a un requisito numerado, el alcance va a derivar. Mitigación: el MCP de GitHub auto-inyecta la URL del ancla al crear el issue.
- Release notes generadas desde commits. Los stakeholders ven ruido técnico. Mitigación: las release notes se generan a partir del diff del spec mediante las instrucciones con alcance.
- Verbos ambiguos. Palabras como “soportar”, “manejar”, “mejorar” están prohibidas por las instrucciones del spec. Mitigación: el hook
pre-commitlas rechaza.
KPIs y métricas de impacto
| KPI | Línea base | Meta | Medición |
|---|---|---|---|
| Lead time del spec, de toma a aprobado | 5 días | < 1 día | Timestamps del PR de SPECIFICATION.md en GitHub |
| Requisitos en forma EARS | 20 por ciento | 100 por ciento | Reporte del linter de spec en GitHub Actions |
| Cobertura de aceptación, requisitos con Given-When-Then | 40 por ciento | 100 por ciento | Matriz de trazabilidad |
| Tasa de cambios de alcance post-aprobación | 35 por ciento | < 10 por ciento | Conteo de PRs de spec reabiertos |
| Tiempo para responder una consulta de auditoría | 2 días | < 1 hora | Log de consultas a la matriz de trazabilidad |
| Satisfacción de stakeholders con la claridad | Desconocida | > 4.2 de 5 | Encuesta trimestral vía Microsoft Forms |
Madurez en cuatro niveles
| Nivel | Nombre | Marcadores |
|---|---|---|
| L1 | Manual | Tickets en prosa, sin EARS, sin aceptación, alcance negociado en review |
| L2 | Asistido | GitHub Copilot usado para pulir el texto del ticket, sin spec legible por máquina |
| L3 | Aumentado | Agente Spec Scribe, cuatro slash prompts, instrucciones con alcance, uno o dos MCPs, EARS forzado |
| L4 | Autónomo | Kit completo de primitivas, hooks forzados, trazabilidad auto-generada, release notes desde el diff del spec, digest a stakeholders automatizado |
Integración con otras personas
- Hacia Requirements Engineer:
SPECIFICATION.mdaprobado con requisitos EARS numerados como entrada canónica para la descomposición detallada - Hacia Business Manager: hooks de KPI a nivel de requisito para que los resultados puedan amarrarse a la historia de valor
- Hacia Enterprise Architect: cláusulas del spec que disparan un nuevo ADR o invocan un principio existente
- Hacia Software Architect: superficie de contrato usada para derivar
CODEMAP.mdy los contratos de API - Hacia QA Engineer: aceptación Given-When-Then como fuente directa de los casos de prueba
- Hacia Developer: ancla del spec en cada pull request para implementación trazable
- Hacia Tech Writer: release notes generadas a partir del diff del spec, no del diff de commits
Glosario
- EARS: Easy Approach to Requirements Syntax. La forma canónica
WHEN ... THE system SHALL ...usada enSPECIFICATION.md. - Given-When-Then: formato de criterio de aceptación que une una precondición, una acción y un resultado observable.
- Ancla del spec: ancla markdown estable sobre el ID de un requisito, usada como objetivo canónico de enlace desde issues, PRs y pruebas.
- Matriz de trazabilidad: tabla generada que mapea cada requisito a sus pruebas, pull requests y artefactos desplegados.
- Hipótesis de resultado: el resultado de negocio medible que la feature se supone debe producir, distinto de la lista de salidas.
- Backlog: la lista ordenada de work items en GitHub Projects o Azure Boards, cada uno enlazado a un ancla del spec.
Referencias
- GitHub Projects documentation — planificación y seguimiento de specs y backlog
- Azure Boards documentation — seguimiento de work items cuando el equipo usa Azure DevOps
- GitHub Copilot documentation — fuente autoritativa para features de Copilot, agent mode e instructions
- Microsoft 365 Agents SDK overview — integración de Teams y superficies de Microsoft 365
- EARS notation reference, Microsoft Learn — guía sobre calidad de requisitos y alineación arquitectónica