The 12 boundary questions.
Motivation
- Who is (ought to be) the intended beneficiary of the system? Clarifies whose needs and interests are prioritised.
- What is (ought to be) the purpose of the system? Makes explicit the claimed purpose versus hidden agendas.
- What is (ought to be) the measure of improvement or success? Surfaces which metrics matter, and whether they serve all stakeholders.
Control
- Who is (ought to be) the decision-maker? Identifies who holds authority and whether this is legitimate.
- What resources are (ought to be) controlled by the decision-maker? Shows which resources or levers are available and who commands them.
- What conditions are (ought to be) outside the decision-maker’s control? Acknowledges external constraints and limits of influence.
Knowledge
- Who is (ought to be) considered an expert? Highlights which voices are valued for expertise.
- What expertise is (ought to be) consulted, and why? Surfaces bias in which knowledge is prioritised.
- What or who is (ought to be) assumed as the source of knowledge? Exposes reliance on particular data, models, or narratives.
Legitimacy
- Who is (ought to be) affected but not involved? Brings forward marginalised or excluded stakeholders.
- Who is (ought to be) the guarantor of those affected? Identifies who speaks or advocates for the excluded.
- What worldview is (ought to be) assumed and legitimised? Surfaces underlying cultural, political, or ethical assumptions shaping the system.
As 12 perguntas de delimitação
Motivação
- Quem é (ou deveria ser) o beneficiário principal do sistema? Esclarece cujas necessidades e interesses são priorizados.
- Qual é (ou deveria ser) o propósito do sistema? Torna explícita a diferença entre o propósito declarado e as agendas ocultas.
- Qual é (ou deveria ser) a medida de melhoria ou sucesso? Revela quais métricas importam e se elas atendem a todos os stakeholders.
Controle
- Quem é (ou deveria ser) o tomador de decisão? Identifica quem detém a autoridade e se ela é legítima.
- Quais recursos são (ou deveriam ser) controlados pelo tomador de decisão? Mostra quais recursos ou alavancas estão disponíveis e quem os comanda.
- Quais condições estão (ou deveriam estar) fora do controle do tomador de decisão? Reconhece restrições externas e os limites de influência.
Conhecimento
- Quem é (ou deveria ser) considerado especialista? Destaca quais vozes são valorizadas como portadoras de expertise.
- Que tipo de expertise é (ou deveria ser) consultada, e por quê? Revela vieses em relação a quais conhecimentos são priorizados.
- O que ou quem é (ou deveria ser) assumido como fonte de conhecimento? Expõe a dependência de determinados dados, modelos ou narrativas.
Legitimidade
- Quem é (ou deveria ser) afetado, mas não está envolvido? Traz à tona stakeholders marginalizados ou excluídos.
- Quem é (ou deveria ser) o garantidor daqueles que são afetados? Identifica quem fala ou defende os excluídos.
- Qual visão de mundo é (ou deveria ser) assumida e legitimada? Revela suposições culturais, políticas ou éticas que moldam o sistema.
CSH strengthens these PRD sections:
- Problem statement: Who defines the problem and whose needs are being prioritized?
- Goals & success metrics: Are KPIs serving all users or mainly business stakeholders?
- Assumptions: Which worldviews or power structures are shaping the definition of “success”?
- Non-goals & risks: What is being excluded, and who might be affected by those exclusions?
This turns the PRD into a living document of product ethics and power awareness, not just execution specs.
Boundary Lens | Reflection |
Beneficiaries | Are we optimizing for power users or the average user? What trade-offs exist? |
Control | Who holds decision power in roadmap shifts? What’s outside our control? |
Knowledge | What types of data are shaping decisions (quantitative vs qualitative)? |
Legitimacy | Who is affected but not represented in our user research or success metrics? |
Strategic impact
- Makes assumptions explicit, reducing blind spots and ethical debt.
- Improves alignment between leadership, delivery teams, and marginalized users.
- Builds legitimacy: decisions are documented transparently, not just justified post hoc.
- Reinforces accountability: metrics and success criteria reflect who truly benefits.
When to use CSH in the PM process
Stage | How to apply CSH |
Discovery | Use the 12 questions to surface hidden assumptions in user research and business framing. |
Problem definition | Clarify whose problem is being solved and who is left out. |
PRD drafting | Embed a short “Boundary Reflection” section that summarizes insights from CSH. |
Stakeholder review | Use CSH prompts to challenge bias in prioritization and metric definition. |
Post-launch retros | Revisit boundaries: did the product deliver fairness, or reinforce exclusion? |
Aqui estão os principais aprendizados sobre Critical Systems Heuristics (CSH) aplicados à gestão de produto, segundo o artigo do Product Breaks:
- O que é CSH: Criada por Werner Ulrich, a abordagem serve para expor pressupostos ocultos em decisões de produto, revelando dinâmicas de poder, valores e limites que geralmente passam despercebidos. É útil especialmente em ambientes com múltiplos stakeholders afetados.
- Como aplicar: O método utiliza 12 perguntas de delimitação, agrupadas nas categorias Motivação, Controle, Conhecimento e Legitimidade. Elas ajudam a identificar:
- Quem se beneficia
- Quem decide e controla recursos
- Cujo conhecimento conta
- Quem é excluído do processo
- Usos práticos em Product Management: Você pode usar CSH em atividades como discovery, refinamento de backlog, planejamento de roadmap e retrospectivas para revisar quem está (e quem está ausente) nas decisões do produto.
- Processo sugerido:
- Defina o contexto do produto e a decisão a ser tomada
- Envolva diferentes partes interessadas (inclusive grupos marginalizados)
- Realize workshops focados nas 12 perguntas estruturadas
- Identifique pressupostos e tensões entre respostas dos envolvidos
- Analise implicações éticas, sociais e sistêmicas dos limites atuais
- Reframed, ajuste decisões para maior inclusão e transparência
- Principais tensões e riscos diagnosticados:
- Eficiência versus equidade – focar apenas em automação pode excluir os mais vulneráveis.
- Hierarquia de conhecimento – dados quantitativos são priorizados, enquanto experiências de usuários ficam de fora.
- Falta de representatividade – grupos afetados são reconhecidos, mas raramente envolvidos na concepção.
- Divergência de propósito – líderes focam em economia, equipes em bem-estar do usuário.
- Insights centrais:
- Pressupostos não desafiados podem transformar produtos em barreiras digitais.
- Inclusão deve ser projetada deliberadamente — não ocorre automaticamente em transformações digitais.
- CSH permite balancear eficiência com justiça social, elevando legitimidade e reputação do produto final.
- Tecnologia nunca é neutra, os limites definidos determinam quem se beneficia e quem é prejudicado.
Esses pontos ajudam product managers a garantir decisões mais transparentes, inclusivas e legítimas em ambientes complexos e carregados de tensões de poder.