O conteúdo desta publicação é de inteira responsabilidade do(s) autor(es):

_ Idealização: Jônatas Falcão

_ Texto: Daniele Mazza, Frederico Parreira, Jônatas Falcão
_ Templates e exemplos do Miro: Frederico Parreira
_ Diagramação e edição de texto: Daniele Mazza
_ Planejamento MVP: Frederico Parreira
_ Capa: Flávio Peixoto (Bigoi)
_ Revisão de texto: 3GB Consulting
_ Fotos: br.freepik.com

2
_ Agradecimentos especiais:
A Alice Alves, Débora da Silva Santos, Georgios,
Gritzapis, Luciana Braga Guerreiro, Victor Ferreira e
ao pessoal do iCarros: Aline Santos, Beatriz Duarte,
Carlos Souza, Daianne Rodrigues, Ewerton Silva,
Gabriela Lorena, Marcelo Nasser, Maria Amaral, Maria
Cardoso, Natalia Barbosa, Priscilla Rodrigues,
Rosangêla Nunes, Stella Oliveira, Stephanie Negri,
Taity Armando, Tamiris Velicka, Thaisa Merola,
Vinicius Frachia e Vitor Gonçales, que foram nossos
primeiros leitores, revisores e experimentadores do
e-book, testando o nosso produto e nos fazendo
evoluir para entregarmos a versão 1 do
Simplificando a criação de produtos digitais.

Ao Instituto Federal do Triângulo Mineiro do

Campus Uberlândia Centro que nos abriu as portas
e permitiu que publicássemos o livro, e as pessoas
que fizeram essa ponte, Márcia Aparecida Bellotti e
Walteno Martins Parreira Jr.

A Zup IT por nos propiciar a cultura #somosnerds.

_ÍNDICE
I_ INTRODUÇÃO 5 5_ BRAINSTORM 36
6_ PREPARANDO PESQUISAS 39
II_ DEPOIMENTOS 6
7_ CONSOLIDAÇÃO DE PESQUISAS 42
III_ O E-BOOK 7 8_ PROTO-PERSONAS 45
IV_ PENSANDO COMO PRODUTO 8 9_ JORNADA DO USUÁRIO 48
10_ APLICAÇÃO DE DOT VOTING 53
V_ AGILIDADE E PRODUTO 10
11_ COMO PODERÍAMOS (CP) 55
VI_ DISCOVERY E DELIVERY DE PRODUTO 13
12_ MATRIZ VALOR X ESFORÇO 58
VII_ CONTINUOUS DISCOVERY E DELIVERY 15 13_ ESCRITA DE HISTÓRIAS 62

VIII_ PRODUTO BASEADO EM DADOS 16 14_ ROADMAP E FERRAMENTAS 65

15_ PAPÉIS E RESPONSABILIDADES 68
IX_ AS TÉCNICAS ESCOLHIDAS 18
+ BÔNUS: PRIORIZAÇÃO DE HMVP 71
X_ COMO USAR O E-BOOK 19
XII_ GLOSSÁRIO 74
XI_ TÉCNICAS 20
XIII_ APÊNDICE
1_ ASSESSMENT 21
1_ A CRIAÇÃO DO TIME AD HOC 81
2_ NUVEM DE PALAVRAS 24
2_ FRAMEWORK DE PRODUTOS AD HOC 82
3_ LEAN CANVAS 26
XIV_ BIBLIOGRAFIA E CRÉDITOS 97
4_ RISCOS DO PRODUTO 32
I_ INTRODUÇÃO
Agradecemos por escolher este e-book. Se você o escolheu, é porque
precisa de “algo mais”, e ele foi desenvolvido para que possa sentir
“acolhimento”, pois sabemos bem que a tarefa de uma pessoa que
pretende criar, recriar e, principalmente, “pensar como produto” não é
nada fácil.
Temos hoje tantas teorias, cursos online e presenciais, certificações,
opções de templates, frameworks, siglas e nomes bonitos em inglês
para ficar “in”, que muitas vezes nos deparamos com uma situação em
que nem sabemos por onde começar. Estudamos muita teoria, e aí
chega o dia em que precisamos sentar na nossa cadeira, lá no
escritório (ou remotamente, e teremos que começar a “fazer
acontecer” o produto que vamos desenvolver. E então, bate o
desespero! Por onde eu começo mesmo? Qual das teorias que vou
usar faz mais sentido? O que fazer primeiro?
Tranquilize-se! Porque este e-book veio para ajudar a conhecer como
fazer para começar a construir um produto que os seus clientes (ou
clientes dos seus clientes) irão amar!
Não iremos usar as palavras mais bonitas da moda, até porque isso
você poderá achar em vários livros que estão no mercado. Queremos
partir do simples, um simples que o passo a passo poderá ajudá-lo a
conseguir desenvolver o seu produto do zero até o momento do
lançamento em produção.
Um ponto importante que já deve saber e que devemos reforçar é:
fazer produto não é fácil. Os conceitos muitas vezes são fáceis de
serem assimilados, porém, o mais difícil é colocá-los em prática. Mas
ao praticar as técnicas que iremos apresentar, você conseguirá evoluir
na carreira de produto e começar a criar produtos apaixonantes para o
seu cliente.
Boa leitura!
Jônatas, Dani e Fred
5
 II_DEPOIMENTOS
“ Tudo começou através da escuta ativa, ouvindo cada um de
nossos clientes e entendendo suas necessidades. A ideia do time
Ad Hoc desde o início foi resolver problemas reais por meio de
times dedicados ao compartilhamento de conhecimentos e
coconstrução gerando soluções incrementais ou do zero, todas
com o mesmo propósito: geração de valor aos clientes finais. A
nossa missão é ajudar a formar os times que irão dar
continuidade, sustentação e evolução dos produtos, gerando
ciclos de vidas cada vez mais perenes e saudáveis.
Este e-book é um concentrado de técnicas que foram utilizadas
pelo time, ou seja, as técnicas foram aplicadas e trouxeram
resultados. Sinto-me feliz e lisonjeada por contribuir com a
iniciativa e pela oportunidade de ter estado próxima ao time Ad
Hoc. Seremos sempre sócios do grande objetivo de construir
produtos cada vez mais aderentes ao que os clientes desejam e
precisam.
”
6
Ad Hoc por Alexandra Borges de Lucena
Diretora de Tecnologia na Zup Innovation
“
Podemos dizer que o Discovery de Produto é o processo
essencial para que os times investiguem e cheguem a soluções
que efetivamente resolvam dores reais de nossos clientes. É
onde fomentamos a inovação e descobrimos novas formas de
resolver velhos (e novos) problemas.
Para que isso aconteça, existem diversas técnicas que podem ser
aplicadas e que contribuem imensamente nessas jornadas de
descobertas. O E-book que está em suas mãos serve como um
companheiro fiel em seus próprios processos de Discovery, pois
apresenta ferramentas que já trouxeram resultados confiáveis
para milhares de times ao redor do mundo, tais como Lean
Canvas, Jobs To Be Done (JTBD), Matriz Valor x Esforço e 4
Riscos de Produto.
Tenho certeza de que o livro ajudará você e seu time a criar
soluções inovadores e que encantem os seus usuários.
Aproveitem!
E-book por Vinicius Morgado
Diretor de Tecnologia na Zup Innovation
”
III_ O E-BOOK
Para quem é este e-book?
Um ponto importantíssimo que precisamos lhe dizer é que este
e-book não é só para Product Managers. Pelo contrário, é para
qualquer pessoa que gostaria de saber o mínimo necessário para
começar a construir um produto digital. Vamos nesta jornada lhe
mostrar porque devemos fazer produtos apaixonantes e como isso
pode transformar a sua forma de pensar, a do seu time e das pessoas
ao seu redor sobre como construir produtos.
Se você é analista, gerente, desenvolvedor ou qualquer outra função e
tem interesse em saber como desenvolver um produto, conseguirá ter
aqui seu ponto de partida. Até porque pessoas que fazem produtos,
sejam elas PMs ou GPMs, exercem funções relativamente novas, e
não existe uma carreira lógica para esse tipo de formação. Por isso, o
que mais vale é a paixão por querer fazer o produto certo para as
pessoas certas.
Bala de prata
A “bala de prata”, a “regra de ouro” ou qualquer outro jargão para
impressioná-lo a fazer o produto NÃO EXISTE!
Não há um padrão certo para fazer determinado produto. Muitas
coisas dependem de situações específicas para cada negócio/área ou
empresa. Se você está em uma startup, determinadas técnicas podem
ser necessárias. Por outro lado, se trabalha em uma grande empresa
com culturas diferentes de desenvolvimento, poderá ter mais
esforço para concluir o seu produto. Mas uma coisa é certa: tanto
uma quanto a outra desejam que seus produtos sejam apaixonantes o
suficiente para que os seus clientes continuem desejando e pagando
por eles.
Então, mãos à obra! Porém, antes precisamos lhe contar uma coisa
muito importante, que mudará a forma de você pensar, e que também
pode mudar a forma como irá analisar tudo à sua volta, e servirá para
o resto da sua vida: que é PENSAR COMO PRODUTO.
7
 IV_ PENSANDO COMO PRODUTO
Este tema é tão importante que fizemos questão de deixar um
capítulo só para falarmos sobre isso: “Muito mais do que fazer um
produto, é pensar como produto!”
Pensar como produto é pensar em fazer algo que tenha valor, que
faça sentido para quem vai usá-lo, que você possa acompanhar e ter
condições de saber o resultado do que fez (medir) e analisar a
experiência das pessoas por meio do que está fazendo.
Então espera aí! Isso significa que, se pensarmos como produto,
podemos fazer ou melhorar qualquer coisa além de produto?
Exatamente!
Quando pensamos como produto, significa que podemos criar,
mudar, melhorar não somente produtos, mas também processos e
serviços que estão à nossa volta, e ter a oportunidade de deixá-los
muito melhor para quem os usa.
Vamos dar alguns exemplos:
8
Produto digital
Um bom exemplo é um aplicativo mobile ou web com a interface (as
telinhas lindas, coloridas, botões, etc. ), o usuário, que é a pessoa que
vai utilizar o aplicativo, e um item invisível e mais importante de
todos: a experiência que o nosso produto vai gerar no momento que
esse cliente estiver utilizando o aplicativo. Aí que está o ponto!
Como deixar esse aplicativo mais agradável para quem o utilizará?
Como deixá-lo apaixonante? Como deixar a experiência do usuário
que utilizará esse aplicativo incrível? Se você tiver respondido cada
uma dessas perguntas, estará chegando ao melhor nível que um
produto pode ter, que é quando ele realmente tem o seu VALOR,
quando está fazendo realmente diferença na vida das pessoas que o
estão utilizando.
Processos
Nenhuma empresa vive sem um processo. Se não existissem os
processos, estaríamos em um completo caos. Porém, sabemos que
muitos deles também deixam as empresas mais “engessadas” e
tornam difícil acompanhar o time to market (tempo de início do
desenvolvimento de um produto até ele estar pronto para a venda).
IV_ PENSANDO COMO PRODUTO
Existem processos que são manuais e automatizados, mas
independentemente de qual seja, podemos ter também o
“pensamento de produto” para eles: ainda precisamos desse
processo? Se sim, como podemos melhorá-lo para que possa ser
utilizado mais facilmente? Como podemos simplificá-lo para ajudar no
dia a dia das pessoas que o utilizam? Qual experiência as pessoas
estão tendo ao utilizar esse processo?
Serviços
Um exemplo de serviço no qual podemos aplicar o “pensamento de
produto” é o de facilities. Toda empresa física precisa de serviços de
manutenção, limpeza, elétrica, etc. Normalmente a empresa que
presta esse serviço é terceirizada. Isso significa que o produto dela é o
serviço que pode nos ajudar no dia a dia com facilidades para que
possamos fazer o nosso trabalho na empresa.
Nesse caso, podemos pensar o seguinte: como deixar a experiência
cada vez melhor para quem usa os serviços de facilities? Mesas e
banheiros limpos, luzes bem instaladas, local de trabalho limpo e
adequado, café sempre pronto e quentinho na copa.
Um outro exemplo pode ser visto em hotéis, quando as camareiras
arrumam o quarto e dobram as toalhas e roupas de cama em formatos
especiais como aves, corações ou quando elas deixam o banheiro
organizado com alguma mensagem no espelho. Isso tudo pode ser
considerado um "a mais no serviço", que agrega valor a quem vai usar,
por vezes gerando engajamento e fotos na internet.
Como pôde ser visto nesses exemplos de serviços, podemos aplicar o
“pensamento de produto” para mudar a experiência das pessoas e
atribuir mais valor ao que pretendemos melhorar, seja um produto,
processo ou serviço.
Se você começar a pensar dessa forma, coisas incríveis poderão ser
feitas, pois nada como ter empatia com as pessoas para que possamos
ajudá-las a ter experiências cada vez melhores.
9
 V_ AGILIDADE E PRODUTO
Atualmente, quase toda empresa fala em agilidade. Seja utilizando
frameworks em seus processos, seja modificando estruturas inteiras
para que os processos possam funcionar de uma forma “mais ágil”.
Neste e-book não iremos nos aprofundar no tema agilidade, pois já
existe muito material bom no mercado falando sobre isso, mas
queremos responder uma pergunta que sempre aparece:
O que tem a ver produto com agilidade?
Tem tudo a ver, e vamos lhe explicar o porquê neste capítulo, mas para
isso precisamos contar uma história bem resumida.
Tudo começou em 2001, em um resort nas montanhas no estado de
Utah, nos Estados Unidos, onde 17 amigos com grande conhecimento
em desenvolvimento de software juntaram-se, não só para se divertir,
mas principalmente para conversar sobre como poderiam melhorar o
que vinham fazendo em termos de desenvolvimento de software. Eles
não estavam contentes com a forma como as empresas estavam
trabalhando.
10
Queriam fazer diferente! Estavam incomodados com a forma como
trabalhavam e perceberam que poderiam fazer melhor, com entregas
mais ágeis e com mais valor. Foi dessa conferência de dois dias (como
eles mesmos chamaram à época) que saiu o Manifesto Ágil. Um
documento que continha quatro princípios importantes e que mudou
muito a forma como muitas empresas e pessoas trabalham até hoje.
1º Princípio Ágil: indivíduos e interações, mais que processos e
ferramentas.
Este princípio já mostra logo que agilidade tem a ver com produto. Se
estamos desenvolvendo um produto, precisamos conhecer as pessoas
(indivíduos) que o estão utilizando. Precisamos conhecer suas
necessidades, vontades e desejos, além das dificuldades que
enfrentam no dia a dia. Para isso, precisamos conversar (interações)
com elas e entender suas jornadas.
Qual a necessidade dessa pessoa? O que ela faz? Por que ela faz isso?
Para que ela faz isso? Quando ela faz? Como ela faz? Quanto custa
para ela fazer isso? Essas respostas ficam evidentes quando fazemos
essas interações usando a jornada do cliente, uma das técnicas que
serão apresentadas e ensinadas no decorrer deste e-book.
V_ AGILIDADE E PRODUTO
2º Princípio Ágil: software em funcionamento, mais que
documentação abrangente.
Há algum tempo, era natural que um produto de software muito bem
documentado fosse visto com muito bons olhos, pois significava que
os processos foram seguidos e que estava tudo muito bem organizado.
Porém, a grande maioria das documentações, depois de entregues,
nunca mais eram lidas, até porque as atualizações do software e as
novas features implementadas nem sequer eram atualizadas no
documento original, e, mesmo que fossem, ninguém mais o leria. Fazer
documentações detalhadas para acabarem em algum arquivo
empoeirado de uma sala escura não faz sentido.
Uma das coisas que Eric Ries cita no livro Lean Startup é sobre o MVP
(Minimum Valuable Product). Um MVP que você coloca em
funcionamento, usando o mínimo de features possíveis, mas que
agregue um real valor para o cliente, de uma forma rápida e sem a
necessidade de escrever grandes documentações, é fundamental:
“Para que vou desenvolver um produto com tantas funcionalidades,
sendo que nem sei se o meu usuário vai usar todas elas?”. “Imagina
escrever uma documentação completa de algo que o usuário nem
sequer irá usar?”
De nada servirá desenvolvermos um produto com dez
funcionalidades, documentá-las uma a uma e, depois de lançar,
perceber que perdemos o time to market e ainda vimos que os
usuários estão usando apenas uma das funcionalidades lançadas.
É por isso que a experimentação em produtos é importante. Colher
feedbacks rápidos para “corrigir o rumo” do seu produto de forma mais
ágil, ou seja, errar rápido e corrigir rápido para gerar menos prejuízos!
Não precisamos sair desenvolvendo e documentando tudo o que se vê
pela frente, precisamos ter algo simples, mas que tenha o valor que o
cliente perceba.
3º Princípio Ágil: responder às mudanças, mais que seguir um
plano.
Talvez um dos princípios fundamentais de agilidade que uma pessoa de
produtos PRECISE ter em mente todos os dias é: “O seu produto é vivo
e precisa responder às mudanças”. Normalmente essas mudanças
precisam ser rápidas, afinal, o mercado muda, os seus clientes e
usuários mudam, as vontades e paixões desses consumidores mudam,
e precisamos ficar atentos a tudo isso.
11
 V_ AGILIDADE E PRODUTO
Evidentemente existem exceções, produtos militares, aeroespaciais,
etc. A equipe da SpaceX, companhia de Elon Musk, que é uma das
principais empresas privadas de serviços de transporte espacial do
mudo, nunca vai deixar de seguir um plano para construção de um
módulo espacial, certo?
Mas como nosso foco são produtos digitais, isso, sim, muda! E muito
rapidamente, e é por isso que o conceito de “experimentação” é válido,
pois devemos fazer mudanças rápidas, experimentar e mexer no que
for necessário, para garantirmos que os usuários de nossos produtos
continuarão os utilizando.
4º Princípio Ágil: colaboração com o cliente, mais do que
negociação com contratos.
Foi-se o tempo em que as empresas olhavam somente para contratos
e valores. Nos dias de hoje, é muito mais assertivo sermos
colaborativos com os nossos clientes, e explicaremos o porquê.
12
O mundo corporativo está cada vez mais competitivo e integrado. Isso
significa que necessitamos muitas vezes cocriar, sugerir, ajudar nossos
clientes para que eles tenham sucesso em seus produtos e serviços.
Não é à toa que temos visto muito se falar em customer success. Não
iremos entrar em detalhes neste e-book sobre CS, mas,
resumidamente, significa que o sucesso do seu cliente também é o seu
sucesso! As parcerias atuais são cada vez mais duradouras, e isso não é
mais questão de preço, e sim de valor.
Preço é só um número, porém, o valor é o que você agrega ao seu
cliente, colaborando com o que ele precisa para que o produto,
processo ou serviço que faz continue relevante e, consequentemente,
você também ganhe com isso, na fidelidade do seu cliente. Lembre-se:
se os clientes do seu cliente estão felizes, significa que o seu cliente
está mais feliz, e é muito provável que ele esteja muito feliz com você
também.
VI_ DISCOVERY E DELIVERY DE PRODUTO

Para que um produto possa ser feito, precisamos entender dois É com o auxílio de técnicas, templates, entrevistas e, principalmente,
macroprocessos: Discovery e Delivery. muita interação com o cliente que conseguiremos experimentar e
fazer descobertas incríveis que possam, de fato, fazer a diferença para
Discovery de Produto o produto que pretendemos desenvolver.

Nada melhor do que conhecer o problema dos nossos usuários,
ouvi-los e entender o que eles, de fato, estão precisando, e estar
disposto a descobrir o que tem de ser feito. Mas não pense que as
coisas são fáceis, já que nem tudo o que o cliente fala é o que ele
realmente necessita. Precisamos ficar atentos ao que ele
verdadeiramente precisa que seja resolvido, a sua real dor, e em cima
dessa dor conseguir criar soluções que realmente agreguem valor e
resolvam a sua necessidade.
Observe que é possível usar o processo de “Discovery de Produto” não
somente para um produto em si, mas também para criar um processo
ou serviço, pois precisamos sempre “descobrir” o que os nossos
clientes estão precisando, para que possamos ajudá-los nesse caminho
de descoberta. Por isso, “pensar como produto” é importante.

Mas, então, como conseguir identificar isso? Com muito treino e mão
na massa! E é por isso que este e-book trará algumas técnicas
minimamente necessárias para que você e seu time possam descobrir
juntamente com o seu cliente o que valerá a pena ser feito.

Esse processo de descoberta e interações, conforme falamos no

capítulo 2, é chamado de Discovery de Produto.

13
 VI_ DISCOVERY E DELIVERY DE PRODUTO

Delivery de Produto

Agora que descobrimos o problema e a solução que o produto está se

propondo a resolver, precisamos desenvolvê-la e entregá-la para que
possa ser testada e experimentada. A esse processo de
desenvolvimento chamamos de Delivery. É nesse momento em que a
equipe de desenvolvimento (engenharia) vai construir esse produto.
Nesse processo, podem ser consideradas as várias etapas de entregas
desse produto, em que partes podem ser entregues em pequenas
fases (podem receber o nome de iterações ou sprints), para que
possam ser testadas e validadas com nossos usuários (lembre-se do
que falamos no capítulo 4 sobre agilidade), para que o produto possa
ser colocado de fato em produção.

Um ponto importante é: no momento em que se coloca para ser

validado, o conceito de “experimentação” continua sendo válido, ou
seja, se tem algo que precisa ser mudado, temos que mudar
rapidamente, ajustar e novamente apresentar ao usuário para
verificar se o desenvolvimento feito está de acordo com as reais
necessidades previamente identificadas no Discovery.

14
14
VII_ CONTINUOUS DISCOVERY E CONTINUOUS DELIVERY
Teremos em mente que, mesmo executando o processo de Discovery
e Delivery, cada um deles com maestria, não conseguiremos aprender
tudo de uma única vez. Isso significa que, mesmo que você faça o
Discovery e o Delivery, o seu produto não acaba por aqui.
Sempre haverá novas descobertas a serem feitas e atualizações
frequentes de forma sustentável. É por isso que temos uma etapa que
chamamos de Continuous Discovery e Continuous Delivery. Tal etapa
é a continuidade de descobertas e entregas que o time faz após a
entrega da primeira versão do produto (MVP).
Por mais completo que seja, um produto continua tendo evoluções em
todo o seu ciclo de vida, e, para que possamos atender as expectativas
de nossos usuários, temos que dar continuidade aos processos
executados para garantir o encantamento do nosso cliente com o
nosso produto.
Vamos dar um exemplo de dois produtos distintos:
Produto físico
Um exemplo de um produto físico é o iPhone, da Apple.
Quando foi lançado, em 2007, simplesmente revolucionou o mundo
com um produto de que nem sabíamos que precisávamos: o
smartphone! Um verdadeiro computador na palma da nossa mão. Mas
nem por isso a Apple parou de evoluir esse produto. São lançadas
várias versões e modelos, e temos o iPhone cada vez mais robusto e
com mais features periodicamente, levando uma multidão de fãs junto
com a marca. Se a Apple não tivesse uma equipe para fazer um bom
Continuous Discovery e Continuous Delivery, provavelmente o iPhone
não teria tanto sucesso como tem até hoje.
Produto digital
Já como produto digital, temos o exemplo do aplicativo do seu banco.
Você percebe que sempre estão alterando a versão ou colocando
novas features para facilitar a vida de quem tem o banco no aplicativo
do celular? Sempre temos atualizações no nosso internet banking,
onde colocam algumas funcionalidades (e às vezes tiram outras), para
que a equipe de Continuous Discovery possa “medir” a nossa
experiência e entender se está gerando valor àquela experiência.
Tanto é que, em alguns aplicativos de banco, após a atualização de uma
nova versão, sempre nos perguntam o que achamos da mudança. O
Continuous Delivery também é sempre posto à prova e está
continuamente fazendo entregas com códigos com menos erros, boa
performance e mais qualidade.
15
 VIII_ PRODUTO BASEADO EM DADOS
Quando desenvolvemos um produto, este precisa ser medido,
independentemente se é um produto digital ou não. Explicando de
forma simplificada, precisamos ver e acompanhar se o produto está
tendo o sucesso esperado.
Produto físico
Para um produto físico, os dados também são de suma importância,
pois também é dessa forma que se verifica se o produto está tendo
sucesso. E não são só o marketing e a propaganda os responsáveis por
isso. Ele precisa ser o produto certo para um tipo de consumidor, caso
contrário, se tornará obsoleto em pouco tempo.
Alguns exemplos de perguntas que precisam ser respondidas em um
produto físico: como estão as vendas? Os consumidores estão usando
o produto? O estoque está alto ou baixo? Estão comentando sobre
nosso produto de forma positiva ou negativa? Algum site de
reclamação está falando do nosso produto? Aumentou a demanda no
canal de atendimento ao cliente? Estão com muitas dúvidas de como
usar o nosso produto? Novamente, todas essas perguntas podem ser
respondidas por meio de dados – colhidos em relatórios, planilhas,
inventário de estoque, entrevista com usuários, experimentações ao
vivo com os clientes.
16
Produto digital
Existem várias maneiras de medir o sucesso de um produto digital
(aplicativo, website, e-commerce, jogos). Por exemplo, verificar se há
muitos acessos dos usuários, se as pessoas estão comprando, quais
telas os usuários mais acessaram. Qual o percentual de usuários está
clicando no botão comprar? Quais funcionalidades estão sendo mais
usadas? Como estão os comentários? E as avaliações?
Existe uma resposta para todas essas perguntas: dados. E toda pessoa
que trabalha com produtos deve ter em mente: “Contra dados, não há
argumentos!”. Nada adianta desenvolver um aplicativo que, quando se
colhem os dados, percebe-se que não está sendo utilizado ou
comprado por quase ninguém!
Para colher tais dados, é possível usar a tecnologia a seu favor, a partir
de bancos de dados, tagueamento, análises gráficas e mais uma
infinidade de opções que a área pode ajudar colhendo essas
informações.
VIII_ PRODUTO BASEADO EM DADOS

Data Driven

É a partir de todos esses dados coletados que um produto pode ser

modificado, ajustado ou até deixar de existir, dependendo das
informações que serão interpretadas. Esse acompanhamento do
sucesso do produto atualmente é conhecido pelo nome em inglês
“Data Driven” (orientado a dados).

Um produto sempre precisará ser orientado por dados para que

você possa ter as devidas informações sobre ele, para poder
corrigi-lo e ajustá-lo quando necessário e, assim, garantir sua
continuidade e relevância para o uso do seu cliente/usuário.

17
 IX_ AS TÉCNICAS ESCOLHIDAS

Como escolhemos as técnicas do e-book

Também utilizamos alguns templates e exemplos, com dados
Existem centenas de técnicas diferentes no mercado e que estão fictícios, para ajudar na prática a absorver as informações que serão
espalhadas em muitas plataformas de conteúdos (livros, artigos, passadas nas técnicas a seguir.
posts, blogs, podcasts, vídeos). Muitas são de boa qualidade e têm o
propósito de fornecer mais ferramentas para quem deseja criar um
produto. Mas com isso ficam algumas perguntas: de qual delas
preciso e em qual ordem? Qual utilizar primeiro? Qual resultado
esperado dessa técnica?

Já utilizamos na prática várias delas, mas queríamos justamente

escolher algumas técnicas com as quais, de uma forma bem
simplificada, uma pessoa pudesse desenhar o seu produto do início
ao fim. Foi por isso que escolhemos as técnicas que vocês verão nas
próximas páginas.

Tomamos o cuidado de escrever passo a passo. Fizemos também de

uma forma ordenada, mas você perceberá que, ao começar a
utilizá-las, não precisará seguir uma sequência lógica, pelo
contrário, poderá utilizá-las na ordem que precisar, e isso que é o
legal em produtos: usar o que for necessário e quando necessário.

18
X_ COMO USAR AS TÉCNICAS?

DISCOVERY links para o

O selo indica
template do
a fase do ciclo O que esperar de
IDEATION O motivo para board e exemplo
em que a Visão geral de resultados após fazer
usar a técnica (quando houver)
técnica se DELIVERY como fazer a técnica. Possíveis
encontra: links para outras
técnicas

Acesse o MIRO para Entenda o que é

a técnica Informações que ajudam a definir o escopo da dinâmica. Ex.: se for uma atividade
todos os templates e que leva muito tempo, precisa alinhar com os participantes o comprometimento
exemplos das que terão ao participar dela. Assim como o nível de aplicabilidade. Caso seja mais
técnicas abordadas no fácil, demanda menos esforço e comprometimento, o contrário também é
livro: verdadeiro. Também serve para priorizar uma atividade em detrimento de outra,
caso haja pouco tempo hábil para fazer o Discovery

19
XI_TÉCNICAS
TÉCNICA 1
ASSESSMENT
O QUE É?
O assessment (briefing inicial) é a primeira
etapa para conhecer todo o contexto que
envolve o "produto ou projeto" que vamos
iniciar. Essa técnica serve para levantar as
características básicas necessárias, como os
desafios macro, as dores, as pessoas
envolvidas, os fluxos e, também, conhecer as
relações e histórico de acontecimentos.
COMO FAZER
De forma colaborativa, os participantes irão praticar a técnica, agrupando idéias afins e
registrando o que ficou definido. Não existe uma técnica específica para fazer o
assessment; algumas pessoas preferem usar as perguntas do 5W2H: 5W – What (o que
será feito?) – Why (por que será feito?) – Where (onde será feito?) – When (quando?) –
Who (por quem será feito?) 2H – How (como será feito?) – How much (quanto vai custar?),
que serão respondidas pelo grupo, outras preferem fazer uma entrevista e usar as respostas
para puxar mais informações. Um ponto-chave é levantar o maior número possível de
informações sobre a situação-problema e entender que do outro lado existe uma pessoa
com dores, necessidades e vontades. Por isso é interessante começar perguntando um
pouco sobre a pessoa, sua vida, experiências, até achar os caminhos do produto/projeto
durante essa conversa.
21
 TÉCNICA 1: ASSESSMENT

POR QUE USAR

É importante fazer o assessment porque abre várias

possibilidades de como abordar o trabalho, além de mostrar de
uma forma geral as características do negócio e alguns pontos PARTICIPANTES MATERIAIS
que podem ser muito úteis na execução do projeto.
Product Manager, Miro, Figma, Draw.io,
Stakeholders, UX e PowerPoint
RESULTADOS ESPERADOS quem mais for
necessário
Não há um resultado específico em um assessment, mas alguns
pontos para mapear e levantar são: stakeholders,
macrojornadas, datas e marcos importantes, informações
relevantes, notícias, concorrentes, modelo de negócios,
investidores, necessidades, dores, primeiras impressões,
história atrelada. Esses pontos fazem parte de um bom
assessment e devem estar registrados de forma visual e
organizada em algum repositório. Sugerimos uma ferramenta de TEMPO APLICABILIDADE
colaboração online para que o time possa consultar e usar a 1 a 2 horas Fácil
qualquer momento.

22
TÉCNICA 1: ASSESSMENT

exemplo no miro

_ Exemplo: gympass

23
 TÉCNICA 2
NUVEM DE PALAVRAS
O QUE É?
A nuvem de palavras (word cloud) é uma
ferramenta no formato de gráfico digital que
mostra a frequência das palavras em um texto.
Quanto mais a palavra é utilizada, mais
chamativa é a representação dessa palavra no
gráfico. Essa dinâmica é usada no Discovery do
produto e a qualquer momento durante a
jornada (continuous Discovery/Delivery),
inclusive para comparar o antes e depois. Pode
ser direcionada a vários aspectos, como
entendimento do processo, comportamento e
propósito do time.
24
COMO FAZER
Uma boa forma de fazer essa técnica é juntar o grupo e pedir para descreverem em uma
palavra o sentimento deles em relação a uma pergunta. Exemplos: "O que você espera do
processo de Discovery do produto x?"; "Para você, qual o propósito do Produto x?" ; "O que
é mais importante na formação de um time?".
Podemos fazer uso de um gerador de nuvem de palavras colaborativa online, em que cada
pessoa colocará a palavra que descreve melhor o sentimento em relação à pergunta.
Também podemos usar um editor de texto compartilhado, em que cada um colocará suas
palavras e, depois, o facilitador passará essa lista para uma ferramenta geradora de nuvem
de palavras.
Se preferir usar um board, o grupo receberá post-its para serem colocadas as palavras, e o
facilitador seguirá com a clusterização para montar a nuvem de palavras.
TÉCNICA 2: NUVEM DE PALAVRAS

site para gerar nuvem de palavras

(mentimeter)

POR QUE USAR

Esta dinâmica mostra a evolução do time na jornada do
produto, pois pode ser repetida em diversos momentos.
PARTICIPANTES MATERIAIS
Também permite que transpareçam sentimentos comuns a
todos do grupo e a cultura implícita vivida por eles. Product Manager, Editor de texto, post-
Tech Lead, Team its ou geradores de
members, UX, UI, nuvens como a world
RESULTADOS ESPERADOS Stakeholders, clouds, mentimeter
Developers
Esperamos que, com essa atividade concluída, o time possa ter
registrado os sentimentos principais em relação a algum
tema e, com base nisso, possa trabalhar olhando para esses
pontos. Ex.: numa dinâmica em que a pergunta seja “Qual o
sentimento do time em relação ao trabalho da squad? Se as
palavras em maior destaque são negativas, isso é um sinal
claro para os líderes agirem a fim de melhorarem a cultura no TEMPO APLICABILIDADE
grupo.
20 min Fácil

25
 TÉCNICA 3
LEAN CANVAS
O QUE É?
Essa é uma técnica muito útil para se criar um
produto/negócio quando não se sabe por onde
começar! O Lean Canvas auxilia a validar a
hipótese, a partir do preenchimento ordenado
de um quadro dividido em nove partes
(denominado blocos). Para além da criação de
um produto ou serviço, essa técnica é utilizada
também para a criação de startups.
O Lean Canvas não é preenchido de uma única
vez. É natural que se preencha conforme as
iterações e inceptions que forem sendo feitas
com o time durante o processo. É importante
marcar reuniões de pelo menos 1 hora para
finalizar/ajustar o canvas.
26
COMO FAZER
Como foi dito, o Lean Canvas deve ser preenchido seguindo a numeração de cada bloco, de 1
a 9. O preenchimento não segue uma ordem visual padrão, mas ao final a leitura do board se
apresenta, de forma estratégica, da esquerda para a direita. Os participantes irão
desenvolver a técnica agrupando ideias afins e registrando o que ficou definido.
Bloco 1: Segmento de Clientes
Você sabe quem são os seus clientes em potencial? Qual o perfil deles? Para quem o seu
produto será primordial? Quais as características do seu cliente ideal?
É preciso saber quais são os seus clientes e quais usuários utilizarão o seu produto. Sem uma
definição clara de para quem irá desenvolver, talvez o produto deva ser repensado ou mesmo
nem deva ser iniciado, afinal, sem resolver os problemas do cliente, o produto perde o sentido
de existir.
Bloco 2: Problemas
Neste bloco, devem ser colocados quais são os principais problemas que o seu produto irá
resolver.
TÉCNICA 3: LEAN CANVAS

COMO FAZER
Bloco 3: Proposta de Valor
Você poderá colocar três principais problemas
Todo produto precisa ter um valor! E o cliente tem que perceber que o produto que está
a serem resolvidos, podendo variar para mais
sendo criado pode trazer algum benefício tangível para ele! Para isso, você precisa colocar
ou menos, se necessário. Lembre-se: um
neste bloco uma mensagem clara e objetiva de como ajudará seus potenciais clientes a
produto precisa ser feito para resolver um
resolverem os problemas deles. Lembre que valor é diferente de preço.
problema, sob o risco dele nascer malsucedido!

Uma seção que pode ser colocada dentro do
Bloco 2 é “Alternativas Existentes”. Nessa
seção, podem ser colocadas as alternativas
existentes no mercado para que esses
problemas possam ser resolvidos. Dessa
forma, o grupo deverá descrever cada uma
delas, além das que seu produto deseja criar.
Bloco 4: Solução
Neste bloco você deve colocar qual a característica que o produto terá de forma a solucionar
o problema.
É importante descrever os atributos para que todos possam, facilmente, saber as
características fortes que o produto terá para solucionar o problema.

27
 TÉCNICA 3: LEAN CANVAS
COMO FAZER
Bloco 5: Canais
O bloco Canais é onde deverá ser colocado
quais caminhos serão usados para chegarmos
até os os usuários do produto. Será por um
website, e-mail, aplicativo mobile? Ou poderia
ser por carro de som, chamada em rádio ou
propaganda no You Tube?
Enfim, quais serão os canais utilizados? Lembre
que os canais variam de produto a produto,
podendo ser totalmente diferentes, mas
somente deverá ser colocado aqui o que fizer
sentido para o produto.
28
Bloco 6: Fontes de Receita
De nada adianta termos um produto maravilhoso que não gere receita. É preciso deixar
explícito como essa receita será gerada, para viabilizarmos a criação do produto.
Há várias formas de gerar receita com um produto, desde uma venda direta ao cliente,
assinatura (se for um produto digital), passando por visualizações, até ser parte de um outro
produto vendido (combo).
Bloco 7: Estrutura de Custos
No bloco de Estrutura de Custos, você deverá mostrar quais custos terá para desenvolver o
seu produto. Os custos podem ser diversos, como de pessoal, transporte, fornecedor,
aquisição de hardware e equipamentos de infraestrutura geral, softwares de apoio etc.
Nesse momento não precisa entrar em níveis de detalhes de qual valor será gasto, mas
deve-se listar, de preferência, todos os custos que você imagina ter no desenvolvimento do
seu produto.
TÉCNICA 3: LEAN CANVAS

COMO FAZER
No caso específico de um produto digital, existe uma série de métricas, por exemplo: taxa de
Seja transparente! Muita gente tem mania de
conversão (desde um clique pra conhecer o produto até o momento em que o usuário de
“maquiar” custos ou receitas para ganhar no
fato o compra para usá-lo), quantidade de novos clientes por mês, likert (likes e deslikes),
pitch (para que o projeto seja aprovado por um
mapa de calor, monitoramento da mídia, índice de reclamações etc.
comitê executivo). Nunca minta, pois o seu
produto e o time ficariam desacreditados.
Um fator importante em métricas ;;;é você utilizar (e muito!) o pessoal de dados, pois é com
base real nos dados que conseguirá saber se o seu produto está indo no caminho certo,
Bloco 8: Métricas-Chave
Não tem valor fazer um produto e não saber se afinal: contra dados não há argumentos!
ele está fazendo sentido/sucesso entre os seus
usuários! É por isso que neste bloco deve ser Bloco 9: Vantagem Competitiva
colocado como serão as métricas principais Pode não ser uma boa ideia fazer um produto que é exatamente mais do mesmo! Então,
para que você possa saber se o seu produto você precisa mostrar o quão diferente o seu produto é dos demais e o quanto de valor ele
está fazendo sentido ou se precisa ser pode proporcionar para as pessoas. É nesse momento que deverá parar e refletir se está
melhorado/evoluído. fazendo algo realmente relevante e não somente “porque a concorrência já tem!” Tenha em
; mente que um usuário só irá usar o seu produto se ele realmente vir algum valor a mais,
caso contrário, não deixará de usar o já existente para usar o seu.

29
 TÉCNICA 3: LEAN CANVAS

POR QUE USAR

Ter um Lean Canvas é item obrigatório para qualquer time que
vai desenvolver um produto. Esse é o norte para que todos os
PARTICIPANTES MATERIAIS
envolvidos possam estar cientes de para onde devem seguir.
Quando falamos todos os envolvidos, são todos mesmo: desde PM e todos os Miro para times
o desenvolvedor até o sponsor do seu projeto. envolvidos no remotos.
produto presencialmente,
quadro branco e
RESULTADOS ESPERADOS
post-its
O Lean Canvas é uma técnica que gera um quadro com várias das
características mais importantes sobre o produto/ideia que
estamos trabalhando. Esse quadro deve ficar visível em um
repositório de fácil acesso e que se possa editar. O canvas é vivo;
sempre que possível, deve-se atualizá-lo. Ele deve ser sempre
consultado antes de realizar as atividades, para que essas
tenham resultados conectados com a Proposta de Valor TEMPO APLICABILIDADE
desenhada. 1 a 2 horas Difícil

30
TÉCNICA 3: LEAN CANVAS

template lean canvas

_ Exemplo: gympass
exemplo no miro

31
 TÉCNICA 4

RISCOS DE PRODUTO

O QUE É?
Risco de Valor:
Nessa técnica, vamos levantar com o time de
Os usuários veem valor no produto a ponto de usá-lo? Existe demanda suficiente por aquele
Discovery se o produto é viável respondendo a
determinado produto/feature? Ele resolve uma dor real?
estes quatro riscos:

Risco de Viabilidade:
O que queremos construir é tecnologicamente
viável? Temos a arquitetura necessária para
construir o que queremos? Temos o tempo
necessário para construir o que queremos?
Temos/conseguimos ter a infra disponível para
lidar com a escala?
Risco de Usabilidade:
Os fluxos pensados pelo time de produto são bons/simples o suficiente para o usuário
entender? A interface faz sentido e ajuda o usuário a finalizar sua tarefa?
Risco de Negócio:
O custo de produção e venda do seu produto é menor do que a receita que ele gera? Seu
produto/feature causa algum impacto negativo à empresa (imagem, marketing, vendas,
jurídico, etc.)?

32
TÉCNICA 4: RISCOS DE PRODUTO

COMO FAZER
De forma colaborativa, os participantes irão
praticar a técnica, agrupando ideias afins e
registrando o que ficou definido. A primeira coisa
que devemos fazer é avaliar o risco de negócio.
Essa avaliação é tão importante que pode
inviabilizar totalmente o produto. Devemos
avaliar com alguns stakeholders como marketing,
vendas, financeiro, jurídico se o produto está
alinhado com o negócio da empresa. Se há
viabilidade jurídica, compliance, financeira para o
seu desenvolvimento.
O custo de produção é menor do que a receita
esperada? Proporciona risco legal ao negócio?
Algum produto existente será afetado? É um
produto/feature que vai contra os valores da
empresa?
Essas perguntas e tantas outras devem ser respondidas, em conjunto, pelas áreas da
empresa.
Caso já exista um produto, será testada a usabilidade no produto atual, ou, caso ainda não
exista, em um protótipo de baixa ou alta fidelidade (se considerar necessário). Com isso,
conseguiremos avaliar: o usuário conseguiu realizar a tarefa com facilidade e sem ajuda? O
usuário teve dificuldades mas conseguiu realizar a tarefa? Ou o usuário não entendeu como
o produto funcionava e não conseguiu realizar a tarefa?
Também é importante avaliar o risco de valor, fazendo alguns testes qualitativos: quanto o
consumidor estaria disposto a pagar e indicar o produto/funcionalidade? E, também, testes
quantitativos, como testes A/B, e convidá-lo para testar versão beta, por exemplo.
Por último, devemos avaliar a viabilidade. O time precisa dedicar tempo para entender a
viabilidade do produto/funcionalidade e responder algumas perguntas: sabemos
desenvolver isso? Temos as habilidades para desenvolver isso? Temos tempo para
desenvolver isso? Como isso influencia nossa infraestrutura atual? Teremos problemas de
performance? Isso é escalável?

33
 TÉCNICA 4: RISCOS DE PRODUTO

POR QUE USAR

Avaliar os riscos nos ajuda a determinar se o produto a ser criado
poderá gerar valor e estará alinhado com o negócio da empresa.
Imagine que um ou mais riscos são altos! Será importante avaliar
se é possível mitigar o risco ou se o desenvolvimento do produto PARTICIPANTES MATERIAIS
é inviável. Product Manager, Miro, Figma,
PowerPoint
Tech Lead, UX, UI,
RESULTADO ESPERADO Stakeholders

Teremos os riscos mapeados ou resolvidos em relação a cada um

dos quatro campos e analisaremos quais terão que ter mais
atenção para serem mitigados ou eliminados. A expectativa é
que, com o passar do tempo, esses campos sejam atualizados,
sejam resolvidas as dúvidas, geradas outras, e tenhamos insumos
para nortear os rumos do produto até a criação/evolução do
Lean Canvas.
TEMPO APLICABILIDADE
Inclusive deve-se levar em consideração que, dependendo do 2 a 16 horas Média
risco, pode-se chegar à conclusão de que será preciso alterar
significativamente o rumo do produto.
34
TÉCNICA 4: RISCOS DE PRODUTO
template 4 riscos

exemplo no miro

_ Exemplo: gympass

35
 TÉCNICA 5
BRAINSTORMING
O QUE É?
O brainstorming, do mineirês "Toró de
Parpites", é uma dinâmica de grupo em que
várias pessoas lançam suas ideias "na mesa"
(seja de forma escrita ou falada). Essas ideias
podem ser dores, soluções ou problemas que
cada usuário identifica como importantes. A
missão do brainstorming é aumentar a
quantidade de possíveis "palpites" sobre
determinado ponto ou discussão.
36
COMO FAZER
Na prática, temos dois tipos de brainstorming: o individual, que recebe o nome de
braindumping, e o coletivo, que chamamos de brainstorming. Ambos têm o mesmo intuito,
que é aumentar a quantidade de ideias/palpites.
O braindumping é recomendado para aumentar, numericamente, sem a interferência de
outras pessoas ou discussão, a quantidade de propostas. Recomendamos que seja feito de
forma escrita e em post-its, para gerar várias ideias.
O Brainstorming pode ser falado ou escrito. Quando falado, deve-se atentar para que os
participantes não cortem as ideias uns dos outros, para que elas possam fluir em
quantidade.
Fazer um brainstorming após um braindumping é interessante para levantar tudo que foi
pensado individualmente, deixando fluir uma discussão superficial sobre as propostas. O
resultado dos dois será o aumento significativo das ideias, mesmo que elas possam não ter
uma ligação clara ou contexto definido com a proposta inicial.
TÉCNICA 5: BRAINSTORMING

POR QUE USAR

É uma ferramenta muito utilizada para abrir o funil – uma
metáfora para gerar novas ideias. É indicado para quando PARTICIPANTES MATERIAIS
precisamos pensar "fora da caixa", aumentando a possibilidade Product Manager, Miro, Figma ou
de inovações.
Stakeholders, UX e post-its
quem mais for
RESULTADOS ESPERADOS necessário

Teremos várias ideias geradas após a realização do

braindumping e do brainstorming. O ideal nesse momento é
aplicar alguma técnica de agrupamento (clusterização), e na
sequência usar uma técnica de priorização, como o Dot
Voting, que será apresentado mais à frente, ou até mesmo uma
Matriz de Priorização, que também será abordada neste
e-book. Depois de organizado o brainstorming, podemos TEMPO APLICABILIDADE
pensar em possíveis desdobramentos, por exemplo, uma 1 hora Fácil
pesquisa em cima dos itens levantados.

37
 TÉCNICA 5: BRAINSTORMING
template brainstorming

exemplo brainstorming no miro

_ Exemplo: gympass
exemplo pós-brainstorming no miro

38
TÉCNICA 6

PREPARO DE PESQUISAS

O QUE É?
Alguns tipos de pesquisas:
Antes de fazer a pesquisa, deve-se determinar o
. Quantitativa: normalmente são perguntas de múltipla escolha, cujos resultados, ao serem
objetivo e quem são as pessoas que serão
analisados, geram dados numéricos que representam a qualidade daquela pesquisa.
estudadas. Algumas dicas de como fazer uma boa
Ex: Qual a sua idade ?
pesquisa:
o Entre 20-30 anos
. Apresente-se e deixe claro que o ambiente é
o Entre 31-50 anos
seguro para o entrevistado, e também assegure o
. Qualitativa: são pesquisas para coletar emoções, insights. Normalmente são usadas
anonimato dele.
perguntas abertas, nas quais o usuário pode contar um pouco do que deseja, do que gosta,
. Deixe claro quais são os objetivos da
do que viu, suas dores em relação ao tema, entre outros sentimentos que vierem à tona.
pesquisa/entrevista.
Ex: O que você achou da sua experiência com esse produto?
. Não sobrecarregue o entrevistado com
. Exploratória: são pesquisas que tendem a explorar algum conteúdo ou ideia de forma a
perguntas em excesso.
descobrir mais informações sobre aquele tema específico.
. Inclua uma mistura de perguntas de sim-não,
Ex: A qual gênero de cinema o usuário gosta de assistir?
múltipla escolha e perguntas abertas.
. Validação: são pesquisas com a finalidade de validar determinada informação.
. Certifique-se de utilizar perguntas claras, de fácil
Normalmente são usadas quando já temos uma solução ou ideia em mente e precisamos
entendimento e sem vieses.
validar a proposta.
. Informe o tempo estimado da pesquisa.
Ex: O nosso usuário gosta de assistir a filmes de terror?

39
 TÉCNICA 6: PREPARO DE PESQUISAS

COMO FAZER
Há diversos formatos para fazermos pesquisas: . Perguntas de satisfação do cliente: avaliação do valor do produto/serviço com relação aos
formulários online, e-mail, entrevistas ao vivo, seus custos, fidelidade à marca, indicação do produto.
por telefone, por videoconferência etc. O mais . Perguntas sobre a experiência do cliente com o produto: navegação, melhorias na
importante é escolher o melhor formato que experiência, preço, FAQ, descrição das funcionalidades/produtos.
atende ao cliente. . Perguntas sobre a experiência do cliente com a concorrência: já conhecia o produto, o
Além disso, o roteiro deve estar pronto e pode porquê da escolha do nosso produto/serviço, nosso produto é melhor ou pior que o dos
ser dividido por categorias, e as perguntas concorrentes, segue nas redes sociais, em quais plataformas? Você lê nosso blog e/ou está
precisam estar alinhadas com o objetivo inscrito para receber nossas newsletters?
traçado.
Listamos aqui alguns temas que podem ajudar Não se limite aos exemplos acima e sempre estude quais perguntas fazem sentido para a
a estruturar as perguntas. pesquisa que precisa fazer.
. Perguntas demográficas: nome, e-mail, idade,
moradia, profissão, estado civil.
. Perguntas sobre o uso do produto:
frequência de uso, funcionalidade preferida,
eficiência para o negócio, recomendação,
melhorias.

40
TÉCNICA 6: PREPARO DE PESQUISAS

template roteiro

POR QUE USAR

Os feedbacks nos ajudam a melhorar a jornada do cliente.
Essas informações facilitam a identificar os pontos fortes e PARTICIPANTES MATERIAIS
fracos, a melhorar o atendimento ao cliente, a desenvolver Stakeholders, gravador, planilha,
novos produtos e serviços, a descobrir e fornecer o que seu editor de texto,
Sponsors, Product
público-alvo quer e a crescer como empresa.
Manager, Tech Lead, Google form,
UX, UI, Data Analytic, Typeform
RESULTADO ESPERADO Developers, People
Research
O resultado esperado do preparo das pesquisas é que o time
tenha definido quem é o público para o qual será realizada a
pesquisa, além de quais as motivações e o tipo de pesquisa.
Também quais as perguntas e, posteriormente, os resultados
esperados dela, pois na etapa seguinte iremos consolidar seus
TEMPO APLICABILIDADE
dados.
1 hora Difícil

41
 TÉCNICA 7

CONSOLIDAÇÃO DE PESQUISAS

O QUE É?
Quando realizamos pesquisas, nos deparamos
Interpretações: após a documentação das
com um mar de informações que irão gerar
evidências, será possível interpretar os
insights para ações futuras. Por isso, elas
dados e anotar os insights obtidos,
devem estar compiladas para podermos
inferindo os porquês de cada
acessar, em algum momento, de forma rápida e
comportamento, sentimento ou
lógica.
necessidade observada. Elas podem ser
associadas a uma ou mais evidências e
Podemos organizar as informações que
também podem ser clusterizadas.
coletamos nas pesquisas por categorias,
divididas em evidência (ou fatos),
Conclusões: são constatações, padrões
interpretações (ou insights) e conclusões (ou
percebidos que geram hipóteses a serem
recomendações):
levantadas.
Evidências: dados que podem ser
documentados e não dão margem a
interpretação. Esses dados devem ser
clusterizados (agrupados) segundo critérios
pré-estabelecidos.

42
42
TÉCNICA 7: CONSOLIDAÇÃO DE PESQUISAS

COMO FAZER
Colocar todas essas informações de forma
lógica e de fácil acesso demanda esforço. O
ideal é separarmos um bom tempo para acessar
o material dessas pesquisas. Desenhar um
mapa mental pode ajudar a organizar/agrupar
as respostas por tema, sentimentos,
expectativas e percepções.

Uma estratégia legal para organizar essas

informações é criar um quadro num dashboard
ou num arquivo Excel. Podemos até gerar
gráficos que ajudarão no entendimento dessas
informações!

43
 TÉCNICA 7: CONSOLIDAÇÃO DE PESQUISAS

POR QUE USAR

Compilar pesquisas é uma parte importante para organizar
todas as informações colhidas do cliente. Aqui conseguimos PARTICIPANTES MATERIAIS
captar quem é nosso cliente, como ele age, quais são suas Product Manager, UX, Miro, Excel, planilha
principais dores e expectativas. A partir disso, fica mais fácil
UI, Data Analytic, Google
validar hipóteses, derrubar certezas e mitigar riscos do
produto. Business Analyst,
People Research

RESULTADO ESPERADO
O resultado esperado da consolidação é relativo a cada tipo de
pesquisa que foi feito, mas de uma forma geral podemos
pensar que a pesquisa deve se desdobrar em “Novos
Caminhos” que serão validados e pesquisados. “Validação de
Hipóteses" são pontos que foram validados e que vamos TEMPO APLICABILIDADE
continuar evoluindo (e pontos que não foram validados e que 4 a 20 horas Difícil
servem de aprendizado), além de dados e informações que
servem para nortear os próximos passos.
44
TÉCNICA 8
PROTO-PERSONAS
O QUE É?
A proto-persona é um conjunto de
informações formuladas pelo time que, quando
agrupadas, mostram como imaginamos que o
nosso usuário é.
Para fazermos a técnica, devemos revisitar o
Lean Canvas, no bloco de segmentos de
clientes, para termos o ponto de partida sobre
quem será nossa persona. Ela não é
necessariamente uma só, podendo ser
representada por mais de uma pessoa.
O objetivo final da proto-persona é entender
melhor o público e saber como o produto
poderá, de fato, agregar valor na vida das
pessoas.
COMO FAZER
Para aplicarmos a proto-persona na prática, precisamos primeiro entender um pouco do
contexto do nosso produto. Em segundo lugar, nos colocar no lugar desses usuários e
começar a entender quais características desse usuário são importantes.
Para esse processo, podemos reunir o time e usar o framework que contenha,
minimamente: nome, idade, sexo, trabalho, relacionamento, formação, do que gosta, do que
não gosta. Durante a dinâmica, cada um pode ir escrevendo ou falando o que acredita que
sejam as características desse usuário. Pode-se começar a fazer perguntas mais abertas de
como ele se sente, pensa, dores, ganhos, até chegar nas mais específicas, a fim de facilitar a
visualização da persona. Durante o processo, o grupo vai organizar as ideias, e o resultado
esperado é a criação de uma persona que representa o usuário ideal do nosso produto e que
tenha as características que pensamos para ele.
Depois que a proto-persona é pensada pela equipe, podemos validar as informações que
foram levantadas em campo com a que desenhamos. Com a entrevista com os usuários e
usando as bases de dados que temos, criamos uma persona com dados estatísticos, ainda
mais parecida com a realidade.
45
 TÉCNICA 8: PROTO-PERSONAS

POR QUE USAR

A persona é uma técnica muito forte para o contexto de venda
e oferta do produto – já que com a persona mapeada, podemos PARTICIPANTES MATERIAIS
moldar o linguajar, a forma de comunicar e até as ferramentas Todos os envolvidos Miro, Google
que o nosso produto pode ter, pois cada característica
no produto
levantada dá insights de como entregar o produto certo para
o cliente certo.

RESULTADO ESPERADO

Com a aplicação desta técnica, será possível ter uma visão

muito mais próxima do usuário real, pois se estará
desenvolvendo o produto, já pensando na proto-persona criada TEMPO APLICABILIDADE
com características de uma pessoa real, e voltado para o 1 a 2 horas Fácil
público que se deseja alcançar.

46
TÉCNICA 8: PROTO-PERSONAS

template persona

_ Exemplo: gympass exemplo no miro

47
 TÉCNICA 9
JORNADA DO USUÁRIO
O QUE É?
Essa técnica faz um mapeamento das
interações do usuário com um produto ou
serviço em todas as fases dessa jornada (antes,
durante e depois do uso), sob seu ponto de
vista, seus sentimentos e sensações. É
importante que essa história seja contada
pelo usuário do início ao fim!
Nesse momento, serão capturadas a vivência,
pontos de atrito e encantamento do usuário
com o produto ou serviço.
Lembre-se! A jornada não são requisitos, e,
sim, a experiência do usuário com o produto!
48
COMO FAZER
No caso de ser um produto novo, a jornada será contada pelas pessoas de negócio, com a ajuda
do PM, UX e Desenvolvedores trazendo suas percepções por meio de pesquisas de como o
produto irá resolver um problema X.
Se for um produto existente, o ideal é termos a persona já definida. A partir disso, é necessário
chamar o cliente para participar dessa jornada e contar passo a passo sua interação com o
produto. Uma boa forma de desenharmos isso é criando um fluxo detalhando cada etapa.
Deverão ser feitos dois fluxos: o primeiro é um fluxo com base na situação atual na qual o
usuário se encontra (as is), e o segundo fluxo deve ser feito sob o olhar dos participantes: será
desenhado o fluxo de como gostaríamos que fosse a interação do usuário com o produto X (to
be). A partir dessas novas ideias, pode-se usar a técnica Dot Voting para refinar ainda mais
como deveria ficar o novo fluxo (to be).
Entre um fluxo e outro, pode ser feita a técnica Como Poderíamos (CP) em cima das Dores da
Jornada (as is) e depois construir a Jornada (to be) com os insights trazidos por essa técnica.
TÉCNICA 9: JORNADA DO USUÁRIO

COMO FAZER
Há várias formas de se desenhar uma jornada,
. Quais são as principais dores que o usuário tem ao utilizar o produto? O app não abre, o site
mas alguns elementos são importantes de
não carrega? Não consegue realizar a compra?
trazermos:
. Qual ação finaliza a relação do usuário com o produto? É a indicação do produto para um
amigo? É o preenchimento de uma avaliação?
. Existe mais de um tipo de cliente? Quem é a
. O que foi observado sobre possíveis oportunidades nessa jornada? Em conjunto com o time,
persona da sua jornada?
discuta o que pode ser melhorado, suprimido e implementado para uma experiência mais rica
. Construa um storytelling de como é a
para o usuário.
experiência do usuário antes, durante e depois
da interação com seu produto.
Não caia nestas armadilhas:
. Em quais lugares essa trajetória acontece?
. Não infira comportamentos ao seu usuário, sempre baseie suas premissas em estudos e
Mapeie os pontos de contato do usuário com o
pesquisas.
seu produto. Em casa, no trânsito, num
. Trabalhe de forma colaborativa, compartilhando informações. Tentar desenhar uma jornada
estabelecimento?
sozinho o levará a vieses que serão difíceis de contornar.
. O usuário precisa interagir com pessoas para
. Não antecipe etapas do processo. Levante o maior número possível de insumos até chegar a
acessar seu produto? Quais são elas? Como se
uma versão aceitável da jornada do usuário.
dá essa interação?

49
 TÉCNICA 9: JORNADA DO USUÁRIO

POR QUE USAR

Perceber como o usuário interage com o produto nos ajuda a
mapear as principais falhas e pontos de melhoria que irão PARTICIPANTES MATERIAIS
gerar insights para essa jornada. Clientes, especialistas Miro, Figma, Power
nas ferramentas Point ou Draw io.
utilizadas, PM, UX, Algumas ferramentas
RESULTADO ESPERADO Tech Leader, têm um template
Stakeholders para construção da
Espera-se que o time possa ter uma visão real de todo o
jornada
processo de uma forma visual e detalhada e que consiga
enxergar as oportunidades em que o produto pode se encaixar
para resolver o problema dos seus usuários nesta jornada.
Essa "espinha dorsal” será utilizada durante todo o
desenvolvimento do produto, já que, toda vez que for preciso
tirar dúvidas sobre um contexto específico, nada será melhor
do que entrar na jornada do usuário e refrescar a memória
lembrando de como o usuário realmente faz no seu dia a dia.
TEMPO APLICABILIDADE
2 a 4 horas Difícil

50
TÉCNICA 9: JORNADA DO USUÁRIO

template jornada do usuário

_ Exemplo: gympass
exemplo no miro

51
 TÉCNICA 9: JORNADA DO USUÁRIO

_ Exemplo: gympass

52
TÉCNICA 10
APLICAÇÃO DE DOT VOTING
O QUE É?
O Dot Voting é uma técnica de facilitação,
baseada em cumulative voting, utilizada para
priorização colaborativa. Ela pode ser utilizada
em vários momentos na atividade de
facilitação, quando um PM precisa decidir
juntamente com o time a priorização de
alguma atividade, feature ou até mesmo um
assunto importante.
No caso do Dot Voting nas Dores da Jornada, o
time irá votar na escolha das principais dores
ou oportunidades que foram mapeadas
durante a jornada do usuário.
COMO FAZER
Cada integrante do time terá direito a três ou mais votos.
Liste as atividades, tópicos, temas que precisam ser votados, e coloque no quadro (pode ser no
Miro ou em post-its, em caso presencial).
Faça uma explicação de forma breve de cada um dos itens que serão votados.
Conte os votos recebidos para cada item; aqueles que receberem mais votos são os mais
prioritários.
Os votos devem ser únicos para cada atividade escolhida (usar todos os votos em uma única
atividade só pra ganhar votos não vale!).
Voto de minerva – Em alguns casos podemos ter um voto de ouro (ou voto de minerva), que é
dado ao líder/sponsor do produto/projeto. Isso serve para priorizações de desenvolvimento
ou de algo importante que precisa ser feito, independentemente da votação dos demais
integrantes. Esse voto é único e pode ser inserido pelo líder uma única vez em uma votação,
mas terá o maior peso para aquele item a ser votado.
53
 TÉCNICA 10: APLICAÇÃO DE DOT VOTING

POR QUE USAR

A técnica de Dot Voting é muito usada para os casos em que
precisamos que o time tome decisões em conjunto, PARTICIPANTES MATERIAIS
principalmente para evitar discussões improdutivas. De forma Persona, especialistas Post-its, selos
democrática, essa técnica resulta no progresso e na
nas ferramentas
priorização das atividades do time.
utilizadas, PM, UX,
Tech leader, Devs,
Stakeholders
RESULTADO ESPERADO

O time terá como resultado o que está sendo considerado

mais importante, coletivamente, nesse processo de votação.
Será mais fácil tomar decisões em grupo, de forma
democrática, evitando interesses pessoais de um ou outro TEMPO APLICABILIDADE
participante após a votação. Resumindo, os itens mais
20 min Fácil
votados serão analisados primeiro para decidir quais ações
serão tomadas.

54
TÉCNICA 11
COMO PODERÍAMOS (CP)
O QUE É?
Como Poderíamos (CP) é um exercício criativo
de sugerir hipóteses para solucionar
problemas/ oportunidades encontradas após a
aplicação do Dot Voting na Jornada do
Usuário.
Essa técnica tem um bom aproveitamento se
for aplicada após o Dot Voting da Jornada do
Usuário (as is), pois trará insights para a
construção da Jornada do Usuário (to be).
COMO FAZER
A ideia é fazer perguntas amplas, sem conduzir os participantes para uma solução
específica. Cada pergunta deve seguir o modelo: “Como nós poderíamos + verbo (por
exemplo, melhorar), + substantivo (por exemplo, o onboarding) + o tipo de usuário (por
exemplo, da persona X).
Usando o exemplo anterior: "Como poderíamos melhorar o onboarding do cliente?". Os
envolvidos na dinâmica irão criar sugestões de como esse problema poderia ser abordado.
O facilitador deverá ler e pedir para cada um explicar suas sugestões, e essas devem ser
agrupadas por categorias. Após essa fase, pode ser rodado um novo Dot Voting, a fim de
excluir as hipóteses não aderentes ao produto/serviço.
55
 TÉCNICA 11: COMO PODERÍAMOS (CP)

POR QUE USAR

Ao utilizar as notas Como Poderíamos, transformamos as
afirmações em questionamentos. De forma colaborativa (visão PARTICIPANTES MATERIAIS
multidisciplinar do time), podemos construir insights e PM, pessoas de Miro, Figma, post-its
hipóteses para a solução do problema.
negócio, team
members, Tech
leader
RESULTADO ESPERADO

Com a aplicação desta técnica, o time trará uma uma série de

ideias/soluções para os problemas apontados. Algumas ideias
serão menos relevantes, e outras, mais interessantes; a partir daí
poderão ser aplicadas técnicas de priorização como o Dot
Voting ou a Matriz Valor X Esforço (próxima técnica) para
TEMPO APLICABILIDADE
decidir quais dessas ideias poderão ser mais detalhadas com o
grupo. Após a priorização, recomendamos que o time escreva as 1 hora Média
Histórias de usuários (técnica 13), que posteriormente poderão
ser organizadas no Roadmap (técnica 14).
56
TÉCNICA 11: COMO PODERÍAMOS (CP)

exemplo no miro
_ Exemplo: gympass

57
 TÉCNICA 12

MATRIZ VALOR X ESFORÇO

Tarefas que geram Atividades igualmente

mais resultados com importantes, mas de
menor esforço. Essas muita dificuldade.
ações devem ser
O QUE É?
Demandam um time já
priorizadas por
maduro, exigem alto
serem mais
produtivas e por
1o Quadrante 2o Quadrante grau de conhecimento
Essa importante técnica ajuda times gerarem alto grau de
envolvimento e de
Prioritárias Complexas técnico e do negócio,
por isso vale dedicar
juniores e seniores a mapear quais estímulo ao time. (Bora fazer!) (Planejar com um tempo maior para o
atividades têm maior importância no planejamento dessas
contexto. cuidado) tarefas, podendo até
mesmo quebrá-las em
tarefas menores.
A matriz é composta de quatro
VALOR
partes, divididas de acordo com o
valor gerado e o esforço despendido:
Tarefas de pouco valor e Tarefas que devem ser
pouco esforço. Cuidado ao desconsideradas, pois
priorizá-las, pois são têm pouco valor e
atraentes do ponto de 3o Quadrante 4o Quadrante exigem muito esforço,
vista de esforço, mas ou seja, são totalmente
também não apresentam Pouco relevantes Prejudiciais inadequadas do ponto
resultados relevantes.
(Fazer com tempo (Não fazer) de vista financeiro e de
Caso sejam priorizadas, engajamento do time.
faça em momentos de ocioso)
ociosidade de parte do
time ou quando ele estiver
ESFORÇO
com baixa energia.

58
TÉCNICA 12: MATRIZ VALOR X ESFORÇO
COMO FAZER
Antes do começo da dinâmica, o facilitador deve
deixar claro que as estimativas são uma ordem
de grandeza, um “chute” ou ponto de partida do
que deve ser priorizado. Não se trata de algo
imutável, pois no decorrer da técnica o time
poderá perceber que uma tarefa pode ter um
valor ou demandar esforço maior ou menor do
que a outra, e assim fazer a mudança necessária
na matriz.
Comece pela primeira tarefa e pergunte aos
participantes qual nível de valor e esforço que
estimamos para ela. Em seguida, faça a mesma
pergunta e, se necessário, compare com a
primeira tarefa. Faça esse mesmo exercício para
todas as tarefas do board na matriz.
As áreas de negócio e técnica devem ser provocadas para darem sua
opinião. Nesse momento, algumas dúvidas e insights irão surgir, por
isso vale a pena registrá-los no board também.
Uma boa tática para deixar os participantes à vontade é sugerir
usarem o Dot Voting para votar nas tarefas que acham ter mais
valor e demandar mais esforço. Diferencie com cores os dots de
valor e esforço para a organização do mapa.
A partir das respostas, posicione os post-its das tarefas em um dos
quadrantes ou mude a cor deles seguindo a matriz: verde –
quadrante 1, azul – quadrante 2, amarelo – quadrante 3, e
vermelho – quadrante 4.
O resultado deve espelhar as tarefas prioritárias, as complexas, as
pouco relevantes e as prejudiciais.
59
 TÉCNICA 12: MATRIZ VALOR X ESFORÇO

POR QUE USAR

A matriz valor x impacto aumenta a produtividade, maximiza
resultados e prioriza o problema certo. Isso tudo de forma PARTICIPANTES MATERIAIS
transparente e contando com a colaboração de todo o time! Business analytic, Post-its,
Team members, Tech ferramentas como
leader, Infraestrutura, Miro, Figma
RESULTADO ESPERADO Product Manager

Mostrar para o time o que precisará ser feito primeiro. Tarefas

que podem trazer um ótimo resultado e exigem menor esforço
para serem feitas são as que devem ser priorizadas, por
exemplo. Visualmente você terá essas tarefas no quadrante
superior esquerdo da matriz.

TEMPO APLICABILIDADE
1 hora Média

60
TÉCNICA 12: MATRIZ VALOR X ESFORÇO

template valor x esforço

_ Exemplo: gympass
exemplo no miro

Valor

61
 TÉCNICA 13
ESCRITA DE HISTÓRIAS
O QUE É?
A escrita de histórias de usuário é uma técnica
na qual o responsável pelo produto faz uma
explicação informal e geral sobre um recurso,
ferramenta ou desenvolvimento que precisa
ser feito pelo time.
É chamada de história do usuário porque parte
da perspectiva do usuário final. Seu objetivo é
apresentar para o time de desenvolvimento
como essa história pode gerar valor para o
cliente.
62
COMO FAZER
Como exemplo, podemos trazer features provindas do mapeamento da técnica CP para a
criação das histórias. Na prática usamos algumas ferramentas de apoio para criá-las. Para as
Histórias de Discovery de Produto, usamos um template do JTBD – Jobs to be done. Ex.:
Quando [descrever a situação], Eu quero [Motivação para usar aquela ferramenta], Então eu
posso [Resultado esperado].
Já para as Histórias de Delivery, usamos três ferramentas em conjunto:
- A INVEST, na qual descrevemos as características que a história deve ter – Independente,
Negociável, Valiosa, Estimável, Pequena e Testável.
- O DoR (Definition of Ready), em que descrevemos quais são os itens mínimos necessários
para começarmos a desenvolver. Esses itens são particulares de cada projeto, produto ou
mesmo história que será desenvolvida, e devem ser bem descritos.
- E por último, o DoD (Definition of Done), que são os aceites mínimos para a entrega em
desenvolvimento.
Tanto o DoR quanto o DoD são aceites que podem ser pré-definidos pelo time para todas as
suas histórias e que podem ter alguns itens de singularidade em cada uma delas.
O time de desenvolvimento, à medida que vai trabalhando nas atividades, irá detalhar a
descrição técnica da história de usuário.
TÉCNICA 13: ESCRITA DE HISTÓRIAS

POR QUE USAR

São os critérios mínimos e necessários para o
PARTICIPANTES MATERIAIS
desenvolvimento de uma solução. Com todos esses cenários,
mitigamos a chance de erro, aumentamos a assertividade do Product Manager, Planilha, Jira, Azure
que vamos desenvolver e alinhamos os conceitos. Afinal, num
Tech Leader, Devops
fluxo de desenvolvimento, uma história de usuário pode
impedir ou fazer avançar os outros itens a serem Assistente de PM,
desenvolvidos. Product owner, Team
members, QAs

RESULTADO ESPERADO
Para o time de Discovery de Produto, é importante deixar
registradas as evoluções do processo realizado sobre o
produto. E para o time de Desenvolvimento (Delivery), é
necessário para que possam ter as definições necessárias para TEMPO APLICABILIDADE
o desenvolvimento da história. 1 a 2 horas Média

63
 TÉCNICA 13: ESCRITA DE HISTÓRIAS

template escrita de histórias

_ Exemplo: gympass
exemplo no miro

64
TÉCNICA 14
ROADMAP E FERRAMENTAS – ESTRATÉGIA
O QUE É?
O Roadmap estratégico é uma ferramenta de
gestão que auxilia as organizações a
responderem questões aparentemente
simples: onde estamos, aonde queremos
chegar e como chegaremos lá?
É mais uma ferramenta de comunicação do que
de controle em si, por isso, vale lembrar que
nas lideranças ágeis não temos líderes
controladores, e, sim, colaborativos.
Podem ser feitas reuniões de alinhamento com
lideranças, stakeholders e time, estruturação
de estratégia do time de forma visual em Miro,
entre outras. A ideia central desse tópico é dar
saliência à "Comunicação da Estratégia" para
todos.
COMO FAZER
Olhando para a Matriz Valor x Esforço, temos uma sequência lógica do que pode ser priorizado
no Roadmap. Itens do 1o Quadrante da Matriz podem ser priorizados no curto e médio prazo.
Itens do 2o Quadrante, que precisam de um planejamento maior, podem ser colocados em
médio e longo prazo. Itens do 3o Quadrante, possivelmente ficarão em médio e longo prazo,
caso haja tempo para o desenvolvimento. Quanto ao 4o Quadrante deve ser reavaliada a
presença dele no Roadmap. Para efeito de cálculo: curto prazo (1 mês), médio prazo (3 meses)
e longo prazo (6 meses a 1 ano). Deve-se organizar esses pontos com clareza das
necessidades, oportunidades e riscos e colocar em um modelo visual.
Para classificar e organizar essas necessidades e oportunidades, recomendamos a utilização de
discussão e escrita desses pontos, para que sejam documentados, lembrando que, quanto
mais longe e incerto for o item, mas em alto nível será o Roadmap.
A criação desse Roadmap pode partir de um brainstorming coletivo, passando pela priorização
e análise de todo o time e finalizando com as lideranças organizando e sintetizando o material,
antes de levar aos sponsors. Indicamos alinhar com o time e checar se todos estão "comprados
e de acordo" com a proposta, pois isso garante sinergia entre todos os membros.
65
 TÉCNICA 14: ROADMAP E FERRAMENTAS – ESTRATÉGIA

POR QUE USAR

Ferramentas de alinhamento estratégicas são importantes,
principalmente pelo caráter de comunicação. Elas antecipam a PARTICIPANTES MATERIAIS
visão futura – lembrando que o futuro é incerto, mas que Inicialmente todo o Miro, PowerPoint
podemos ter um norte a ser seguido! Além disso, dão clareza
do que está por vir para os times e stakeholders.
time. A validação é
responsabilidade do
gestor
RESULTADO ESPERADO
Ter um planejamento com a visão de curto, médio e longo
prazo de como será o produto, e de sua evolução, para que os
times envolvidos nesse produto possam saber qual o "norte"
que deverão seguir. Esse planejamento pode e deve ser
compartilhado, não somente com os times, mas também com TEMPO APLICABILIDADE
os executivos que precisam saber como será a evolução desse
2 a 6 horas Difícil
produto no futuro.

66
TÉCNICA 14: ROADMAP E FERRAMENTAS – ESTRATÉGIA

template Roadmap

exemplo no miro

Matriz Valor x Esforço

Valor

67
 TÉCNICA 15
PAPÉIS E RESPONSABILIDADES
O QUE É?
A técnica de "Papéis e Responsabilidades" é o
mapeamento da jornada que o time tem a
fazer, alinhado com quais são os papéis de cada
parte do time. O cruzamento disso são as
responsabilidades de cada um em cada etapa.
68
COMO FAZER
Na prática, para desenharmos esse fluxo, precisamos entender qual a jornada do time para a
entrega do produto, incremento ou feature. Depois disso, temos que cruzar essas etapas
com os papéis de cada pessoa e, por fim, descrever quais as responsabilidades de cada papel
em cada etapa da jornada.
- Jornada são as etapas pelas quais o time tem que passar para entregar o valor, feature,
produto ou entregável.
- Papel é a posição que uma pessoa ou determinado grupo tem nessa jornada.
- As responsabilidades são os entregáveis necessários para cada papel, em cada uma das
etapas da jornada.
Ao terminar, teremos uma matriz de Papéis por Etapas da jornada. Esse desenho dará
clareza sobre o fluxo de trabalho, evitará contratempos e alinhará todos do time no
processo.
TÉCNICA 15: PAPÉIS E RESPONSABILIDADES

POR QUE USAR

Muito útil para alinhamento estratégico de todas as pessoas
do time. Deixa claro para os stakeholders e as lideranças de PARTICIPANTES MATERIAIS
como flui o processo e ajuda o time a desenrolar Todo o time Miro, PowerPoint,
impedimentos, quando estão em dúvida quanto a esse
Figma
processo.

RESULTADO ESPERADO
Todos conseguirão entender, a partir da visualização da matriz,
quais são as etapas do Discovery e Delivery e a função que
cada papel executa nessas etapas.

Isso dá clareza para o time de como funciona o processo e os

papéis dentro do desenvolvimento do produto, deixando claro TEMPO APLICABILIDADE
o que é da responsabilidade de cada um e o que precisa ser 2 horas Média
feito.

69
 TÉCNICA 15: PAPÉIS E RESPONSABILIDADES

template papéis e responsabilidades

_ Exemplo Miro: gympass
exemplo no miro

70
TÉCNICA BÔNUS
PRIORIZAÇÃO DE DESENVOLVIMENTO DE HMVP
O QUE É?
Antes de apresentarmos a ferramenta, vamos
explicar o que é um MVP: ele é o "Mínimo
Produto Viável", ou seja, o menor e mais
simples produto que podemos fazer para
testar uma possibilidade. O “H” da palavra
HMVP é a hipótese (ou hipóteses) que será
criada com o seu time e testada em produção.
Normalmente, quando estamos
desenvolvendo um produto, podem aparecer
várias sugestões e ideias interessantes para
resolver um mesmo problema. Essas ideias,
normalmente, são trazidas da técnica Como
Poderíamos (CP). Dessa forma, temos
hipóteses de um MVP para validar e,
consequentemente, uma priorização dessas
hipóteses (HMVP), juntamente com o time.
COMO FAZER
Quando um time tem mais de uma hipótese para testar em produção, utilizamos a matriz de
valor e esforço para priorizar e escolher quais HMVPs iremos usar. Nesse caso, não
deixaremos de colocar as outras hipóteses em produção, apenas estaremos priorizando
qual será a primeira a ser desenvolvida. É por isso que a Matriz Valor x Esforço é importante
na concepção dessa técnica, pois nos ajuda a escolher o HMVP que acreditamos ter maior
valor.
O objetivo é avaliar qual será a mais aderente à persona que pretendemos alcançar e que
poderá ser desenvolvida rapidamente.
Desta forma, deve-se:
1. Listar e mostrar para o time cada uma das funcionalidades que serão colocadas na
primeira hipótese de um MVP, por exemplo, HMVP 1.
2. Listar e mostrar para o time cada uma das funcionalidades que serão colocadas na
segunda hipótese do MVP, por exemplo, HMVP 2 .
3. Comparar as hipóteses 1 e 2.
71
 BÔNUS: PRIORIZAÇÃO DE DESENVOLVIMENTO DE HMVP

COMO FAZER HMVP 1 HMVP 2 HMVP

ESCOLHIDO
4. Coloque os HMVPs em votação (Dot
Voting) pelo time, para que seja escolhido
o de maior aderência ao propósito do
FUNCIONALIDADE 1 FUNCIONALIDADE 2
produto/serviço. Se tiver outras hipóteses, FUNCIONALIDADE 2

ponha em pauta para discussão.

5. A hipótese mais votada deverá ser a
primeira a ser desenvolvida pelo time de
engenharia e testada com os usuários em
produção.
FUNCI
FUNCI FUNCI FUNCI FUNCI
ONALI FUNCI
ONALI ONALI ONALI ONALI
DADE ONALI
DADE 2 DADE 3 DADE 5 DADE
4 DADE 5
4

72
BÔNUS: PRIORIZAÇÃO DE DESENVOLVIMENTO DE HMVP

POR QUE USAR

Esta técnica é bem útil, principalmente no caso de ter mais de
uma hipótese descoberta no momento de Discovery. PARTICIPANTES MATERIAIS
Todo o time de Miro, protótipos de
Ajuda o time a ter menos indecisões e definir de uma forma
Discovery. A baixa e alta
coletiva o que deverá ser focado, evitando conflitos e
participação das fidelidade
desperdício de tempo.
pessoas de engenharia
é fundamental nesta
RESULTADO ESPERADO técnica

Ter uma lista bem definida e coerente do que precisa ser

validado primeiro. O time deverá estar de acordo e seguir o
que foi combinado nessa lista para que possa validar as
hipóteses rapidamente. TEMPO APLICABILIDADE
1 a 2 horas Fácil

73
 XII_ GLOSSÁRIO*
Palavra / Termo Explicação
Abrir o Funil É a ação de ampliar a captação de informações, ideias ou necessidades.
O termo “Ad Hoc” vem da língua latina e significa “para isso” ou “para este efeito”. No nosso caso, é para um propósito
Ad Hoc específico.
Adobe XD (ou Adobe Experience Design) é uma ferramenta de edição de gráficos que funciona para criar web e interfaces de
sites de aplicativos. Ele permite que o designer se concentre na experiência do usuário ao navegar, com um intervalo de erro
Adobe XD mínimo e no menor tempo possível.
Agilidade não quer dizer apenas rapidez. Agilidade quer dizer rapidez com flexibilidade, colaboração, adaptação e
sustentabilidade. Esse conceito de agilidade segue os valores e princípios que foram difundidos no “Manifesto para o
Agilidade desenvolvimento Ágil de Software”, em fevereiro de 2001, no estado norte-americano de Utah.
Aplicativo Mobile Programa de computador (software) que é usado em dispositivos móveis (celulares, tablets etc.).
Aplicativo Web Programa de computador (software) que é usado por meio da internet.
O Azure DevOps Server é um produto da Microsoft que fornece controle de versão, relatórios, gerenciamento de requisitos,
gerenciamento de projetos, compilações automatizadas, testes e recursos de gerenciamento de lançamentos. Ele cobre todo
Azure DevOps o ciclo de vida do aplicativo e habilita os recursos de DevOps.
Conjunto de dados organizados de forma a permitir a sua recuperação, inserção, modificação e exclusão de informações de
Banco de Dados forma rápida e precisa.
Business analytic (ou Análise de negócios) refere-se às habilidades, tecnologias e práticas para exploração iterativa contínua
Business analytic e investigação do desempenho de negócios passado para obter insights e conduzir o planejamento de negócios.
Canvas é uma ferramenta para inovação de modelos de negócios, que pode ser utilizada na criação de uma nova empresa,
produto ou negócio; basta que os envolvidos estejam dispostos a pensar colaborativamente em busca de novas soluções
Canvas para os seus problemas.

*Termos retirados de site de busca, Wikipedia e glossários da web

74
GLOSSÁRIO

Palavra / Termo Explicação

Ciclo de vida É o processo pelo qual um produto ou serviço passa desde o seu lançamento até o seu descontinuamento.
É o processo de desenvolvimento de um produto ou serviço em colaboração com os clientes ou outras partes
Cocriar interessadas. Normalmente é realizado em grupo.
CS (customer success) É a prática de garantir que os clientes sejam bem-sucedidos ao usar um produto ou serviço.
Data Driven É uma abordagem para tomar decisões baseadas em dados e métricas, ao invés de opiniões ou intuição.
Delivery É o processo de entrega de um produto ou serviço.
DEvs (ou desenvolvedores) são os profissionais que integram a equipe (squad) para a criação, manutenção e otimização
Devs de software.
O processo de descoberta (ou Discovery) é uma etapa do desenvolvimento de um produto digital no qual toda a equipe se
Discovery compromete a definir os objetivos principais do negócio, os resultados desejados e as metas e métricas do futuro.
Definition of Done (DoD) (ou “Definição de Pronto”) é um item da metodologia ágil Scrum que estabelece os critérios para
DoD (Definition of Done) que uma tarefa seja considerada “finalizada”.
DoR (Definition of Definition of Ready (DoR) (ou “Definição de Pronto”) é um elemento importante da metodologia Scrum para definir se uma
Ready) tarefa está ou não pronta para ser executada pelo time de desenvolvimento.
e-book Livro digital.
É a compra e venda de produtos ou serviços pela internet, incluindo todas as etapas do processo, desde o catálogo de
e-commerce produtos até a finalização da compra.
É um empreendedor e autor americano conhecido por ser o criador do conceito "Lean Startup", que é uma metodologia
Eric Ries para o desenvolvimento de novos negócios e produtos.
Experimentação É o processo de testar e validar hipóteses para melhorar continuamente um produto ou serviço.
As técnicas de facilitação são usadas para tornar as dinâmicas mais eficientes, deixando claro o objetivo, mantendo o
foco para atender esse objetivo, estimulando participação e ainda garantindo que as decisões tomadas serão
Facilitações de grupo corretamente documentadas e executadas.
*Termos retirados de site de busca, Wikipedia e glossários da web

75
 GLOSSÁRIO

Palavra / Termo Explicação

A palavra Facilities é usada para definir os serviços ligados à infraestrutura predial, como limpeza, segurança e
Facilities manutenção.

Features são funcionalidades ou recursos desenvolvidos por um time de pessoas, geralmente de produtos e plataformas
Features digitais, que têm como propósito adicionar uma nova entrega de valor e experiência para seus usuários.

Feedbacks São comentários ou avaliações de clientes sobre um produto ou serviço.

Figma é uma ferramenta de design que combina a acessibilidade da web com as funcionalidades de um aplicativo nativo.
Isso significa que o Figma é disponibilizado via web, com acesso por meio de qualquer navegador, sem a necessidade de
Figma download ou instalação de algum software.

“Fora da Caixa” É a capacidade de pensar de forma diferente e inovadora, fora dos conceitos e métodos convencionais.
Framework é um termo inglês que, em sua tradução direta, significa estrutura. De maneira geral, essa estrutura é feita
Frameworks para resolver um problema específico.
São características, capacidades ou itens de um produto ou sistema que vão ser desenvolvidos por partes para que ao
Funcionalidades final se entregue um resultado.
GPM (Group Product
Manager) Cargo/função de um líder de Gerentes de Produtos (PM).
Em empreendedorismo, principalmente no contexto de startups, um produto mínimo viável é a versão mais simples de
um produto que pode ser lançada com uma quantidade mínima de esforço e desenvolvimento. O H-MVP é a Hipótese de
H-MVP MVP, ou seja, são hipóteses a serem testadas para a escolha do MVP.
Uma inception marca o início de um projeto e se caracteriza pela reunião das pessoas envolvidas em um mesmo local.
Ela é uma etapa que tem como objetivo fazer com que a equipe descubra e entenda coletivamente o escopo do que será
Inception desenvolvido. Ao seu final, o time deve estar mais entrosado e com uma visão mais clara do caminho a seguir.

*Termos retirados de site de busca, Wikipedia e glossários da web

76
GLOSSÁRIO

Palavra / Termo Explicação

A palavra “insight” é usada pelas pessoas para se referir ao momento em que tomamos consciência de algo, como
Insights em uma epifania.

Interações São ações que acontecem em conjunto com uma pessoa ou uma máquina.
Interface é o nome dado para o modo como ocorre a “comunicação” entre duas partes distintas e que não podem se
conectar diretamente. Um software ou sistema operacional, por exemplo, pode ser controlado por uma pessoa
Interface usando um computador.
INVEST é um acrônimo para independent (independente), negotiable (negociável), valuable (de valor), estimable
(estimável), small (pequena) e testable (testável). A ideia é utilizar a palavra como checklist e visão, validando se a
INVEST história na qual estamos trabalhando atende aos requisitos de cada inicial.

Iterações É o processo de melhorar continuamente um produto ou serviço por meio de pequenas mudanças e testes.
Job to be done (ou “trabalho a ser feito”) é uma metodologia que auxilia na compreensão do problema que um
JTBD - Jobs to be done usuário ou cliente quer resolver com determinado produto ou serviço.

Lançamento em Produção Colocar o produto "pra valer" no mercado.

É uma filosofia de produção que nasceu durante o Toyotismo, que se concentra em eliminar desperdícios e
Lean maximizar a eficiência.
É uma metodologia de desenvolvimento de negócios que foi criada por Eric Ries. Ela se concentra em entregar valor
Lean Startup aos clientes o mais rápido possível e usar feedbacks para melhorar continuamente.

Meet Meet é um aplicativo que facilita a participação de usuários em videochamadas.

É uma plataforma visual em formato de lousa (board) online que une um time para colaborar de forma síncrona ou
Miro assíncrona.
Um modelo de negócios descreve como uma organização cria, entrega e captura valor, em contextos econômicos,
Modelo de Negócio sociais, culturais ou outros.
*Termos retirados de site de busca, Wikipedia e glossários da web

77
 GLOSSÁRIO

Palavra / Termo Explicação

MVP (Minimum Valuable É uma versão mínima de um produto que pode ser lançado para receber feedbacks dos clientes e melhorar
Product) continuamente.
OKR significa Objetivos e Resultados-chave (ou Objectives and Key Results) e indica o foco principal dessa
metodologia de gestão: facilitar a definição e o acompanhamento dos objetivos e resultados esperados de uma
OKRs organização.
Pivot (ou “pivotar”) é o movimento que você deve considerar ao chegar à conclusão de que o seu produto estagnou e
já não atende ao mercado. Ou então se ele não está fazendo progresso suficiente em termos de Product-Market Fit.
Um pivot é mudar totalmente para uma nova direção, a partir de uma nova hipótese sobre o produto, a estratégia
Pivot do produto e/ou o modelo de negócio adotado até então.
PM (Product Manager) Cargo/função de um Gerente de Produtos.
É a pessoa responsável por liderar o processo de desenvolvimento de um produto. Ele está presente, especialmente,
PO (Product Owner) em metodologias ágeis, como o Scrum.
Um post-it (ou nota adesiva) é um pequeno pedaço de papel com uma tira de cola readesiva no verso, feito para
Post-it anexar notas temporariamente a documentos e outras superfícies.
Produto digital é qualquer item que seja comercializado no meio online, como produto de software web ou mobile,
Produto Digital cursos, E-books, ferramentas e outros. Ou seja, produtos digitais não são físicos.
Roadmap é uma ferramenta visual que funciona como um mapa para guiar equipes ao longo de um projeto. Ele se
assemelha a um cronograma em alto nível e é usado nas empresas para organizar e gerenciar o desenvolvimento de
Roadmap produtos, o planejamento estratégico do ano, o desenvolvimento de pessoas, entre outras aplicações.

Software Programa de computador.

Sponsor, significado de acordo com o PMI® (Project Management Institute) é “Uma pessoa ou grupo de pessoas que
Sponsor do projeto fornece os recursos e suporte para o projeto, programa ou portfólio, sendo responsável pelo seu sucesso”.

*Termos retirados de site de busca, Wikipedia e glossários da web

78
GLOSSÁRIO

Palavra / Termo Explicação

É uma unidade de tempo, geralmente de duas a quatro semanas, durante o qual um conjunto de tarefas deve ser
Sprints concluído em um projeto de desenvolvimento de software.

No mundo corporativo, stakeholders (ou "partes interessadas") é o conceito que se aplica em qualquer indivíduo ou
Stakeholders empresas que podem ser impactados por um negócio ou projeto.
Startup É uma empresa recém-criada, que tem um crescimento exponencial de forma escalável.
É uma expressão do latim que significa “estado atual”. O status quo está relacionado ao estado dos fatos, das
situações e das coisas, independentemente do momento. O termo status quo é geralmente acompanhado por outras
Status quo palavras, como manter, defender, mudar etc.

É o processo de adicionar palavras-chave ou marcas a uma informação em um site/website com a finalidade de

Tagueamento descobrir o que, quem e quando acessou cada parte da página.

Tech lead (ou líder técnico de TI) é o profissional responsável por liderar tecnicamente as equipes de desenvolvimento
Tech leader de software para entregas de valor para o cliente.
Templates Exemplo a ser seguido.

Também conhecido por sua sigla TTM, foi desenvolvido em Londres como uma técnica para definir os conceitos e
Time to market medições de tempo desde o início do desenvolvimento de um produto até ele estar pronto para a venda.
User interface (ou interface de usuário) são os recursos de um dispositivo ou aplicativo que permitem a interação do
UI (User Interface) usuário com o sistema.

User experience (ou experiência do usuário) é o conjunto de elementos e fatores relativos à interação do usuário com
UX (User Experience) determinado produto, sistema ou serviço cujo resultado gera uma percepção positiva ou negativa.
Web App Programa de computador (software) que é usado por meio da internet.

É uma página ou conjunto de páginas da web que são acessadas por meio de um navegador de internet e podem
Website incluir conteúdo estático ou dinâmico, como texto, imagens, vídeos, e-commerce, entre outros.
*Termos retirados de site de busca, Wikipedia e glossários da web

79
XIII_ APÊNDICE

80
APÊNDICE
1_ A CRIAÇÃO DO TIME AD HOC
Antes de explicarmos como começou o time Ad Hoc, precisamos
explicar o que significa Ad Hoc.
O termo “ad hoc” é uma expressão de origem latina. Sua tradução é
“para isto” ou “para esta finalidade”.
A partir de uma pesquisa com pessoas que trabalhavam com produtos
digitais, percebeu-se que grande parte delas era recentemente
formada no mercado para trabalhar com produtos e que tinha uma
enorme bagagem teórica, porém, na prática não tinha experiência e
precisava já aplicar os conhecimentos no seu dia a dia, na empresa,
com seus times. Com tanto material sobre o tema, como templates,
treinamentos, certificações, cursos online, frameworks, livros
nacionais e internacionais, novas teorias, por onde de fato começar na
prática? Qual a melhor forma de iniciar um produto do zero? O que
deve ser feito primeiro?
O time Ad Hoc nasceu a partir do desejo de ajudar essas pessoas
nessa dor latente.
Um grupo de especialistas, não conformados com esse “status quo”,
resolveu “pegar na mão” desses profissionais e fazer dessa trajetória
de produtos um caminho mais fácil a ser seguido, pois não estariam
sozinhos.
Sabemos que, por mais teorias que conheçamos, existem medos,
incertezas, questões e aquele friozinho na barriga que ocorre na
primeira vez ao falar com um time que está querendo saber como
fazer um produto. Nossa missão é justamente mostrar que as pessoas
não estão sozinhas, que ninguém que está trabalhando pela primeira
vez com produto deve se sentir um “lobo solitário”, e, sim, cocriador,
pois construímos em time.
Com essa missão, criamos também um framework para que você não
só aprenda, mas também possa disseminar o conhecimento e o
pensamento de produto para todos os envolvidos na sua equipe.
Assim que o time Ad Hoc verifica que o time já está andando sozinho,
com um nível de maturidade maior, saímos de cena e “decolamos” para
outro time, diretoria, empresa, com o objetivo de ajudar outras
estruturas em suas "missões''.
81
 APÊNDICE

2_ FRAMEWORK
Time AdHoc + Discovery de Produtos

Experimentação
Time de Ideia
Discovery
de
Produto
Time Ad
Hoc

Membro(s) Pesquisa
Métricas Membro(s) do
Áreas
Time de Engenharia
Estratégicas Problema do cliente / Assessment / Hipóteses
negócios squad
e de Necessidade do Raio X Protótipo
Negócios negócio
Planejamento
Estratégico OKR

MVP
Squad

Customer Time de
Delivery
de
Centric Continuous
Discovery de
Produto
Produto

+ Gestão do Negóci
Conhecimento os

82
APÊNDICE

_ Alinhados à Estratégia da Empresa

Planejamento estratégico

As empresas normalmente fazem seu planejamento para o

trimestre, quadrimestre ou até mesmo para o ano. Em
muitas delas, ele é transformado em OKRs (Objective Key
Results) para disseminar a estratégia do que será feito para
toda a organização.

Espera-se que todas as empresas tenham o seu

planejamento e a clareza de suas metas, e, para o
framework, isso é de extrema importância, pois todo
produto deve ser alinhado à estratégia da empresa, e é de
onde partimos.

83
 APÊNDICE

_ Estratégia e Negócios

Áreas estratégicas e de negócios

Empresas são feitas de pessoas! Quando uma empresa

desenha seu planejamento estratégico, ela precisa
envolver todas as áreas de negócio e as pessoas
envolvidas, para que possam ter o objetivo e propósito
atrelados aos OKRs. Além disso, eles devem ser
divulgados e acompanhados para que toda a organização
tenha conhecimento sobre os objetivos traçados.

84
APÊNDICE

_ Um problema do Cliente ou uma Necessidade de Negócio

Resolvendo um problema ou uma

necessidade do negócio do cliente

Sempre trabalhamos para resolver/melhorar/adaptar um

problema ou uma necessidade, tendo o cliente como o
centro (customer centric).

Para isso, devemos atender às necessidades de negócio e

de nossos clientes, que serão priorizadas conforme a
estratégia de cada empresa.

85
 APÊNDICE

_ Entender e Atuar no Problema Certo

Assessment – raio X

Antes de qualquer atuação, precisamos fazer um raio X do

problema que podemos resolver. Um diagnóstico do time
e do projeto é necessário para saber qual ferramenta o
time Ad Hoc deverá usar para que possa ajudar da forma
correta. Os problemas podem ser variados, desde um
time que precisa criar um Discovery, até um problema de
capacitação ou gestão que precisa ser resolvido antes
mesmo de o time Ad Hoc atuar. Isso traz com mais
efetividade o panorama do que precisa ser feito para que
posteriormente todo o processo seja realizado com
sucesso.

86
APÊNDICE

_ Discovery de Produto

A coisa toda acontece aqui!

O time de Discovery é composto de um time

multidisciplinar em que não interessam cargos ou
posições. O que mais interessa aqui são os conhecimentos
que essas pessoas têm a agregar e a paixão em comum
que elas têm: O PRODUTO!

Nesse time, a experimentação e o aprendizado são

fundamentais! Errar aqui, ao contrário do que toda a nossa
sociedade nos ensinou a crer, não é ruim e não tem
Experimentação
punição! É aprendizado para fazer diferente, com o Time de
Ideia
propósito de fazer um produto incrível e apaixonante para Discovery
de
os nossos usuários! Produto Time
Ad Hoc
Vamos descrever cada parte desse time para ficar mais
fácil para você entender.

Pesquisa
Métricas Membro(s)
Membro(s) do
Engenharia
Time de
squad
negócios

87
 APÊNDICE

_ Ad Hoc Zup

O time de produtos Ad Hoc

É o time da Zup de Produtos que dá todo o apoio

necessário às áreas demandantes. Deve ter autonomia
para ajudar/apoiar e ensinar os times de engenharia e os
de negócios para que esses possam evoluir na visão de
produto e na experimentação, trazendo real valor para o
seu produto.

Normalmente esse time ajuda a conduzir todo o processo

de Discovery, garantindo que todos os participantes
possam ter o mindset de produto. Metodologias, técnicas,
facilitações, dinâmicas e inceptions poderão ser feitas pelo
time Ad Hoc com o objetivo de coconstruir o melhor
produto com a participação de todos.

88
APÊNDICE

_ Engenharia (time técnico)

Membros da engenharia

Essa turma tem uma contribuição incrível para o time

de Discovery! São essas pessoas que conseguem nos
orientar em relação a um dos principais riscos de
produto que estamos desenvolvendo: a viabilidade
técnica!

Durante as discussões, levam o olhar técnico e nos

ajudam a descobrir novos meios de solução para o
problema/oportunidade e, também, são inseridos no
contexto do propósito do produto desde a sua
concepção.

O time de engenharia sempre deve ser envolvido

desde o início da concepção de um produto, e não
somente no Delivery.

89
 APÊNDICE

_ Área de Negócios

Membros da área de negócio

Não existe produto sem ter a área de negócio envolvida,

certo? É ela que consegue passar a visão do mercado,
além de conhecer muito bem o negócio em que está
inserida e suas principais necessidades e estratégias.

Independentemente de cargo ou função, os

participantes do negócio, no time de Discovery, são
pessoas de profundo conhecimento no tema e devem
estar abertas a novas experimentações.

90
APÊNDICE

_ E o que essa turma toda faz?

Pensa em como construir o melhor produto!

Tendo uma visão do que o

Aplicar o conceito de nosso cliente faz e deseja,
experimentação e todas as ideias são
PENSAR NO SIMPLES é bem-vindas! Todo o time
o principal mindset pode propor o que achar
dessa turma. legal, sem julgamentos! O
Experimentação
Experimentar sem Ideias propósito é gerar insights
Time de para que possamos
medo de falhar e que
Discovery
seja rápido e barato! de desenvolver uma proposta
produto de valor!
Time
Adhoc

Fazer qualquer produto

sem medi-lo é o caminho Como sabemos o que o
para o insucesso! A equipe Pesquisa
usuário deseja ou o que é
Métricas Membro(s) do melhor para ele?
sempre precisa criar formas Time de Membro(s)
de medir o que está sendo negócios Engenharia Pesquisando! Uma das
criado, pois assim coisas que gostamos e
conseguirá trazer dados precisamos fazer é “ouvir”
que balizarão estratégias de o nosso cliente e “ver” o
mudanças, ajustes, que ele faz, assim
melhorias ou, até mesmo, teremos uma visão clara
do pivot do produto. dos objetivos de produto
que queremos alcançar!

91
 APÊNDICE

_ Resultados vão aparecendo...

Com essa turma toda junta e pensando o que podemos fazer para ter um
produto apaixonante para nosso cliente, começa a surgir coisa boa....

A cultura da experimentação começa a se acentuar, e

nesta etapa é onde começamos a ver os “filhos nascendo”.
É aqui que o resultado de todas as conversas, dinâmicas,
inceptions, pesquisas é transformado, com a ajuda dos
designers, em algo “palpável” – essa turma também está
conosco desde o início. Dessa forma, poderemos ter:

Hipóteses: nessa etapa algumas hipóteses (ou HMVP –

Hipóteses de MVP) poderão ser experimentadas e testadas,
com usuários internos ou externos. E serão pré-validadas
pelo time para que possa ser efetuado algum ajuste,
melhoria ou exclusão da hipótese.

Protótipo: um ou mais protótipos da solução encontrada

podem ser gerados (em baixa ou alta definição) de forma
manual ou não. Não se preocupe, isso não importa! O
importante é se o protótipo faz sentido em relação a todo o
processo que já foi discutido com o time.

92
APÊNDICE

_ O MVP está preparado para ser construído

Construindo o MVP

Enfim chega o grande momento da nossa jornada!

Momento no qual cada hipótese e protótipo foi validado e
testado, de forma mais assertiva possível, para que
possamos lançar o MVP, a fim de testarmos no mercado.

Nesse momento o design já está em alta fidelidade e que

iremos testar no mercado, e novamente devemos ter em
mente: PENSAR SEMPRE NO SIMPLES. O que podemos
validar em um produto de forma simples e rápida sem
muito esforço? Sem muita integração? Sem dependência
de diversas áreas? São essas perguntas que precisam estar
sempre na mente do time de Discovery para entregarem
os requisitos mínimos para que os times de Delivery e de
Discovery possam desenvolver.

93
 APÊNDICE

_ Construindo o MVP com o time de Delivery

Aqui os times de Discovery e Delivery trabalham MAIS, juntos

Time de A grande sacada!

Discover
y de
produto
Time
AdHoc Vocês devem lembrar que, no começo do framework, falamos que a
equipe de engenharia (técnica) também participava do Discovery.
Evidentemente não é todo o time de engenharia, porém, esses
membros, no momento do desenvolvimento do MVP, retornam para o
time de Delivery com o objetivo de “contaminá-los” com o “vírus” de
Membro(s) do Membro(s)
Time de Negócios Engenharia
squad
produto.

Isso possibilita aos demais integrantes de Engenharia conhecer todo o

processo de Discovery: detalhes do produto, propósito de valor, e
também como irão desenvolver o produto da melhor forma, visando a
Squad
estratégia definida na empresa.
Time de
Delivery
Continuous de O time Ad Hoc de produto permanece por mais algum tempo com o
Produto
Discovery
de Produto
time de Delivery, trabalhando TODOS juntos até a maturidade da equipe,
momento em que o time Ad Hoc vai para outra missão.
Negócios

94
APÊNDICE

_ O Discovery do produto tem que continuar!

A importância do Continuous Discovery...

Um produto digital é muito vivo!

Time de
Discover
y de
produto
O produto digital que desenvolvemos hoje pode estar obsoleto em
Time
AdHoc questão de dias ou meses!

Por isso mesmo, o conhecimento adquirido do time, na época em

que faziam parte da equipe de Discovery, é tão importante. Aquele
mindset de produto não pode ser abandonado!
Membro(s) do Membro(s)
Time de Negócios Engenharia
squad

Esses membros da equipe irão continuar, juntamente com a

equipe de Delivery, a fazerem novas descobertas: de como
melhorar o produto após o MVP no ar, como mudá-lo, aperfeiçoá-lo
e deixá-lo cada vez mais desejável para os usuários.
Squad

Time de É importantíssimo ressaltar que o time deve ter a liberdade e a

Delivery
Continuous de autonomia necessárias para fazer experimentos com o propósito
Produto
Discovery
de Produto
de continuar tendo um produto que faça sentido e que agregue
valor ao cliente final.
Negócios

95
 APÊNDICE

_ Mas como ensinar isso pra todo mundo que participa?

É aqui que a Gestão do Conhecimento entra em jogo !

Ninguém sabe de tudo!

Ah, sim! Temos várias pessoas de várias áreas participando de tudo isso, mas nem todos sabem técnicas
ou metodologias de produto! Mas precisam construir um produto! E, então, como isso acontece? Afinal,
pode haver pessoas que nunca passaram por um Discovery de Produto.

Como fazemos:
O time Ad Hoc treina as pessoas e aplica cada método ou técnica necessária para aquele produto na MÃO
prática!
Damos workshops rápidos de 1 a 2 horas sobre um tema específico que pretendemos aplicar. E depois,
mão na massa! NA
Observamos que dessa forma as equipes conseguem aprender cada técnica de produto, participam,
influenciam nas decisões e conseguem praticar o que estamos fazendo. Consequentemente, levam essa MASSA
experiência para o momento em que estiverem participando do time de Delivery.

96
XIV_ BIBLIOGRAFIA E CRÉDITOS

BIBLIOGRAFIA CRÉDITOS

AGUIAR, Fábio; CAROLI, Paulo. Product Backlog Building. 1. ed. Rio de Janeiro: Idealização: Jônatas Falcão
Caroli, 2015. Texto: Daniele Mazza, Frederico Parreira e Jônatas Falcão
Templates e exemplos do Miro: Frederico Parreira
CAGAN, Martin. Inspired: How to Create Tech Products Customers Love. 2.ed. Diagramação e edição de texto: Daniele Mazza
New Jersey: Wiley, 2017. Planejamento MVP: Frederico Parreira
Capa: Flávio Peixoto (Bigoi)
Revisão de texto: 3GB Consulting
CAROLI, Paulo. Lean Inception: Como Alinhar Pessoas e Construir o Produto Fotos e ícones: br.freepik.com
Certo. 1. ed. Rio de Janeiro: Caroli, 2019.

GONZÁLEZ, Carlos; ANON, Josh. The Product Book: How to Become a Great Com esta licença, você pode:
Product Manager. 1. ed. New York: Product School, 2017. COMPARTILHAR: copiar, distribuir e transmitir a obra.
NÃO COMERCIAL: não pode usar esta obra para
propósitos comerciais.
KNAPP, Jake; ZERATSKY, John; KOWITZ, Braden. Sprint: How to Solve Big
Problems and Test New Ideas in Just Five Days. 1. ed. New York: Simon &
Schuster, 2016.
PERFIL DOS AUTORES
RIES, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous
linkedin.com/in/daniele-mazza-982b8246
Innovation to Create Radically Successful Businesses. 1.ed. New York:
linkedin.com/in/parreirafrederico
Currency, 2011. linkedin.com/in/jonatasfalcao

SUTHERLAND, Jeff; SUTHERLAND, JJ. Scrum: The Art of Doing Twice the Work
in Half the Time. 1. ed. New York: Currency, 2014.

97
Acesse o MIRO para
todos os templates e
exemplos das
técnicas abordadas
no livro: