Guia • Scrum.org • PPDV

Dominando a Certificação Professional Product Discovery and Validation (PPDV)

Um guia completo em 7 partes para dominar Product Discovery, hipóteses, experimentos, validação, entendimento de usuários, colaboração com stakeholders, formulação de problemas e estratégia de prova para a certificação PPDV da Scrum.org.

Por Alexandre Vignado · Atualizado em 25 de julho de 2025 · Leitura: 45 min

Introdução

Desenvolver um produto vai muito além de escrever histórias de usuário e entregar funcionalidades: Product Discovery é o que separa produtos relevantes de soluções que só parecem uma boa ideia no papel.

A certificação Professional Product Discovery and Validation (PPDV), da Scrum.org, valida a capacidade de descobrir o que realmente gera valor, formular hipóteses, testar com inteligência e tomar decisões baseadas em evidências.

Visão geral da PPDV

O exame PPDV avalia três grandes dimensões: alinhar visão e estratégia de produto (Engage with Vision), conectar mercado e negócio à estratégia de produto (Lead to Value) e evoluir continuamente com validação e experimentos (Evolve with Validation).

  • Formato: 20 questões de múltipla escolha, em inglês.
  • Duração: 30 minutos, com nota mínima de 85%.
  • Custo: US$ 200 por tentativa, certificação vitalícia.

Parte 1 – Fundamentos do Product Discovery

O que é Product Discovery?

Product Discovery é o processo de entender o que realmente vale a pena ser desenvolvido, investigando o problema real, para quem ele importa e qual impacto se espera gerar.

Isso significa sair da mentalidade de “construir o que pedem” e entrar em “descobrir o que gera valor”, usando dados qualitativos e quantitativos, além de colaboração com stakeholders.

Por que Product Discovery importa?

  • Reduz desperdícios ao evitar funcionalidades que ninguém usa.
  • Aumenta o alinhamento com necessidades reais dos usuários.
  • Diminui riscos e melhora a tomada de decisão.
  • Gera aprendizado validado antes de grandes investimentos.

Discovery vs Delivery

  • Discovery: entender problemas, formular hipóteses, conduzir experimentos, aprender em ambientes de alta incerteza.
  • Delivery: construir soluções validadas, focar em execução, código, deploy e documentação em contexto mais previsível.

Ciclo de aprendizado contínuo

O ciclo Build–Measure–Learn, com ênfase em aprender antes de construir, estrutura o discovery como um processo iterativo e incremental, em que o produto evolui conforme o time aprende com usuários e mercado.

Parte 2 – Hipóteses, Experimentos e Priorização

Hipóteses de produto

Uma hipótese de produto é uma suposição estruturada sobre algo que pode ser valioso, funcional ou desejado para o usuário ou para o negócio.

Hipóteses bem formuladas incluem: uma suposição clara, o grupo de usuários alvo, o impacto esperado e critérios de sucesso mensuráveis.

O papel dos experimentos

Experimentos testam hipóteses com o menor custo possível antes de desenvolver a solução completa.

  • Devem ser rápidos, baratos e focados em algo observável.
  • Devem ter critérios claros de sucesso e fracasso.
  • Geram aprendizado relevante mesmo quando invalidam a hipótese.

Priorização de hipóteses (valor x risco)

  • Alta oportunidade / alto risco → experimentar.
  • Alta oportunidade / baixo risco → construir e medir.
  • Baixa oportunidade / alto risco → ignorar.
  • Baixa oportunidade / baixo risco → deixar para depois.

Truth Curve

A Truth Curve mostra quanta confiança podemos ter em cada tipo de evidência, desde suposições internas até dados de uso real, orientando quanto investir em validação antes de decidir.

Parte 3 – Validação e Testes no Processo de Descoberta

O que é validação?

Validação é o processo de confirmar ou refutar hipóteses com base em evidências reais, substituindo achismos por decisões informadas.

Validação qualitativa x quantitativa

  • Qualitativa: entrevistas, testes de usabilidade, observações – trazem profundidade e contexto.
  • Quantitativa: analytics, métricas de uso, testes A/B – trazem escala e confiança estatística.

Combinar ambas aumenta a qualidade das decisões de produto.

Técnicas comuns de experimentação

  • Entrevistas com usuários.
  • Testes de usabilidade com protótipos.
  • Landing pages e fake door tests.
  • Testes A/B.
  • MVPs parciais, concierge e Wizard of Oz.

Quando a validação é suficiente?

Considera-se validação suficiente quando o aprendizado é confiável, replicável, consistente com dados anteriores e o risco residual é aceitável para seguir em frente.

Validação x julgamento

Dados não devem ser usados para punir o time, e sim para decidir onde investir, pivotar ou descartar iniciativas com responsabilidade.

Parte 4 – Entendimento Profundo dos Usuários

Por que conhecer o usuário?

Entregar valor real exige entender profundamente para quem o produto é feito, quais problemas enfrenta, o que o frustra e o que o motiva.

Muitos produtos falham por resolver o problema errado, para a pessoa errada, da forma errada.

Ferramentas e práticas

  • Proto-personas: suposições estruturadas sobre perfis de usuários, a serem refinadas com dados reais.
  • Entrevistas: exploram dores, contexto, motivações e expectativas.
  • Jornada do usuário: mapeia passos, fricções e emoções ao longo da experiência.
  • Mapa de empatia: ajuda a entender o que o usuário vê, sente, pensa, fala e faz.

Alinhamento interno

Descobrir quem é o usuário é uma atividade coletiva; revisitar dados de uso, entrevistas e mapas visuais ajuda a criar entendimento compartilhado entre times e stakeholders.

Parte 5 – Colaboração, Stakeholders e Decisões Informadas

Discovery como esporte coletivo

Product Discovery exige a participação ativa de desenvolvimento, negócio, marketing, vendas, suporte, especialistas de domínio e usuários finais.

Mais perspectivas ampliam a capacidade de enxergar riscos e oportunidades, desde que decisões sejam guiadas por evidências.

Papel dos stakeholders

Stakeholders trazem contexto, expectativas e histórico, mas não devem ditar escopo sem validação; o PO facilita decisões baseadas em dados, não em hierarquia.

Decisão baseada em evidências

  • Métricas de comportamento e resultados de experimentos são as fontes mais confiáveis.
  • Opiniões e discussões internas são insumos, não decisões finais.

Ferramentas colaborativas

  • Workshops de visão e proto-personas.
  • Canvas colaborativos de hipóteses e priorização.
  • Painéis de aprendizado e dashboards.
  • Sprint Reviews focados em aprendizado.

Armadilhas comuns

Funcionalidades impostas sem evidência, decisões políticas e falta de transparência no aprendizado são sinais de alerta; a resposta saudável combina empatia, facilitação e foco em dados.

Parte 6 – Identificação e Formulação de Problemas

Comece pelo problema

A pergunta central do discovery é: “estamos resolvendo o problema certo?”. Começar pela solução sem entender o problema leva a desperdício.

O que é um bom problema?

  • É centrado em quem sente a dor.
  • Não embute a solução no enunciado.
  • Tem impacto observável em usuário ou negócio.
  • Conecta-se a objetivos estratégicos.

Business Problem Statement

Ferramenta para alinhar por que uma iniciativa existe, explicando o problema de negócio, stakeholders envolvidos, impactos negativos atuais e impacto desejado após a solução.

Técnicas para encontrar o problema certo

  • Entrevistas abertas explorando dores reais.
  • Análise de métricas comportamentais.
  • Observação contextual.
  • Mapas de causa e efeito (ex.: 5 Porquês, Ishikawa).

Problema x solução

Pedidos como “precisamos de um app” ou “queremos um chatbot” são soluções supostas; o trabalho do time é descobrir qual problema real está por trás dessas demandas.

Parte 7 – Estratégia de Prova, Aprovação e Certificação

O que a PPDV mede

A PPDV valida domínio em descoberta orientada a valor, hipóteses, experimentos, validação qualitativa e quantitativa, alinhamento com negócio e usuários, colaboração e decisões baseadas em evidências.

Tipos de questões

As questões combinam teoria e prática, pedindo para interpretar cenários com múltiplas variáveis (time, stakeholders, dados, risco) e escolher a melhor próxima ação.

Estratégias de estudo

  • Praticar com questões e simulados focados em cenários.
  • Buscar entender conceitos em vez de decorar respostas.
  • Conectar o conteúdo à realidade do seu trabalho.
  • Revisar erros para reforçar pontos fracos.

Checklist final

  • Diferenciar claramente problema de solução e de pedido de stakeholder.
  • Saber quando experimentar, medir, construir ou dizer “ainda não”.
  • Sentir-se confortável para lidar com pressão usando dados e colaboração.

Introduction

Building a product is much more than writing user stories and shipping features: Product Discovery is what separates truly valuable products from ideas that only look good on paper.

The Professional Product Discovery and Validation (PPDV) certification from Scrum.org validates your ability to discover what really creates value, formulate hypotheses, run smart experiments, and make evidence-based decisions.

PPDV overview

The PPDV assessment focuses on three major dimensions: aligning product vision and strategy (Engage with Vision), connecting market and business insights to product strategy (Lead to Value), and evolving continuously through validation and experiments (Evolve with Validation).

  • Format: 20 multiple-choice questions, in English.
  • Duration: 30 minutes, passing score 85%.
  • Cost: US$ 200 per attempt, lifetime certification.

Part 1 – Fundamentals of Product Discovery

What is Product Discovery?

Product Discovery is the process of understanding what is truly worth building, by investigating the real problem, who it matters to, and which impact is expected.

It means moving from “building what was requested” to “discovering what creates value”, using qualitative and quantitative data plus stakeholder collaboration.

Why Product Discovery matters

  • Reduces waste by avoiding features no one uses.
  • Improves alignment with real user needs.
  • Reduces risk and improves decision-making.
  • Generates validated learning before large investments.

Discovery vs Delivery

  • Discovery: understanding problems, forming hypotheses, running experiments, learning in high-uncertainty environments.
  • Delivery: building validated solutions, focusing on execution, code, deployment, and documentation in a more predictable context.

Continuous learning cycle

The Build–Measure–Learn loop, with emphasis on learning before building, structures discovery as an iterative, incremental process where the product evolves as the team learns from users and the market.

Part 2 – Hypotheses, Experiments and Prioritization

Product hypotheses

A product hypothesis is a structured assumption about something that may be valuable, functional, or desirable for users or the business.

Well-formed hypotheses include a clear assumption, target audience, expected impact, and measurable success criteria.

The role of experiments

Experiments test hypotheses with minimum cost before investing in full delivery.

  • They should be fast, inexpensive, and observable.
  • They require explicit success and failure thresholds.
  • They generate useful learning even when they invalidate the hypothesis.

Prioritizing hypotheses (value vs risk)

  • High opportunity / high risk → experiment.
  • High opportunity / low risk → build and measure.
  • Low opportunity / high risk → ignore.
  • Low opportunity / low risk → defer.

Truth Curve

The Truth Curve indicates how much trust you can place in different evidence types, from internal assumptions to real usage data, guiding how much validation is needed before committing.

Part 3 – Validation and Testing in Discovery

What is validation?

Validation is the process of confirming or refuting hypotheses using real evidence, replacing guesswork with informed decisions.

Qualitative vs quantitative validation

  • Qualitative: interviews, usability tests, observation – provides depth and context.
  • Quantitative: analytics, usage metrics, A/B tests – provides scale and statistical confidence.

Combining both leads to stronger product decisions.

Common experimentation techniques

  • User interviews.
  • Usability testing with prototypes.
  • Landing pages and fake door tests.
  • A/B tests.
  • Partial MVPs, concierge and Wizard of Oz approaches.

When is validation “enough”?

Validation is sufficient when learning is reliable, repeatable, consistent with previous data, and the remaining risk is acceptable to move forward.

Validation vs judgment

Data should not be used to judge team performance, but to decide where to invest, pivot, or stop initiatives with responsibility.

Part 4 – Deep Understanding of Users

Why know your users?

Delivering real value requires deeply understanding who the product is for, what problems they face, what frustrates them, and what motivates them.

Many products fail not due to technical issues, but because they solve the wrong problem for the wrong person.

Tools and practices

  • Proto-personas: assumption-based user profiles to be refined with real data.
  • Interviews: explore pains, context, motivations, and expectations.
  • User journeys: map steps, frictions, and emotions across the experience.
  • Empathy maps: help understand what users see, feel, think, say, and do.

Internal alignment

Discovering “who the user is” is a collective activity; revisiting usage data, interviews, and visual artifacts helps teams and stakeholders reach shared understanding.

Part 5 – Collaboration, Stakeholders and Informed Decisions

Discovery as a team sport

Product Discovery involves development, business, marketing, sales, support, domain experts, and end users working together.

Multiple perspectives increase the ability to see risks and opportunities, as long as decisions are evidence-based.

Stakeholder role

Stakeholders provide context, expectations, and organizational history, but should not dictate scope without validation; the Product Owner facilitates data-driven decisions instead of political ones.

Evidence-based decision-making

  • Behavioral metrics and experiment results are the most reliable sources.
  • Opinions and internal debates are inputs, not final answers.

Collaborative tools

  • Vision and proto-persona workshops.
  • Collaborative hypothesis and prioritization canvases.
  • Learning boards and dashboards.
  • Sprint Reviews focused on learning, not only delivery.

Common pitfalls

Features imposed without evidence, political decisions, and lack of transparency about learning are red flags; healthy responses combine empathy, facilitation, and data focus.

Part 6 – Identifying and Formulating Problems

Start with the problem

The key discovery question is: “are we solving the right problem?”. Jumping to solutions without understanding the problem leads to waste.

What is a good problem?

  • Centered on who feels the pain.
  • Described without embedding the solution.
  • Has observable impact on users or business.
  • Connected to broader strategic goals.

Business Problem Statement

A Business Problem Statement aligns the organization on why an initiative exists, describing the business problem, involved stakeholders, current negative impacts, and desired outcomes.

Techniques to uncover the right problem

  • Open-ended interviews about real pains.
  • Analysis of behavioral metrics.
  • Contextual observation.
  • Cause-and-effect tools like 5 Whys and Ishikawa diagrams.

Problem vs solution

Requests like “we need an app” or “we want a chatbot” are assumed solutions; the team’s role is to uncover the underlying user or business problem behind these demands.

Part 7 – Exam Strategy, Passing and Certification

What PPDV really measures

PPDV validates mastery in value-oriented discovery, hypotheses, experiments, qualitative and quantitative validation, strategic alignment, collaboration, and evidence-based decisions.

Question style

Questions mix concepts and practice, asking you to interpret scenarios with multiple variables (team, stakeholders, data, risk) and pick the best next action.

Study strategies

  • Practice with scenario-style questions and mock assessments.
  • Focus on understanding principles instead of memorizing answers.
  • Relate concepts to your real work context.
  • Review mistakes to strengthen weaker areas.

Final checklist

  • Clearly distinguish problem from solution and stakeholder request.
  • Know when to experiment, measure, build, or say “not yet”.
  • Feel comfortable handling stakeholder pressure using data and collaboration.

PPDV • Prep

Perguntas de Preparação para o Exame PPDV

Coleção de questões em inglês, organizadas pelas 7 partes do guia PPDV, com a alternativa correta destacada em verde.

Parte 1 – Fundamentos do Product Discovery

Quiz de Revisão – Parte 1

  1. What is the main goal of Product Discovery?

    • A) To gather business requirements for documentation
    • B) To design the UI/UX before the product is built
    • C) To understand what is valuable to build before investing in development
    • D) To ensure developers know what features to code

  2. Which of the following best describes the difference between Discovery and Delivery?

    • A) Discovery is for prototypes, delivery is for MVPs
    • B) Discovery focuses on learning and value; delivery focuses on building and releasing
    • C) Discovery is led by business, delivery by developers
    • D) They are interchangeable phases

  3. Why is learning early during discovery so important?

    • A) It guarantees stakeholder approval
    • B) It reduces the risk of building the wrong product
    • C) It helps speed up project documentation
    • D) It avoids the need for further releases

  4. Which activity is MOST associated with Discovery?

    • A) Deploying code to production
    • B) Conducting interviews to validate user needs
    • C) Running automated tests
    • D) Creating epics in Jira

  5. Which of the following is NOT a benefit of Product Discovery?

    • A) Reduced waste
    • B) Faster feature delivery regardless of value
    • C) Increased alignment with users
    • D) Better product-market fit

  6. What does the Build-Measure-Learn loop help with?

    • A) Optimizing velocity in delivery
    • B) Planning long-term roadmaps
    • C) Structuring learning and decision-making in discovery
    • D) Assigning tasks to developers

  7. What is most likely to happen if you skip Product Discovery?

    • A) You'll build faster and cheaper
    • B) You may invest in building features no one wants
    • C) You'll have higher NPS automatically
    • D) The vision becomes clearer

  8. Product Discovery is most valuable in which type of environment?

    • A) Predictable, repetitive systems
    • B) Waterfall projects
    • C) Complex and uncertain product development contexts
    • D) Short-term marketing campaigns only

  9. One key indicator that a team is doing good discovery work is:

    • A) Code coverage above 95%
    • B) Frequent learning cycles based on user feedback
    • C) Full product backlog for 6 months
    • D) 100% delivery on sprint commitments

  10. The ultimate purpose of Discovery is to...

    • A) Please all stakeholders
    • B) Finish development early
    • C) Deliver value by solving the right problems
    • D) Reduce the number of product releases

Parte 2 – Hipóteses, Experimentos e Priorização

Quiz de Revisão – Parte 2

  1. What is the purpose of formulating a product hypothesis?

    • A) To justify budget allocation for delivery.
    • B) To define the final set of product requirements.
    • C) To describe an assumption that needs to be validated before investing in a solution.
    • D) To plan the final stages of development.

  2. A well-structured hypothesis includes:

    • A) Problem, epics, roadmap, budget.
    • B) Customer name, industry, solution scope, timeline.
    • C) Assumption, target audience, expected impact, success criteria.
    • D) Stakeholder opinion, business case, urgency, cost.

  3. Which type of experiment gives the most reliable evidence?

    • A) Brainstorming session with internal team
    • B) Customer survey
    • C) Interview with stakeholder
    • D) A/B test with real users

  4. When should you prioritize running an experiment instead of building a feature?

    • A) When there's low value and low risk
    • B) When the opportunity is high and the risk is high
    • C) When the team is ready to start development
    • D) When the marketing department demands it

  5. What is the Hypotheses Prioritization Canvas used for?

    • A) Estimating delivery times
    • B) Breaking down user stories
    • C) Evaluating value vs. risk to decide which hypotheses to test first
    • D) Mapping personas to backlog items

  6. According to the Truth Curve, which type of data is least reliable?

    • A) Internal assumptions
    • B) Customer behavior data
    • C) Prototype interaction feedback
    • D) Real usage metrics

  7. What is a key characteristic of a good experiment?

    • A) Expensive enough to impress stakeholders
    • B) Designed to bring learning with minimal cost
    • C) Planned after the release of the feature
    • D) Based on gut feeling of the PO

  8. If you have a hypothesis with high potential and low uncertainty, what should you do?

    • A) Ignore it
    • B) Build and measure
    • C) Run extensive experiments
    • D) Escalate to leadership for validation

  9. What does the Truth Curve help teams decide?

    • A) How much to trust a piece of evidence when making product decisions
    • B) How much velocity is needed to deliver faster
    • C) How many stakeholders to involve in discovery
    • D) How to document assumptions and dependencies

  10. What is the risk of building without testing a high-risk hypothesis?

    • A) Minor delays in the roadmap
    • B) Wasting effort on something that might not deliver value
    • C) Getting early feedback
    • D) Creating too much excitement among users

Parte 3 – Validação e Testes

Quiz de Revisão – Parte 3

  1. What is the primary purpose of running experiments during discovery?

    • A) To test delivery timelines
    • B) To validate or invalidate product hypotheses with evidence
    • C) To estimate team velocity
    • D) To finalize technical architecture

  2. Which of the following is an example of quantitative validation?

    • A) Observing user interviews
    • B) Running a prototype demo with a stakeholder
    • C) Conducting an A/B test with 1,000 users
    • D) Asking for opinions in a focus group

  3. What makes a validation "sufficient"?

    • A) When all stakeholders agree to proceed
    • B) When there is enough reliable evidence to make a confident decision
    • C) When time runs out for more experiments
    • D) When the solution is already in the roadmap

  4. What is the key difference between qualitative and quantitative data?

    • A) One is more expensive than the other
    • B) One provides context and depth; the other provides statistical confidence
    • C) Only quantitative data can be trusted
    • D) Only qualitative data requires user input

  5. What is a fake door test?

    • A) A method that simulates a feature to measure user interest without building it
    • B) A security tool for authentication
    • C) A technique for testing usability navigation flows
    • D) A prototype with all features behind a login page

  6. Why should Product Owners not use data to judge team performance?

    • A) It violates agile principles
    • B) Because data should be used to support product decisions, not blame
    • C) Because developers don't trust data
    • D) Data is too complex for meaningful judgment

  7. When should you stop validating and move into building?

    • A) After running at least three tests
    • B) When the Product Owner decides to proceed
    • C) When you have learned enough to make a responsible investment decision
    • D) Only after a steering committee review

  8. What technique is best for exploring user motivations?

    • A) Heatmap click tracking
    • B) One-on-one interviews
    • C) Test coverage reports
    • D) A/B testing button placements

  9. In the Build-Measure-Learn cycle, which part should come first in discovery?

    • A) Build
    • B) Learn
    • C) Measure
    • D) Deliver

  10. What is the risk of skipping validation in product development?

    • A) Faster release with more bugs
    • B) Building features that users don't want or need
    • C) Reduced technical debt
    • D) Improved code quality

Parte 4 – Entendimento Profundo dos Usuários

Quiz de Revisão – Parte 4

  1. What is the primary reason for creating proto-personas early in discovery?

    • A) To finalize the design system
    • B) To segment the market by pricing tiers
    • C) To align the team on assumptions about users before gathering real data
    • D) To generate tasks for the development backlog

  2. Which method is most effective to explore user needs and motivations?

    • A) Reviewing feature requests from sales
    • B) Conducting user interviews
    • C) Analyzing story points and burn-down charts
    • D) Creating technical documentation

  3. What is a key limitation of proto-personas?

    • A) They are difficult to create
    • B) They require expensive tools
    • C) They are based on assumptions, not validated evidence
    • D) They focus too much on business needs

  4. Which of the following activities best helps the team empathize with users?

    • A) Creating acceptance criteria for backlog items
    • B) Mapping user journeys and pain points
    • C) Splitting epics into user stories
    • D) Optimizing sprint velocity

  5. What is a signal that your team may not deeply understand the user?

    • A) The backlog has too many items
    • B) Hypotheses are built without real user input
    • C) Sprint burndown is incomplete
    • D) Stakeholders disagree on design patterns

  6. Which of the following is NOT a user-centered validation method?

    • A) Asking internal teams how users behave
    • B) Observing users interacting with a prototype
    • C) Running empathy workshops
    • D) Conducting contextual interviews

  7. How does shared understanding of users help discovery?

    • A) It helps predict market growth
    • B) It improves team alignment and decision-making
    • C) It reduces scope creep in the roadmap
    • D) It increases the number of planned releases

  8. Why are interviews with users more powerful than surveys in early discovery?

    • A) They generate quantifiable insights
    • B) They uncover motivations, emotions, and context
    • C) They validate pricing strategies
    • D) They are easier to automate

  9. What is the benefit of using a user journey map?

    • A) To visualize steps, frictions, and emotional experiences of the user
    • B) To estimate delivery time per feature
    • C) To define success metrics for stakeholders
    • D) To allocate tasks across squads

  10. How can you turn stakeholder assumptions about users into shared understanding?

    • A) Write detailed epics
    • B) Co-create proto-personas and validate them with data
    • C) Ask executives to approve user stories
    • D) Create dashboards with NPS only

Parte 5 – Colaboração, Stakeholders e Decisões Informadas

Quiz de Revisão – Parte 5

  1. What is the role of stakeholders in the discovery process?

    • A) To approve backlog items and prioritize technical tasks
    • B) To contribute context, collaborate in hypothesis building, and support decisions based on evidence
    • C) To manage delivery deadlines and cost
    • D) To create the product roadmap alone

  2. What is the best way to make product decisions according to PPDV?

    • A) Based on intuition and team experience
    • B) Using validated data from experiments and real user behavior
    • C) Following the competitor's roadmap
    • D) Prioritizing what executives request first

  3. How should a Product Owner respond to conflicting opinions from stakeholders?

    • A) Choose the highest-ranking stakeholder's idea
    • B) Facilitate a discussion using data and experiment results to align on value
    • C) Build both versions and decide later
    • D) Escalate to leadership to make the decision

  4. What type of data is most reliable for making product decisions?

    • A) Assumptions from internal team members
    • B) Quantitative user behavior from real product usage
    • C) Feature suggestions from customer support
    • D) Internal documentation and historical reports

  5. What is the primary benefit of involving stakeholders early in discovery?

    • A) It allows them to create wireframes
    • B) It creates shared understanding and avoids surprises later
    • C) It helps close deals faster
    • D) It improves sprint estimation

  6. When stakeholders push for a feature that lacks evidence, what should the PO do?

    • A) Propose an experiment to validate the assumption before committing
    • B) Immediately reject the idea
    • C) Add the feature to the backlog as-is
    • D) Shift focus to delivery and skip the discussion

  7. Which of the following best supports a culture of evidence-based decisions?

    • A) Running small experiments and sharing learning transparently
    • B) Conducting retrospectives after every release
    • C) Documenting opinions from all teams
    • D) Asking for customer reviews before delivery

  8. Why is relying solely on stakeholder opinions risky in discovery?

    • A) Stakeholders don't care about the product
    • B) It may lead to solutions that do not reflect real user needs or behaviors
    • C) It slows down design work
    • D) It violates agile principles

  9. What does the PPDV assessment expect regarding decision-making processes?

    • A) That Product Owners decide alone based on best practices
    • B) That decisions are made collaboratively and supported by data
    • C) That all decisions go through executive review
    • D) That delivery velocity dictates product direction

  10. Which tool helps facilitate decision-making across diverse perspectives?

    • A) Burndown chart
    • B) Hypothesis Prioritization Canvas
    • C) Gantt chart
    • D) Technical roadmap spreadsheet

Parte 6 – Identificação e Formulação de Problemas

Quiz de Revisão – Parte 6

  1. What is the most common mistake when defining a problem in product discovery?

    • A) Involving too many stakeholders
    • B) Jumping to a solution before understanding the real problem
    • C) Spending too much time on interviews
    • D) Using visual tools to map assumptions

  2. What best describes a well-defined product problem?

    • A) A request from a stakeholder with business justification
    • B) A user-centered need or obstacle that impacts outcomes and is free of predefined solutions
    • C) A technical dependency blocking the next sprint
    • D) A bug reported multiple times by support

  3. What tool helps you align the team and stakeholders on the business challenge being solved?

    • A) Feature roadmap
    • B) Business Problem Statement
    • C) Release plan
    • D) Product backlog

  4. Which of the following is a problem statement, not a solution?

    • A) "We need to build a mobile app to retain users."
    • B) "Users drop off at the payment stage due to lack of mobile accessibility."
    • C) "We should offer coupons through push notifications."
    • D) "Marketing wants us to add gamification."

  5. What technique helps uncover the root cause of a problem?

    • A) User persona workshop
    • B) Sprint planning
    • C) 5 Whys (Five Why analysis)
    • D) A/B testing

  6. When is it most important to revisit and refine the problem definition?

    • A) When early experiments reveal new user behaviors
    • B) When the team reaches the final development phase
    • C) After the release of the MVP
    • D) When the roadmap is delayed

  7. Which signal suggests your team is working on a poorly defined problem?

    • A) Experiments are generating clear feedback
    • B) The team can't agree on who the user is or what need is being addressed
    • C) Developers are busy and velocity is high
    • D) Stakeholders are requesting new features

  8. What's the risk of not identifying the real problem before building a solution?

    • A) It slows down backlog refinement
    • B) It leads to waste by solving the wrong thing
    • C) It reduces developer motivation
    • D) It breaks stakeholder trust automatically

  9. A good problem definition avoids which of the following?

    • A) Mentioning user context
    • B) Relating to business outcomes
    • C) Embedding the solution into the problem statement
    • D) Stating the pain point in plain language

  10. What should you do when a stakeholder presents a request like: "We need to build a chatbot"?

    • A) Add the feature to the backlog
    • B) Investigate what user problem they're trying to solve before accepting the solution
    • C) Reject the idea if it's not on the roadmap
    • D) Forward it to the UX team