Logo Agile SchoolLogo Agile School
Logo Agile SchoolLogo Agile School
0
R$0.00 0 item

Nenhum produto no carrinho.

Sabemos que gerenciar um Product Backlog exige alta capacidade, uma vez que ele muda constantemente e, por isso, demanda que se considerem muitas opções ao adicionar, excluir, atualizar e ordená-lo. Mas você sabia que é possível melhorar o seu desempenho de gerenciar todos os aspectos do Product Backlog?

A seguir, separamos algumas dicas que podem te auxiliar.

Se você atua como Product Owner (e busca por maneiras práticas de lidar com os stakeholders e com o Product Backlog), um Product Owners (que deseja compreender melhor seus clientes e stakeholders), um  Product Manager ou Analistas de Negócios (que espera melhorar suas habilidades de gerenciamento de Product Backlog) ou  Scrum Master (que quer ser um coach eficaz para Product Owners), fique com a gente e acompanhe essa leitura!

Estude técnicas de refinamento

Como dizem, “a experiência leva à prática”. E no caso de um Product Backlog, não é diferente. Praticar as técnicas de refinamento, como a decomposição e a subdivisão de itens do Product Backlog vai te levar mais longe como profissional! Com o tempo você vai perceber que a simplicidade pode ser a chave que faltava para resolver Product Backlogs complicados e complexos. 

Conecte seus Product Goal

Os Product Goals fornecem contexto para o Product Backlog e servem como uma meta para o Time Scrum. Estes são um objetivo de longo prazo, uma declaração direcional simples, que fornece contexto e propósito para o Time Scrum e seus stakeholders. Ao conectar os Products Goals nos quais você investe o seu tempo, é possível garantir que estejam entregando valor.

Lide bem com todos os seus stakeholders


Para ser um(a) excelente profissional, faça um mapa dos seus Staheolders. Entenda quais são suas necessidades, você perceberá que alguns você vai precisar estar mais próximos e outros nem tanto. Além disso, é importante que você também saiba lidar, compreender e gerenciar a interação com todos os stakeholders envolvidos nos projetos, incluindo a sua própria equipe. Por isso, a nossa dica é: melhore a sua comunicação!

Encante os seus clientes com o Product Backlog

Este tópico também tem a ver com o item acima, afinal, o cliente é um dos seus stakeholders.

Quando você domina a metodologia com maestria, oferece transparência e uma visão de futuro com o total domínio a seus clientes. Desta maneira, é impossível não deixá-los encantados. Para isso, é importante saber identificar as necessidades deles e abranger tudo no Product Backlog. 


E como conseguir tudo isso?


Por meio do treinamento Professional Scrum Product Backlog Management SkillsTM, da Scrum.org, promovido pela Agile School. Essa capacitação traz técnicas e métodos para gerenciar efetivamente um Product Backlog. 

"O novo treinamento da Scrum.org ajudará você desde a construção da visão do seu produto a ter seu Product Backlog refinado e conectado com os objetivos de negócios. Tudo isso numa abordagem mão na massa",  explica  Thiago Fregni, Head de Operações da Agile.inc e trainer Oficial da Scrum.org neste curso.

Ao longo de 8 horas, você vai aprender a:

Confira todos os detalhes na página do curso e inscreva-se!

Inteligência artificial têm sido um dos temas mais discutidos nas redes sociais atualmente e um dos produtos mais comentados é o Chat GPT. Mas afinal, como essa tecnologia pode ajudar o trabalho do Product Owner? Essa é a pergunta que muitos têm se feito. 

Para responder essa questão, utilizamos o próprio Chat para obter insights sobre como ele pode ser usado na função. O resultado foi surpreendente, pois a ferramenta pode apoiar o Product Owner de diversas maneiras, oferecendo suporte a tarefas e responsabilidades associadas à função. 

Neste artigo, apresentaremos oito maneiras pelas quais o Chat GPT pode ser utilizado para ajudar o Product Owner na execução do seu papel.

1. Definição de Requisitos

A definição de requisitos é uma das atividades cruciais na gestão de um produto. Nesse sentido, o chat GPT pode ser uma ferramenta valiosa para auxiliar o Product Owner. Ele pode ajudar na elaboração de histórias de usuário, na definição de critérios de aceitação, bem como na comunicação com os stakeholders e a equipe de desenvolvimento.

Para ilustrar essa possibilidade, utilizamos o próprio chat GPT e solicitamos a criação de uma história de usuário para o pagamento de uma compra em um e-commerce, utilizando um cartão de crédito e adicionando os critérios de aceitação necessários para validar os dados do cartão. Para nossa surpresa, o chat GPT respondeu prontamente com uma história de usuário bem descrita e com critérios de aceitação detalhados.

Entre os critérios de aceitação apresentados, destacamos a validação do número de cartão de crédito digitado pelo usuário, verificando se ele é válido e se possui a quantidade correta de dígitos, além da verificação da data de validade e do código de segurança (CVV).

Essa demonstração evidencia que o chat GPT pode ser uma ferramenta útil para auxiliar o Product Owner na definição de requisitos de forma ágil e precisa. Com isso, é possível otimizar o tempo e aumentar a eficiência na gestão do produto, proporcionando uma experiência mais satisfatória para os usuários e agregando valor ao negócio.

2. Priorização de Backlog

A priorização do backlog é uma das tarefas mais desafiadoras para o Product Owner, pois requer uma análise cuidadosa dos requisitos e um equilíbrio entre as demandas dos stakeholders e da equipe de desenvolvimento. É nesse contexto que o chat GPT pode ser um grande aliado na tomada de decisões.

Com base em fatores como valor de negócio, riscos e dependências de esforço, a ferramenta pode ajudar a priorizar itens do backlog de forma mais eficiente. Para ilustrar isso na prática, fizemos um teste com a ferramenta, fornecendo a ela um esboço de backlog embaralhado e pedindo para que ele priorizasse os itens levando em consideração a jornada de compra.

E o resultado foi surpreendente! Com base na jornada do usuário, a inteligência artificial apresentou a seguinte priorização: página inicial do e-commerce, pesquisa de produto por categoria, seleção de itens de carrinho de compra, fechamento do carrinho de compra, dados do meio de pagamento, dados do local de entrega, envio do e-mail de confirmação de compra e, por último, a ordenação da busca de produtos.

O Chat GPT justificou sua escolha, afirmando que embora a ordenação de busca de produtos seja útil para os usuários, ela é menos crítica na jornada de compra do que as outras funcionalidades. Com isso, fica claro que ele pode ser uma ferramenta poderosa para auxiliar o Product Owner na priorização do backlog, trazendo mais objetividade e assertividade para o processo de desenvolvimento de produtos.

3. Planejamento de Sprints

O chat GPT pode, sim, ser uma ferramenta para apoiar o Product Owner no planejamento de Sprints, mas é importante lembrar que sua sugestão de distribuição de tarefas entre os membros da equipe pode não ser a melhor opção. A inteligência artificial é baseada em informações fornecidas por seres humanos, e pode haver imprecisões ou inadequações no input utilizado para treiná-la. Portanto, é essencial usar o senso crítico para avaliar as sugestões apresentadas.

Embora ele possa ser útil para definir metas e objetivos de Sprint, é importante ressaltar que a distribuição de tarefas é responsabilidade da equipe e não do Product Owner. A auto-organização da equipe é um dos princípios fundamentais do Agile e deve ser preservada. Portanto, é recomendável descartar sugestões que possam prejudicar a autonomia da equipe, avaliar criticamente o que ele ofereceu e usar esses dados com cautela.

4. Gerenciamento de Stakeholders

O chat GPT pode também ser uma ferramenta útil para o Product Owner no gerenciamento de stakeholders, fornecendo dicas e conselhos sobre como gerenciar expectativas, comunicar efetivamente e resolver conflitos.

Apesar de ser uma ferramenta básica, ela pode ser eficaz em oferecer sugestões de gerenciamento de informações e conselhos de gestão. Para ilustrar, um exemplo seria uma instrução simples dada ao chat GPT para fornecer dicas e conselhos sobre como gerenciar expectativas, comunicar efetivamente e resolver conflitos entre os stakeholders. Através dela, ele foi capaz de fornecer informações valiosas e úteis em uma variedade de tópicos de gestão de stakeholders.

5. Análise de métricas e KPI’s

Dentro da análise de métricas e KPI 's do projeto, ele pode ajudar a identificar métricas e equipes relevantes para acompanhar o progresso e sucesso do projeto, além de fornecer insights para melhorar o desempenho da equipe.

Durante um teste com a ferramenta, foi possível gerar dados fictícios e métricas de um e-commerce, chamado Fashion X. A inteligência artificial criou diversos exemplos de métricas bastante interessantes, o que já demonstra o valor da ferramenta.Porém, é importante salientar que para uma análise mais crítica e aprofundada dos dados, é necessário fornecer contexto e informações mais detalhadas. Na prática, os dados utilizados no projeto serão específicos e é importante compreender as métricas de forma mais ampla.

O Chat GPT consegue fazer sugestões de otimização baseado nas métricas apresentadas, mas é importante ressaltar que essas sugestões são genéricas e dependem do contexto do projeto. Cabe ao Product Owner analisar cuidadosamente essas sugestões e avaliar se elas são aplicáveis ao seu contexto.

Algumas sugestões que foram oferecidas: aumento da taxa de conversão, redução de custos, redução da taxa de devolução e aumento do engajamento em redes sociais. É importante analisar essas sugestões com cautela e realizar uma análise mais aprofundada para compreender se elas realmente são aplicáveis ao contexto do projeto.

6. Condução de reuniões

Além de ajudar na preparação de agendas, a inteligência artificial também pode fazer a sumarização de reuniões de maneira automática. Entretanto, é possível ir além e explorar a capacidade do chat GPT em sugerir pautas de agenda.

Ao testar essa habilidade, nós obtivemos sucesso na obtenção de uma boa proposta de agenda. O chat sugeriu uma pauta bem estruturada, que incluía a revisão do que foi feito na Sprint, com a participação dos desenvolvedores, e a realização da retrospectiva da Sprint, apesar de haver uma pequena confusão na colocação dessa atividade.

No geral, a dinâmica apresentada pela inteligência foi bem interessante e pode ser uma boa ajuda na preparação de reuniões eficientes. É importante lembrar, no entanto, que é sempre necessário avaliar e adaptar suas sugestões de acordo com o contexto da equipe e do projeto em questão.

7. Pesquisa e Validação

Ao inserir um contexto específico, como a criação de um app de gestão de investimentos para uma corretora de valores, é possível obter informações valiosas sobre as melhores práticas de mercado, tendências e tecnologias emergentes. Durante o exercício, o chat GPT ofereceu sugestões como design intuitivo e fácil de usar, personalização do aplicativo de acordo com o perfil do investidor, automação, segurança e gamificação.

O chat também destacou a importância da educação financeira, sugerindo que o conceito fosse integrado à plataforma. As sugestões oferecidas podem ajudar na criação de um backlog com ideias de tendências futuras. Ao levar em consideração o contexto específico, o Product Owner pode tomar decisões mais informadas e criar um produto mais atraente para seus clientes.

8. Melhoria contínua

Com a capacidade de identificar áreas de melhoria, a ferramenta pode fornecer sugestões para aprimorar a eficiência e eficácia do produto. Além disso, é possível utilizá-la para realizar comparações de benchmarking entre seu produto e os concorrentes, o que pode ajudar a entender melhor seu mercado e a identificar pontos fortes e fracos.

Por exemplo, se você tiver um produto visível no mercado, pode pedir ao chat GPT para comparar seu produto com o líder do seu segmento e destacar características relevantes do concorrente. Embora as respostas possam ser um pouco genéricas, elas ainda fornecem embasamento suficiente para guiar as análises do Product Owner. 

Conclusão

Em resumo, a substituição completa do papel do Product Owner ou de outros profissionais do conhecimento pela inteligência artificial ainda não é possível. Embora a IA possa potencializar e auxiliar em algumas tarefas, ela ainda não possui a capacidade de compreender o contexto e as nuances das necessidades do negócio, do mercado e dos usuários, além de habilidades de comunicação e negociação. 

Portanto, aqueles que devem se preocupar com a perda de empregos para a IA são aqueles cujo trabalho é apenas uma variação ou combinação do que os outros já criaram antes deles. 

A contribuição da IA é potencializar e catalisar as entregas de valor, evoluindo o papel dos profissionais do mercado e suas carreiras. Então, se você procura evoluir sua carreira como Product Owner e saber executar esse papel com êxito, inscreva-se na nossa próxima turma de Professional Scrum Product Owner Advanced.

Este treinamento oficial da Scrum.org,  é essencial para Product Owners que desejam aumentar seus conhecimentos e habilidades, com dinâmicas e práticas para o dia a dia deste papel. Garanta sua vaga na próxima turma de PSPO-A e conquiste uma certificação internacional.

Assumir novos papéis nem sempre é uma tarefa fácil, ainda mais quando chegamos em um ambiente desconhecido e que não estamos habituados. Por isso, trouxemos neste artigo cinco dicas essenciais que você, Product Owner, deve saber ao adentrar em um novo time.

Já falamos aqui sobre a função desse papel e também sobre a diferença dele para o Product Manager. Mas apenas para relembrar: o Product Owner é a pessoa responsável pelo refinamento do produto, ou seja, é alguém sempre atento às tendências de mercado e às necessidades do cliente. 

Sua função é muito relacionada ao Scrum e ao backlog de produtos, para que os desenvolvedores realizem seu trabalho e entreguem resultados de valor. Portanto, é essencial que esse papel seja bem executado, e para isso, é necessário atentar-se a certos pontos:

Mapeie seus Stakeholders

Os Stakeholders representam o conjunto de indivíduos a quem o seu produto ou projeto interessa de alguma forma, podendo ser externos ou internos à organização. Nesse contexto, falamos principalmente sobre os colaboradores, clientes, e outras pessoas que irão ser responsáveis em apoiar e desenvolver esse produto.

Portanto, mapeá-los de forma ágil é essencial! Entenda a organização da empresa em que você está inserido e a hierarquia vigente, o que pode ser feito através de um organograma dos processos, onde você é capaz de visualizar as áreas conectadas e definir quem deve ser priorizado no momento de resolver impasses do seu produto em questão.]

Compreenda o mercado do seu produto

O mercado de cada produto possui um comportamento singular, por isso, é essencial compreender em qual deles o seu projeto está inserido. Busque compreender o modelo de negócio da sua empresa, e com isso, defina o mercado-alvo (aquele que busca atingir com o lançamento do produto) e o posicionamento que diferencia seu produto dos outros que já atuam no mercado.

Além disso, faça uma lista das fontes de receitas e despesas e estabeleça uma visão compatível ao seu objetivo.

Defina as metas a serem alcançadas com o produto

Para quem não sabe pra onde vai, qualquer caminho serve. Logo,dê preferência às metas objetivas, quantitativas e com prazo. Caso a empresa já possua alguma estrutura (OKR por exemplo), faça uso das metas ou objetivos estratégicos já existentes. 

É crucial que exista esse parâmetro, pois você irá utilizá-lo como medidor de sucesso e progresso.

Crie um bom Product Backlog

Baseado nas metas estabelecidas pelo tópico anterior, inicie a criação do Product Backlog com itens mais genéricos, em alto nível (podem ser épicos). Ordene os itens de forma a constituir uma versão inicial de Roadmap de Produto e se for adequado, pode ser feito um plano de lançamento das versão inicial do produto (Release Plan). 

Na sequência, inicie o refinamento dos itens mais prioritários do Product Backlog (que estão no topo da lista), quebrando-os em itens menores e detalhando suas funcionalidades e características do escopo desejado.

Tenha um bom relacionamento com o time

O Product Owner também deve investir seu tempo em estabelecer um relacionamento com sua equipe. É fundamental que, uma vez que os desenvolvedores irão construir o produto, a dinâmica de comunicação, negociação, troca de opiniões e feedback seja muito fluida. 

O Product Owner também é um membro do time e não pode se ausentar ou ser visto como inimigo da equipe. Uma atenção especial pode ser dada a BA, Designer, QA e o Scrum Master, pois terão uma proximidade maior do POs nas atividades do dia-a-dia.

Invista em treinamentos que irão alavancar sua atuação

A nossa última dica (mas não menos importante) para você que é um Product Owner recém chegado em um time, é investir em treinamentos e cursos que irão te auxiliar a assumir esse papel com êxito e, ainda, ter uma certificação internacional!

Estamos com vagas abertas para nosso treinamento Professional Scrum Product Owner, que irá acontecer de forma online e ao vivo. Ele é voltado para todos aqueles que buscam como trabalhar melhor com os Stakeholders, como gerenciar um backlog de sucesso e entre outras funções essenciais do PO.

Aproveite essa oportunidade e garanta sua participação! 

Um dos temas mais pedidos em nossos canais digitais, são dicas para se tornar Scrum Master e/ou Product Owner sem ter experiência prévia. Por isso, neste conteúdo, vamos te trazer dicas reais e aplicáveis para você começar na carreira de especialista em Produto através do Scrum.

Agora, se você quer ser Scrum Master, esse artigo aqui é ideal para te ajudar nessa jornada

Bom, voltando para o papel de Product Owner, a primeira oportunidade é o momento no qual a experiência como Product Owner começará a ser lapidada, e para que isto aconteça, o candidato deve trazer algumas questões para que o possível empregador tenha segurança ao dar esta primeira chance. Isso porque, a função de Product Owner é de uma responsabilidade enorme para o time e organização em que ele estará trabalhando.

Então, quais são essas questões para se ter cuidado para que o empregador se sinta confiante ao contratar um Product Owner sem ter experiência? Vamos entender isso a seguir!

Passos antes de se tornar um Product Owner

Para assumir o papel de Product Owner, uma das maneiras mais adequadas é subir posições dentro de um time e/ou empresa. Seja você uma pessoa desenvolvedora, Scrum Master, analista de negócios, entre outros papéis que possuem mais relação com a pessoa de Produto. Isso é importante para, aos poucos, você aprender e desenvolver as soft skills necessárias para o papel, demonstrar interesse, ir somando sua experiência e estar próximo, de forma que, se tornar um Product Owner, seja quase uma consequência natural.

Isso porque estando dentro do time ágil, a organização já te conhece como profissional, sabe como você trabalha e, por consequência, se sinta mais confiante em te dar uma oportunidade para mudar de carreira ali mesmo, levando em consideração que você entende bastante do negócio e isso é uma das principais habilidades do PO.

Mas, o que fazer caso a empresa em que você está trabalhando não tenha perspectiva de ter um time ágil ou desenvolver a transformação ágil? Neste caso, é importante analisar as empresas ou áreas para as quais pretende atuar como PO. Por exemplo, se você já atua como um analista financeiro, esta experiência tem grande valor para o contratante de um Product Owner neste segmento, mesmo que não tenha atuado ainda como um Product Owner de fato.

Isso porque, seu papel como analista financeiro garante um conhecimento valioso sobre essa área, de forma técnica e, na hora de um processo seletivo, isso vai te ajudar! Entretanto, se além desta competência mais específica, você tiver algum curso ou certificado respeitado no mercado, isso é um ponto muito relevante num processo seletivo.

Um Product Owner capacitado para a atual onda de Agilidade e Produtos Digitais que vivemos, deve levar em consideração questões como “User Experience”, por exemplo. Afinal é papel do PO ser responsável pelo Produto, incluindo técnicas como Design Thinking, que fazem parte do hall de conhecimento de um bom Product Owner.

Por ser um papel tão multifacetado, vale ressaltar que nem sempre todas estas habilidades deverão ser utilizadas. Porém, mostrar que você está preparado para quando for necessário, dará muito mais tranquilidade para o empregador e, para dominar estas habilidades, não é necessário estar já atuando como um Product Owner.

Além de questões relacionadas ao papel do Product Owner, é também importante que o profissional domine outras habilidades que serão importantes para a execução deste papel, como: liderança, comunicação, tratamento em equipe, resiliência… E, tudo isso deve ser mostrado em um processo seletivo para conquistar esse papel..

Assista à esse conteúdo agora

Conclusão

Para que você possa demonstrar que está apto para exercer o papel de Product Owner, tudo isto que foi demonstrado aqui é importante que seja trabalhado, pois será valorizado pela empresa empregadora - para que esta tenha maior confiança na hora de dar a oportunidade ao profissional.

Além disso, certificações como a PSPO I (da Scrum.org) também tem um peso positivo no currículo - sendo esta uma das mais desejadas pelo mercado. Saiba mais agora sobre esta certificação através do treinamento Professional Scrum Product Owner, clicando aqui.

Muitos dos nossos alunos quando nos procuram, têm a intenção de se tornarem um profissional de Produto e, mesmo após os treinamentos, muitas dúvidas sobre o dia a dia desses profissionais ainda surgem.

Neste artigo, trouxemos uma visão do dia a dia do profissional de Produto na prática, como entender os eventos do dia a dia, os obstáculos e exemplos de ações que você pode sim fazer com seu time.

Confira nossa agenda de turmas para se tornar um Product Owner

A diferença entre Product Owner e Product Manager

É muito comum ver o mercado colocando o Product Manager acima do Product Owner, como uma hierarquia. Num breve resumo, o que temos visto muito nos dias de hoje no dia a dia de times de Agilidade e Desenvolvimento de Produtos Digitais, é o papel de Product Owner ser mais focado só no time Scrum, enquanto o Product Manager vai cuidar do mercado, ver como estão as aplicações novas do produto, analisar os concorrentes e etc.

Entretanto, essa expertise da função de Product Manager deve estar no Product Owner e vice-versa. Segundo o Scrum Guide, a pessoa que atua como Product Owner já deve possuir essas competências. Algumas delas são:

Todas essas características precisam estar na atuação como Product Owner e também são essenciais para quem atua como Product Manager. A separação que o mercado faz entre esses dois papéis é prejudicial, pois eles acabam afastando a estratégia do operacional e isso vai contra os valores e princípios da Agilidade. Falando ainda sobre fundamentos, um dos princípios do Manifesto Ágil é fazer o trabalho em conjunto, ou seja, pessoas da área de Negócios e pessoas dos Times Ágeis.

“Todo Product Owner deve ser um Product Manager” (Martin Keegan)

Você pode ler mais sobre esse assunto neste artigo aqui!

O conceito de User Stories dentro da área de Produto

Independente do nível de experiência de uma pessoa de Produto, essa é uma ferramenta essencial em sua rotina de trabalho. User Stories ou Histórias de Usuários é uma forma de descrever uma demanda que ajuda na mudança de foco na hora de detalhar requerimentos de aplicações. Geralmente, um User Story é feito utilizando sentenças narrando a utilização do requerimento, por exemplo:

“Como <tipo de usuário>, quero <alguma meta> para que eu possa <algum motivo>.”

É importante lembrar que independente do framework que você irá utilizar, o User Stories está ali para te auxiliar a organizar um pensamento… Mas você não precisa seguir “a ferro e fogo” o modelo que citamos acima.

A principal necessidade é fazer com que o time de Desenvolvimento entenda o que realmente precisa ser feito. Podemos até dizer que esse papel de deixar claro o projeto é do próprio Product Manager, mas caso não tenha esse papel no time, essa tarefa pode ser da pessoa que exerce a função Product Owner.

E o seu papel como pessoa de Produto, seja PM ou PO, é deixar o time inteiro na mesma página e todas as pessoas envolvidas alinhadas sobre o processo e execução de todo o projeto.

Organização e gerenciamento do Product Backlog

Após você e o seu time identificarem o processo e as demandas que foram geradas através do User Stories, é hora de colocar tudo no Backlog. A pessoa que exerce o papel de PO ou PM não deve fazer essa etapa sozinha! É um momento complexo e que envolve outros papéis, por isso, é preciso alinhar as necessidades dos stakeholders, do time e dos desenvolvedores. 

E esse profissional também não pode ocupar muito o tempo dos desenvolvedores para entender a complexidade de cada tarefa… Então uma dica é: envolva nessa reunião o tech lead, profissional de design UX e a pessoa de Negócios. Essas são pessoas chaves que vão poder te dar uma orientação de quais serão os próximos passos, pois eles que vão desenvolver o produto e compreender melhor a complexidade de cada etapa. 

Existem empresas que ainda trabalham num modelo de hierarquia tradicional e, por isso, alguns stakeholders acreditam que o que eles querem é o que deve ser feito. Quando algo desse gênero se apresenta, a comunicação é fundamental para que você consiga lidar com essa situação, mostrando o valor dessa prática e seus benefícios para o dia a dia de trabalho e, consequentemente, nas entregas.

Para isso, sempre mostre dados que apresentam o quanto a solução que você está sugerindo pode ser a melhor para a execução e/ou melhoria daquele Produto. Desta forma, você mostra que não trabalhou apenas com achismos e que fez um estudo sobre todo o projeto e chegou às melhores conclusões. 

O processo de Product Discovery

Continuando a nos aprofundar no papel de profissionais de Produto e sua evolução, é super importante falarmos sobre Product Discovery. Basicamente, essa é uma estratégia para estudar a viabilidade de determinado produto ou solução digital. Além disso, é muito utilizada para a identificação das necessidades futuras dos usuários.

Essa abordagem permite você verificar se determinada funcionalidade que você está planejando lançar realmente será eficaz e interessante para o consumidor final… Tudo isso antes do desenvolvimento de fato da novidade! Isso evita que você gaste recursos desenvolvendo soluções que não serão verdadeiramente úteis para seus clientes.

O profissional de produto e sua evolução (PM e PO)

Normalmente quem lidera esse processo de Product Discovery é a pessoa que exerce o papel de Designer UX. E assim, nesse caso, a pessoa de Produto é um copiloto, que precisa participar das entrevistas, da pesquisa como um todo e ter um olhar voltado tanto para o usuário quanto para negócios.

A função da pessoa de Produto nas reuniões do time Scrum

Conforme você vai crescendo e ganhando responsabilidades como pessoa de Produto não há justificativa para deixar o seu time de lado, não!

Isso não faz sentido. Você como profissional de Produto precisa conseguir participar das cerimônias e entender as dores do time. É preciso entender que, em alguns eventos da equipe, podem acontecer dos membros não entenderem o porquê estão desenvolvendo tal função, não concordarem com as iniciativas que estão tomando, não compreender a visão de negócio daquele produto e etc. E, ao se manter longe, as pessoas da equipe podem acabar se sentindo desmotivadas também!

Por isso, é fundamental que você como PM e/ou PO faça sim parte das reuniões e encontros do time Scrum e mostre o porquê de cada etapa está sendo desenvolvida e também escute o que a sua equipe tem para falar.

Benchmarking, Análise de Mercado, Estratégia e Pricing

Normalmente, essas são práticas que dependem de diversas outras áreas de qualquer empresa. Nesses casos, o profissional de Produto participa de encontros para realizar esses processos, mas não é exatamente ele que faz isso. Ou seja, no processo de Pricing, por exemplo, ele participa e apoia os outros times, mas não é ele quem define o preço dos produtos/serviços.

Mas como o PM/PO pode contribuir para essa pesquisa? Nas reuniões, esse profissional pode levar tudo que ele sabe e que ele recolheu junto com o time e mostrar como está o mercado, o que os concorrentes estão fazendo, o que está sendo imposto para esse tipo de produto, tendências atuais e futuras e etc.

Com essas informações, é possível todas as áreas envolvidas conversarem e alinharem uma estratégia que faça sentido para a organização como um todo - colocando também o cliente no centro dessas decisões.

Conclusão

Conseguimos entender como é na prática o dia a dia do profissional de Produto e a evolução da sua carreira, seja este Product Owner e/ou Product Manager. Sabemos ainda que, ao ler sobre esse assunto, parece mais complicado avançar e colocar em prática, não é mesmo?

Entretanto, também sabemos que são pequenos passos que podem te ajudar a evoluir profissionalmente como uma pessoa de Produto, ou seja, aprendendo, ir testando, validando e aprendendo novamente.

O papel de Product Owner é realmente multifacetado, exigindo comportamentos desafiadores e ferramentas que vão além do Scrum e da Agilidade. Aqui na Agile School acreditamos que todo profissional pode e deve evoluir constantemente em suas habilidades… Por isso, recomendamos o treinamento de PSPO-A (Professional Scrum Product Owner Advanced) da Scrum.org para você dar o próximo passo em sua carreira na área de Produtos Digitiais. Você pode saber mais sobre esse treinamento clicando aqui.

Veja a super aula do nosso trainer Rodrigo Pinto junto com Marcell Almeida falando sobre a evolução do profissional de Produto (Product Owner/Product Manager)

Vamos falar sobre as características elementares que todo profissional que deseja se tornar ou já é um Product Owner deve ter para ter um excelente desempenho e gerar mais resultados.

Anteriormente falamos sobre as características elementares que todo Scrum Master e Dev-Team deve possuir.

Hoje iremos falar sobre Product Owner, porém devemos lembrar que essas características que iremos colocar como elementar são a base e pontos fundamentais que você irá observar e que devem estar presentes, sendo assim vamos a elas:

Conhecer o usuário 


Essa é a primeira característica elementar que um Product Owner deve ter, sem dúvida é um fundamento inicial o exercício da empatia, ele precisa entender de quem é o seu cliente, para quem ele está trabalhando, quais são as dores dessa pessoa, quais são as principais características desse principal indivíduo.


Podemos também falar de um produto para o mercado aberto, nesse caso um Product Owner precisa saber qual o nicho que ele irá focar, quem será o seu usuário, quais são os dados demográficos e gostos pessoais e de novo qual a dor que ele precisa resolver.
Também existe a possibilidade de ser um produto para uso interno, assim ele irá precisar saber qual o stakeholder chave que vai ta utilizando esse sistema, se esse stakeholder chave irá contratar o serviço e por que ele irá contratar.

Assim podemos ver que sem o conhecimento nos mais ricos detalhes possíveis sobre quem é o seu usuário não é possível fazer uma estruturação de um produto.


Um Product Owner pode usar em seu favor as pesquisas de campo com os usuários, pesquisas de mercado e benchmarking.

Bom Gerenciamento 


Como segunda característica elementar de um Product Owner temos um bom gerenciamento do product backlog. Uma metáfora para entender melhor essa característica, é pensar como se todo time de scrum estivesse dentro de um carro e quem está no volante é o Product Owner. Como está no volante, ele que conduz para qual caminho o time de scrum deve seguir.

Assim é imprescindível ser claro e transparente em cada projeto, no fatiamento, na estruturação e no refinamento.


Para ter esse bom gerenciamento, é importante se utilizar da inteligência coletiva do time de Desenvolvimento para ajudar a compor itens funcionais ou não funcionais que irão auxiliar para que um bom gerenciamento do backlog seja feito.

Já que  o Product Owner tem conhecimento sobre o seu usuário, ele poderá sair do campo das ideias e conseguir chegar em um campo mais concreto para se chegar no software. Com isso voltamos a ideia inicial do bom gerenciamento do caminho percorrido com uma boa estruturação de um product backlog.

Ser Data Driven 


Uma última característica elementar para ser um Product Owner é ser um profissional com pensamento orientado por dados e por fatos, pois como trabalha num ambiente complexo, o que mais se encontra são incertezas, a falta de clareza entre a causa e o efeito, ambiguidade. Um Product Owner da mais alta maturidade precisar pensar muito em como validar o mais rápido possível todas as hipóteses daquilo que ele entende que vai ser um benefício para o usuário e para o seu produto.


Ser data driven e ter uma boa orientação por dados ajuda a saber quais respostas eu consigo tirar do mercado do produto e do meu usuário. Assim o Product Owner irá utilizar ferramentas que possibilitem realizar o teste A/B, como o Google Analytics ou APM, entre outras ferramentas que possam trazer dados que realmente comprovem e validem os fatos.

Com a cultura da data driven é possível sair do achismo, sair do seu âmbito de gosto pessoal para algo que te traga realmente valor, fundamentado nos fatos reais de um mundo real. 

Essas são as três habilidades que um Product Owner deve ter. São habilidades simples, porém muito profundas, que realmente uma pessoa muito bem estruturada e muito bem fundamentada precisa ter para se tornar um Product Owner.

Inscreva-se para a próxima turma de Professional Scrum Product Owner e  entenda como criar um produto que gere alto valor para o mercado

Entenda melhor um dos três artefatos do Scrum e como ele deve estar estruturado

O Backlog do Produto é um dos 3 artefatos do Scrum (os outros são o Sprint Backlog e o Incremento) e consiste numa lista ordenada de tudo o que é necessário para maximizar o valor do produto. Tal lista é composta por Itens do Backlog que geralmente representam melhorias, correções e débitos técnicos.

Product free icon

É importante que o Backlog do Produto esteja visível para o Time Scrum (Time) e Stakeholders a fim de promover transparência sobre o que será construído e em qual ordem será construído.

O Backlog do Produto é a única fonte de requisitos do Produto. Ou seja, tudo o que for relativo ao Produto deve estar contido apenas nele.

O único responsável pelo Backlog do Produto é o Product Owner (PO) e, embora ele possa delegar a ordenação do Backlog para alguém do Time de Desenvolvimento, ele continua sendo o responsável por ele. Portanto, a fim de evitar conflitos de interesses, todo Backlog deve mantido por apenas um Product Owner.

Como o Backlog do Produto está estruturado?

Os primeiros Itens do Backlog são aqueles que são mais importantes para o produto em dado momento. Eles devem estar mais detalhados e serem mais bem compreendidos por todos do Time. Dessa forma, são os Itens mais elegíveis a serem desenvolvidos nas próximas Sprints.

Por sua vez, os Itens mais ao fundo são aqueles que ainda não estão bem compreendidos, precisam ser refinados para melhor detalhamento e serão desenvolvidos mais tardiamente, sem previsão esperada para as próximas Sprints. Imagina-se que com mais detalhes, a estimativa seja mais assertiva e seja mais fácil atingir o Objetivo da Sprint dentro do Timebox.

O critério utilizado para ordenação do Backlog é definido pelo PO, que pode utilizar diversas técnicas conforme a necessidade, como por valor, por prazo (caso seja uma ação de marketing ou determinação legal), por risco, por dependência técnica ou de negócio...

Os critérios são muitos e cabe ao Product Owner decidir qual o melhor critério para o momento vivido pelo Produto. Já a estimativa é de responsabilidade do Time de Desenvolvimento que são os executores. Contudo, o PO ajuda na determinação e entendimento do escopo.

Uma imagem contendo uma explicação sobre o Backlog do Produto

Por seu dinamismo, o Backlog do Produto é considerado um artefato vivo uma vez que está em constante mudança a fim de garantir a adequação e maximização do valor do Produto.

Os Itens de Backlog geralmente são escritos como Histórias de Usuários, embora o Scrum não especifique um formato padrão. Qualquer que seja a forma escolhida é uma boa prática conter uma descrição, qual a estimativa de esforço, qual o valor pretende gerar ao negócio, quais são os critérios de aceite e quais testes devem ser realizados. Esses atributos contribuem para comprovar a completude do PBI quando “Pronto”.

Características de um bom Backlog do Produto

Um bom Backlog do Produto deve ser DEEP e o PO deve ser um bom FDP. Calma, não é isso que você está pensando! Te explico abaixo cada conceito.

DEEP é o acrônimo que significa que o backlog deve ser: Detalhado apropriadamente, Estimado, Emergente e Priorizado.

Quando dizemos que o PO deve ser um bom FDP estamos nos referindo a ação do PO: Fatiar, Descartar e Priorizar.

Conclusão

O Backlog do Produto é um artefato vivo e a entrada para todo o fluxo de Eventos do Scrum. Enquanto existir Produto, existirá Backlog para ele. A priorização de melhorias, correções, débitos técnicos e refinamento é de responsabilidade do PO, que deve ser uma única pessoa para evitar conflito de interesses e dificuldade na tomada de decisão quanto ao escopo do Produto e a prioridade na sua execução.

Eleve o nível de seus conhecimentos com treinamentos oficiais da Scrum.org. Clique aqui e confira a agenda completa!

É Product Owner ou pretende atuar neste papel? Baixe agora nosso e-book gratuito "8 instâncias do Product Owner" e aprenda as diferentes formas de atuaçãono trabalho de criação de produtos/serviços e na geração de valor ao cliente.

Leia também:

Product Owner

Introdução

Employee free icon

O Product Owner (PO) é o papel responsável pela definição do produto, por cuidar que ele entrega o valor proposto durante todo o seu ciclo de vida.

Todas as decisões relativas ao produto são de responsabilidade do PO, ainda que ele esteja representando o desejo de um comitê ou que ele delegue ao Time de Desenvolvimento. Atividades como a ordenação do Backlog do Produto, a escrita dos Itens, tirar dúvidas de negócio para os desenvolvedores ou qualquer outra ação relacionada ao produto.

Nesse contexto, cabe ao PO garantir que o Backlog do Produto esteja visível e os Itens do Backlog estejam escritos de forma clara a fim de maximizar e otimizar o valor do produto que será construído pelo Time de Desenvolvimento.

Idealmente, o Backlog do Produto deve estar ordenado, assegurando transparência ao roadmap do produto para os Stakeholders e para o próprio Time Scrum, facilitando algumas tomadas de decisões tais como: dependência entre Itens de Backlog, possíveis impedimentos, mapeamento de débitos técnicos ou outros fatores necessários para manter o produto em um estado competitivo, estável, escalável, de qualidade e que atenda principalmente aos desejos e anseios de clientes e stakeholders.

Logo, o Backlog do Produto deve ser único para cada produto de modo a manter centralizado tudo o que é referente a ele: features, bugs, débitos técnicos, documentação... de mesmo modo, cada produto só deve ter um PO responsável, reduzindo assim a complexidade na tomada de decisão, evitando conflito pela falta de consenso caso houvesse mais de um PO por produto.

Para auxiliar na transparência do Backlog do Produto e facilitar o Planejamento da Sprint, o PO realiza o refinamento do Backlog do Produto com o Time de Desenvolvimento. O refinamento tem como objetivo preparar todo o Time Scrum para o trabalho a ser feito nas próximas Sprints, uma vez que é uma oportunidade que o Time Scrum tem de antecipar dependências, impedimentos, melhorar o entendimento das necessidades do cliente, deixando assim os Itens de Backlog preparados para as Sprints que virão. O refinamento não é um evento do Scrum, portanto, não tem um time-box estipulado, mas é uma prática importante e necessária à maioria dos times Scrum.

Cabe ao PO realizar a gestão de stakeholders internos, clientes e usuários para agir como a voz deles, assegurando que a solução correta seja desenvolvida. Qualquer solicitação que, de alguma forma, chegue ao Time de Desenvolvimento diferentemente dos Itens de Backlog planejados no Planejamento da Sprint e que compõe o Backlog da Sprint, deve ser levada ao PO. Como Dono do Produto, o PO é o único responsável por priorizar as atividades executadas pelo Time de Desenvolvimento. 

Interferências externas põem em risco o Objetivo da Sprint e tiram o foco do time do que foi priorizado durante o planejamento!

Imprevistos e mudanças podem acontecer? Podem! Mas cabe ao Product Owner lidar com elas e adicionar ao Backlog do Produto. Se for um caso urgente, que precise ser resolvido ao longo da Sprint, todo o Time Scrum deve conversar e discutir as ações a serem tomadas, mas ainda assim, a responsabilidade de qualquer mudança é do PO.

O Incremento pronto, entregue ao final da Sprint pelo Time de Desenvolvimento deve atender aos critérios estipulados pelo PO. Uma prática que implementa isso é a definição de critérios de aceite para os itens do Backlog do Produto.

Conclusão

O Product Owner é a pessoa responsável por responder pelo produto, ou seja, pelo valor gerado, estabilidade e qualidade do produto. O PO também precisa garantir que o Backlog do Produto esteja sempre transparente, que seja expresso de forma clara e entendível, e assegure também que o Backlog do Produto esteja visível e ordenado para o Time Scrum e Stakeholders.

Inscreva-se já para o próximo Treinamento Online de Professional Scrum Product Owner. VAGAS LIMITADAS!
menu