Gestão de produtos digitais: Product Discovery

Entendendo product discovery - Apresentação

Apresentando o curso e o instrutor

Seja muito bem-vinde ao curso de Product Discovery (descoberta de produto).

Eu sou o Alexandro, mas podem me chamar de Alê. Atuo com gestão de produtos há cerca de sete anos, desde que realizei minha transição de carreira para essa área. Desde então, trabalho com empresas dos segmentos de saúde, seguradoras e e-commerce (comércio eletrônico), normalmente atuando em um ou diversos produtos.

Além de atuar como Product Manager (gerente de produto), sou instrutor em cursos e mentor de carreira.

Oferecendo mentoria e convidando para contato

Minha mentoria é diversificada, podendo ter foco em Discovery (Descoberta), estratégia, dados ou inteligência artificial, com ênfase em como potencializar seu produto e seus projetos, seja em sua empresa ou em iniciativas pessoais. Minha mentoria oferece suporte significativo nesse aspecto.

Deixo meu link para contato; fique à vontade para me adicionar e enviar uma mensagem. Será um prazer conhecer você e trocar ideias sobre produtos, educação a distância (EAD) e Discovery (Descoberta). Será uma alegria ter você por lá.

Nos vemos na próxima aula, e espero que você aproveite muito esta jornada.

Entendendo product discovery - O que é product discovery

Introduzindo o discovery

Seja muito bem-vindo à primeira aula. Antes de mais nada, eu vou compartilhar o que vamos ver nesta aula.

Vamos iniciar entendendo o que é um Discovery (descoberta), para que serve, por que o executamos, quais são os benefícios de realizar um Discovery (descoberta), quando iniciá-lo e por onde começar. Esses dois últimos pontos são muito importantes, porque nem todo processo exige a execução de um Discovery (descoberta). Quando for necessário, precisamos saber por onde começar. É essencial que tenhamos essa visão clara, portanto, vamos iniciar esta aula abordando esses quatro pilares.

O que é um Discovery (descoberta)? É uma etapa que ajuda a reduzir incertezas na tomada de decisão sobre o que priorizar, desenvolver e construir. Pode ser realizado por meio de técnicas, frameworks (estruturas) ou pela busca de evidências e dados. Ele reduz incertezas e riscos sobre o que vamos priorizar no desenvolvimento do produto, seja algo que estamos construindo do zero, algo novo, ou algo existente que estamos evoluindo.

Focando no problema e pilares iniciais

O Discovery (descoberta) impede que partamos diretamente para a execução e para a construção, ou que comecemos a falar de solução antes de entender o problema. Precisamos parar, refletir e pensar no problema: qual problema estamos resolvendo? Existe realmente um problema?

Vamos a um caso simples, porém frequente: uma liderança, uma pessoa cliente ou outra pessoa chega e afirma que precisamos criar uma nova funcionalidade. Por exemplo: no aplicativo, permitir que a pessoa cliente cadastre o e-mail para receber promoções; ou criar na home (página inicial) uma forma de cadastro para envio de anexos de documentos em um processo. Antes de discutirmos como construir ou implementar isso, é fundamental entender o cenário, verificar se há algo a ser ajustado e, principalmente, se existe uma dor a ser resolvida.

Antes de começarmos a falar de solução, precisamos avaliar alguns pontos que consideramos essenciais:

• Problema: este problema realmente existe? Se sim, vale a pena resolver agora? É o momento adequado? Estamos direcionando esforços para algo com baixo impacto neste momento, enquanto existem outras demandas mais relevantes?
• Pessoa usuária e contexto: para quem estamos resolvendo e em qual contexto? Se existe um problema, alguma pessoa o vivencia. Estamos resolvendo para quem? No contexto dessa pessoa, o problema pode ser resolvido? É um problema grave? Nem sempre vamos resolver problemas com desenvolvimento ou evolução da ferramenta. Muitas vezes, ao entender o contexto da pessoa cliente, conseguimos resolver ajustando ou melhorando o processo, sem necessariamente alterar o produto.
• Hipóteses: o que acreditamos? O que ainda precisamos descobrir? O que não está claro? Quais são as hipóteses relacionadas ao problema, à pessoa usuária ou ao contexto? Precisamos mapear essas hipóteses e entender o que não está claro ou o que exige aprofundamento.
• Evidências: o que aprendemos que sustenta a próxima decisão? Precisamos de evidências — falaremos bastante disso ao longo do curso — porque elas nos ajudam a estruturar uma proposta e a decidir qual caminho seguir. Se identificamos um problema, uma pessoa usuária e um contexto, e temos hipóteses, com base em quais evidências e informações estamos tomando a decisão de seguir por determinado caminho?

Esses quatro tópicos nos orientam no começo do Discovery (descoberta) e esclarecem o que vamos avaliar quando falamos de um Discovery (descoberta) de produto.

Compreendendo benefícios e propósito

O Discovery (descoberta) não é uma etapa burocrática, apesar de muitas pessoas o considerarem burocracia antes do desenvolvimento. Trata-se de uma forma de aprender antes de assumir compromissos maiores. Antes de sair construindo e desenvolvendo, vamos realizar um processo de Discovery (descoberta), entender melhor e aprender mais, para não perceber adiante que desperdiçamos tempo e poderíamos ter evitado esse esforço.

Quais são os benefícios? Um benefício central é a redução de desperdício: de tempo e de recursos. Reduzimos incertezas e o risco de construir ou priorizar algo desnecessário. Pode até existir uma dor, mas talvez a priorização daquela solução, naquele momento, não seja a mais adequada. O Discovery (descoberta) ajuda especialmente na redução de desperdício.

Para que serve um processo de Discovery (descoberta) do produto? Está diretamente alinhado ao que acabamos de discutir e é pautado pelos pontos apresentados acima.

Reduzindo incertezas com hipóteses

Em vez de chegarmos dizendo “o que vamos fazer?” ou “o que vamos construir?”, seguimos pela linha de que tipo de incertezas estamos tentando reduzir. Sempre haverá incertezas. No desenvolvimento de produto, nunca teremos 100% de certeza sobre o que vamos construir ou se aquilo dará certo. É importante entendermos que trabalhamos com hipóteses. Quanto menor o nível de incerteza, melhor para o produto, para o desenvolvimento e para a qualidade.

Teremos uma hipótese e, ao realizarmos um processo de Discover (descoberta), essa hipótese pode ganhar mais força e reduzir riscos de erro e de priorização incorreta.

Falando do problema: este é um problema real? Ele existe? Insistimos nesse ponto porque, se não houver um problema, não há o que corrigir. Nesse caso, não faz sentido seguir com o Discover (descoberta) e sequer com o desenvolvimento.

Validando valor, solução e resultados

Isso é relevante para quem estamos tentando atender? No contexto apresentado anteriormente, no slide (apresentação) anterior, precisamos avaliar se a pessoa cliente vê valor. Quando resolvermos o problema que entendemos ser um problema, a pessoa cliente verá valor? Ela entenderá algo como “resolveu o meu problema” ou “melhorou isto; realmente eu tinha esse problema e não sabia”?

Essa solução tem potencial para resolver o problema? Depois de concluirmos o Discover (descoberta), trata-se da solução que entendemos ser a ideal para resolver esse problema? Com base no Discover (descoberta), passamos a ter mais certezas — não 100% —, mas nos aproximamos mais da melhor proposta de solução.

E quanto ao resultado? Temos evidências de que o comportamento pode mudar? É importante que tudo o que desenvolvemos possa ser medido. Precisamos medir a qualidade da entrega e, após o desenvolvimento, entender quais são os resultados esperados conforme o Discover (descoberta) e como vamos medir esses resultados.

Uma frase que reforça essa mentalidade: “O Discover (descoberta) transforma o ‘eu acho’ em ‘temos evidências suficientes para decidir’.” Assim, temos embasamento para tomar decisões, evitando decisões baseadas apenas em suposição.

Diferenciando outputs e outcomes

O que são Outcomes (resultados) e o que são Outputs (saídas)?

• Quando falamos de Output (saída), é o que estamos entregando. Exemplos:
  • Lançar um filtro de busca.
  • Incluir um campo de texto para digitação e localização.
  • Criar uma tela de Onboarding (integração inicial).
  • Adicionar notificações Push (notificações por envio) no aplicativo.
  • Implementar chat (conversa) de suporte.
• O que são Outcomes (resultados)? É o que queremos mudar. Exemplos:
  • Reduzir o tempo para achar um produto.
  • Aumentar a conclusão do cadastro.
  • Aumentar a retenção no sétimo dia.

Como medir Output (saída) versus Outcome (resultado)? Como medir o valor que estamos gerando?

• Tempo médio até a primeira compra.
• Taxa de conclusão.
• Outras métricas dependem do cenário.

É útil manter em mente a estrutura: “quem faz o quê, de X para Y, em quanto tempo”. Essa é uma forma de estruturar metas e medições que ajuda em diversos cenários.

Conduzindo descoberta orientada a riscos

Quais são os benefícios do Discover (descoberta)?

• Ajuda na qualidade da decisão: quanto mais insumos temos, melhor a qualidade da decisão.
• Reduz desperdício.
• Melhora o alinhamento, especialmente entre as squads (equipes), o time de produto, o time de design, o time de tecnologia e o time de negócio. Com embasamento nos insumos do Discover (descoberta), teremos um alinhamento muito mais rico.
• Cria uma fonte da verdade, para que todas as pessoas compartilhem o mesmo entendimento e saibam a direção a seguir.
• Promove aprendizado contínuo, cultivando a cultura de sempre estarmos aprendendo.
• Mantém o foco no resultado: mesmo discutindo o problema, o foco é o resultado, que deve ser medido. Se o resultado não foi atingido como esperávamos, continuamos medindo e aprendendo.

Sobre o gráfico/imagem mencionado: quando não fazemos Discover (descoberta), operamos com baixa ou nenhuma certeza, seguindo no escuro. Com o avanço do Discover (descoberta), aumentamos o nível de certeza e também o nível de profundidade. Quanto mais profundo for o Discover (descoberta), maior será a certeza, o que ajuda significativamente na tomada de decisão sobre o que priorizar e o que construir. É fundamental entendermos qual nível de profundidade precisamos no Discover (descoberta) para atingir o nível de certeza desejado.

Os quatro riscos que o Discover (descoberta) endereça:

• Valor: é o que a pessoa usuária quer? Precisamos entender se ela tem essa necessidade.
• Usabilidade: a pessoa usuária consegue usar? Não adianta construir algo que a pessoa cliente não consiga usar; isso está muito conectado com o primeiro ponto (valor).
• Viabilidade: conseguimos construir? Não adianta ter valor e usabilidade se não houver viabilidade técnica.
• Alinhamento com o negócio: faz sentido para o negócio? Muitas vezes, tendemos a priorizar temas que não estão alinhados com a estratégia da empresa. A empresa pode estar priorizando uma direção enquanto priorizamos o desenvolvimento de temas desalinhados com os objetivos e a estratégia daquele momento. Assim, podemos gerar valor, porém desalinhado com a estratégia. Precisamos sempre estar direcionados e alinhados com o que a empresa espera do produto.

Discover (descoberta) sem foco em riscos vira pesquisa sem propósito. Isso é muito verdadeiro.

Nós nos vemos na próxima aula. [♪]

Entendendo product discovery - Visão, contexto e restrições

Entendendo quando iniciar o discovery

Aula 2 — Quando iniciar um discovery (descoberta)

Vamos discutir quando iniciar um discovery (descoberta).

Normalmente, o discovery (descoberta) é iniciado quando há uma decisão relevante a ser tomada sobre o produto, com impacto no negócio; quando identificamos uma oportunidade de mercado ou uma oportunidade interna; quando há um problema pouco claro que exige aprofundamento porque ainda não está compreendido; ou para validar uma hipótese que surja do time, da pessoa cliente ou que tenha sido identificada em uma pesquisa.

No próximo slide, apresentamos alguns exemplos de quando podemos iniciar esse discovery (descoberta).

Identificando gatilhos para iniciar o discovery

Ao tratar de oportunidade, retomamos o que comentamos na aula anterior: podemos identificar uma oportunidade interna ao avaliar o processo atual e o produto. Com o discovery (descoberta), conseguimos entender com mais detalhe e profundidade se é o momento de decidir, se há valor a ser gerado e se existe uma dor envolvida, como discutimos anteriormente.

Quando lidamos com um problema recorrente — aquele que todas as pessoas conhecem e que, em nenhum momento, recebe priorização —, o discovery (descoberta) pode nos ajudar a aprofundar o entendimento sobre a gravidade de não corrigi-lo, o impacto de sua recorrência e as hipóteses de solução possíveis.

Diante de uma queda de métrica, ao medir o produto e sua saúde, podemos identificar que, nos últimos meses (por exemplo, no último mês ou nos últimos três meses, a depender da métrica), houve declínio. Nesse caso, podemos usar o discovery (descoberta) para entender por que a métrica está caindo, como podemos melhorá-la, se isso já se converteu em uma dor e quais hipóteses e propostas de solução podem fazer essa métrica voltar a subir.

Em situações de grande investimento, quando a empresa investe significativamente em um determinado negócio ou jornada, é importante realizar o discovery (descoberta) por cautela e para reduzir riscos. O objetivo é diminuir ao máximo as incertezas e os riscos, além de priorizar soluções e evoluções que realmente sejam necessárias, que gerem valor e que tratem um problema ou dor da pessoa cliente ou da pessoa usuária.

Mudanças de contexto — provocadas por fatores internos ou externos — também podem motivar um discovery (descoberta). Antes de partir diretamente para soluções que façam o produto acompanhar essa mudança, vale entender a mudança em si, onde ela impacta, quais dores gera e onde devemos priorizar o esforço e o desenvolvimento do produto.

Avaliando incerteza e impacto do discovery

A seguir, indicamos quando aplicar o discovery (descoberta). Em termos gerais, ele é proporcional ao nível de incerteza e ao impacto da decisão.

Apresentamos um exemplo clássico: mudar o texto de um botão. Em muitos casos, não é necessário realizar pesquisa extensa ou investir meses para decidir se vale reduzir ou ajustar. Nessas situações, mudar a cor ou o texto de um botão é algo pequeno, que pode ser avaliado diretamente: por que fazer, qual necessidade existe e qual dor está sendo resolvida. São casos de baixa incerteza que não demandam discovery (descoberta).

Sugerimos pausar o vídeo neste ponto para analisar com calma a tabela apresentada e compreender o que estamos explicando. De forma orientativa:

• Pequena melhoria conhecida: incerteza baixa; discovery (descoberta) reduzido ou inexistente.
• Problema recorrente com dados: incerteza média; discovery (descoberta) moderado.
• Nova oportunidade de mercado: incerteza muito alta (dados pouco explorados); necessidade de discovery (descoberta) muito alta.
• Solução para problema desconhecido: incerteza muito alta; necessidade de discovery (descoberta) muito alta, pois não podemos partir para a solução sem compreender o contexto atual e as dores.
• Decisão de grande investimento: como o investimento é alto, a expectativa também é alta; precisamos reduzir ao máximo incertezas e riscos para evitar priorizar ou resolver problemas que poderiam ter melhor destino em outro local, outro produto ou outra jornada do produto.

Esse guia nos ajuda, inclusive, a estimar por quanto tempo será necessário realizar o discovery (descoberta). Não fornece uma medida exata de tempo, mas nos orienta: fazemos discovery (descoberta) para reduzir incerteza. Se a incerteza é baixa, não há necessidade; se é alta, a necessidade aumenta.

Orientando o discovery com frameworks

Quanto à origem do discovery (descoberta), existem alguns frameworks que geram insights, insumos e gatilhos para começarmos. Utilizamos muito o Double Diamond (Duplo Diamante), que, em essência, promove um ciclo constante de aprender, desenvolver, construir, medir e aprender novamente. Recomendamos manter um aprendizado contínuo: aprendemos sobre o produto e a dor, realizamos o discovery (descoberta), partimos para o desenvolvimento e retornamos para aprender mais sobre essa ou outra jornada. É um processo de aprendizado constante.

Por fim, apresentamos uma comparação entre discovery (descoberta) e delivery (entrega). O discovery (descoberta) é o ato de aprender, reduzir incertezas e decidir o que vale construir. O delivery (entrega) é a etapa de construção: tudo o que aprendemos e os insumos gerados no discovery (descoberta) servem para o delivery (entrega) construir o que precisa ser priorizado, com qualidade e com base no que foi aprendido.

Assim como no Dual-Track (duas trilhas), não se trata de uma linha reta — não é “discovery (descoberta), delivery (entrega), acabou”. Eles ocorrem em paralelo.

Relacionando discovery e delivery

Relação entre discovery e delivery

Sempre que o time de desenvolvimento está trabalhando no processo de delivery (entrega), nós estamos em discovery (descoberta), aprendendo sobre outros temas, mapeando e entendendo assuntos que servirão de insumo para o desenvolvimento após a conclusão do que está em andamento no delivery (entrega).

O discovery (descoberta) permanece à frente do delivery (entrega), normalmente três ou quatro passos adiante. Quando o time de delivery (entrega) chega para executar, já temos a descoberta realizada e os aprendizados consolidados.

Ambos acontecem em paralelo.

Começando pelo objetivo e perguntas-chave

Por onde começar?

É importante que façamos quatro perguntas:

• Qual é o resultado que queremos alcançar?

  • Não estamos falando de funcionalidade, mas de impacto.
  • Qual é o valor gerado que queremos trazer para o time de negócios?
  • Mesmo partindo de algo desconhecido, precisamos de ao menos uma primeira hipótese de resultado a alcançar.

• O que já sabemos sobre esse problema?

  • Qual é o nosso nível de entendimento e de aprofundamento do tema?
  • Sabemos o problema em nível detalhado? Temos certezas ou ainda não as temos?
  • Caso não tenhamos clareza, podemos buscar dados, pesquisas anteriores, feedbacks e decisões já tomadas. Isso é essencial, pois são lições aprendidas que evitam repetir erros de algo que já foi feito ou priorizado e não funcionou.
  • Precisamos estudar cuidadosamente o problema. Devemos estar apaixonados pelo problema, não pela solução. Esse é um conselho prático: aprender continuamente sobre o problema.

• O que estamos assumindo sem evidência?

  • Quando não há evidência, partimos no escuro. Falta algo que sustente a premissa para priorizar determinado ponto.
  • A evidência ajuda a direcionar melhor as decisões.

• Quais são os limites reais?

  • Precisamos entender nossos limites: tempo, orçamento, tecnologia, compliance (conformidade regulatória) e política interna.
  • Por que afirmamos isso? Às vezes, a empresa solicita um discovery (descoberta) de uma semana sobre um novo investimento. Talvez esse prazo não seja suficiente. Podemos precisar renegociar antes de começar.
  • Em orçamento, pode ser que não haja verba e seja necessário usar inteligência artificial para realizar tudo.
  • Pode não ser possível falar com pessoas clientes externas, caso o produto seja B2C (empresa-para-consumidor), ou com pessoas clientes internas, devido a questões de compliance (conformidade regulatória).
  • Pode haver limitações tecnológicas por falta de domínio ou maturidade.
  • Em política interna, pode haver pessoas que não compartilham conhecimento ou inexistência de documentação.
  • Tudo isso deve ser compreendido antes de partir para o discovery (descoberta).

Ao consolidar: qual resultado buscamos, o que já sabemos sobre o problema, o que estamos assumindo sem evidências e quais são os limites reais, obtemos uma ideia clara de como estruturar o briefing (resumo) da fase de discovery (descoberta) antes de iniciar.

Analisando visão, contexto e restrições

Visão, contexto e restrições

Após validar esses pontos, começamos analisando visão, contexto e restrições:

• Visão: para onde queremos ir e qual resultado importa. Podemos ter mais de um resultado. Isso se conecta ao objetivo estratégico da empresa, como já discutimos na aula anterior. O discovery (descoberta) precisa estar alinhado à visão da empresa.

• Contexto: o que já sabemos e quais forças mudam o problema. É importante separar claramente o que já está consolidado do que ainda não está claro.

• Restrições: o que podemos ignorar e onde estão os limites reais. Algumas restrições podem ser ignoradas por não gerarem impacto geral; outras, de fato, limitam e impedem o avanço.

Definindo a visão de produto

O que é e o que não é a visão de produto

Para esclarecer o que é a visão do produto e o que ela não é:

• A visão não é um roadmap (roteiro de entregas).
• A visão não é uma lista de features (funcionalidades).
• A visão é um resultado desejado.

Devemos explicitar também o horizonte de tempo desse resultado. Exemplo: “Reduzir o abandono no onboarding (integração) de 35% para 15% em seis meses.” Assim, definimos o que queremos e em quanto tempo desejamos alcançar.

Uma boa visão responde:

• Quem se beneficia.
• Do que se trata.
• Por que isso importa agora.

Com isso, qualquer pessoa que leia a visão do produto entende por que priorizamos aquele objetivo e como ele se conecta ao que estamos construindo.

Mapeando o contexto organizacional

Mapeamento de contexto organizacional

No mapeamento do contexto organizacional, observamos:

• Estratégia: o alinhamento ao objetivo estratégico.
• Team capacity (capacidade do time): não adianta priorizar temas se não houver time suficiente para desenvolvê-los no tempo necessário.
• Orçamento.
• Histórico: o que já foi tentado, para evitar repetir tentativas infrutíferas e aproveitar lições aprendidas.
• Stakeholders (partes interessadas): quem precisa ser convencido e quem pode bloquear ou acelerar.
  • Há sempre pessoas usuárias-chave, os key users (pessoas usuárias-chave), que dominam o negócio ou o produto, e pessoas que precisam aderir ao que está sendo proposto, bem como aquelas que podem acelerar o avanço. É importante mapear essas pessoas.

Diferenciando restrições de crenças

Restrições reais e crenças

É fundamental distinguir restrições reais de crenças e suposições. Por exemplo: “Não podemos mudar o fluxo de cadastro.” Trata-se de uma decisão técnica, política ou de uma suposição? Pode ser apenas uma crença — ou uma crença disfarçada.

Outro exemplo: “As pessoas usuárias não vão aceitar isso.” Essa frase expressa uma hipótese, não uma evidência. Ainda é uma crença.

Isso é diferente de restrições reais.

Por exemplo, podemos ter seis meses ou seis semanas até o lançamento, e isso é um fato que molda o escopo do Discovery (descoberta). Assim, o Discovery (descoberta) já começa com um prazo predefinido.

Outro exemplo de restrição real: não podemos acessar dados de pagamento por motivos de compliance (conformidade). Esse é um limite legítimo que define o que podemos investigar.

Isso se conecta com a parte que nós comentamos há pouco sobre as restrições. Você entende a diferença entre uma crença e uma restrição real? Muitas pessoas caem em armadilhas nesse ponto; é muito importante que você atente para a diferença entre elas.

Estruturando o briefing de partida

Aqui deixamos um briefing (resumo orientador) de como estruturar o ponto de partida. Como sugestão, pause o vídeo e analise com calma esta tabela. Ela é importante porque dimensiona resultado esperado, contexto, premissas e restrições.

Também deixamos algumas perguntas-chave como exemplo, mas você pode incluir outras, bem como exemplos de como medir.

Alinhamento e visão com as partes interessadas

• Alinhamento e visão com o/a stakeholder (parte interessada) são essenciais. Existem stakeholders que podem acelerar e outros que podem bloquear o avanço. É muito importante estar alinhado com quem deve estar a par do Discovery (descoberta), com quem deve estar ciente do que está acontecendo, dos avanços e das descobertas.
• Compartilhe o briefing (resumo orientador).
• Sempre distribua o documento de visão e crie uma “fonte da verdade” acessível, na qual as pessoas consigam entender por que você está fazendo aquilo, o que está fazendo, qual é a visão e quais são os objetivos.
• Identifique divergências em que as pessoas discordam quanto ao resultado esperado; é importante que todas as pessoas estejam de acordo com isso.
• Separe o ‘o quê’ do ‘como’. Alinhe o resultado desejado antes de qualquer conversa sobre solução e abordagem. Isso é extremamente importante.
• Documente o que ficou em aberto. Deixe claro o que permanece pendente: nem tudo precisa ser resolvido antes de começar, mas registre para que todas as pessoas tenham ciência.

Simulando objeções com inteligência artificial

Uso de IA para simular objeções

• Antes de conversar com o/a stakeholder (parte interessada), peça para a IA agir como essa própria parte interessada. Forneça contexto, peça para ser questionadora, cética e para trazer diferentes perspectivas.
• Isso ajuda você a treinar e a formular melhores perguntas. Questões que podem ser óbvias para outras pessoas talvez não sejam para você; com a ajuda da IA, podemos reduzir esse risco e seguir com perguntas mais objetivas, que trarão mais valor.

Recapitulando a aula

Recapitulação da aula

• Vimos a importância de termos uma visão do que é o Discovery (descoberta) antes da pesquisa, de entendermos os benefícios, por onde começar e o que fazer para começar.
• Discutimos a necessidade de entender o contexto e os insumos: estratégia; quem são as pessoas envolvidas, direta ou indiretamente; lições aprendidas; o que já foi feito para não repetirmos; o histórico; o entendimento do problema; e as restrições.
• Reforçamos que é sempre importante mapear as restrições, entender o que é uma restrição real, o que não é, e o que efetivamente nos bloqueia naquele momento.

Trazemos aqui uma recapitulação para destacar que, antes de começar um Product Discovery (descoberta de produto), nós já iniciamos com um mapeamento aprofundado de tudo o que está acontecendo e do que já temos, antes de começarmos a execução.

Nos encontramos na próxima aula.

Sobre o curso Gestão de produtos digitais: Product Discovery

O curso Gestão de produtos digitais: Product Discovery possui 194 minutos de vídeos, em um total de 46 atividades. Gostou? Conheça nossos outros cursos de IA para Produto & Negócio em Inteligência Artificial, ou leia nossos artigos de Inteligência Artificial.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Entendendo product discovery
• O problema e o usuário
• O produto e seus dados
• Mapeando oportunidades e gerando soluções
• Testando hipóteses e validando soluções
• Roadmap, documentação e apresentação