The Product Book PT

THE
PRODUCT
BOOK
JO SH AN O N
com
CA R LOS G O NZÁL E Z D E VI LLAUM B RO S IA
PUBLICADO POR
The Product Book: Como se Tornar um Grande Product Manager
Direitos Autorais ©2017 da Product School
Todos direitos reservados.
Nenhuma parte desta publicação pode ser reproduzida, armazenada ou

transmitida de qualquer forma ou por qualquer meio, eletrônico, mecânico,
fotocópia, gravação, digitalização ou outro, sem permissão por escrito do editor.
É ilegal copiar este livro, publicá-lo em um site ou distribuí-lo por qualquer outro
meio sem permissão.
NOTA LEGAL
Todas as marcas registradas são de propriedade de seus respectivos proprietários.
Salvo indicação em contrário, todos os textos e imagens são de direito autoral da
Product School, e não podem ser reproduzidos sem permissão.
ISBNS 978-0-9989738-8-3 IMPRESSÃO

978-0-9989738-7-6 MÓVEL
DESIGN DO LIVRO POR The Frontispiece
PUBLICADO POR Product School

TABELA DE CONTEÚDOS
INTRODUÇÃO 7
1 O Que é o Product Management 9
2 Estrategicamente Entendendo uma Empresa 36
3 Criando Oportunidades Hipotéticas 74
4 Validando suas Hipóteses 125
5 Colocando Ideias em Ação 170
6 Trabalhando com Design 214
7 Trabalhando com a Engenharia 246
8 Colocando seu Produto no Mercado 276
9 Finalizando o Ciclo de Desenvolvimento do Produto 317
Reconhecimentos 342
Sobre os Autores 344

INTRODUÇÃO
Obrigado por escolher este livro! Sabemos que seu tempo é precioso, e 7
faremos nosso melhor para a sua leitura valer a pena.
Uma das partes mais importantes de ser um Product Manager é saber
quem são seus clientes e o que eles precisam. Partindo deste princípio,
quem nós acreditamos que você seja, e qual a necessidade deste livro?
Fundamentalmente, você é alguém que gostaria de saber mais sobre
Product Management. Talvez você seja um recém-graduado tentando
descobrir se a gerência de produtos é a carreira certa para você. Talvez
você seja um engenheiro que esteja em fase de transição para Product
Management. Talvez você seja um fundador de uma empresa recém-
criada que quer descobrir como construir sua divisão de produtos. Ou
talvez você já seja um Product Manager que evoluiu naturalmente para o
cargo, e está procurando preencher lacunas em seu conhecimento.
Além disso, há muita sabedoria sobre as práticas recomendadas para
Product Managers, mas a maioria concentra-se em partes do ciclo de vida
de desenvolvimento do produto. Este livro lhe dará uma visão completa
do que significa criar um ótimo produto, bem como o que os Product
Managers fazem no dia a dia.
Os próximos capítulos abordarão uma mistura de teoria e conselhos
práticos para ensiná-lo como identificar uma oportunidade e construir um
produto com sucesso para abordar essa oportunidade, seja o resultado um
novo produto ou um refinamento de um produto existente. Se você for
novo no Product Management, ou um veterano experiente, este livro está
aqui para ajudá-lo a aprender as habilidades necessárias para, de forma
eficaz e bem-sucedida, se tornar um líder de produtos.
Uma breve palavra de aviso: Assim como o xadrez, o pôquer e o
Minecraft, o Product Management é fácil de aprender, mas pode levar
uma vida inteira para dominar. Se seu objetivo é ser um Product Manager,
considere este livro como o início de sua jornada.
Tornar-se um Product Manager verdadeiramente eficaz requer prática!
8 Se, depois de ler este livro, você ainda quiser se tornar um Product
Manager, considere inscrever-se na Product School, a primeira escola
de negócios de tecnologia do mundo. A Product School oferece aulas de
Product Management ministradas por Product Managers do mundo real,
trabalhando nas mais renomadas empresas de tecnologia como Google,
Facebook, Snapchat, Airbnb, LinkedIn, PayPal e Netflix. As aulas da
Product School são projetadas para se encaixarem nas brechas do seu
horário de trabalho, e os campus estão convenientemente localizados no
Vale do Silício, São Francisco, Los Angeles, Santa Mônica e Nova Iorque.
Agora, continue a ler para começar sua jornada pelo mundo amplo e
fascinante do Product Management.
CAPÍTULO UM
O QUE É O PRODUCT MANAGEMENT?
“Ninguém pediu para que você aparecesse”. Todo Product Manager 9

experiente já ouviu alguma versão dessas palavras em algum momento
de sua carreira. Neste caso, essas palavras dolorosamente frustrantes são
de Ken Norton, sócio da Google Ventures, em uma postagem de blog
intitulada “Como Contratar um Product Manager.”
Pense em uma empresa por um segundo. Engenheiros constroem
o produto. Designers certificam-se de que ele forneça uma ótima
experiência de usuário e tenha boa aparência. O Marketing garante que os
clientes conheçam o produto. Os vendedores fazem com que clientes em
potencial abram suas carteiras para comprar o produto. O que mais uma
empresa precisa? Onde um Product Manager se encaixa nessa confusão?
Essas simples perguntas são o que causam não apenas essa

confusão toda, mas também a oportunidade que acompanha o Product
Management. Caramba, se você estiver fazendo a transição para a área
de Product Management, essas perguntas podem deixar você preocupado
com o fato de os Product Managers serem irrelevantes. E se você for
atualmente um Product Manager, pode sentir uma necessidade repentina
de justificar sua existência. Na verdade, sem um Product Manager, uma
empresa continuará a operar muito bem—até certo ponto. No entanto,
com um Product Manager forte, uma empresa pode se tornar excelente.
O QUE UM PRODUCT MANAGER FAZ?

Colocando de forma simples, um Product Manager (PM) representa
o cliente. Ninguém compra um produto porque quer dar dinheiro à
empresa. Os clientes compram e usam produtos porque os produtos
atendem às suas necessidades. Feito corretamente, os produtos deixam
os clientes impressionados. O resultado final de representar o cliente é
que um PM ajuda o cliente a ser incrível.
Há muito por trás dessa definição simples, no entanto. Adam Nash,
10
CEO da Wealthfront e ex-vice-presidente de produtos do LinkedIn,
resumiu a gestão de produtos dizendo que os PMs descobrem que jogo
THE PRODUCT BOOK
uma empresa está jogando e como ela mantém a pontuação (não é sempre
sobre quanto dinheiro a empresa faz).
No dia a dia, os PMs devem entender tanto a estratégia quanto a
execução dos negócios. Eles devem primeiro descobrir quem são os
clientes e quais os problemas que os clientes têm. Eles devem saber como
definir uma visão, encontrando as oportunidades certas em um mar de
possibilidades, usando dados e intuição. Eles devem saber como definir
o sucesso, para o cliente e o produto, priorizando fazer o que é certo em
vez de fazer o que é mais fácil. Eles devem saber como trabalhar com
engenheiros e designers para obter o produto certo, mantendo-o o mais
simples possível. Eles precisam saber como trabalhar com marketing
para explicar ao cliente como o produto preenche melhor as necessidades
do cliente do que o produto de um concorrente. Eles precisam fazer o
que for necessário para ajudar a lançar o produto, encontrando soluções
em vez de desculpas. Às vezes, isso significa até mesmo um PM indo
buscar café para uma equipe, que está trabalhando longas horas, para
demonstrar apreço. A propósito, os PMs gerenciam produtos, não
1. O Que é o Product Management

pessoas, por isso precisam alcançar tudo usando um pouco de influência,
uma comunicação eficaz, liderança e confiança - não ordens. Mesmo
que nem sempre seja óbvio o que os PMs fazem do lado de fora, eles
realmente fazem muito! Os PMs fazem tanto que, às vezes, são chamados
de “Mini CEOs”.
Ironicamente, o que um PM faz mais é dizer “não”. Algumas pessoas
acreditam que os Product Managers apenas ditam quais recursos
construir. Considerando que todo mundo possui muitas idéias para
recursos, por que se preocupar com um PM? É verdade que todos têm
muitas ideias, algumas são boas, mas a maioria das ideias que as pessoas
têm são para coisas que querem, não necessariamente coisas que os
11
clientes vão querer. Por exemplo, pense em um engenheiro que passa
seus dias usando ferramentas de linha de comando enigmáticas - com
certeza você conhece alguém assim! Esse engenheiro provavelmente
prefere atalhos de teclado, não gosta de GUIs e favorece o uso de
código para especificar explicitamente o significado. Agora, imagine
que esse engenheiro faça parte de uma equipe que trabalha em um
processador de texto para iPad para idosos. Você acha que os recursos
que o engenheiro priorizaria correspondem aos recursos que os clientes
idosos precisam? Uma grande parte do trabalho de um PM é descobrir
o pequeno número de características-chave a serem priorizadas pelo
cliente e estabelecer as bases para a viabilidade de negócios a longo
prazo, dizendo graciosamente “não” aos inúmeros pedidos que não
condizem com as necessidades do cliente.
Similar, mas Diferente
Também vale a pena olhar cargos relacionados, mas diferentes, ao Product
Management. Esses trabalhos se confundem com o Product Management
porque, em algumas empresas, um Product Manager também lida com as
responsabilidades desses cargos, mesmo que eles não sejam os principais
pontos fortes do Product Manager. Por exemplo, lembra como dissemos
que um bom Product Manager faria o que fosse necessário para lançar
um produto? Outras coisas confusas, todas essas funções relacionadas
são abreviadas como “PM”.
Os gerentes de projetos são mais frequentemente confundidos com

Product Managers. Embora existam muitas diferenças sutis, elas podem
ser resumidas dizendo que um gerente de projeto possui o cronograma
e ajuda a garantir que a equipe esteja no caminho certo para cumprir os
12 prazos. O gerente de projetos geralmente trabalha com o Product Manager,
e um Product Manager fornecerá informações sobre o cronograma. Os
THE PRODUCT BOOK
gerentes de projeto são mestres de cronogramas e gráficos de Gantt, não

de representar clientes.
Em geral, os gerentes de programas são um pouco mais parecidos
com os Product Managers, mas os gerentes de programa geralmente se
concentram mais em “obter isso”, trabalhando de perto com a equipe
de Engenharia e Operações. Se você estiver criando uma tecnologia
utilizável, por exemplo, o gerente do programa provavelmente entrará em
contato com a fábrica frequentemente, enquanto um Product Manager
terá uma interação direta limitada com ele. Os gerentes de programa
tendem a ser mestres de execução, como um “super” gerente de projeto.
Para confundir ainda mais as coisas, o título que descreve o que um
Product Manager faz varia ligeiramente de empresa para empresa. A
Microsoft, por exemplo, chama seus Product Managers de “gerentes de
programa”. A divisão geralmente divide o papel do Product Manager em
“Gerente de Engenharia do Programa” (GEP) e o “Gerente de Marketing
do Produto” (GMP), com o GMP mais próximo da definição de um
Product Manager, e o GEP está mais próximo de um gerente de projetos.

Product Managers são como o maestro de uma orquestra. O maestro
nunca faz som algum, mas é responsável por fazer com que a orquestra
planeje toda a programação da temporada para a sala de concertos,
configurando as coisas para que os gerentes de projetos possam fazer com
que cada apresentação seja bem-sucedida.
Grandes regentes entendem e se envolvem com todos na orquestra,
usando o vocabulário certo em cada seção, movendo diplomaticamente
todos juntos para um objetivo comum de uma grande performance.
Os gerentes de projeto ajudam a manter todos os ensaios organizados
para que a orquestra esteja preparada para os concertos. Os gerentes de
programa estão envolvidos no planejamento de toda a programação da
13
temporada para a sala de concertos, configurando as coisas para que os
gerentes de projeto possam tornar cada desempenho bem-sucedido.
TORNANDO-SE UM PM
Não há caminho óbvio para se tornar um Product Manager. E se você
estiver revendo currículos para potenciais contratações na área de
Product Management, especialmente se você for um fundador de uma
nova empresa, não é muito óbvio o que você deve procurar. A maioria
das carreiras tem um caminho muito claro: você vai à escola, estuda
ciências da computação e, em seguida, se torna engenheiro. O Product
Management não é uma dessas carreiras.
Como o Product Management é uma disciplina relativamente nova,
ele possui um processo de treinamento muito menos formalizado do
que outras carreiras. Dado que o cargo geralmente se resume a “fazer
o que for preciso para lançar um produto que os clientes vão adorar e
que atinja as metas de negócios”, os Product Managers devem ser pessoas
inteligentes e talentosas que consigam resolver tarefas por conta própria.
Além disso, os Product Managers costumam ter uma interseção de um
histórico técnico - não apenas de engenharia -, como experiência no setor
e habilidades de comunicação. O tipo mais comum de Product Manager
é alguém com formação em engenharia/informática que se interessou
por negócios. Os PMs geralmente começam como engenheiros que
contribuem individualmente e, então, assumem mais responsabilidades:
conduzir entrevistas com clientes, trabalhar com o Design para validar
ideias e possivelmente até mesmo colaborar com o marketing para garantir
que o que eles estão trabalhando esteja de acordo com as necessidades
do cliente. Eles não são necessariamente os melhores codificadores ou
os especialistas de domínio mais definitivos, mas os seus conjuntos de
habilidades os tornam únicos. Às vezes, os PMs vêm de Design, Marketing
ou até mesmo da faculdade de administração!
14
Na Product School, muitas vezes falamos sobre o Triângulo do
Produto (Figura 1-1). Esta é uma maneira simples de visualizar e entender
THE PRODUCT BOOK
onde o Product Management (idealmente) se situa em relação a outros

departamentos centrais:
Engenharia (desenvolvimento do produto), Design e Marketing. Este
diagrama é útil por dois motivos. Primeiro, enfatiza visualmente que
o Product Management é um papel generalista e que os PMs precisam
trabalhar com domínios significativamente diferentes. Em segundo lugar,
à medida que você avança no processo de construção de um produto,
você muda o equilíbrio para as diferentes partes do triângulo - veremos
mais sobre isso em breve. Pensar em qual parte do triângulo você está se
concentrando, permitirá que você pense sobre o caminho certo para se
comunicar - você vai falar com a equipe de Design de forma diferente do
que você faz com a equipe de Engenharia - e saber as metas certas para
definir durante cada fase.
Design
do Produto

Gerenciamen-
to do Produto
Desenvol- Marketing
vimento do Produto
do Produto
Figura 1-1. O Triângulo do Produto, mostrando o Product Management na interseção de três

domínios principais.
Uma pergunta comum sobre como se tornar um PM é: quão técnico 15

os PMs precisam ser? Eles precisam saber o suficiente para trabalhar
de forma eficiente com os engenheiros, participando de tarefas
como priorização de erros no sistema e reuniões de metas, mas eles
não precisam de um curso de ciência da computação ou engenharia
elétrica. Especialmente para PMs de software, saber como codificar um
pouco será benéfico, e se você quiser se tornar um PM, mas se não sabe
codificar, é altamente recomendável aprender o básico. Felizmente, há
muitos recursos para ajudá-lo a aprender - você pode se inscrever em
um treinamento como o Code School ou o Hack Reactor ou fazer um
curso on-line no lynda.com ou na Udemy.
Um grande benefício para aprender a codificar é que os PMs
frequentemente confiam em um modo de pensar comum à codificação
- design de cima para baixo e implementação de baixo para cima. Isso
significa que você pensa sobre o quadro geral, divide-o em pequenos
pedaços e constrói esses pequenos pedaços primeiro. Depois de
construir os pequenos pedaços, você os combina para obter uma
imagem maior. Aprender a codificar lhe dará uma prática consistente
em pensar dessa maneira.
Outra questão comum é: quão orientados aos negócios os PMs
precisam ser? Os PMs não precisam de um MBA - na verdade, algumas
empresas de tecnologia preferem não contratar MBAs - nem precisam
de formação em vendas. Eles devem entender o setor da empresa em
que estão interessados e responder às seguintes perguntas: Quem
são os clientes? Quem são os principais jogadores? O que diferencia
uma empresa da outra? Como as empresas ganham dinheiro? Os PMs
também devem entender conceitos financeiros básicos, como renda
versus lucro - receita é quanto dinheiro uma empresa absorve e o lucro
é quanto resta após as despesas.
Em geral, quando trabalhamos com pessoas que querem fazer a
16
transição para se tornarem um Product Manager, recomendamos que
comecem com um setor/ empresa com o qual já esteja familiarizado. Isto
THE PRODUCT BOOK
facilita a transição porque, provavelmente, você saberá as respostas para

muitas das perguntas acima, mesmo que não perceba isso explicitamente!
Depois de alguns anos de experiência em Product Management, é muito
fácil mudar para um novo domínio, pois você sabe as perguntas certas a
serem feitas para ter sucesso. Se você é o fundador de uma empresa e deseja
criar a equipe de produtos de sua empresa iniciante, recomendamos que
você se concentre em encontrar a melhor pessoa possível para o produto,
mesmo que essa pessoa não esteja familiarizada com seu domínio.
Tipos de Product Managers
Embora, muitas vezes, você ouça as pessoas falarem sobre Product
Managers no sentido geral, você também ouvirá falar sobre Product
Managers especializados. Dependendo do seu histórico, você pode

encontrar em uma dessas especializações uma opção de carreira mais
apropriada do que a função geral.
A especialização mais comum é o gerenciamento técnico de produtos.
Isto refere-se a um PM que tenha uma sólida formação técnica e que
trabalhe em um produto técnico. Por exemplo, essa pessoa pode trabalhar
em um API de software em que o cliente final seja um desenvolvedor de
software. Os PMs técnicos não estão escrevendo o código nem realizando
tarefas técnicas, mas precisam entender os detalhes do que acontece
nessas tarefas.
Outra especialização é o gerenciamento estratégico de produtos. Esse
papel é o complemento para um PM técnico, e é alguém que tem um 17
sólido histórico de negócios.
De vez em quando, você também verá títulos vinculados a diferentes
diretrizes ou tarefas específicas, como o Product Manager em crescimento
ou o Product Manager para dispositivos móveis. Essas funções são mais
focadas do que a função geral de gerenciamento de projetos, e uma
pessoa em tal função terá um conjunto mais específico de habilidades,
como ser especialista em todas as diferentes coisas que você pode fazer
para desenvolver um produto - ou seja, obter mais clientes usando-o.
COMO OS PRODUCT MANAGERS CRIAM SEUS PRODUTOS

Embora, às vezes, pareça que o CEO imagina um produto durante o banho
e depois diz à equipe de engenharia para construí-lo, qualquer um que te-
nha sido CEO sabe que esse não é o caso. A gestão de produtos é igualmen-
te mal compreendida pelo público em geral. Na TV, é provável que você
veja um rapaz sair do chuveiro e começar a hackear um laptop com texto
em verde claro, resolvendo ocasionalmente um problema difícil ao dese-
nhar no vidro. O mundo real não funciona assim. Então, como os produtos
são construídos? O que um Product Manager realmente faz e como?
Na realidade, os produtos passam continuamente por um ciclo de

vida de desenvolvimento do produto, e um Product Manager leva o
produto a passar por cada fase, apropriando-se de algumas fases e con-
tribuindo para outras. O ciclo de vida do desenvolvimento do produto
envolve etapas discretas e cada etapa enfatiza uma etapa diferente do
Triângulo do Produto.
Embora as etapas estejam bem definidas, existem várias abordagens

sobre como essas etapas podem ser implementadas. Em uma extremidade
do espectro, há a abordagem “lean” ou “enxuta”, baseada nos métodos de
18
fabricação da Toyota e adaptada ao desenvolvimento de software/produto
por Steve Blank e Eric Ries. A metodologia “enxuta” se concentra em ciclos
THE PRODUCT BOOK
iterativos muito rápidos, nos quais seu objetivo é fazer algo pequeno,
liberá-lo, aprender com ele e usar esse conhecimento para descobrir o que
fazer a seguir. Ciclos “enxutos” podem acontecer em apenas alguns dias.
No extremo oposto do espectro, você tem a abordagem “cascata”, onde
você constrói algo grande de uma forma muito linear - você gasta muito
tempo planejando um produto, e uma vez que você decidir o que fazer, é
exatamente isto que você construirá e lançará, mesmo que demore muito
tempo. O produto passa por cada passo a passo do processo e, como uma
cascata, as coisas funcionam de uma maneira e - quase - nunca mudam
depois de definidas. Os ciclos de cascata podem levar um ano ou mais.
Para o desenvolvimento de produtos de software, empresas maiores e
mais antigas tendem a usar uma abordagem em cascata, enquanto muitas
empresas recém-criadas usam uma abordagem “enxuta”.
Como você pode esperar de maneira intuitiva - e tem havido muitos
estudos para comprovar isso-, criar produtos com uma abordagem “enxuta”
é mais bem-sucedido porque você não está arriscando tudo em um projeto
potencialmente longo e lento de criar. Em vez disso, você arrisca um

pouco para construir algo pequeno, aprender com ele e interagir. Por essa
razão, empresas ainda maiores e mais antigas estão mudando para uma
abordagem “enxuta”, afastando-se da abordagem de cascata.
A abordagem mais comum que você encontrará é um híbrido de

“cascata” e “enxuta”, no qual o gerente de projeto planeja com um pouco
de antecipação para encontrar a oportunidade certa, mas, em seguida,
as equipes implementarão o produto de maneira iterativa. Isso é bom
porque permite que você mantenha uma meta geral em mente, mas mude
o curso, se necessário, como se você encontrasse um obstáculo técnico
significativo ou descobrisse que os clientes não desejam o produto que
você está construindo. Vamos nos concentrar principalmente em uma 19
abordagem híbrida neste livro.
O desenvolvimento de produtos de hardware exige uma abordagem

mais complexa, porque é mais difícil alterar as coisas que você está criando
fisicamente. Por exemplo, o hardware requer muito mais planejamento
antecipado, e os ciclos iterativos durante o desenvolvimento para obter
novas construções de hardware são muito mais longos do que para um
software. No entanto, os princípios gerais para a criação de produtos são
muito semelhantes aos do software, e o processo é semelhante o suficiente
para que os estágios do ciclo de vida que lhe ensinamos se apliquem ao
Product Management de hardware e software.
Nos capítulos futuros, nos aprofundaremos em cada estágio do
ciclo de vida de desenvolvimento do produto em profundidade. Por
enquanto, vamos analisar uma visão geral de cada etapa, começando
pela fase de planejamento.
O CICLO DE DESENVOLVIMENTO DO PRODUTO
Cada produto passa por cinco etapas conceituais principais:
1. Encontrar e planejar a oportunidade certa

2. Projetar a solução
3. Construir a solução
4. Compartilhar a solução
5. Avaliar a solução
Em outras palavras, esse processo envolve descobrir qual problema trabalhar

pensando em como resolvê-lo, construindo a solução, colocando-a nas
mãos dos clientes e vendo se funciona para eles. Parece fácil, certo?
Conceitualmente, é! O mal está nos detalhes. Para ajudá-lo a ver como

cada estágio se conecta, antes de mergulharmos fundo, vamos ver uma
20
visão geral de alto nível de cada estágio.
THE PRODUCT BOOK
Encontrando e Planejando a Oportunidade Certa

A primeira fase do ciclo de vida do desenvolvimento de produtos é
encontrar e definir claramente a próxima oportunidade a ser seguida.
O mundo é um mar de possibilidades! O que você deve construir em
seguida? Geralmente, cabe ao Product Manager criar e classificar todas
as possibilidades, escolhendo o caminho certo para se concentrar no
que vem a seguir.
Essa fase é uma parte crítica do seu trabalho. Ao contrário das outras
fases, em que outras disciplinas assumem a liderança, essa fase é onde o
produto toma a liderança, recebendo informações de outras disciplinas.
É provavelmente o mais diferente de qualquer coisa esperada em outra
posição. Como isso é tão importante para o seu trabalho, abordaremos
a oportunidade certa em profundidade, dividindo-a em três partes:
estrategicamente entendendo uma empresa (Capítulo 2), criando uma
oportunidade hipotética (Capítulo 3) e validando hipóteses. (Capítulo 4).

Para um Product Manager, entender estrategicamente uma empresa
envolve aprender sobre aspectos da empresa que contribuem para o
sucesso de seus produtos, incluindo seus clientes-alvo, sua especialidade,
seu cenário competitivo e muito mais. Compreender esses aspectos, que
às vezes nos referimos como o contexto de uma empresa, ajudará você a
tomar as decisões corretas sobre o produto e a começar a se concentrar no
mar de possibilidades. Um exemplo simples é a equipe de comunicação
da CNN. Eles são ótimos na criação de produtos de software, incluindo
um site e aplicativos para dispositivos móveis, que entregam as notícias
de maneira rápida e eficiente a seus clientes. Como seus PMs sabem que
têm especialização em software e não são especialistas em hardware, eles
provavelmente não estão incentivando a CNN.com a criar um relógio 21
inteligente voltado para notícias ou outro produto de hardware.
A identificação clara dos objetivos da empresa, outro elemento

estratégico, ajudará você a restringir e priorizar as possibilidades. Em
um nível mais alto, as metas da empresa se dividem em três categorias:
crescimento, lucro e satisfação do cliente. Especificamente, a empresa
deseja obter mais usuários para o produto, aumentar o investimento
dos clientes atuais ou tornar seus clientes atuais mais felizes? Se a meta
é lucro, como a empresa atualmente monetiza seu produto e como você
pode aumentar o valor para os clientes para torná-los mais dispostos a
pagar pelo produto? Se a meta é crescimento, o que impede novos clientes
de usar o produto? Se o objetivo é encantar seus clientes, o que você pode
oferecer que eles adorariam, mas não esperariam? Ao entender as metas
atuais, você pode pensar estrategicamente e garantir que os produtos que
você está construindo estejam alinhados com essas metas, ajudando a
empresa a ter sucesso.
Além dessas, existem outras questões estratégicas do contexto da

empresa para as quais você deve saber a resposta: O que a empresa
está construindo agora? O que é excelente em comparação com seus
concorrentes? Quem são os principais clientes para os quais você
pretende solucionar um problema? Qual é a visão da empresa e, mais
fundamentalmente, por que a empresa existe?
Com o contexto da empresa em mente, o próximo passo, que
abordaremos no Capítulo 3, será criar uma oportunidade hipotética. O
que você acha que seria a coisa certa para trabalhar em seguida? Pode ser
algo tão pequeno quanto consertar um erro no sistema que está na sua
lista de tarefas por algum tempo ou algo tão grande quanto construir um
produto totalmente novo.
22 Essas hipóteses de oportunidade vêm de muitos lugares diferentes.
Analisar como os clientes existentes usam seu produto é uma fonte
THE PRODUCT BOOK
comum de novas oportunidades, permitindo que você encontre maneiras

de atender melhor seus clientes e as metas de sua empresa. Uma métrica
é uma medida de uma tarefa que um cliente faz com seu produto.
Coletivamente, suas métricas podem fornecer ótimas informações. Nas
métricas, você pode encontrar uma oportunidade, como aumentar o
envolvimento com um componente de seu produto.
Por exemplo, a CNN.com provavelmente monitora em quais seções
os visitantes clicam, quantas pessoas começam a assistir a cada vídeo,
quantas terminam de assistir cada vídeo, quantas deslizam pela página e
lêem cada artigo e muito mais. Eles podem então usar esses dados para
tirar conclusões, como: “Devemos priorizar conteúdo de vídeo em vez de
texto porque as pessoas tendem a assistir a vídeos até a conclusão e ver
cada anúncio, enquanto poucas pessoas leem artigos até o fim”.
Depois de pensar no contexto e objetivos da empresa, conversar com
usuários, analisar dados de uso, observar relatórios de erros e solicitações
de recursos existentes, e usar outras abordagens que veremos mais
adiante no Capítulo 3, você terá uma idéia sobre o que fazer a seguir.

Mas antes de começar a criar um recurso, você deve fazer algum tipo de
trabalho de validação para garantir que essa é a oportunidade certa a ser
desenvolvida e que, na verdade, o ajudará a atingir suas metas. Você tem
tempo e recursos limitados, e gastar um pouco de tempo validando uma
hipótese de oportunidade pode economizar muito tempo e dinheiro,
mantendo-o focado nas melhores oportunidades.
O Capítulo 4 aprofunda-se em como validar uma ideia.
Depois de validar sua ideia, você precisará desenvolvê-la em algo

que suas equipes possam implementar. Uma parte importante da fase
de planejamento de produtos no ciclo de vida de desenvolvimento de
produtos é o escopo da oportunidade. O escopo significa definir claramente 23
a oportunidade e os clientes que você deseja segmentar, juntamente com

os requisitos para a solução. Se você está construindo uma caneta, você
precisa que ela funcione no espaço sideral? Embaixo d´água? De cabeça
para baixo? Você deve definir claramente essas situações para ajudar
todos a entender o que o produto precisará fazer quando estiver pronto.
Ao trabalhar em ambientes lean ou híbridos, muitas vezes, você ouvirá

sobre o produto mínimo viável (MVP). Este é um termo da metodologia
lean que simplesmente significa: “Qual é a coisa mais minimamente
apresentada que você pode construir para abordar bem a oportunidade
para a maioria de seus clientes-alvo e validar sua oportunidade?” Em
outras palavras, se você pensasse sobre a função principal que você está
tentando permitir que os clientes realizem, qual seria o produto mais
simples que você poderia criar para atingir essa meta?
Continuando com nosso exemplo da CNN, se você voltasse no tempo
e estivesse trabalhando na primeira versão do aplicativo para dispositivos
móveis da CNN, qual seria o aplicativo mais simples que você poderia
criar para fornecer valor a seus clientes? Pode ser algo como uma lista de
notícias e um botão de atualização, e quando você toca em cada um, você
vê o vídeo da história. Novamente, a chave para identificar o MVP é que
você esteja focado na funcionalidade principal que fornece ao usuário
- notícias, neste caso - em vez de se concentrar em todos os recursos
possíveis que você pode criar além dessa função principal.
Identificar o MVP é uma parte fundamental do escopo de um

produto, pois ajuda a identificar a coisa mais importante a ser construída
primeiro - abordaremos dicas sobre como fazer isso no Capítulo 5. Isso
permite que você concentre seus esforços de design e desenvolvimento
para criar um produto - com toda certeza - útil e que você pode entregar
24 aos clientes rapidamente, seja como software enviado ou software testado
internamente. Testar o MVP com clientes reais o ajudará a descobrir
THE PRODUCT BOOK
quais outros recursos estarão dentro e fora do escopo, pois você obterá
uma avaliação real sobre o que os clientes gostam e o que não gostam.
Observe que um MVP não significa que o produto seja ruim ou mal
construído. De fato, muito pelo contrário - deve ser muito bom no que
faz, mas deve se concentrar em fazer apenas algumas tarefas importantes.
Compare isso com abordagens não baseadas em MVP para o

desenvolvimento de produtos, que são especialmente comuns no
desenvolvimento em cascata. Naquele mundo, você acaba gastando
muito tempo tentando construir o produto “perfeito” com todos os
recursos que você pode imaginar, leva uma eternidade para construir, e
uma vez no mundo real você descobre que os clientes não usam metade
das características que você pensou que eles usariam.
Um diferencial importante entre os modelos de “cascata” e “lean”
é que o modelo “lean” ou “enxuto” alavanca os MVPs. Com uma
abordagem “enxuta”, você constrói a coisa mais simples possível, coleta
dados sobre como os clientes a usam e aprimora o produto, se necessário.

Isso permitirá que você trabalhe com bastante eficiência, criando apenas
os recursos que os clientes desejam e usarão em vez de perder tempo
criando coisas com as quais os clientes não se importam.
Gastar muito tempo interagindo internamente e construindo recursos

sem lançar um produto pode ser bastante prejudicial para o seu negócio.
Com nosso exemplo de aplicativo CNN hipotético, se não adotássemos
uma abordagem baseada em MVP, poderíamos decidir replicar o site
completamente, incluindo recursos como comentários, vídeos enviados
por usuários e fluxos de notícias personalizados. A criação de todos esses
recursos pode atrasar nosso lançamento em meses e quem sabe quanto
de nossa base de clientes usaria esses recursos em seus celulares. Sim, 25
poderíamos usar as métricas do site para priorizar esses recursos, mas

esperamos que você entenda. Além disso, enquanto gastávamos muito do
nosso tempo e criávamos recursos para nosso aplicativo inédito, nossos
clientes queriam um aplicativo de notícias para celular e recorreram à
Fox News ou outro concorrente que criou seu aplicativo usando uma
abordagem baseada em MVP. Os clientes se preocupavam com a função
principal - receber notícias em qualquer lugar - e não quanto a todos os
recursos extras. E é difícil recuperar os clientes depois que eles se voltam
para um concorrente!
A maioria das empresas que usa um modelo híbrido nunca constrói

um verdadeiro MVP, mas sim um MVP com alguns recursos extras que
eles acreditam que tornarão o produto mais atraente. Se você sabe que
certos clientes desejam esses recursos importantes, incorporá-los desde o
início ajudará a reduzir o ciclo de iteração.
Para ser justo, o desenvolvimento de hardware geralmente exige que
você tente criar mais do que um MVP, pois disponibilizar uma atualização
de hardware é muito mais complexo do que uma atualização de software.
Mas manter o MVP em mente, mesmo com hardware, ajudará você a
priorizar seus esforços de desenvolvimento.
Às vezes, como discutiremos no Capítulo 4, seu primeiro MVP será

baseado em recursos humanos, e não em automação. Por exemplo, se
você é um gerente de projeto no Yelp e deseja adicionar um recurso
de recomendação de restaurante, acabará criando um algoritmo
totalmente automatizado para gerar recomendações. Mas você pode
criar um MVP inicial que faça parecer que o usuário está recebendo
recomendações automatizadas quando realmente quem faz é um ser
humano e envia essas listas. Se muitas pessoas curtirem e usarem esse
recurso, ótimo, você criará o mecanismo de automação. Se ninguém
26 usá-lo, então este pequeno MVP economizou o seu tempo e esforço em
construir o recurso completo.
THE PRODUCT BOOK
Tão importante quanto definir o escopo do problema é definir suas

métricas de sucesso. Quais são seus objetivos para o produto e como você
mantém a pontuação para ver se está os alcançando?
Voltando à CNN.com, seu objetivo final pode ser se tornar o local de

notícias que as pessoas mais procuram. Isso significa que suas métricas de
sucesso incluem o número de visualizações em uma parte do conteúdo,
a porcentagem de pessoas que consomem cada conteúdo, o número de
artigos lidos ou vídeos assistidos em uma sessão e como a pessoa chega
até o site da CNN.com. A razão pela qual não usamos apenas exibições de
página em um conteúdo é porque uma pessoa pode clicar em um artigo,
mas nunca lê-lo. Isso significa que a pessoa não está realmente recebendo
notícias/ consumindo conteúdo da CNN.com.
Os Product Managers criam um documento que engloba toda a
fase de planejamento, chamado de documento de requisitos do produto
(PRD), coletando todas essas informações de planejamento em um único
local. Um PRD contém a explicação de por que você está buscando essa

oportunidade, a definição do problema para alcançar o escopo, as métricas
de sucesso e muito mais. No entanto, você não cria o PRD isoladamente;
você trabalha com sua equipe, seu chefe e outras partes interessadas do
produto para garantir que as oportunidades e os requisitos sejam claros e
que as metas sejam alcançáveis.
Um dos maiores motivos pelos quais outras partes interessadas, como

líderes em design e engenharia, estão envolvidas no PRD é que caberá
a elas - não ao Product Manager - descobrir a solução certa para essa
oportunidade. Afinal, as equipes de design e engenharia são especialistas
em seus domínios, e o Product Manager não é, mesmo que ela tenha
27
iniciado sua carreira em um desses domínios!
Os PRDs ganharam uma má reputação através do desenvolvimento

em cascata porque eram documentos gigantes que as pessoas não
gostavam de ler. Na verdade, o modelo enxuto não usa em grande
parte os PRDs. No modelo híbrido, o PRD é tratado como uma ótima
ferramenta de comunicação para colocar todos na mesma página e
como um documento - vivo - sem decretos. Durante o ciclo de vida
de desenvolvimento de produto, o PRD se expandirá para conter mais
informações, mas começa explicando claramente o problema e por
que estamos trabalhando nele. Quando o produto é construído, o PRD
fornece uma excelente referência para as equipes de vendas e suporte,
para entender o que está no produto e por quê. Examinaremos como
efetivamente escrever e usar um PRD no Capítulo 5.
Assim que tivermos este primeiro rascunho de um PRD - identificando
claramente a métrica de oportunidade/ problema e sucesso - e todas
as partes interessadas concordaram em qual próximo problema deve
ser trabalhado, passaremos para a próxima fase do ciclo de vida do
desenvolvimento de produtos.
Projetando a Solução
Durante essa fase, abordada em detalhes no Capítulo 6, descobriremos
uma solução viável para o problema que identificamos.
Aqui, os PMs trabalharão principalmente com a equipe de projeto,

mas a equipe de engenharia também oferecerá informações para ajudar
a avaliar a viabilidade. Por exemplo, um PM da CNN.com pode ter
descoberto que seus leitores completam muito mais artigos quando um
vídeo em 360° de realidade virtual é incluído, ou seja, melhores métricas
28 de sucesso, e o PM deseja integrar vídeos em 360º em mais conteúdos. A
equipe de design pode então criar projetos em que todas as notícias de
THE PRODUCT BOOK
última hora tenham um vídeo de 360° transmitido ao vivo para colocar os

espectadores ali mesmo com o repórter, mas a equipe de engenharia pode
não conseguir criar uma solução de transmissão ao vivo. Isso significa
que a equipe de projeto precisa apresentar outra solução que a equipe de
engenharia possa implementar.
Embora o próprio PM não consiga a solução sozinho, ele continuará

ativamente envolvido nessa fase. Ele provavelmente trabalhará de
perto com o design para conduzir pesquisas de usuários, observando o
comportamento atual das pessoas. Ele também ajudará a se comunicar
com a Engenharia para garantir que o Design não esteja funcionando
de forma isolada. Todos estão trabalhando juntos para resolver os
problemas do cliente.
Ao contrário da crença popular, design não significa apenas a aparência
da solução. O design envolve aspectos como arquitetura da informação
(em que ordem as coisas são apresentadas ao usuário?), wireframes (onde
as informações devem ficar na tela?) e pixels (como eles são exibidos?). É

incomum encontrar um designer que seja especialista em cada um desses
aspectos, e um PM provavelmente estará trabalhando com uma equipe
de design, em vez de apenas um designer para descobrir como o produto
deve funcionar e quanto sua aparência.
Se possível, você desejará que a equipe de design produza protótipos

das soluções que eles possam testar com os clientes para validar o design.
Esses protótipos podem ser impressões que você altera quando o cliente
clica em algo, modelos clicáveis que trabalham com dados falsos, etc. O
segredo é ter algo que represente com precisão a solução, mas você possa
simular sem precisar criar a solução .
29
O design é feito apenas quando você validar um protótipo como uma
solução adequada. A equipe de Engenharia concordou com a viabilidade
da solução e você definiu a aparência e uma solução que todas as partes
interessadas concordaram.
Criando uma Solução

Depois de definir o problema e criar uma solução, é hora de construí-la.
As empresas têm diferentes abordagens para implementar soluções,

dependendo de sua história, do produto e de seus desejos. Por exemplo,
se você estiver trabalhando em um aplicativo para dispositivos móveis,
é muito fácil lançar uma nova versão para os clientes toda semana, e o
desenvolvimento provavelmente se concentra em versões menores, mas
mais frequentes - o desenvolvimento lean ou enxuto é muito comum em
aplicativos móveis e da rede. Se você estiver construindo um hardware,
há muito tempo entre o design do produto e quando o hardware estará
pronto para produção em massa. As empresas de engenharia de hardware
geralmente têm menos lançamentos, mas de alta qualidade. Afinal, é
difícil lançar uma atualização de hardware para corrigir um erro!
No Capítulo 7, abordaremos algumas das metodologias mais

comuns de desenvolvimento de software, além de dicas para trabalhar
com engenheiros.
Basta dizer que o PM permanecerá envolvido durante o

desenvolvimento, ajudando a priorizar erros (fazendo revisões do
acúmulo), testando softwares e fazendo o que for necessário para ajudar
no lançamento do produto. Uma nota de cautela, se você for atualmente
um engenheiro que deseja fazer a transição para o Product Management
30 - o desenvolvimento pode se tornar a fase mais frustrante para você,
porque você não será mais um engenheiro. Você não estará escrevendo
THE PRODUCT BOOK
códigos para o produto ou dizendo às pessoas qual código escrever. Seu

trabalho é ficar de lado e deixar as pessoas que ainda são engenheiras
escreverem o código. Você os ajuda no que mais puder, mesmo que
isso signifique trazer o café, mas não lhes diga o que fazer, a menos que
peçam sua ajuda.
Além disso, como PM, você será colocado em posições em que terá
que negociar a contratação de dívida técnica, o que significa que você
precisa pedir à equipe de engenheiros para escrever um código que não
seja sustentável a longo prazo para fazer algo à curto prazo.
Engenheiros odeiam assumir dívidas técnicas - eles querem escrever

uma resposta completa desde o início. Se você vem de uma formação
em engenharia, assumir dívidas técnicas pode ser difícil. Como PM,
muitas vezes, você terá que tomar decisões difíceis, aceitando dívidas de
curto prazo para fornecer valor ao cliente mais rapidamente. O oposto
também acontece, o que é difícil para os PMs de uma formação não

técnica. Você terá que pagar essa dívida mais tarde, limpando o código.
Caso contrário, o código pode ficar pesado e pode se tornar muito
difícil interagir com o projeto.
Além disso, embora estejamos apresentando o ciclo de vida de

desenvolvimento de produtos de maneira muito linear, é muito mais
iterativo na vida real, especialmente entre o design e a criação da solução.
Por exemplo, embora o Design tenha descoberto os casos de uso mais
comuns no estágio de prototipagem, provavelmente há muitos casos
extremos que surgirão enquanto a Engenharia constrói o produto.
O pessoal do Produto, do Design e da Engenharia trabalharão juntos 31

para atender a essas necessidades e questões que surgem durante o
trabalho no produto.
Durante a fase de desenvolvimento, um gerente de projeto deve

tentar encontrar oportunidades efetivas para compartilhar protótipos
do produto com clientes ou pessoas dentro da empresa, para que você
possa obter uma avaliação antecipada sobre o produto. Ele atende às
necessidades do cliente de forma eficaz ou há um grande comércio que
você não previu? Se você priorizar a criação do produto mínimo viável
identificado anteriormente, poderá começar a testar o produto principal
quando o MVP estiver pronto. É importante solicitar essa avaliação nos
momentos certos -se você esperar até o momento certo para liberar a
avaliação, talvez não tenha tempo de agir de acordo com o que aprender.
Novas informações que afetam o escopo do produto também podem
surgir durante o desenvolvimento. Voltando ao nosso exemplo de vídeos
ao vivo em 360° na CNN.com, talvez uma empresa de terceiros tenha
lançado uma ferramenta que facilita a transmissão desses vídeos ao vivo.
Seria mais fácil para os engenheiros da CNN.com adicionar vídeo em 360º
no local a notícias de última hora, que originalmente eram consideradas
fora do escopo devido ao desafio técnico.
Na abordagem de desenvolvimento de produtos que apresentamos

neste livro, é sempre melhor fazer mais pesquisas antecipadamente,
para que você não desperdice recursos projetando uma solução e tenha
que alterar uma grande parte dela. Mas os melhores Product Managers
são aqueles que sabem que não conseguem definir tudo com perfeição
e que geralmente é impraticável passar meses tentando fazê-lo. Em vez
disso, eles fazem o possível para planejar, mas também procuram novas
informações para ajudar a melhorar o produto, e reagem às mudanças
32 necessárias de braços abertos.
THE PRODUCT BOOK
A fase de desenvolvimento do ciclo de vida do desenvolvimento do

produto é feita quando um produto funcional, que foi totalmente testado,
está finalmente pronto para ser lançado.
Compartilhando a Solução
Por mais que gostaríamos de acreditar que, se construirmos algo,
os clientes farão filas para comprar, o mundo não funciona dessa
maneira. O marketing de produto (Capítulo 8) - na verdade, marketing
em geral - é uma parte extremamente importante do ciclo de vida
de desenvolvimento de produto e realmente começa depois que
construímos a solução. Esta fase do ciclo de vida é onde lançamos nosso
produto, compartilhando com o mundo e deixando que nossos clientes
saibam como nosso produto os ajudará.
Contar ao mundo sobre o nosso produto de forma efetiva é tão
importante que algumas empresas até criam uma posição separada,
o gerente de marketing de produto. Um Gerente de Marketing de
Produto é muito semelhante a um PM, mas um PM tende a ser mais

focado internamente - criando o produto - enquanto um GMP é
focado externamente - trabalhando com os clientes para entender suas
necessidades e para comunicar o valor do produto.
No início do primeiro estágio do ciclo de vida de desenvolvimento

de produtos, antes mesmo de definir a oportunidade, deve ficar claro o
que esse produto fará pelo cliente. Esta não é uma lista de quais recursos
ele possui ou do que o produto faz, mas sim qual será o problema
que ele resolverá. Na fase de marketing do produto do ciclo de vida
de desenvolvimento de produtos, você descobre como comunicar de
forma sucinta e eficaz como o produto resolve esse problema e torna o
33
cliente impressionante. É essencialmente como contar histórias, e o que
chamamos de “mensagens”.
Por exemplo, voltando ao recurso de vídeo de realidade virtual ao vivo

de 360 ° da CNN.com, se promovêssemos o recurso em si, “a transmissão
do vídeo ao vivo em 360° de realidade virtual”, a maioria dos clientes não
saberia o que isso significa - ou se importaria. Em vez de falar sobre o
recurso específico, podemos nos concentrar no valor e no benefício que
esse recurso oferece: “Esteja em cena com nossos repórteres”. Podemos,
então, continuar dizendo qual é o recurso e como usá-lo, mas levei com
uma mensagem clara a razão pela qual um cliente deve se importar.
Essa fase do ciclo de vida de desenvolvimento de produto é mais

do que apenas mensagens, no entanto. Também vamos planejar o
lançamento do produto. A versão pode envolver o planejamento de um
teste beta, a criação de ativos de marketing para um site ou anúncio, o
trabalho com parceiros-chave antes do lançamento, a apresentação de
informações à imprensa ou o planejamento de um evento de lançamento.
As necessidades exatas variam de lançamento a lançamento. Em termos
gerais, essa fase do ciclo de vida do desenvolvimento do produto é
feita quando o produto é lançado, mas provavelmente haverá muitas
campanhas e tarefas de marketing para ajudar a alcançar as métricas
de sucesso do produto, além do lançamento. O marketing continuará
mesmo quando a equipe, internamente, passar para a próxima versão do
produto ou para um produto completamente diferente.
Avaliando a Solução
A última fase do ciclo de vida de desenvolvimento de produtos é avaliar
como foi a recém-concluída iteração do ciclo, ver se você está no caminho
certo para atingir suas métricas de sucesso e sugerir o que fazer para a
34 próxima etapa. iteração. Como você pode imaginar, essa recomendação é
inserida na fase de planejamento inicial da próxima iteração.
THE PRODUCT BOOK
Durante essa fase, você se encontrará com a equipe com a qual você
construiu o produto e avaliará como foi. Todos ficaram tão esgotados
que metade da equipe desistiu? A equipe ficou muito feliz com o
processo e empolgada em trabalhar no próximo projeto? Qual foi a
força competitiva global da equipe e em que a equipe poderia melhorar?
Use esta avaliação para determinar o que correu bem e o que você deve
fazer diferente na próxima vez.
Agora que o produto foi lançado, você deve começar a ver dados
reais sobre como as pessoas o estão usando. Está de acordo com as suas
expectativas ou é algo distante do que você esperava? E o mais importante,
parece que você está no caminho certo para alcançar suas métricas
de sucesso? Por exemplo, a CNN.com pode ver quantas pessoas estão
assistindo às novas transmissões em 360° e se o número total de pessoas
que recebem conteúdo da CNN aumentou após o lançamento desse
novo recurso. Se o número de pessoas assistindo a essas transmissões e

buscando mais conteúdo na CNN tiver melhorado, então seu produto foi
um sucesso. Se não houver mudanças, avalie por que essa estratégia não
funcionou da maneira esperada. Por que os clientes não gostam disso?
Uma vez que você teve a chance de ver como seu novo produto
foi recebido por seus clientes, você irá fazer uma recomendação para
o que vem a seguir: você deve iterar mais sobre esse recurso/produto,
mudar para outra coisa ou acabar com este recurso/produto? Essa
recomendação ajudará a informar a próxima iteração durante o ciclo de
vida do desenvolvimento do produto e explicaremos como criar uma boa
recomendação no Capítulo 9.
35
Como você pode ver, o gerenciamento do produto e o ciclo de vida
do desenvolvimento do produto são muito importantes. Mas não se
preocupe, os capítulos a seguir dividirão cada etapa com mais detalhes e
o ajudarão a entender como ser um ótimo Product Manager que produz
produtos incríveis que os clientes adoram.
CAPÍTULO DOIS
O ESTRATEGICAMENTE ENTENDENDO
UMA EMPRESA
36 Uma das primeiras coisas que um ótimo Product Manager deve fazer
antes de pensar em um produto é entender a empresa que o produz.
THE PRODUCT BOOK
Cada empresa é um pouco diferente e tem diferentes prioridades, valores,

pontos fortes e fracos. Conhecer esses detalhes sobre uma empresa -
entender o contexto completo de sua situação atual - é o ponto de partida
para encontrar e avaliar oportunidades de produtos e tomar decisões
estratégicas sobre os produtos. Vamos nos basear em como aproveitar
esses detalhes nos próximos capítulos.
A análise de uma empresa se divide em três categorias principais:

Qual produto estamos construindo? Como sabemos se o produto é bom?
O que mais tem sido, está sendo e será construído?
QUAL PRODUTO ESTAMOS CONSTRUINDO?

Esta categoria de análise é focada no produto atual da empresa. Pode
ser um produto existente que você tem a tarefa de melhorar ou pode ser
o próximo novo produto que você deseja criar.
Por Que a Empresa Existe?
2. Estrategicamente Entendendo
A coisa mais fundamental a entender sobre uma empresa é porque
ela existe. Qual é a sua missão ou, ainda mais importante, a sua crença
central: o valor que agrega ao mundo que o diferencia de outras empresas?
Simon Sinek tem uma ótima palestra no TED chamada “Como
Grandes Líderes Inspiram a Ação” e um livro sobre o mesmo tema,
chamado “Comece Com o Porquê”. Em ambos, ele defende o que ele
chama de Círculo Dourado (Figura 2-1). Especificamente, ele diz que o
“porquê” de uma empresa é o que as pessoas realmente se importam e
compram. Como você entrega esse valor e os produtos que você criar
serão construídos sobre esse valor central. Do ponto de vista do produto,
“por que” é a sua luz orientadora - ela vai ajudá-lo a descobrir o que é 37
mais importante do que a razão da empresa existir e o que não existe.
Em outras palavras, os produtos que você constrói são um meio para um
fim. Esse “fim” é o quadro maior e o que os clientes compram/ desejam
alcançar quando compram seus produtos.
Pense em como contar histórias - o “porquê” é o tema. O que seria

essa história? Que ponto de vista específico o escritor quer compartilhar
com o mundo que o levou a escrever a história? Temas em filmes são
muitas vezes óbvios: o amor vence tudo, a vingança não leva à felicidade,
etc. O tema de uma empresa pode ser um pouco mais difícil de decifrar.
Muitas vezes, seu tema é expresso como um valor dentro da declaração
de missão da empresa, que você geralmente encontra no site. Mas mesmo
que uma empresa tenha uma declaração de missão clara com um tema
claro, ela pode esquecê-la ao tomar decisões, levando a resultados mistos.
Vamos ver o exemplo de Sinek da Apple. Se a Apple começasse com “o
quê”, o que muitas empresas fazem, Sinek afirma que sua mensagem seria:
“Nós fazemos grandes computadores. Eles são intuitivos, são lindamente
projetados e fáceis de usar. Quer comprar um?” Tudo bem, mas parece
bem genérico. Muitos outros fabricantes de PC até fazem exatamente a
mesma afirmação!
PORQUÊ
38 COMO
THE PRODUCT BOOK
O QUÊ
Figura 2-1. Círculo Dourado de Simon Sinek, começando com “por que” como o aspecto
mais importante de uma empresa.
Em vez disso, lembre-se da campanha Pense Diferente, que a Apple

fez no final dos anos 90, que falou sobre o “porquê” da Apple sem
sequer mencionar os produtos: “Um brinde aos loucos”. A partir dessa
declaração de missão, Sinek diz que uma mensagem de marketing mais
realista da Apple seria: “Tudo o que fazemos, fazemos para desafiar o
status quo. Nosso objetivo é pensar diferentemente. Nossos produtos são
intuitivos, belamente projetados e fáceis de usar. Nós apenas fazemos
grandes computadores.
Quer comprar um?”
Esta versão começa com o “porquê ”(desafiar o status quo), então
segue-se para o “como” (sendo fácil de usar, etc.) e, finalmente, o “o
quê” (vendendo grandes computadores). É muito mais atraente do que a
primeira versão, e também diz muito mais sobre o que a Apple representa
e quem são como empresa.
O “Por que” está no cerne do Círculo Dourado porque é a coisa mais
fundamental que você precisa entender sobre uma empresa. Tudo o
que uma empresa faz, desde os produtos que constrói até as decisões de
recurso que faz para esses produtos, deve emergir desse valor. Se isso não
acontecer, há uma boa chance de que a decisão não esteja funcionando
bem para a empresa.
O Google escreve sua declaração de missão como “Organizar as
informações do mundo e torná-las universalmente acessíveis e úteis”.
Há uma proposta implícita de valor para impulsionar a raça humana,
que o Google faz principalmente com dados. É improvável que você
faça o mesmo com uma torradeira, mesmo que esteja conectada por 39
Wi-Fi, porque isso não organiza as informações do mundo, não as torna
acessíveis ou nos impulsiona. No entanto, o Google comprou a Nest, que
fabricava aparelhos semelhantes, incluindo um termostato e um detector
de fumaça. Os produtos da Nest envolvem a organização de informações
sobre sua casa e a aplicação da ciência da computação a essas informações
para melhorar a função da sua casa. O Termostato Nest aprende seu
comportamento e adapta automaticamente como aquece e esfria sua casa
para economizar energia - economizando seu dinheiro - enquanto ainda
mantém você confortável.
Vale a pena notar que todas as empresas cuja missão fundamental é

“ganhar dinheiro”, em vez de se concentrar no valor que podem adicionar
à vida dos clientes, fracassaram. Sinek discute isso em detalhes em
sua palestra. Se sua empresa funcionar bem e os clientes quiserem os
produtos que você estiver produzindo, você ganhará dinheiro. A renda
é a validação de que uma empresa está fazendo a coisa certa para seus
clientes - a renda não deve ser o motivo de uma empresa existir. Isso
não é apenas verdade para campanhas socialmente conscientes como
a TOMS, a empresa de calçados, mas sim para todas as empresas. Os
clientes pagam pelo seu produto porque isso melhora a vida deles, não
porque eles querem lhe dar dinheiro.
Da mesma forma, as empresas que começam sem uma missão, mas
com alguma invenção à qual tentam encontrar um uso, geralmente
falham. Especificamente, se sua empresa começou porque alguém disse:
“Essa é uma boa ideia - podemos vendê-la?”, Em vez de “Essa invenção
tornaria a vida das pessoas melhor porque ...”, onde você tem uma
solução procurando um problema. Uma inovação de engenharia, por si
só, não cria um produto - os produtos são soluções para os problemas
que as pessoas enfrentam. Com frequência, você ouve as empresas
40 recém-criadas falarem sobre “dinamização” porque elas descobriram
que os clientes não queriam o produto que elas criaram, e a empresa
THE PRODUCT BOOK
recém-criada está tentando adaptar o que ela criou para algo que os
clientes usarão.
Algumas empresas são moderadamente bem-sucedidas sem ter
uma declaração de missão clara. Mas eles lutam para crescer porque
não está claro para a liderança por que o produto foi bem-sucedido e
como expandir a sua linha de produtos. O resultado é um portfólio de
produtos que se sente muito desconectado. A Misfit, que foi comprada
pela Fóssil, obteve sucesso com seu rastreador de atividade de tecnologia
utilizável da Shine, mas não tinha uma missão clara. Seus produtos de
acompanhamento incluíam uma lâmpada inteligente e um sensor de
sono, e eles não conseguiram ganhar muita atenção. A Misfit parece
estar ciente desse problema e tentando consertá-lo, já que agora está
focada em tornar as tecnologias utilizáveis uma parte natural de sua vida,
com rastreadores de atividades conscientes da moda e fones de ouvido
inteligentes com um rastreador de atividades integrado. A proposição
implícita de valor é que a Misfit quer que você viva uma vida melhor, e
isso permite que você analise sua vida, especialmente sua saúde.
Como Product Manager, manter a proposta de valor central da empresa
em mente ajudará você a entender a visão da empresa. E entender a visão
permitirá que você entenda os objetivos da empresa, o que permite que
você entenda o roteiro de seu produto. Estamos colocando a carroça à
frente dos bois aqui! Basta dizer que sua primeira tarefa ao olhar para
uma empresa do ponto de vista de um produto deve ser para entender o
seu “porquê”.
Clientes e Personas
A parte mais fundamental de uma empresa, depois de entender
por que ela existe, é saber para quem está solucionando problemas. 41
Essencialmente, quem são os clientes de seu produto e por que estão

comprando seu produto? Você otimizará seus produtos para essas
personas. Imaginemos que estamos construindo um acessório de câmera
que se conecta ao iPhone, como o DxO ONE. Seus clientes provavelmente
gostam de fotografar com seus smartphones, mas querem uma melhor
qualidade de imagem do que a câmera integrada oferece.
Como somos específicos do iPhone, não nos importamos com pessoas

com celulares Android. E, como estamos criando um acessório para o
qual as pessoas precisam pagar mais, vamos ignorar as pessoas felizes
com a câmera integrada. Mas mesmo entre todos os clientes com os quais
nos importamos, há muita variabilidade. Talvez alguém simplesmente
adore tirar fotos de seus cachorros enquanto outro tira fotos de seus
furões. Lidar com muitas pessoas reais e sua variabilidade pode gerar
discussões complexas - nosso acessório de câmera precisa funcionar para
gatos, cachorros, furões, coelhos etc. Em vez disso, seria mais fácil se
apenas deixássemos as coisas abstratas e disséssemos: “Nossos clientes
tiram fotos de seus animais de estimação”.
Podemos usar os vários traços comuns com os quais nos preocupamos
em nossos clientes em potencial e abstraí-los em uma persona. Uma
persona é um cliente fictício e típico, e a definição de pessoas-chave
permite segmentar seus clientes, destacando as coisas com as quais seus
clientes se importam e que são relevantes para o seu produto. Personas
são ferramentas para ajudá-lo a entender seus clientes, mas elas não são
clientes finais reais. Uma ótima maneira de pensar sobre a diferença é
que o Facebook e o Snapchat têm muitos dos mesmos clientes, mas suas
personas internas - como segmentam esses clientes e com quais aspectos
do produto se preocupam - são diferentes.
42 Você provavelmente já falou sobre uma persona sem perceber.

Quando alguém pergunta: “Minha mãe pode usá-lo?”, Eles não querem
THE PRODUCT BOOK
dizer a mãe real, mesmo que ela seja uma cientista espacial. Em vez disso,
eles querem dizer a persona “mãe” de uma pessoa de meia-idade que está
pela primeira vez a comprar uma nova tecnologia, e quebrará muitos
dispositivos simplesmente tentando ativá-los. Quando dizemos: “Minha
mãe pode usá-lo?”, Na verdade, estamos perguntando se o produto é fácil
de usar e que alguém de persona “mãe” pode usar o produto para atingir
uma meta sem quebrá-lo e sem pedir ajuda.
Boas personas terão uma foto e um nome fictício. Elas incluirão

detalhes relevantes sobre a vida da pessoa, como dados demográficos,
atividades externas e tarefas comuns, além de quais problemas a pessoa
está tentando resolver. Pense em uma persona completa como uma
maneira de dar vida a um cliente típico - você quer detalhes suficientes
para se imaginar no lugar da pessoa. Roman Pichler colocou isso em um
modelo que você poderá preencher para começar a criar suas próprias
personas (Figura 2-2).
TEMPLATE DE PERSONA DE ROMAN
FOTO & NOME DETALHES OBJETIVO

Como esta persona se Quais são as características Por que a persona usaria ou
parece? Qual seu nome? e comportamentos compraria o produto? Qual
Escolha uma foto e um nome relevantes desta persona? benefício a persona deseja
que sejam apropriados e que Por exemplo, dados alcançar? Qual problema a
o ajude a simpatizar com demográficos como idade, persona deseja solucionar?
esta persona. gênero, profissão, e renda;
psicográficos incluindo
estilo de vida, classe social,
e personalidade; atributos
comportamentais, como
padrões de uso, atitude,
e fidelidade à uma marca.
Apenas liste detalhes
relevantes.
43
Figura 2-2. Modelo de criação de personas de Roman Pichler, disponível em

www.romanpichler.com e incluído sob a licença não-portada de Atribuição-Partilhada nos
Mesmos Termos 3.0 da Creative Commons (CC BY-SA 3.0), https://creativecommons.org/
licenses/by-sa/3.0.
Embora seja tentador tornar suas personas muito detalhadas, descrevendo

todos os aspectos da vida da persona, ela pode rapidamente ficar
sobrecarregada com muitos detalhes irrelevantes. No geral, mantenha
as personas da forma mais ampla possível, mas com detalhes suficientes
para que elas sejam críveis e representem um verdadeiro mercado-alvo.
Se você estiver se perguntando como fazer isso, escreva uma persona
detalhada e, para cada declaração que fizer sobre a pessoa, se ela não for
relevante para o seu produto, exclua-a.
As principais coisas que você procura são as prioridades dessa
persona, relacionadas ao seu produto/ área de especialização. O que a
persona “Tiago do TI” está tentando fazer que seja significante e o que
seria realmente insignificante: quais pontos de dor extrema ele tem
e quais pontos de dor são insignificantes? Quais são as coisas que ele
deve ter de qualquer solução que você crie? Por exemplo, o “Tiago do
TI” pode estar muito ocupado todo o seu dia de trabalho com emails de
suporte ao cliente. Ele provavelmente se beneficiaria de um novo sistema
de implantação de máquinas automatizadas em vez de um sistema que
envolve muita intervenção manual.
Uma maneira de visualizar as prioridades desses clientes é imaginar

a jornada do cliente. Qual é o problema que uma determinada persona
esteja tentando resolver, o que ela faz quando tenta resolver e o que
acontece como resultado? Conte-nos uma história sobre o cliente.
44
Não se esqueça do lado social ou emocional. O aparelho freio de burro
THE PRODUCT BOOK
pode resolver problemas ortodônticos - um ponto de dor significativo

- mas você quer ser o garoto no parquinho que precisa usar o freio de
burro durante dois anos? Outros fatores, como canais de distribuição que
alcançam as várias personas e se estão dispostas a pagar por diferentes
partes do produto, podem ajudar a diferenciar as personas. As personas
contêm informações demográficas apenas se forem relevantes. Por
exemplo, as personas “hospedeiras” do Airbnb provavelmente não
incluem o valor que cada pessoa ganha por ano, mas provavelmente
incluem o motivo pelo qual uma pessoa está interessada em alugar seu
lugar. Um jovem anfitrião urbano pode estar alugando um sofá ou um
segundo quarto para ajudar a pagar o condomínio. Na verdade, ele pode
ter que fazê-lo, o que significa que ele se preocupa mais em maximizar
o quanto ele ganha por seu espaço em relação a ter alguém lá o tempo
todo. Um casal de aposentados que são como andorinhas, migrando da
Pensilvânia para a Flórida a cada inverno, pode querer alugar sua casa de
férias quando não a estiver usando para complementar sua renda. Eles
provavelmente preferirão os hóspedes do Airbnb que permanecem por
períodos mais longos e tratam a casa como se fossem deles, mesmo que
isso signifique que sua casa de férias esteja vazia periodicamente.
Isso pode ir contra ao que você sabe sobre a típica teoria de marketing,
onde a demografia é a chave. Repetidas vezes, a teoria e a prática dos
produtos mostraram que se concentrar em um problema, dor ou desejo
comuns produz uma melhor segmentação do que a demografia.
O professor da Faculdade de Negócios de Harvard, Clayton
Christensen, vem trabalhando por mais de uma década em uma
abordagem de segmentação de clientes que ele chama de “trabalhos a
serem feitos”. Pensar dessa maneira o ajuda a construir grandes personas.
O exemplo que Christensen dá é que quando uma empresa de lanchonetes
tenta melhorar suas vendas de milkshake, primeiro faz a segmentação 45
demográfica tradicional e pergunta a cada pessoa (por exemplo, o
típico bebedor de milkshake de 18-35 anos) sobre seu milkshake ideal e
implementa mudanças.
As vendas estavam estagnadas. Mas quando a empresa de lanchonetes
se concentrou em quem comprou os milkshakes, quando os comprou
e onde os bebeu, encontrou uma maneira diferente de segmentar seus
clientes. Um segmento comprou milkshakes pela manhã para mantê-
los satisfeitos até o almoço. Como um benefício adicional, o milkshake
da manhã deu-lhes algo para ocupar sua mão livre durante a condução
por um trajeto chato. Aquele grupo quer um milkshake que demore um
pouco mais para ser bebido, para que eles se sintam mais satisfeitos e para
que dure mais. Agora considere outro segmento: clientes que compram
milkshakes como um tratamento especial para crianças pequenas.
As crianças provavelmente só querem um petisco saboroso e não têm
paciência para beber um milkshake por 30 minutos. O uso de dores e
objetivos, em vez de apenas demografia, ajudará você a segmentar seus
clientes em personas úteis.
É possível que seu produto tenha várias personas. Por exemplo, as
pessoas que lêem e escrevem comentários no Yelp são clientes, mas as
empresas que essas pessoas analisam também são clientes do Yelp. Crie
várias personas, se necessário, e identifique o principal que elas desejam
satisfazer. Às vezes, o cliente e o comprador - a pessoa que usa o produto
e a pessoa que realmente o compra - não são os mesmos, como os pais
que compram um balanço para seus filhos. Isso é comum com softwares
corporativos, e você precisará criar personas separadas para esses casos.
Em última análise, seu objetivo com cada persona é ter informações
e detalhes suficientes sobre essa categoria de cliente ao ponto de você
poder se imaginar no lugar dessa pessoa. Isso ajudará com que você tenha
empatia por esse cliente, entenda seus pontos problemáticos e pense em
46 maneiras pelas quais seu produto pode resolver essa dor (abordaremos
isso em detalhes no Capítulo 3).
THE PRODUCT BOOK
Como as personas o ajudam a entender como é um grupo de clientes,

uma peça essencial de uma persona é ser autêntica - se você descobrir
que sua persona está incrivelmente ocupada, trabalhando mais de
80 horas/ semana, quanto tempo você acha que ela terá? Ela terá que
aprender como usar seu produto? Se você deixar de notar como a sua
persona funciona, você pode tomar as decisões erradas para o produto,
assumindo que essa persona tem tempo de assistir a um longo tutorial de
vídeo sobre integração.
Sempre que você começar a trabalhar em um novo produto ou em

uma nova empresa, descubra o mais rápido possível quem são as personas
relevantes. Certifique-se de que elas estejam claramente escritas no
formato Nome/ Foto/ Detalhes/ Metas. Muitas empresas usam arquivos
do Word ou do Google Docs com seus dados de persona, e há ferramentas
especializadas que explicitamente gerenciam suas personas e organizam
a pesquisa que entra em cada uma delas (no momento em que escrevo, o
panorama das ferramentas de persona tem sido tão inconstante, que nós
decidimos deixar para você pesquisar e encontrar o panorama atual).
Se não houver nada escrito, é provável que a empresa tenha uma
ideia aproximada de quem sejam seus clientes. Use esse conhecimento
para escrever um primeiro rascunho da persona, e você irá revisá-la
com o tempo.
Não é obrigatório ter conhecimento pré-existente do cliente para criar
uma persona. Apenas crie um perfil aproximado de suas personas no
começo, e à medida que você aprende mais sobre seus clientes, refine
as personas, talvez dividindo-as e criando uma nova persona quando
surgirem as principais diferenças. Você pode até descobrir, enquanto fala
com os clientes e mostra a eles os protótipos de seu produto/ recurso, que
alguém que você achava que era a persona certa, na verdade não é. 47
Tome a Airbnb como exemplo. Mesmo que os viajantes de negócios

viajem com frequência, eles podem não ser a melhor persona para a
Airbnb se concentrar porque gastam seus quartos de hotel, o que significa
que não são sensíveis a preço, se importam mais com serviço do que com
um anfitrião e geralmente têm cartões de recompensas que permitem
acumular estadias gratuitas para viagens pessoais. A Airbnb se concentra
em tornar as interações com seu anfitrião e outros locais parte de sua
experiência de viagem. Os viajantes de negócios, no entanto, estão lá para
trabalhar, não para se sentirem locais. Tudo isso significa que eles estão
mais bem servidos em hotéis regulares, e a Airbnb pode optar por não
perder muito tempo segmentando essa persona agora.
Você também quer garantir que sua persona esteja alinhada com o
que seu produto faz. Se você estiver criando um software de folha de
pagamento para uma empresa de pequeno ou médio porte, suas personas
devem ser baseadas em cafés e consultórios médicos, e não em um pai que
trabalha em domicílio. Os pais que trabalham em casa não têm nenhum
motivo para comprar seu software e você quer gastar seu tempo tomando
decisões com base nos clientes que comprarão e usarão seu software.
Note que “todo mundo” não é uma persona, já que “todo mundo” é
muito vago para ajudá-lo a tomar decisões. Muitas pessoas acham que
grandes empresas como o Google, o Facebook e a Apple têm como alvo
a “todos”, mas não têm e são bastante diretos quanto a isso. O Facebook
começou voltado para uma persona, estudantes universitários. Com o
tempo, o Facebook cresceu, adicionando alunos do ensino médio e mais
além, e sua base de clientes atual é muito diversificada. O Facebook
provavelmente tem muitas personas internas, mas quando lança novos
recursos, eles ainda são direcionados a personas específicas. Uma
persona como um “Estudante do Colégio Henrietta” não se importa com
48 o recurso de comentários nas páginas de negócios, mas uma empresa que
criou uma página do Facebook certamente se importa!
THE PRODUCT BOOK
Outro grande atributo a considerar sobre suas personas é onde, na

curva de adoção, elas caem. Nem todo mundo compra/ começa a usar
algo novo ao mesmo tempo. Há uma teoria geral da adoção - que pode
se referir a um novo produto ou a um novo recurso - que diz que há um
pequeno grupo de adotantes precoces que precisam ser os primeiros a ter
coisas novas - pense na primeira pessoa que você conhece que possui um
relógio inteligente. Então, há um grupo um pouco maior de pessoas que
gostam de ser uma das primeiras - mas não necessariamente a primeira -
a ter algo novo. Pense na primeira pessoa que você conhece que comprou
um relógio da Apple, mas não tinha um relógio inteligente anteriormente.
Infelizmente, há uma lacuna (consulte a figura 2-3) antes de chegar ao
próximo grupo de pessoas. Se o seu produto for incrível e atender a uma
proposta de valor com a qual seus clientes se preocupam, você continuará
para a próxima etapa, a adoção em massa do mercado, quando a maioria
dos possíveis clientes comprar/ usar seu produto. Eventualmente, até
mesmo os adotantes tardios - as pessoas que parecem estar sempre anos
atrás de todos os demais - começarão a usar seu produto. Levar em
consideração onde suas várias personas se encaixam nessa curva, ajudará
você a entender quando elas provavelmente adotarão seu novo produto
ou recurso. Isso ajudará a priorizar recursos. Os adotantes precoces
tolerarão os recursos ausentes que os retardatários podem exigir, por
exemplo.
Participação de Mercado
49
Investidores
Adotantes Maioria Maioria
Precoces Precoce Tardia Retardatários
Período de Adoção
Figura 2-3. A curva de adoção em que o eixo x representa os grupos de clientes que
potencialmente comprarão seu produto ao longo do tempo. O eixo y representa a participação
de mercado aproximada de cada grupo.
Mas se o seu produto não for incrível, quando você atingir a lacuna
antes da adoção no mercado de massa, seu crescimento será interrompido
porque seu produto não fornece valor suficiente para a vida da maioria
das pessoas. O mercado de massa não vai adotá-lo.
Sempre que você pensar em como melhorar um produto, seus

primeiros pensamentos devem ser sobre quem são as personas-alvo e
quais necessidades delas não estão sendo atendidas pelo produto. Isso
oferece um ótimo filtro imediato para garantir que você tome decisões
estratégicas sobre o que fazer em seguida.
50
THE PRODUCT BOOK
DICA DO CAPÍTULO DOIS
Ao longo deste livro, para oferecer uma perspectiva adicional, pedimos a
Product Managers experientes que compartilhem seus melhores conselhos
sobre o tópico de cada capítulo.
Nossa primeira dica vem de Jeremy Toeman, vice-presidente de produtos
da CNET. Jeremy gerencia as equipes de desenvolvimento de público,
engajamento e mídia social da CNET, e ele é responsável pela criação de
produtos multicanais da CNET, incluindo aplicativos da rede, dispositivos
móveis e aplicativos. Jeremy tem mais de 20 anos de experiência, incluindo 51
ser VP de Product Management na Sling Media; trabalhando em Dropcam,

Sonos e Sphero; e fundando várias empresas que tiveram saídas bem-
sucedidas. Em outras palavras, ele sabe do que está falando! E aqui vai o que
ele tem a dizer sobre personas.
TORNANDO AS PERSONAS REAIS COM EMPATIA

Com aproximadamente 20 anos de experiência, percebi que a tendência
consistente é que os Product Managers definam personas com 90% de
dados demográficos e 10% de desejos / necessidades / emoções. Talvez
menos. Por exemplo, é fácil criar Júlia - uma jovem de 23 anos de idade
em um grande metrô que tem um colega de quarto, adora viajar e está
muito interessada no mundo dos DJs. Júlia está pensando em comprar
seu primeiro carro. Esse é um ótimo ponto de partida. Mas é apenas a
ponta do iceberg.
Júlia se importa com o que o carro diz sobre ela ou se preocupa com a
eficiência do combustível? Júlia está focada em economizar dinheiro ou em
valor de revenda? Júlia se preocupa com a tecnologia do carro, ou apenas
se preocupa que ela consiga chegar aos lugares? Além disso, Júlia aprecia o
processo de pesquisa, ou ela só quer ser apontada na direção certa? Ela vai
fazer uma pequena planilha de comparação para si mesma, ou apenas quer
arriscar e ver no que vai dar?
Com demasiada frequência, os produtos chegam ao mercado

sem considerar as necessidades do indivíduo, ao contrário dos dados
demográficos puros. Todos os cenários acima são válidos para um Product
Manager que está projetando um site/ aplicativo para atender aos
compradores de carros. Mas uma simples revisão de sites de compra de
carros mostra uma clara falta de consideração por necessidades emocionais
versus necessidades puramente práticas.
Quando a indústria da TV tentou trazer a tecnologia 3D para dentro
52 de casa, eles mostraram uma clara falta de empatia. Claro, os filmes em
3D estavam se saindo bem nos cinemas, então, logicamente, fazia sentido
THE PRODUCT BOOK
levar esse tipo de tecnologia para as casas. Mas um Product Manager

empático poderia facilmente prever a má recepção: as salas de cinema são
principalmente experiências solitárias (embora compartilhadas), enquanto
a família/ salas de estar são principalmente experiências sociais. E nenhuma
família quer se sentar no sofá usando um monte de óculos estúpidos (o que
não seria um problema em um cinema escuro).
Grandes Product Managers podem se colocar na mentalidade da persona
e realmente entrar em sua pele para entender os desejos e necessidades
e, mais importante, os gatilhos emocionais de seus usuários. E os Product
Managers realmente excelentes percorrerão muitas personas diferentes
ao considerarem as principais necessidades do produto. Esse processo
determina as sutis diferenças ao pegar bons produtos e transformá-los em
produtos excepcionais.
Casos de Utilização
Casos de utilização são simplesmente como uma empresa espera que
cada persona use o produto da empresa para atingir uma meta. Eles
fornecem o contexto para que você entenda o link entre suas personas e
seus produtos.
Dia a dia, um PM precisará pensar sobre os casos de utilização
que deseja apoiar para o produto, o que ajuda a encontrar e priorizar
oportunidades. Os casos de utilização afetarão tudo, desde os recursos
que você prioriza ao resolver os problemas de seus clientes, até para quais
clientes você comercializará seu produto.
Por exemplo, um caso de utilização chave para um iPhone é verificar

seu e-mail em qualquer lugar. A Apple tomará decisões de produto
para o iPhone que o ajudarão a saber quando você tem novos e-mails,
e permitirá que você responda ao e-mail, redija novos e-mails, e etc. Por
53
outro lado, o iPhone não foi projetado para ajudá-lo a pressionar dentes
de alho, apesar de que, teoricamente, você poderia usá-lo para fazer isso
- recomendamos comprar um espremedor de alho. A Apple se preocupa
com o primeiro, não com o segundo. As escolhas feitas serão focadas
em melhorar o email em movimento, mesmo que isso signifique que um
iPhone futuro não seja bom para cozinhar com alho.
Esse exemplo é bastante drástico e óbvio, então vamos ver um

exemplo mais sutil que as empresas geralmente enfrentam. Uma
categoria importante de empresa é chamada de empreendimento ou
B2B (de empresa para empresa), que se aplica a empresas que criam
ferramentas para atender às necessidades relacionadas ao trabalho de
outras empresas. Estes empreendimentos voltados para outras empresas
vão, frequentemente, escolher um tamanho de empresa do cliente
para se concentrarem - pequeno, médio ou grande porte - e depois se
concentrarem mais nas diretrizes selecionadas do setor.
Gusto, anteriormente ZenPayroll, é uma empresa de soluções de RH
para pequenas empresas. E percebeu que as pequenas empresas têm uma
ampla gama de necessidades complexas de “executar negócios” (RTB),
como RH, contabilidade e administração de escritórios. Normalmente,
uma única pessoa não pode realizar todas essas tarefas, as pequenas
empresas não têm recursos para contratar muitas pessoas para realizar
essas tarefas e as ferramentas existentes, como a ADP, são excessivas para
as pequenas empresas.
A persona inicial da Gusto provavelmente era dona de uma pequena

empresa - vamos chamá-la de “Suzana, a Dona de uma Pequena Empresa”.
O site da Gusto lista instâncias dessa persona, incluindo em seu repertório
empresas recém-criadas de tecnologia, lanchonetes, lojas de automóveis,
agências de criação, escritórios de advocacia e restaurantes. Estes são os
clientes que Gusto tem como alvo.
54 Vamos fingir que Suzana é dona de uma cafeteria. Coloque-se no lugar
dela por um segundo - quais são as tarefas do RTB com as quais ela tem
THE PRODUCT BOOK
que lidar? As mais simples são em torno da folha de pagamento: ela quer
uma maneira de coletar informações relacionadas ao W2 (formulários
de trabalho exigidos pelo governo dos EUA) para seus funcionários,
deseja uma maneira fácil de pagar funcionários e deseja uma maneira
automatizada de fornecer impostos em formação. Essas situações que ela
precisa encontrar uma solução - problemas que ela quer resolver - são
casos de utilização para os quais ela pode querer usar a Gusto, e a Gusto
provavelmente criará recursos para resolver esses problemas.
Na parte superior do site da Gusto, há um link da folha de pagamento.

Quando você clica nele, verá que a Gusto afirma especificamente como ela
tem um auto investimento de funcionário para W2s e mais, soluções de
folha de pagamento e impostos automatizados. Gusto criou recursos em
seu produto para permitir que ele funcione nesses casos de utilização que
sua persona alvo, a “Suzana, a Dona de uma Pequena Empresa”, possui.
Gusto inicialmente focou em um caso de utilização principal:
gerenciamento de folha de pagamento. Mas, com o tempo, expandiu
para cobrir mais casos de utilização, como o seguro de saúde. Com o
tempo, Gusto provavelmente continuará ajudando pequenas empresas a
simplificar suas tarefas de RTB. Eles abordarão mais casos de uso que a
“Suzana, a Dona de uma Pequena Empresa” precisa tratar.
No entanto, se uma grande empresa tentasse fazer uso da Gusto, o

negócio teria recursos em falta porque seus requisitos são mais complexos
do que os requisitos das pequenas empresas que a Gusto almeja. A Gusto
não lida com todos os casos de utilização de uma grande empresa, mas um
produto mais complexo, como o ADP, lida com esses casos de utilização.
55
Em seu percurso, Gusto poderia optar por expandir para apoiar
outro cliente, um grande negócio. Para tratar desse cliente, Gusto criaria
personas para representar diferentes tipos de clientes de grandes empresas,
como o “Mateus da Multinacional”. Gusto acrescentaria recursos ao
produto para tratar dos casos de utilização que grandes empresas têm,
mas que as pequenas empresas não precisam, como lidar com vários
escritórios internacionais. Esta seria uma maneira de crescer e conquistar
mais clientes. No entanto, o suporte a grandes empresas e seus casos de
utilização não são uma prioridade para a Gusto. Por isso, ela não criou
recursos para atender a essas necessidades.
Concentrando-se em casos de utilização específicos para personas

específicas, você pode garantir que o seu produto atenda às necessidades
dessas pessoas de maneira eficaz, o que torna seus clientes finais
felizes. Adicionar recursos para suportar novos casos de utilização ou
facilitar a obtenção de casos de utilização atuais é uma fonte comum de
oportunidades de produtos.
Empreendimento versus Empresas de Consumidor

Relacionado a casos de utilização e personas, é preciso saber se a empresa
está desenvolvendo produtos corporativos (B2B) ou para consumidores
(também chamados de negócios para consumidores ou B2C). Isso
significa simplesmente perguntar se os clientes finais estão usando o
produto em suas vidas pessoais ou no trabalho. Você provavelmente não
precisa de software de folha de pagamento em casa e provavelmente não
precisa de um dispositivo à vácuo conectado ao smartphone no trabalho.
A principal diferença em como essas empresas funcionam é que o B2B

envolve mais tomadores de decisão, e as pessoas que decidem comprar
56 o produto geralmente não são as que usam - por exemplo, um CTO
aprova a compra de um software para RH, mas é o RH quem o usa no
THE PRODUCT BOOK
dia a dia. As empresas B2B geralmente têm equipes de vendas maiores

com funções especializadas, como engenheiros de vendas, que ajudam
a integrar o produto no ambiente do cliente e as funções de treinamento
do cliente. É improvável que você comece a usar o SalesForce de maneira
inusitada, por exemplo, e nem seria o esperado.
O software de B2B também enfatizou historicamente a utilidade sobre

a sua usabilidade: isto é, desde que resolvesse seu problema, tudo bem se
for realmente doloroso de usar. No entanto, a tecnologia B2B mudou para
se concentrar mais no cliente final do que apenas no tomador de decisões.
Como vimos com o Slack, Gusto e outros, as empresas B2B estão agindo
mais como empresas B2C, criando software com design intuitivo que
você pode usar de forma simples, sem precisar de treinamento para usar,
exatamente como o Facebook.
As ferramentas e técnicas que você aprenderá neste livro serão
aplicadas aos dois estilos de empresas. Você criará personas e analisará os
casos de uso, independentemente de estar criando produtos B2B ou B2C.
Esteja ciente de que você terá que fazer um trabalho extra para explicar os
tomadores de decisão adicionais e suas personas em uma empresa B2B.
O software B2B também possui maior probabilidade de estar sujeito a
requisitos de conformidade legal e precisa funcionar em um ambiente
multiusuário, o que cria requisitos adicionais de produtos fundamentais
que o software B2C não possui.
COMO SABEMOS SE NOSSO PRODUTO É BOM?

No Capítulo 1, mencionamos que uma grande parte do Product
Management é saber como mantemos a pontuação. Métricas, em
particular métricas de sucesso, são como medimos essa pontuação.
Métricas são a medição de diferentes aspectos do seu produto. Isso
pode incluir coisas intrínsecas ao seu produto, como quantas pessoas 57
concluem uma tarefa ou coisas afetadas pelo seu produto, como a
renda que você está recebendo. Métricas de sucesso, às vezes chamadas
de indicadores-chave de desempenho (KPIs), são as principais métricas
que definem como vamos manter a pontuação, como quantos gols você
marcou em um jogo de futebol.
As métricas de sucesso são úteis porque nos ajudam a validar se nossa

estratégia atual está funcionando e, se não estiver, podemos investigar
as métricas gerais para criar uma hipótese de como poderíamos fazer
alterações para alcançar nossas métricas de sucesso (mais sobre isso
no Capítulo 3). Embora o Product Management, às vezes, pareça mais
uma arte do que uma ciência, as métricas fornecem a estrutura científica
orientada por dados para o Product Management.
Suas métricas de sucesso são definidas por sua estratégia e metas atuais.
As métricas gerais de sucesso da empresa vêm dos objetivos da estratégia
de curto e longo prazo da empresa, com as métricas de longo prazo sendo
definidas pelos valores centrais da empresa - o “por quê” de que falamos
anteriormente. Se parte da missão da sua empresa é que você deseja que
seus clientes gostem de seus produtos, então uma importante métrica de
sucesso da estratégia de longo prazo da empresa será a satisfação de seus
clientes com cada produto.
Você terá métricas de sucesso adicionais que mudam com o tempo
com base em suas metas de curto prazo. Por exemplo, é comum ver as
empresas mudando sua meta de curto prazo de crescimento (as pessoas
estão usando nosso produto) para renda (pessoas gostam o suficiente do
nosso produto para pagar por ele). Quando as metas mudam, o que foi
uma métrica de sucesso uma semana pode ser considerada uma métrica
regular na próxima semana.
58
Geralmente, você terá métricas separadas de sucesso da empresa
THE PRODUCT BOOK
e do produto, e as métricas de sucesso do produto darão suporte às

métricas da empresa. Talvez a sua métrica atual de sucesso da empresa
seja o reconhecimento da marca, uma métrica de sucesso inicial comum
para empresas recém-criadas. Nesse caso, as métricas de sucesso de seus
produtos incluirão o número de downloads do seu aplicativo, visitas ao
seu site e assim por diante: métricas que indiquem que as pessoas estão
cientes de sua empresa e de seus produtos.
Posteriormente, sua estratégia poderá mudar para tornar seu

aplicativo parte da vida diária das pessoas. Nesse caso, suas métricas de
sucesso se concentrarão no engajamento: Dentre as pessoas que baixaram
o aplicativo, quantas concluíram uma tarefa principal? Quantos destes
clientes realizam essa tarefa todos os dias/ semanas/ meses? À medida que
suas métricas de estratégia e sucesso mudam, seu plano de produtos e os
recursos escolhidos para trabalhar mudam de maneira semelhante. Você
quer ter certeza de que o trabalho em que está se ocupando apóie suas
metas e métricas de sucesso.
É fundamental comparar essas métricas ao longo do tempo, permitindo
que você veja se sua estratégia está funcionando. Você pode estar usando
a renda como uma métrica de sucesso - fazer as pessoas abrirem suas
carteiras é um sinal de que elas valorizam seu produto - e talvez você
tenha uma renda de US$ 1 milhão no momento. Isso parece ótimo até
você perceber que você teve US$10 milhões em renda no mês passado.
Uma pergunta comum com que os PMs lidam é: como escolhemos as

metas corretas e apoiamos as métricas de sucesso para nos concentrarmos?
Em geral, depende da sua empresa. Mas Sarah Tavel, que foi a fundadora
do Pinterest para pesquisa e descoberta e agora é parceira da Greylock, 59
percebeu uma tendência nas métricas de sucesso de empresas recém-criadas
e bem-sucedidas focadas no consumidor e escreveu suas descobertas em
uma postagem intitulada “A Hierarquia de Engajamento ”.
Tavel observou que existem três fases distintas para empresas recém-
criadas em questão de estratégia e, por extensão, novos produtos, e elas
passam por: engajamento, retenção e autoperpetuação. Empresas recém-
criadas que passam por todas três fases tendem a se transformar em
empresas multibilionárias, enquanto novas empresas que ficam presas
em uma fase geralmente fracassam.
O objetivo da primeira fase é fazer com que os clientes usem seu
produto e concluam a ação principal, como postar uma foto no Instagram.
Esse é um sinal de que eles estão envolvidos com seu produto e podemos
dizer que a conclusão da ação principal é uma métrica de sucesso que
apóia uma meta de engajamento. A ação principal do Pinterest é alfinetar
algo. Em 2011, quando o Pinterest estava crescendo bastante, mais de 50%
de seus usuários semanais ainda estavam alfinetando coisas. Compare
isso com a Viddy, uma empresa recém-criada de compartilhamento de
vídeos que se tornou popular em 2012. Quando o Facebook começou a
apresentar o conteúdo da Viddy em 24 de Abril, o crescimento da Viddy
disparou para cerca de 35 milhões de usuários, como você pode ver na
Figura 2-4. Mas os usuários ativos diariamente e as pessoas que realmente
postaram o conteúdo eram muito baixos, atingindo cerca de 5 milhões
de usuários ou cerca de 14% de todos os usuários. Mesmo que a Viddy
parecesse estar indo bem, com muitas pessoas se inscrevendo, muito
poucos completaram essa ação central. A Viddy encerrou suas atividades
no final de 2014.
60
THE PRODUCT BOOK
Figura 2-4. Um gráfico dos usuários ativos mensais da Viddy (linha superior) em
comparação com os usuários ativos diários (linha inferior) de Abril/ Maio de 2012, do
relatório de Tendências da Internet da KPCB/ Mary Meeker.
Agora vamos ver a segunda das três fases de retenção de Tavel. Depois
que as empresas perceberam um bom envolvimento - o que significa
"bom" - elas mudaram para reter usuários com métricas de sucesso
em torno da frequência com que esses clientes usam o produto em um
determinado período. A ideia é que, se o produto melhorar para os
usuários ao longo do tempo, eles continuarão usando e sentirão falta se
deixarem de usar. Na verdade, é melhor ter um crescimento um pouco
mais lento, mas uma porcentagem maior de clientes usando o produto
continuamente, em vez de um crescimento constante, mas com pouca
retenção, porque você acabará tendo mais clientes ao longo do tempo.
Um exemplo simples disso são os pontos de passageiros frequentes

nas companhias aéreas: quanto mais você voa, mais status obtém e mais
agradável o vôo se torna. Em software, pense em redes sociais. Quanto
maior o público que você criou no Twitter, mais você teria a perder
parando de usar o Twitter e tentando reconstruir sua audiência em outra 61
rede. Os produtos que não incentivam os clientes a usá-los continuamente
são facilmente substituíveis. O Lyft e o Uber são os mesmos para um
cliente final, independentemente de você ter viajado uma ou cem vezes.
É provável que você solicite uma carona de qualquer serviço que tenha o
menor tempo de espera. E se um novo concorrente aparecer oferecendo
um incentivo, como a cada 10 vezes que você utilizar o serviço, você
receberá $10 em crédito, você não perderá nada excluindo o aplicativo
Uber e usando o concorrente.
A fase final que Tavel descreve é quando seu objetivo é a

autoperpetuação. Isso significa que seu produto tem várias rotações que
mantêm o cliente envolvido e incentivam outros clientes a se engajarem.
Suas métricas de sucesso serão em torno de quantas vezes as pessoas
completam esses giros. O Pinterest fica melhor quando mais pessoas
postam alfinetadas, porque isso leva a uma melhor descoberta de coisas
novas e relevantes a serem colocadas em prática. E o compartilhamento
de notificações (que veremos mais no Capítulo 3 com a Tela de Gancho)
incentivará os novos clientes a alfinetar algo e os usuários existentes a
retornarem ao produto.
Tavel continua descrevendo o desempenho da coorte como a métrica

de sucesso final que sua empresa deve analisar ao longo do tempo,
abrangendo todos esses três estágios. Especificamente, observe o número
de usuários semanais que concluíram a ação principal e a porcentagem
de usuários ativos semanais que concluíram a ação principal ao longo do
tempo. Isso mostra o crescimento do tamanho da coorte, o envolvimento
da proporção de usuários que concluíram a ação principal e a retenção
de seu desempenho ao longo do tempo. Embora esses estágios não se
apliquem diretamente a alguns produtos, como um produto B2B que
62 uma empresa exige que seus funcionários usem, os princípios ainda
são aplicáveis. Você quer que seus clientes sejam capazes de concluir as
THE PRODUCT BOOK
tarefas básicas em seu produto de maneira suave e repetitiva, e, desde que

essas tarefas principais estejam alinhadas aos casos de uso com os quais
seus clientes se preocupam, então seu produto terá um bom começo.
Métricas de Vaidade versus Acionáveis

Como Product Manager, vemos muitas métricas. Algumas são mais úteis
para nós do que outras, e frequentemente falamos sobre duas categorias
de métricas: vaidade e acionável. As métricas de vaidade são aquelas que
parecem úteis e podem ser ótimas para outras necessidades de negócios,
mas não nos ajudam a medir o desempenho do produto. Métricas
acionáveis são dados reais que podemos usar para tomar decisões.
Vejamos um exemplo, usando a primeira fase de Tavel, o engajamento.

Quando você está lançando um novo produto, digamos, um aplicativo,
como Product Manager, sua meta é fazer com que as pessoas concluam
a tarefa principal. Talvez 1 milhão de pessoas tenham baixado seu
aplicativo no primeiro dia - parabéns! Isso soa incrível, certo? Embora
o primeiro passo seja fazer com que alguém conheça e faça o download
do seu aplicativo, isso não significa que ele realmente abriu e usou seu
aplicativo. As coisas pareceriam muito diferentes se apenas 10 pessoas
concluírem a tarefa principal de seu aplicativo.
Números como exibições de página e downloads são métricas de vaidade

porque elas apenas soam úteis. Elas podem ser úteis dentro do mundo dos
investidores, enquanto negociam preços de exibição de anúncios, 1 milhão
de pessoas observam nossas páginas todos os dias!, e para outras necessidades
da empresa. Mas do ponto de vista da gestão de produtos, estas métricas
não nos ajudam a avaliar se nosso produto é bem-sucedido.
63
Em vez disso, os Product Managers precisam se concentrar em
métricas acionáveis que nos permitam tomar decisões. Agora que
sabemos que apenas 10 pessoas concluíram a tarefa principal do nosso
produto, podemos analisar outras métricas para tentar descobrir por que
poucas pessoas interagiram com o aplicativo.
Como Medir as Métricas

A maneira mais comum de medir as métricas é adicionar pequenos
pedaços de códigos ao seu produto para avaliar o comportamento
do cliente e coletar automaticamente as medidas individuais em uma
ferramenta de análise, como o Google Analytics faz.
Normalmente, essas medidas são muito simples: Quantas pessoas

enviaram um arquivo? Quantas pessoas clicaram neste botão? Quanto
tempo uma pessoa gastou olhando uma página da Web ou uma tela em um
aplicativo? No início, ao planejar um produto, você deve pensar em quais
métricas deseja capturar e trabalhar com sua equipe de desenvolvimento
para capturar essas métricas (Capítulo 5). Por motivos legais, os clientes
geralmente precisam optar por fornecer esses dados de análise, e é por
isso que você frequentemente vê divulgações em termos de uso ou em
pop-ups de alertas de software para avisar aos clientes que você está
coletando dados de uso do produto.
No entanto, nem todas as métricas são capturadas automaticamente.
É difícil saber, por meio de uma ferramenta automatizada, se os clientes
gostam do seu produto ou se o usam várias vezes ao dia quando o usam.
Se o seu objetivo de longo prazo é que os clientes adorem o seu produto,
o que você deve fazer? As empresas frequentemente usam pesquisas e
entrevistas para avaliar grupos de clientes e avaliar essas métricas de nível
superior. Às vezes, essas pesquisas são automatizadas, como um pop-up
64 perguntando o quanto você gosta do aplicativo em uma escala de 1 a 10.
THE PRODUCT BOOK
Pontuação do Promotor Líquido®

A Pontuação do Promotor Líquido (NPS) é uma métrica desenvolvida
pela Satmetrix, Bain & Co. e Fred Reichheld. É uma maneira de avaliar
a satisfação geral do cliente com seu produto, vendo a probabilidade dos
clientes recomendarem o produto a outras pessoas, em uma escala de
-100 a 100. A ideia é que, se os clientes amarem seu produto, eles contarão
a outras pessoas sobre o seu produto. Se eles forem ambivalentes, poderão
mudar para um concorrente. E se eles não gostarem, eles podem dizer aos
outros para ficar longe e isto pode custar o seu negócio.
O NPS é medido perguntando aos clientes: “Em uma escala de 1 a

10, qual a probabilidade de você recomendar [marca] a um amigo ou
colega?” Os promotores que classificam sua marca em 9 ou 10 e são “en-
tusiastas leais que continuarão comprando e recomendado para outros,
alimentando o seu crescimento”. Essas são as pessoas que você quer! Os
passivos classificam você como 7 ou 8 e são “clientes satisfeitos mas sem
entusiasmo, que são vulneráveis a ofertas competitivas”. Os detratores
pontuam de 0 a 6 e “são clientes insatisfeitos que podem prejudicar sua
marca e impedir o crescimento por meio de um boca a boca negativo.
A partir dessas respostas, o NPS é a porcentagem de promotores menos
a porcentagem de detratores, dando-lhe uma pontuação de -100 a 100.
Reichheld, em seu artigo de 2003 sobre NPS, intitulado “O Número

Que Você Precisa Crescer” descobriu que o NPS de muitas empresas era
baixo, com uma média de 16 entre 400 empresas, mostrando que muitas
empresas têm trabalho a fazer para melhorar a satisfação do cliente!
Medir o NPS ao longo do tempo é uma maneira de ver como os clientes
estão reagindo às alterações feitas no produto (ou alteração não feitas). Se
a meta da sua empresa é a satisfação do cliente, com o NPS como sua 65
métrica de sucesso e seu NPS menor do que você gostaria, seus objetivos
imediatos de produto estarão relacionados a melhorar a felicidade de
seus clientes. Vamos nos aprofundar em como descobrir as mudanças a
serem feitas para melhorar a satisfação do cliente nos capítulos 3 e 4.
Ufa! Já vimos que para um conceito tão simples, há muito trabalho para
alcançar as métricas de sucesso. Mas elas são extremamente importantes
para os Product Managers, pois nos permitem descobrir se nosso produto
e a estratégia que estamos adotando estão atingindo nossas metas de
curto e longo prazo.
O QUE MAIS TEM SIDO, ESTÁ SENDO, E SERÁ CONSTRUÍDO?
Infelizmente, você não pode olhar para um produto ou uma empresa
de forma completamente isolada neste período de tempo atual. O que a
empresa fez no passado provavelmente teve um impacto sobre como está
agora. A Microsoft errou completamente o início da era móvel, e isso fez
com que sua unidade agora fosse "celular-primeiro, nuvem-primeiro".
Também vale a pena pensar em onde um produto poderia ser o

próximo. Embora, às vezes, você crie um produto disponibilizando-o
para os clientes, obtendo avaliação e reagindo à demanda do cliente,
muitas vezes também precisará pensar a longo prazo para apoiar as
iniciativas estratégicas gerais da empresa. O que você quer fazer daqui a
três meses, daqui a seis meses ou daqui a dois anos, para preparar as bases
para hoje? Talvez seu produto esteja disponível naquele momento, mas
sua empresa deseja adicionar um sistema de pagamento de assinatura.
66
Seus clientes não estão solicitando o pagamento mensal, mas sua empresa
precisa gerar renda para sobreviver. Você precisará trabalhar agora para
THE PRODUCT BOOK
poder lidar com as informações de faturamento mais tarde.
Roteiro
As empresas geralmente coletam seus planos de produtos em um roteiro.
Um roteiro é um documento que mostra o que a empresa/ produto está
fazendo agora, o que a empresa/produto planeja fazer nos próximos N
meses, o que a empresa/ produto planeja fazer mais tarde, aproximadamente
quanto esforço cada tarefa de alto nível precisará, quais produtos a empresa
criará, e quais recursos eles terão, etc. É uma ferramenta valiosa para ajudar
as pessoas a se comunicarem sobre a empresa, ajudando os funcionários
a entender em que projetos você está trabalhando, e externamente ajudar
seus parceiros a antecipar suas necessidades ou planejar produtos de acordo
com o que você esteja lançando, uma situação comum em provedores de
componentes de hardware.
Os roteiros geralmente são bastante detalhados a curto prazo -em
curto prazo, de 3 a 6 meses para a maioria dos softwares, 6 a 12 meses
para grandes projetos de software e 12 a 18 meses para hardware- e se
tornam mais vagos a longo prazo. Isso acontece a longo prazo porque
as prioridades podem mudar, e não vale a pena planejar detalhes para
coisas que podem simplesmente não acontecer. Apenas saber que você
quer trabalhar em algo em alto nível é suficiente.
Empresas e produtos terão roteiros relacionados. As empresas de
nível 1 definem como todos os produtos se encaixam, e o produto um
- obviamente - se concentra em cada produto específico. Os roteiros das
empresas são geralmente determinados por executivos seniores de uma
empresa, como o CEO ou o chefe de produto. Os roteiros dos produtos
são criados pelos PMs do produto, e geralmente são influenciados e
exercem influência sobre o roteiro da empresa.
Os fatores que discutimos no início deste capítulo, na seção “Qual 67

Produto Estamos Construindo?”, Também fazem um mapa do roteiro.
Os melhores roteiros são aqueles em que a empresa estabeleceu metas
para atingir e, em seguida, planejou projetos que ajudarão a atingir
esses objetivos. Esses mapas de roteiros também fornecerão o sentido
da propriedade necessária para cada projeto e determinarão a ordem na
qual os projetos devem acontecer. Os próximos capítulos abordarão como
encontramos as oportunidades e como os itens acabam no roteiro, mas,
por enquanto, simplesmente sabemos que os roteiros não são arbitrários.
Os roteiros assumem várias formas. Às vezes, eles são uma planilha
colorida para mostrar todos os projetos programados, seus prazos e o
objetivo de cada projeto. Outras vezes as empresas usam uma ferramenta
especial como o Aha! (http://aha.io) que possui recursos adicionais, como
integração de rastreamento de panes com o Jira, para que você possa se
aprofundar em detalhes específicos, como a forma como cada pane se
relaciona com o roteiro. Não importa qual ferramenta você use para criar
seu roteiro. O importante é ter um roteiro.
Há um grande risco com roteiros: você não sabe o futuro e, se seus

planos mudarem, alguém poderá perguntar mais tarde por que você não
entregou um item no roteiro. Manter os roteiros atualizados e manter os
itens mais intencionalmente vagos - mesmo que você tenha estimativas
de tempo mais precisas - pode ajudar a aliviar esse problema.
Concorrência e Clima
O último elemento a ser considerado ao tentar entender uma empresa
é o que está acontecendo em torno dessa empresa: O que outras pessoas
estão construindo? Quem são os principais concorrentes da empresa? Como
os casos de utilização, personas e clientes finais delas são diferentes? Como
seus produtos são diferentes? Como eles estão ganhando ou perdendo em
68 comparação com outra empresa? Você está ciente de quem está por aí?
Na Product School, nós tivemos um estudante que co-fundou um
THE PRODUCT BOOK
serviço focado em ajudar as escolas a reservarem suas instalações para

outros eventos. Originalmente, ele e sua empresa não sabiam de nenhum
outro concorrente. No entanto, enquanto o aluno estava na aula e
trabalhando em seu projeto final, ele descobriu que outra empresa havia
se concentrado em focar nos serviços de reserva mais amplos para se
concentrar especificamente nas escolas. Embora vale a pena dizer que
há uma oportunidade com os casos de utilização que sua empresa estava
direcionando e se concentrou em oferecer um produto melhor do que
seus concorrentes, isso o fez perceber que a empresa dele não era a única
que estava apostando naquele espaço!
Além da concorrência, o que está acontecendo na indústria em geral?

Alguma invenção ou mudança mais ampla fez com que cada empresa
alterasse drasticamente seus planos? Por exemplo, à medida que os
relógios inteligentes se tornam populares, muitas empresas correm para
criar seus próprios relógios ou versões de seus aplicativos para relógios. E
com o Google Chrome agora bloqueando anúncios do Flash, as empresas
de tecnologia de anúncios são forçadas a ajustar seus planos para lidar
com essa mudança.
Mudanças mundiais mais amplas também podem afetar uma empresa.

A China teve sua moeda desvalorizada em Agosto de 2015, possivelmente
para manter suas taxas de manufatura atraentes, e isso teve um impacto
sobre a renda das empresas que vendem na China. Também pode ter
influenciado qualquer empresa que queira construir seus produtos no
Vietnã.
O mundo, especialmente na área da tecnologia, não fica parado!

Um grande PM vai ficar no topo das notícias para se certificar de que a 69
sua empresa não fique no esquecimento porque perdeu uma força mais
ampla que mudou!
UMA ANÁLISE DO 5C
Se você já conversou com consultores ou MBAs, você provavelmente
os ouviu nomear um ou sete enquadramentos. Há uma variedade de
estruturas “padrão” no mundo dos negócios - dizemos “padrão” porque
existem muitos enquadramentos semelhantes, e empresas diferentes
escolhem padrões diferentes. Vamos abordar alguns dos mais comuns
neste livro, mas sempre priorizaremos as apresentações com foco no
produto, mesmo que isso signifique não usar um enquadramento.
Há um enquadramento chamado 5C que é semelhante às áreas que

acabamos de abordar. É um enquadramento situacional, o que significa
que ajuda a entender a situação atual de uma empresa para que você possa
criar uma hipótese de oportunidade. A estrutura 5C é genérica - útil para
produtos, marketing e muito mais - enquanto a forma como apresentamos
as seções deste capítulo é muito focada no Product Management. É bom
saber o que os "C" significam porque você provavelmente ouvirá sobre o
5C mencionado.
Além disso, se você precisar fazer uma análise situacional de pé em
uma reunião ou entrevista, é relativamente fácil de lembrar.
Corporação: refere-se à experiência, tecnologia, cultura, objetivos e

mais da empresa. É semelhante ao material abordado nas seções "Por
Que a Empresa Existe?", "Como Sabemos Se o Produto é Bom?" E "O
Que Tem Sido, Está Sendo e Será Construído?".
Clientes: Quem são as pessoas que compram este produto? Quais

70 são os segmentos de mercado? Quão grandes são eles? Quais são os
objetivos das pessoas em comprar este produto? Como elas tomam
THE PRODUCT BOOK
decisões de compra? Onde elas compram esse tipo de produto? Isso

é semelhante ao que abordamos nas seções "Clientes e Personas" e
"Casos de Utilização".
Colaboradores: Quem são as pessoas externas que tornam o

produto possível, incluindo distribuidores, fornecedores, operadores
logísticos, pessoal de apoio no local e assim por diante?
Concorrentes: Quem está competindo pelo dinheiro de seus clientes?

Isso inclui concorrentes reais e potenciais. Você deve observar como
eles se posicionam em comparação ao seu produto, o tamanho do
mercado que eles abordam, seus pontos fortes e fracos e muito mais.
Clima: Esses são os fatores macroambientais, como tendências e
inovações culturais, regulatórias ou tecnológicas.
Às vezes, os Product Managers adicionam um “P” à estrutura dos
5C para “produto” e nomeiam especificamente o(s) produto(s) que a
empresa produz.
Isso é uma mistura do que abordamos nas seções "O Que Tem Sido,
Está Sendo e Será Construído?", "Como Sabemos Se o Produto é Bom?"
e “Casos de Utilização”.
APRESENTANDO A MOOVER.IO
Ao longo deste livro, usaremos uma empresa fictícia, Moover.io, como
um estudo de caso. Vamos analisar o contexto da empresa usando os
princípios deste capítulo. A Moover foi iniciada há cerca de um ano para
ajudar as pessoas a economizar tempo - seu "por que" -, concentrando- 71
se inicialmente em tornar mais fácil obter estimativas e registrar um
movimento. Atualmente, a Moover tem um aplicativo iOS onde você
insere alguns detalhes básicos sobre sua mudança: códigos postais de e
para, data que você deseja mover, necessidades de embalagem, número
de quartos, número de escadas e outras notas especiais. Você clica em
"Enviar" e, nos próximos dias, as empresas em movimento retornam
lances. Se você vê um que você gosta, você pode clicar em "Reservar",
e a Moover envia uma nota para a empresa de mudança, que é seguida
por um telefonema para confirmar qualquer informação necessária. A
Moover cobra uma pequena taxa fixa de US$10 quando você clica em
"Reservar", usando o Apple Pay ou o PayPal. Há também um aplicativo de
painel da web simples para as empresas de mudanças, onde elas podem
ver cotações pendentes com as informações básicas sobre a casa do cliente
em potencial, além de o cliente ter aceito ou rejeitado a cotação.
O objetivo do caso de utilização da Moover é mudanças de e para
cidades maiores, já que tem funcionado apenas para empresas de
mudança em São Francisco, Nova York, Los Angeles e Chicago para
configurar o serviço.
A Moover tem duas personas-chave. A primeira é uma empresa

de mudanças, "Ant Moving". A Ant é uma empresa de mudanças de
tamanho médio, com cerca de 10 equipes, que possuem alguém em seu
escritório que dá estimativas pelo telefone em tempo integral. A Ant não
tem um sistema de reservas online completo, porque é mais fácil e barato
fazer as coisas manualmente. A segunda persona é o "Beto Realmente-
Ocupado". O Beto é uma pessoa ocupada que gosta de usar serviços de
aplicativos para lidar com os detalhes comuns da vida. Ele prefere Lyft a
ter um carro próprio, pede seu jantar através do Postmates e muito mais.
Beto não se importa em pagar uma pequena taxa por esses serviços, já
72 que ele acredita que seu tempo vale mais do que esta taxa. Beto trabalha
muito, e ter que organizar uma mudança é a última coisa em sua mente!
THE PRODUCT BOOK
A Moover também aprendeu entrevistando muitos “Betos” em

potencial que Beto poderia facilmente ser “Roberta” porque o gênero não
importa. Beto provavelmente se formou já há alguns anos e acumulou
coisas o suficiente para que suas posses não caibam mais em seu carro, e
nós não encontraremos Beto em um campus universitário.
A Moover tem dois negócios atuais A Moover tem duas metas de

negócios atuais: encontrar maneiras de melhorar a satisfação do cliente
e expandir os negócios. A Moover está atualmente experimentando
limitações que impedem que ela atinja esse objetivo, por exemplo, neste
momento, aquele telefonema de acompanhamento para detalhes do plano
é realmente chato, especialmente se a empresa de mudanças tiver que vir
ao local, e a Moover não tem como lidar com casos especiais, como um
piano. As pessoas que trabalham na Moover, no entanto, não têm certeza
sobre o que devem se concentrar em seguida, nem têm certeza se estão
perdendo uma oportunidade.
No momento, a tecnologia de mudanças não é exatamente um
mercado altamente procurado e os principais concorrentes da Moover
são os sistemas de reservas de empresas específicas e pessoas dispostas
a fazer algumas chamadas telefônicas ou usar um serviço como o Fiverr
para que alguém faça as ligações telefônicas por ele.
A Moover acaba de conseguir US$1 milhão e contratou seu segundo

Product Manager: Você!
Ao longo deste livro, vamos ajudar a Moover a descobrir qual recurso

deverá construir em seguida e percorrer o passo a passo de como 73
construí-lo.
CAPÍTULO TRÊS
CRIANDO OPORTUNIDADES
HIPOTÉTICAS
74 Uma parte essencial da sua função como Product Manager é entender seus
clientes e seus problemas e necessidades, e garantir que o que você esteja
THE PRODUCT BOOK
construindo a seguir seja adequado para eles, quer seja um recurso ou um

novo produto. No final do dia, muito poucas empresas falham porque sua
tecnologia não funciona. As empresas falham por falta de clientes.
Aqui vai um segredinho: todo mundo acha que sabe o que seus clientes
precisam. Mas, como mencionamos no Capítulo 1, a maioria das pessoas
- até mesmo o chefe do seu chefe - realmente não tem ideia do que os
clientes precisam até que tenham feito o trabalho de casa direitinho!
Cada empresa tem uma abordagem diferente para descobrir o que os
clientes querem, e há tweets, postagens em blogs, livros e óperas épicas
sobre como fazer isso - bem, talvez não óperas, ainda.
Vamos adotar uma abordagem baseada no método científico -
apresentar uma hipótese sobre as necessidades de seus clientes e como
você pode resolvê-las, validá-las ou invalidá-las. Este capítulo abordará
diferentes maneiras de gerar uma hipótese. O Capítulo 4 discutirá
como validá-lo e o Capítulo 5 ajudará na transição da idealização para a
execução.
3. Criando Opor tunidades Hipotéticas

Tenha em mente que o que estamos ensinando a você é apenas uma
maneira de abordar o que fazer a seguir, embora seja uma boa ideia.
Grande parte do conteúdo deste capítulo é um pouquinho de ovo e galinha
- alguns dos materiais que ensinamos no Capítulo 2 entram em ação aqui,
assim como o material futuro da seção Desenvolvimento de Clientes do
Capítulo 4. O desenvolvimento do cliente pode influenciar suas personas
, casos de utilização podem informar oportunidades e assim por diante.
Em vez de debater incansávelmente por onde começar, escolhemos uma
abordagem. Encorajamos você a manter um modelo mental semelhante,
com base no método científico, independentemente de onde começar,
para que você tome decisões informadas sobre o que fazer em seguida.
75
VOCÊ TEM OPINIÕES, NÃO FATOS
Há algumas más notícias que você deve saber de antemão. Geralmente,
menos de 50% das ideias que você executa, até mesmo ideias incríveis,
melhoram as métricas que devem melhorar. A Amazon testa todas as
suas novas ideias e tem dados para fazer o devido suporte desse valor de
50%. O Yammer segue uma prática semelhante e também viu números
semelhantes. Como Product Manager, você quer encontrar maneiras de
gastar seu tempo em recursos importantes. Isso começa com a aceitação
de que suas idéias começam como opiniões e não como fatos.
Às vezes, é muito difícil para os Product Managers entenderem que

suas opiniões não são necessariamente verdadeiras. Nós gostamos de
estar certos, e somos ensinados na escola que é ruim estar errado. O
mundo real e a construção de produtos não são assim. Não há problema
em estar errado, mas queremos descobrir se estamos errados o mais
rápido possível e corrigir o curso antes de incluir muitos recursos em
nossas opiniões incorretas. Se você está errado, mas insiste que está certo,
o produto falhará. Mas, se você estiver errado, perceber isso rapidamente
e ajustar de acordo, é muito mais provável que você tenha sucesso.
Quantas vezes alguém lhe disse: “Eu tenho uma ideia de um milhão
de dólares para um produto que faz x”, e a voz dentro de sua cabeça
responde: “Eu não compraria”. Muitas pessoas têm opiniões sobre
qual produto ou recurso para construir. Todos presumem que eles são
comuns e que, se quiserem algo, muitas outras pessoas provavelmente
também querem. Por causa disso, muitas pessoas passam imediatamente
de uma ideia para a construção, nunca verificando se outras pessoas
realmente comprariam o produto. As empresas recém-criadas em
estágio inicial frequentemente têm esse problema - essas também
76 são as empresas recém-criadas que evitam o Product Management.
Infelizmente, essas empresas acabam em apuros porque gastam muito
THE PRODUCT BOOK
dinheiro para construir um produto e descobrem que ninguém o quer.

Como resultado, coisas ruins acontecem, desde o abandono do produto
sem recuperar o investimento até a saída do negócio.
Não seria ótimo se você pudesse limitar esses cenários de desastres

de maneira econômica? A abordagem que vamos ensinar a você, focada
em criar e validar uma ideia, permitirá que você filtre rapidamente e de
forma barata ideias que não o ajudarão.
Note que não estamos falando de ideias “ruins” - uma ideia pode ser
boa, mas não ajuda você nem seus clientes.
Steve Blank, um empreendedor de tecnologia, trabalhou com

várias empresas recém-criadas e percebeu uma tendência naquelas
que falharam. Especificamente, essas novas empresas se concentrariam
em seus planos de negócios e iriam direto para o desenvolvimento de
produtos, ignorando qualquer validação de sua ideia fundamental - soa

familiar? No momento em que uma empresa recém-criada recebe uma
avaliação dos clientes, seria um caminho tão difícil que seria difícil fazer
alterações. Blank percebeu que as empresas recém-criadas fracassaram
principalmente devido à falta de clientes e a um modelo de negócios
lucrativo, e as pessoas com quem ele trabalhava e seus investidores não
viam valor em dedicar um tempo para descobrir se as pessoas realmente
queriam o que estavam construindo. Ironicamente, essa desconexão foi
especialmente um problema para os fundadores de novas empresas, que
criaram a hipótese inicial em que a empresa foi fundada. Eles rapidamente
se isolaram de uma avaliação direta do cliente, pois contratavam pessoas
como profissionais de marketing para interagir com os clientes por eles.
O trabalho de Blank levou-o a concluir que “em uma empresa recém- 77

criada não existem fatos dentro da construção; apenas opiniões”. Ele então
criou a ideia de desenvolvimento de clientes, que essencialmente diz que,
seja o que for que você venha a fazer, é uma opinião; você pode estar
errado e precisa interagir com clientes em potencial reais para aprender
a verdade o mais rápido possível. Este capítulo é sobre formar uma boa
opinião. O capítulo 4 é sobre como descobrir a verdade sobre sua opinião.
O desenvolvimento do cliente tornou-se uma parte essencial da

metodologia “enxuta”, que mencionamos brevemente no Capítulo 1.
A nova empresa “enxuta” é uma empresa que aplica uma metodologia
de desenvolvimento de produtos, adaptada por Steve Blank e Eric
Ries, da revolucionária linha de tubulações de fabricação da Toyota, ao
desenvolvimento de produtos/ software. A nova empresa “enxuta” está
focada em ajudar as empresas a serem bem-sucedidas determinando de
maneira rápida e iterativa o que os clientes desejam, construindo algo
que preencha somente essa necessidade, validando a solução e repetindo.
O desenvolvimento do cliente é uma parte fundamental da nova

empresa “lean” ou enxuta, pois é uma maneira de aumentar rapidamente
seu aprendizado, para evitar perda de tempo. Acreditamos que essa
abordagem é útil tanto em empresas recém-criadas que tentam desenvolver
seu produto inicial quanto em empresas estabelecidas, aprimorando os
produtos existentes. Afinal, um grande PM precisa ajudar o cliente a ser
incrível, e você quer concentrar seu tempo na construção de coisas que
eles precisam! Com isso em mente, como você cria as melhores hipóteses
possíveis sobre o que seus clientes querem?
QUAL É A SUA META E COMO VOCÊ QUER ALCANÇÁ-LA?

A primeira coisa a estabelecer é o seu objetivo para esta iteração do ciclo
78 de vida de desenvolvimento de produto. Sua empresa está focada em
adquirir novos usuários? Quer melhorar a renda? Não existe uma solução
THE PRODUCT BOOK
perfeita para escolher o objetivo certo: se você conquistou um grupo

principal de clientes engajados que usam continuamente seu produto,
talvez sua próxima meta seja a renda, seguida de crescimento. Sua principal
prioridade é escolher um objetivo específico. O que você escolher para
trabalhar a seguir estará a serviço dessa meta, e esse é o núcleo de como as
PMs escolhem estrategicamente o que trabalhar a seguir.
Em seguida, você precisa pensar em como atingir essa meta de alto

nível com um produto real. Como você deseja alcançar esse objetivo
em alto nível? Você deseja iterar em um produto existente, encontrando
maneiras de melhorá-lo? Você quer construir algo completamente novo -
uma oportunidade de céu azul, também chamada às vezes de água azul ou
oceano? Ao tomar essa decisão, você pode concentrar seu pensamento para
poder determinar os detalhes sobre o que construir para atingir sua meta.
Vamos ver a iteração primeiro. Comece traduzindo sua meta de
negócios de nível superior em uma meta de produto e, em seguida,
concentre-se nas alterações que podemos fazer em um produto para

atingir essa meta. Por exemplo, a empresa pode querer melhorar a
satisfação do cliente, o que pode se traduzir em “fazer com que os clientes
leiam mais artigos”, porque isso é um sinal de que os clientes gostam do
conteúdo. Outro exemplo de uso de iteração para atingir um objetivo
é quando o Facebook altera o botão Curtir para ter diferentes tipos de
reações, como amor, tristeza e raiva. O objetivo do Facebook poderia
ter sido o de obter mais engajamento, e os PMs do Facebook sabiam
implicitamente que queriam melhorar o produto principal em vez de
criar algo novo. Eles decidiram fornecer aos usuários mais reações pós-
avaliação. Gostar de uma postagem sobre a morte de um cão nunca
pareceu ser a reação correta, e alguns usuários provavelmente optaram
por postar nada em vez de curtir uma postagem. A reação triste agora
fornece uma maneira fácil de avaliar o conteúdo postado, levando a um 79
maior envolvimento nas postagens.
Iterações não são apenas pequenas alterações. Uma iteração pode ser
uma reformulação completa ou reescrita do aplicativo ou de um recurso,
como quando o Gmail refez sua interface “Compose” ou quando a Apple
mudava de esqueumorfismo para um design plano no iOS 7. A definição
principal de uma alteração iterativa é você pegar um produto já existente
e torná-lo melhor.
A iteração é extremamente importante, pois a primeira versão de um
produto nunca é perfeita para todos os clientes, e é por meio da iteração
que um produto evolui para se tornar algo que os clientes adoram. Se
você ainda não tem um produto/ mercado adequado, recomendamos
focar em alcançá-lo antes de tentar se concentrar nas metas de renda
ou crescimento. O que também é bom em iteração é que você já tem
informações sobre como os clientes estão usando o produto e sua
hipótese sobre o que fazer em seguida pode vir de fontes quantitativas
(como quantos usuários reclamam de um certo pane no sistema) ou
fontes qualitativas (como idéias que a equipe de suporte tem).
A desvantagem da iteração é que você pode ficar preso tentando dar

o “máximo naquele local específico”. Isso significa que você otimizou
algo muito bem, mas se concentrou tanto na otimização que perdeu
uma mudança maior que aconteceu. Pense no vídeo da Blockbuster. A
Blockbuster pode ter passado muito tempo interagindo e ter o equilíbrio
ideal entre preço e dias de aluguel/ taxas de atraso. Ela também pode
ter repetido a experiência geral da loja, visando otimizar o número de
aluguéis por cliente, e criar uma ferramenta de recomendação na loja
para otimizar a satisfação do cliente, garantindo que todos os clientes
saiam com um filme. No entanto, ela ainda teria saído do negócio porque
80 perdeu a mudança global em que a preferência dos seus clientes mudou
para transmissão ao vivo de vídeos.
THE PRODUCT BOOK
É aqui que o pensamento do céu azul entra em cena.
Uma oportunidade de céu azul é algo totalmente novo. Os maiores

exemplos de céu azul ocorrem quando você acredita que o mercado/
mundo está mudando de uma certa maneira, e você precisa fazer uma
grande transformação para lidar com uma necessidade que talvez ainda
não exista, mas que você acredita que existirá no futuro. Embora talvez
você possa fazer alterações em seu produto existente para abordar essa
oportunidade, essa nova oportunidade é diferente o suficiente para ser
abordada com a construção de algo novo, projetando desde o início para
aproveitar essa oportunidade. As oportunidades de céu azul também
surgem quando você vê uma nova oportunidade de expandir seus
negócios para áreas que não são exibidas agora porque acredita que essas
áreas terão valor futuro.
Para simplificar, as oportunidades de céu azul são de correr para onde
a bola estará, não onde ela está agora. Às vezes, surgem oportunidades de
tirar o fôlego pensando mais amplamente ou reenquadrando à medida

que você se aproxima de um problema: a Blockbuster enxergava seus
negócios como “locadoras de vídeo” e estava estagnada naquela ideia de
entregar fitas e DVDs aos clientes. A Netflix concentrou-se na “entrega
de conteúdo” e não importava se esse conteúdo vinha do e-mail ou
de transmissão de vídeo. Pensando em como permitir que os clientes
assistam filmes e programas de TV de uma maneira diferente, a Netflix
viu um meio de superar os máximos locais da Blockbuster e encontrar
um novo máximo global.
Outro exemplo de reformulação para encontrar uma oportunidade

a céu azul é a companhia de seguros de vida MetLife. A empresa criou
um aplicativo, o Infinity, para criar seu legado digital, organizando suas
memórias. Os legados digitais estão se tornando um problema muito maior 81
do que há dez anos. Sua empresa de seguro de vida é o único negócio que
sabe ao certo se você está vivo, então, quem melhor para confiar a chave para
transmitir suas fotos, documentos e mais quando você morrer? Às vezes,
novas tecnologias e tendências, como a computação em nuvem, mudam a
forma como resolvemos problemas, criando novas oportunidades.
Olhando para o gerenciamento de fotos; mudamos de álbuns físicos
para ferramentas digitais como o iPhoto. Mas mesmo depois do iPhoto
ter saído do mercado por cerca de 15 anos - uma eternidade para a
tecnologia - a Apple decidiu que o futuro do gerenciamento de fotos
estava na nuvem. Em vez de tentar tornar o iPhoto capaz de gerenciar
uma biblioteca de fotos baseada em nuvem, a Apple depreciou o iPhoto
em favor de um produto totalmente novo, o Fotos. Ao contrário do iPhoto,
o Fotos foi desenvolvido desde o início para o iOS, já que a maioria das
pessoas tira fotos com um smartphone em vez de uma câmera digital.
Outro exemplo de nova tecnologia criando oportunidades de céu azul
é quando o Facebook, reconhecendo o potencial da realidade virtual
(VR), gastou US$ 2 bilhões para comprar o Oculus, acreditando no valor
futuro da VR e seu metaverso do Oculus, para conectar todos juntos,
seria enorme e mais do que justificável por esse preço.
O lado negativo do pensamento do céu azul é o risco potencial. O

pensamento do céu azul sempre exige um palpite - mesmo que seja bem
instruído - sobre o que vai acontecer, e o desenvolvimento de produtos
céu azul tira recursos de iterar produtos existentes com clientes reais.
Novos produtos quase sempre perdem dinheiro no início porque, além
de levar recursos a serem desenvolvidos, você deve convencer os clientes
a usar essa nova ferramenta, fazendo com que as métricas principais
sejam inicialmente mais baixas.
82 Esse fator de risco é de onde vem o “dilema do inovador”. É difícil

para as empresas estabelecidas justificarem a tentativa de construir a
THE PRODUCT BOOK
próxima grande coisa quando poderiam gastar seu dinheiro aumentando

seu produto atual, encontrando o máximo local. Isso leva as empresas
a se concentrarem demais em suas metas de curto prazo, perdendo
oportunidades maiores por causa da queda de curto prazo nos lucros
que resultariam daquilo. Afinal, seu negócio atual está indo bem: por que
mudar? Por esse motivo, as empresas privadas recém-criadas que podem
encontrar uma nova oportunidade têm a chance de interromper um
operador histórico - alguém esperava que os táxis fossem tão prejudicados
quanto o modelo de negócios baseado em aplicativos para smartphones e
a economia de compartilhamento?
É claro que as grandes empresas não querem ser interrompidas, por
isso muitas vezes também estão tentando encontrar oportunidades para o
céu azul. O Alphabet é um ótimo exemplo de como uma grande empresa
pode resolver o dilema do inovador - a maior parte da renda da Alphabet
vem dos anúncios da Rede de Pesquisa do Google. Se a empresa apenas
se sentasse, e otimizasse essa renda, teria alguns anos realmente bons.
Mas a Alphabet sabe que o modelo de negócio não durará para sempre e

preferiria encontrar a próxima grande novidade antes que outra pessoa o
faça. A Alphabet está constantemente tentando chegar à próxima grande
novidade, e alguns de seus trabalhos - como carros autônomos - parecem
promissores, mas ainda não foram pagos, enquanto outros investimentos
não funcionaram tão bem quanto a Alphabet esperava, como comprar
a Boston Dynamics. Infelizmente, se você seguir as ações da Alphabet,
verá que os investidores não gostam de todas essas apostas experimentais
- querem ver opções que geram retornos imediatos.
Se você tiver um produto existente, é totalmente razoável se sua

primeira hipótese de oportunidade se concentrar em iteração, em vez de
melhorias no céu azul. Mas, ao trabalhar para validar sua hipótese, você
pode perceber que a melhor maneira de alcançar seus objetivos e atender 83
às necessidades de seus clientes é construindo algo novo. Até agora, você
deve ter estabelecido uma meta corporativa de alto nível, traduzido essa
meta para uma meta de produto com as principais métricas de sucesso
(por que você está fazendo essa alteração) e pensado se deseja atingir sua
meta alterando seu produto existente ou construindo algo novo (como
você vai alcançar seu objetivo). Agora vamos ver como chegamos ao que
especificamente podemos fazer para atingir nosso objetivo.
ENCONTRANDO QUANTITATIVAMENTE UMA HIPÓTESE DE

OPORTUNIDADE
Existem duas maneiras principais de determinar o que queremos
fazer para alcançar nosso objetivo: raciocínio qualitativo e raciocínio
quantitativo. O raciocínio quantitativo envolve analisar os dados,
interpretá-los e usar essa análise para determinar o que fazer a seguir. O
raciocínio qualitativo envolve conceitos mais abstratos, como observar
sua visão geral do produto ou sua intuição com base no conhecimento
de seus clientes para determinar o próximo passo a ser seguido. Primeiro,
veremos o raciocínio quantitativo porque é a maneira mais comum para
os PMs determinarem o que construir em seguida.
As fontes quantitativas são importantes porque nos permitem coletar

dados sobre como as pessoas realmente usam nosso produto, usar esses
dados para encontrar visões e aplicar essas visões para determinar o que
fazer a seguir. Por exemplo, talvez a Lyft queira aumentar a retenção de
clientes fazendo com que as pessoas usem a Lyft em vez do Uber. Podemos
transformar isso em uma meta de produto específica, concentrando-
nos em como diminuir o número de viagens canceladas - menos
cancelamentos significam mais passageiros atendidos e motoristas mais
felizes, o que significa mais pagamentos. Isso também virá aprimorando
84 o produto atual, em vez de criar algo novo. Quando você cancela uma
corrida com a Lyft, precisa especificar um motivo. Um PM da Lyft poderia
THE PRODUCT BOOK
dar uma olhada nas respostas e ter idéias sobre como mitigar essas razões.
Talvez ele perceba que ao meio dia o número de pessoas cancelando seus
passeios devido a tempos de espera dispara em comparação com a parte
da manhã ou da noite. Como resultado, talvez ele encontrasse maneiras
de incentivar os motoristas a viajarem no meio do dia, diminuindo os
tempos de espera, diminuindo os cancelamentos e, em última análise,
mantendo os clientes com a Lyft em vez do Uber.
As fontes quantitativas também são interessantes porque, depois de
criarmos e implementarmos nossa ideia, podemos comparar os dados
antes e depois da alteração e determinar se ela foi bem-sucedida. Nosso
PM da Lyft compararia o percentual de corridas sendo canceladas e
as razões pelas quais veria se sua alteração diminuiria o número de
cancelamentos. É importante notar que as fontes quantitativas são úteis
para oportunidades interativas e de céu azul, assim como as fontes
qualitativas. Os dados sobre como os clientes usam seu produto atual
podem gerar maneiras de se repetir o produto atual ou podem apontar

uma tendência que revela uma oportunidade para um projeto de céu azul.
Métricas e Análises
Como você saberá o que fazer se não sabe o que seus clientes estão
fazendo? Conforme discutimos anteriormente, as métricas são medidas de
diferentes tarefas que os usuários fazem com seu produto. As métricas são a
fonte mais comum de dados quantitativos sobre seu produto e seus clientes.
As métricas assumem várias formas, desde “Quantas pessoas você
desliza para a direita ou para a esquerda por sessão neste aplicativo?”
até “Quantas pessoas que acessaram seu site por meio de um link de um
afiliado específico concluíram uma compra?” Nos capítulos 1 e 2, falamos
sobre métricas de sucesso, que são os principais indicadores se você está
atingindo suas metas e se seus clientes estão ganhando. Ao trabalhar com 85
métricas, comece perguntando a si mesmo se você está satisfeito com
a métrica de sucesso. Ela está no nível certo para atingir efetivamente
sua meta de produto e, em caso negativo, como você pode melhorar essa
métrica de sucesso?
Nem toda métrica é uma métrica de sucesso. Por exemplo, nossa

principal métrica de sucesso pode ser quantas pessoas concluem uma
compra, mas também mediremos quantas pessoas adicionaram itens
a um carrinho de compras e quantas pessoas tocaram no botão de
finalizar a compra.
Juntas, essas métricas nos dão uma ideia do que está acontecendo de
forma abrangente com o produto. Se muitas pessoas tocarem no botão
de finalizar a compra, mas muito poucas realmente concluíram uma
compra, podemos ter a oportunidade de melhorar o fluxo de trabalho da
finalização de compras para que mais pessoas concluam uma compra. Os
fluxos de trabalho costumam ser chamados de funis e são ótimas fontes
de hipóteses de oportunidade - que abordaremos em breve.
Chamamos o processo de coletar e analisar essas métricas coletivamente

de análises. O Google Analytics permite que você entenda o estado do seu
produto, dando a você uma ideia muito melhor sobre o que seus clientes
estão fazendo e como o produto está funcionando para eles. O Google
Analytics torna as métricas úteis ao fornecer-lhes contexto, permitindo que
você descubra uma visão sobre o que fazer a seguir.
Pense nas métricas como pontos de dados individuais, como a posição

de um carro, a velocidade de deslocamento, o número de passageiros, e
etc. Além de ver uma métrica de sucesso, como “o usuário virou o carro
depois de dirigir por um tempo”, essas métricas de análise colocam
86 esses pontos de dados juntos para ajudá-lo a perceber que a família
está fazendo seu trajeto semanal até a casa da vovó. O Google Analytics
THE PRODUCT BOOK
também permite que você veja se a família chegou até a vovó ou se

ficou sem gasolina no meio do caminho. Se a família ficar sem gasolina
constantemente antes de atingir a meta de chegar à casa da vovó, você,
como PM, procurará maneiras de ajudá-los a não ficar sem gasolina. OK,
esta metáfora também ficou sem gás. Vamos seguir em frente.
A análise e as métricas são úteis por vários motivos. A primeira é que

as pessoas muitas vezes não sabem exatamente o que fazem e inúmeros
estudos mostraram que o uso de autorrelato não é confiável. O registro
automático de suas ações nos permite ver o que as pessoas estão realmente
fazendo com nosso produto e como chegaram lá.
Se o seu produto for muito grande, a análise pode revelar um problema
em uma seção específica que talvez você não encontre manualmente.
Imagine se você fosse um PM para a Amazon e quisesse ver quantas

pessoas compraram cada produto. Se as pessoas pararem de comprar
vários produtos, é um aviso que você deve olhar para o produto para ver o
que está acontecendo. Se você perguntasse a todos o que eles compraram,
você teria uma tarefa impossível por causa do volume de clientes. Se você
pesquisou pessoas aleatoriamente, provavelmente perderia muitos nichos
de produtos. A análise automatizada, no entanto, poderia facilmente
encontrar um produto em que o número comprado de repente caísse de
uma média de cinco por dia para zero.
Por fim, quando você verifica estas análises ao longo do tempo, pode
obter um indicador de para onde esses números estão indo. Talvez sua
taxa de crescimento tenha se estabilizado. Se você não estiver satisfeito
com sua trajetória, se familiarizar com as métricas dos componentes 87
para encontrar o problema e determinar uma maneira de resolver esse
problema formará sua hipótese de oportunidade. Novamente, depois de
implementar a solução, você pode reavaliar essas métricas para ver se sua
estratégia funcionou.
Existem muitas ferramentas de análise, como o Google Analytics

(Figura 3-1) e o Mixpanel sendo dois dos mais populares para aplicativos
da rede e móveis. Adicionar essas ferramentas ao seu produto é bastante
simples e exige apenas um pouco de código de acompanhamento e
anotações para que você possa acompanhar itens específicos, como
quantas vezes um usuário clica em “Reproduzir” em um vídeo. Os
produtos físicos geralmente exigem técnicas de análise completamente
diferentes, mas à medida que mais produtos físicos se conectam, é possível
coletar dados de uso semelhantes.
Figura 3-1. Um exemplo de tela do Google Analytics mostrando quão frequentemente vários
eventos, as métricas que estamos analisando, ocorrem em um período de tempo.
88
Vale a pena notar que os dados de análise nem sempre são perfeitos
THE PRODUCT BOOK
e essas imperfeições podem distorcer sua análise. Se o seu aplicativo

suportar várias plataformas, o evento pode ser marcado acidentalmente
como “eventoA” no Android e “evento A” no iOS. Isso significa que
você não verá o tempo total do Evento A, a menos que você perceba o
problema e faça a conta.
Outras vezes, existem problemas inerentes às suas ferramentas de
análise. O Google Analytics apenas fornece amostras de um subconjunto
de seu tráfego para seus relatórios, mas, para sites de alto tráfego, a
amostra pode não representar com precisão seus dados reais. Se os dados
não representam corretamente o que seus clientes estão fazendo, você
pode tomar as decisões erradas. Vamos ver como usar a análise para
analisar métricas específicas e encontrar oportunidades.
Decodificando as Análises
A primeira parte da análise é garantir que capturamos as métricas
certas. Identifique a principal métrica de sucesso que apóia sua meta e as

métricas que suportam essa meta. Se sua métrica de sucesso for o grau de
envolvimento de seus clientes, você deverá acompanhar a frequência com
que eles concluem a ação principal de “sucesso” e as etapas que os levam a
ela. Se as métricas corretas não estiverem lá, sua primeira tarefa para essa
iteração do ciclo de vida de desenvolvimento de produtos é implementar
a análise dessas métricas.
Um problema comum quando você herda um projeto existente é que

um PM anterior e bem-intencionado registra cada métrica possível. Isso
leva à sobrecarga de dados e pode ser muito difícil separar as métricas
úteis das irrelevantes. Se você se encontrar nessa situação, recomendamos
fazer uma auditoria de análise e reavaliar quais pontos de dados você
89
estará gravando - removendo os irrelevantes - antes de usar os dados para
tomar decisões.
A próxima parte é como agrupamos métricas para identificar

tendências e oportunidades. Existem três formas principais: segmentação,
análise de coorte e funis.
O Google Analytics rastreia todos os clientes igualmente e informa o

comportamento médio. Por exemplo, um novo cliente usará o tutorial de
primeiro uso de um aplicativo, alguns podem ignorá-lo, mas um cliente
recorrente nem verá o primeiro tutorial de uso. Se você simplesmente
analisou a frequência com que um cliente visualiza o tutorial e de quantas
vezes as pessoas usam o aplicativo, parece que poucas pessoas usam o
tutorial como um todo. Cabe a você segmentar seus dados, o que significa
agrupá-los por características comuns.
As ferramentas de análise geralmente fornecem várias maneiras de
segmentar dados. Escolhas comuns variam de agrupamento técnico
(SO, navegador, etc.) a comportamental (usuário novo / recorrente) a
demografia (país / idioma são comuns). Depois de segmentar os dados,
podemos analisar cada métrica, concentrando-nos em nossa métrica de
sucesso principal e nas métricas de suporte e ver se ela está alinhada com
nossa expectativa de linha de base. Se não estiver, vamos simplificar isso
como uma métrica para focar.
Você pode encontrar algo surpreendente para uma métrica não

relacionada ao que você está trabalhando agora. Sinta-se à vontade para
anotá-la para mais tarde, mas não se preocupe com isso inicialmente.
Existem muitas métricas para um produto e os PMs sempre podem
encontrar surpresas. Estamos focados em uma métrica de sucesso
específica e nas métricas de suporte que levam a essa métrica de sucesso.
90
Outra maneira de agrupar dados é a análise de coorte. Isso é muito
THE PRODUCT BOOK
semelhante à segmentação, mas usa um ponto no tempo como uma

característica-chave do grupo e é frequentemente usada para observar
o comportamento ao longo do tempo. Por exemplo, imagine o destaque
de seu produto no Shark Tank da TV, o Dragon’s Den, no Reino Unido,
onde empresários esperançosos apresentam sua ideia aos investidores.
Você pode querer comparar como os usuários que se inscreveram antes
do Shark Tank ir ao ar usaram o produto em comparação com as pessoas
que se inscreveram após o programa ter ido ao ar. E você também
perguntaria como o uso dessas coortes compara dois meses, seis meses,
etc. Ou, o que é mais prático, o engajamento ao longo do tempo com os
clientes antes de criar o tutorial de primeiro uso em comparação com os
clientes que se inscreveram após a implementação do tutorial? Se você
verificar uma diferença substancial no comportamento em um certo
ponto, veja essa métrica.
O último método comum de agrupar dados é um funil. É quando você
mede as principais etapas da jornada de um usuário em direção a alguma
tarefa e as agrupa em ordem de jornada. Normalmente, muitas pessoas

completam o primeiro passo e muito poucas completam o último; Por
exemplo, muitas pessoas podem acessar uma página do produto Amazon,
um número menor clicar em Adicionar ao carrinho e um número menor
ainda concluir a compra. “Vazamento” é como chamamos quando um
cliente deixa de avançar no funil.
Quase qualquer grupo de métricas de ação sequencial (fluxo de

trabalho) pode formar um funil, e seu objetivo é sempre observar como
um usuário vai desde o início até a conclusão de uma ação. Nem todos os
clientes inserem seu produto da mesma maneira (por exemplo, clicando
um aplicativo na tela inicial para abri-lo pela primeira vez, abrindo o
aplicativo pela décima vez com um estado restaurado, clicando em um
link que abre o aplicativo, e etc.). Sua ferramenta de análise provavelmente 91
tem um relatório de fluxo de comportamento para ver como os usuários
entram no funil e para onde vão. Qualquer lugar em que haja uma queda
indesejada substancial é uma oportunidade em potencial e você deve
avaliar essa métrica específica.
Dave McClure, o famigerado capitalista de risco que fundou a 500

Startups, montou uma palestra chamada “Métricas de Novas Empresas
para Piratas”, onde ele desenvolveu uma abordagem geral de métricas
para um produto inteiro, chamado métricas AARRR - apesar de ele ter
montado essa abordagem para empresas recém-criadas, onde o sucesso
de uma empresa depende de um produto, é útil para qualquer produto. A
sigla significa o seguinte:
• Aquisição: Como o usuário chega ao seu produto.
• Ativação: Primeira visita do usuário ao seu produto e sua
primeira experiência feliz.
• Retenção: O usuário gostou do seu produto o suficiente para usá-
lo novamente (e espero que de novo e de novo ...).
• Recomendação: O usuário gosta o suficiente para contar a
alguém sobre isso.
• Renda: O usuário acha seu produto valioso o suficiente para
pagar por ele.
O McClure sugere dividir as principais etapas comportamentais do seu

produto nesses intervalos (cada intervalo pode ter mais de uma métrica
dentro dele) e usar esse funil para ver como os usuários vão desde a
descoberta do produto até o desejo de pagar por ele. Cada grande mergulho
é uma oportunidade em potencial e uma métrica para prestar atenção, e os
92 que estão no topo do funil são os primeiros a serem abordados.
THE PRODUCT BOOK
Observe que a(s) parte(s) do funil em que você se concentra

dependerá da sua empresa e dos objetivos do produto. Se sua meta atual
for o crescimento, você se concentrará na etapa de ativação, e não na
etapa de renda.
Também é importante observar que nem todo mergulho em um funil

é ruim. Por exemplo, os e-mails de spam nigerianos solicitando que você
forneça sua conta bancária a um príncipe (ou algo similar) têm apenas
0,1% de cliques, o que significa que apenas 0,1% das pessoas que o recebem
clicam no link “Enviar dinheiro”. Mas isso acaba sendo um excelente filtro
para clientes crédulos, já que 70% das pessoas que clicam no link realmente
enviam dinheiro. Se eles otimizassem a taxa de cliques e 90% das pessoas
clicassem no link, é mais provável que o site fosse denunciado ou removido,
e o spammer ganharia menos dinheiro no geral.
Também é razoável combinar segmentação e análise de coorte e
funis. Por exemplo, você pode querer observar um funil com análise de
coorte se o seu produto estiver em destaque no Shark Tank. Você pode

acompanhar quantas pessoas passaram de clicar no botão de finalizar
compra para, de fato, concluir a compra antes de você entrar no Shark
Tank, em comparação a quantas pessoas concluem o funil de finalização
de compra após você ter aparecido na TV.
Por fim, não importa como você escolha observar suas análises, sua
meta é encontrar uma métrica que você acredita que vale a pena melhorar
para atingir seus objetivos de produto e empresa.
93
DICA DO CAPÍTULO TRÊS
Esta dica é da Beatriz Datangel. Beatriz já usou vários chapéus no

mundo das empresas recém-criadas. Ela usou suas experiências como
analista para conquistar posições de Product Management, nas quais
ela conduz decisões de dados e visões. Seu foco na Product School
é como usar dados e comunicar métricas de maneira eficaz. Você
poderá contatá-la via Twitter @bzdata.
QUAIS SÃO AS DIFERENÇAS-CHAVE ENTRE MÉTRICAS DE

VAIDADE E MÉTRICAS DE SUCESSO?
Se você perguntar o que faz um ótimo Product Manager, muitos dirão
que é um entendimento do que vai aonde e como - não é tão simples
quando você alterna entre planilhas do Excel, consultas SQL e infográficos
94
visualizados. Vivemos em uma época em que os dados vivem em todos
os lugares. Um Product Manager deve saber como extrair visões do lugar
THE PRODUCT BOOK
certo. Vamos ver como fazer isso usando a Amazon como exemplo.
Comece entendendo a proposta de valor geral do produto e da empresa.

Para a Amazon, a proposta de valor para os clientes é a conveniência
de comprar qualquer coisa e consegui-la rapidamente. Como PM, você
precisará pensar a partir da perspectiva do cliente. Se eles escolheram seu
produto/ empresa entre toda a concorrência para a proposição de valor-
chave, você precisará saber como partes do produto estão funcionando
para garantir que a proposta de valor permaneça intacta. Com quais
métricas os clientes se preocupam e que apoiam a proposta de valor?
Estas incluem:
• Inventário de cada item
• Número de itens abastecidos com estoque em comparação com as
listas principais/ guias de compras de feriados.
• Porcentagem de itens pedidos e que chegam dentro do prazo de
envio e entrega do Amazon Prime (~ 48 horas)
• Velocidade média de carregamento do site

• Tempo médio de espera entre o envio de um tíquete de atendimento
e sua resolução
Se um site estivesse lento ou as entregas não fossem feitas dentro

do prazo, os clientes não necessariamente pensariam que a Amazon
é conveniente. Se não conseguirmos cumprir as métricas acima, não
forneceremos nossa proposta de valor aos clientes e eles comprarão
em outro lugar. Por outro lado, quando entregamos essas métricas, os
clientes ficam felizes. Isso significa que essas são métricas de sucesso nas
quais devemos nos concentrar.
Bem, quais são as métricas de vaidade, então? Eric Ries falou pela primeira
vez sobre métricas de vaidade em 2009, definindo-as como métricas
frequentemente faladas em uma visão de alto nível. Elas também costumam
ser mencionados em siglas:
95
• Visualizações de página
• Número de instalações
• Usuários diários / mensais (DAU)
• Crescimento de usuários, instalações, visualizações de pagina

É realmente ótimo que muitas pessoas consultem a Amazon todos os dias
e acessem a Amazon, mas se elas não completarem suas transações na
Amazon, a Amazon não estará lucrando. Em outras palavras, essas métricas
não nos dizem se estamos fazendo nossos clientes felizes ou não.
Números de vaidade são ótimos para um título rápido. No entanto,
o sucesso vem com contexto. Certifique-se de procurar por métricas
importantes para uma experiência bem-sucedida para o cliente.
Transformando Métricas em Oportunidades
Perguntando o Porquê
O desafio com fontes quantitativas, como métricas, é que elas informam
o que está acontecendo, mas não o motivo. Depois de identificar uma
métrica - ou duas - que você deseja melhorar, como descobrir o que fazer?
Existem algumas maneiras de descobrir o que você deve fazer, e uma das
mais fáceis é perguntar "por quê". Especificamente, pergunte-se por que
você acha que a métrica não está onde você gostaria que ela estivesse. E se
a resposta não for uma hipótese que você possa testar de alguma forma,
continue a se perguntar por que até chegar a uma hipótese específica. Seu
objetivo é chegar ao problema central, a raiz da questão mais profunda.
Você quer resolver problemas, não resolver os sintomas. Perguntar por
que pode ajudá-lo a encontrar esse problema central, levando você a uma
oportunidade potencial de se concentrar na validação.
96
Aqui estão algumas idéias para ajudá-lo. Primeiro, muitas pessoas
se concentram apenas no resultado final do funil. Eles podem dizer:
THE PRODUCT BOOK
“Não temos clientes o suficiente concluindo uma compra”. Se esse for o

caso, pergunte-se por quê. Olhe para trás através do funil e veja onde o
vazamento ocorre. Então, pergunte por que isso está ocorrendo lá. Pode
ser necessário ir a essa parte específica do produto para ver o que pode
estar bloqueando um usuário.
Segmentar seu público e focar em como cada segmento se comporta

pode levar a uma melhor hipótese. Por exemplo, talvez a taxa de conversão
de seu site pareça baixa no geral, mas, quando você a segmenta por
navegador, a taxa de conversão dos clientes do Safari é muito maior do
que para os clientes do Chrome. Como existem mais clientes do Chrome
do que os do Safari, a taxa de conversão média geral parece baixa. Ao se
perguntar por que e tentar usar o site no Chrome, talvez você encontre
um pane de sistema em que um erro de JavaScript aparece quando você
clica em "Finalizar a Compra" no Chrome. Sua hipótese de oportunidade
é que corrigir esse pane no sistema melhorará a aquisição para a página

do carrinho de compras e, eventualmente, aumentará a sua renda.
Veja algumas oportunidades interessantes e comuns que você

encontrará em aplicativos para dispositivos móveis e da rede em métricas:
• Um tempo baixo em uma tela e uma alta taxa de rejeição -

pessoas que saem depois de visualizar esse conteúdo - em uma
página supostamente importante provavelmente indica uma
incompatibilidade entre as expectativas e a realidade. O conteúdo
não era o que os clientes esperavam, então eles saíram.
• Muito tempo em uma tela e uma alta taxa de rejeição pode ser
aceitável se a página for um artigo longo, mas se for uma página
com muito pouco conteúdo, e muitos links, isso pode indicar que a 97
tela não está clara.
• Um grande número de visualizações de tela pode indicar que essa
parte do aplicativo é importante, portanto, você precisa otimizá-la
bem.
• Um baixo número de visualizações pode significar que esta seção é
difícil de encontrar.
Auditoria de Recursos da Intercom

Uma empresa chamada Intercom, que faz ferramentas para permitir que
os proprietários de produtos vejam quem está usando o produto e se
comunique com eles, reuniu vários recursos excelentes em seu blog, em
Inside Intercom, no blog intercom.io. Uma das técnicas que a Intercom
compartilha é uma maneira de analisar suas métricas e oportunidades
pontuais, chamada de auditoria de recursos. Em uma auditoria de recursos,
você começa criando um gráfico de quantas pessoas usam um recurso no
eixo x versus a frequência com que o usam (consulte a Tabela 3-1).
Ao fazer isso, exclua os recursos "administrativos", como recuperação
de senha, pois eles distorcerão o resultado. O valor central do seu produto,
a razão pela qual ele existe e que as pessoas o compram, deve estar no canto
superior direito (Recurso C), porque todos devem usá-lo o tempo todo.
98
THE PRODUCT BOOK
Tabela 3-1. Uma amostra de tabela de auditoria de recursos de intercomunicação.
Existem quatro fontes de oportunidade:
1. Os recursos no canto superior esquerdo do gráfico são mal

adotados (Recurso A na Tabela 3-1): muito poucas pessoas os
usam muito. Às vezes, tudo bem, por exemplo, se é um recurso
de nicho para um cliente-chave em um produto corporativo que
somente a empresa usa, mas, em alguns casos, você quer melhorar
a adoção desses recursos.
2. A segunda fonte é um recurso que todas as pessoas usam
ocasionalmente (Recurso D): é algo que você quer que as pessoas
usem com mais frequência?
3. O terceiro é que talvez você deva acabar com um recurso se for
algo no canto inferior esquerdo que poucas pessoas usam e, então,
e as que as pessoas que usam o fazem com pouca frequência

(Recurso E).
4. Por fim, você pode optar por melhorar um recurso importante
que muitas pessoas usam com frequência (Recursos B e C).
Essa visualização também mostra um possível sinal de alerta: se seu

produto tiver apenas um recurso que as pessoas usam com frequência,
você poderá ser facilmente substituído em seu fluxo de trabalho. O ideal
é que você tenha alguns recursos importantes que as pessoas usem com
frequência para que você não seja um produto descartável quando algo
melhor aparecer em jogo.
Se houver um recurso importante que você acredita ser para todos

os clientes, mas apenas alguns clientes usam, você deve melhorar sua 99
adoção. Para fazer isso, concentre-se em perguntar por que, assim como
discutimos antes. Note que você quer ser muito explícito - não diga
apenas “os clientes não vêem o valor”. Continue perguntando por quê
até chegar à causa principal. Por que eles não veem seu valor? O recurso
não economiza tempo. Por que isso não economiza tempo? Existem
muitas etapas para usar o recurso. Por que existem muitas etapas?
Eventualmente, você criará uma lista de problemas que impedem os
clientes de adotar o recurso (por exemplo, economizar tempo pode ser
apenas uma das muitas razões pelas quais um cliente não vê o valor de
um recurso). Depois de fazer isso, você pode se concentrar em resolver
esses problemas. Nem todas as oportunidades serão alterações no código.
É possível que marketing ou design diferentes ajudem na adoção.
Se houver um recurso que muitos clientes usem com menos frequência,
mas você acha que seria benéfico se eles o usassem mais, é possível que os
usuários não saibam como isso funciona, o que você pode verificar por
meio de um funil. Você também pode verificar o valor, com a ajuda do
Marketing. Para motivar os usuários a usá-lo mais, você pode usar a “Tela
de Gancho”, de Nir Eyal, autor de “Hooked”, para ajudar a criar hábitos em
seu software.
Visto na Figura 3-2, a “Tela de Gancho” possui quatro elementos. O

primeiro é o gatilho - o que acontece para levar o usuário ao produto?
Segundo, qual é a coisa mais simples que você pode fazer para um cliente,
o que lhes dará a recompensa? Terceiro - que recompensa você pode
oferecer que seja gratificante e faça o usuário querer mais e investir mais
no produto? Por último, que pequena ação você pode fazer com que o
cliente invista em algo que leve a mais gatilhos e faça com que eles voltem?
100
THE PRODUCT BOOK
sd- fk-
G atilho mpensação
jsdf
Co
Inv to
estimen Ação
Figura 3-2. A "Tela de Gancho" de Nir Eyal e suas quatro fases.

Se você já ouviu falar de gamificação, que envolve adicionar
mecanismos de jogos a produtos que não são de jogos, você viu a tela
de gancho em ação. Você pode receber um e-mail de uma companhia

aérea dizendo que receberá pontos de bônus se você se inscrever em um
cartão de crédito. Você preenche a forma mais simples que a companhia
aérea pode oferecer e, supondo que tenha sido aprovado, você ganha
pontos suficientes para uma viagem doméstica gratuita. Isso faz você
querer ganhar mais pontos para obter mais viagens gratuitas. O Eyal usa
o Pinterest como um exemplo na Figura 3-3.
sd- fk-
atilho pensação
jsdfG m
Co O que os
Notificações amigos postaram
(tribo), Objetos
Instalar botão de interessantes (caça)
Alfinetar, Re-alfinetar,
seguir comentários 101
Login
Inv to
estimen Ação
Figura 3-3. "Tela de Gancho" do Pinterest, de Nir Eyal.
Pesquisas
É bom se aprofundar além de um NPS geral e perguntar como os clientes
estão satisfeitos com partes específicas de seu produto. Se eles tiverem
menos de 10, peça uma pergunta aberta para receber comentários sobre
como o produto não está atendendo às suas necessidades e expectativas.
À medida que você faz alterações no produto, poderá reclassificar para
ver como a satisfação muda com o tempo. Alguns produtos agora estão
integrando essa pesquisa de satisfação ao produto. Por exemplo, clientes
aleatórios do Twitter verão um tweet em sua linha do tempo dizendo
que foram selecionados para uma pesquisa e ferramentas como Intercom
(http://intercom.io), Delighted (http://delighted.com) e UserVoice (http://
uservoice.com) podem ser facilmente integradas e permitir que os clientes
forneçam avaliações continuamente.
As pesquisas podem ser usadas para coletar dados mais específicos, e

abordaremos a elaboração de comentários mais aprofundados no Capítulo
4, quando analisaremos como usá-los para validar nossa hipótese.
Obviamente, se um cliente não estiver satisfeito e disser o motivo,
essa é uma possível fonte de uma hipótese de oportunidade. Mas existem
outras maneiras de usar os dados da pesquisa para encontrar uma
oportunidade, especialmente criando um gráfico de importância versus
satisfação.
102 Internamente, você deve ter uma noção de quão importante cada
recurso é para o produto. Os recursos que são essenciais para o produto
THE PRODUCT BOOK
e usados com mais frequência são provavelmente os mais importantes.

Para cada recurso, se você criar um gráfico (veja a Figura 3-4) com a
satisfação do cliente no eixo y, aumentando a importância do recurso
no eixo x e uma linha y = x, você verá facilmente as oportunidades. Um
recurso importante que tem baixa satisfação aparecerá abaixo da linha, e
deve ser sua primeira prioridade a melhorar.
Satisfação
Recurso B
Recurso A
Importância
Figura 3-4. Um gráfico mostrando satisfação, com valores coletados por meio de pesquisa, e
importância de recursos, conforme determinado internamente. O Recurso A, com uma satis-
fação muito baixa, provavelmente será o primeiro a se concentrar, em vez do Recurso B, que é
mais importante, mas tem uma satisfação moderada.
103
Geralmente, você coloca na balança a importância versus quão
insatisfeitos os clientes estão, então você pode trabalhar em algo que
é bastante importante com uma satisfação muito baixa (Recurso A na
Figura 3-4) antes de focar em um recurso que é muito importante com
satisfação moderada (Recurso B). Além disso, tudo bem se recursos
menos importantes tiverem menor satisfação geral; eles não são críticos
para o produto. Se esses recursos se tornarem mais importantes, você
deve se concentrar em melhorá-los para que a satisfação do usuário
permaneça acima da linha x = y.
E Quanto as Entrevistas Com o Cliente?

É possível que, enquanto você estiver falando com os clientes, por
exemplo, enquanto o usuário testa outro recurso, eles podem dizer algo
que desperte uma ideia em sua mente. No entanto, acreditamos que as
entrevistas com clientes não devem ser a fonte de sua primeira hipótese
de oportunidade. Se você começar as entrevistas com o cliente sem ter
uma ideia vaga do que está procurando aprender, as entrevistas serão
desfocadas e inúteis, e é improvável que você encontre uma boa hipótese.
Em vez disso, acreditamos que você deva começar com uma hipótese
de oportunidade, mesmo que seja vaga, e depois fazer entrevistas com o
cliente para validá-la. É possível que, ao fazer essas entrevistas, você crie
uma nova hipótese, e tudo bem.
ENCONTRANDO QUALITATIVAMENTE UMA HIPÓTESE DE

OPORTUNIDADE FUNDAMENTADA
Nem toda oportunidade surge de algo que pode ser quantificado e
medido. Como Henry Ford supostamente disse: “Se eu tivesse perguntado
às pessoas o que elas queriam, elas teriam dito um cavalo mais rápido”.
104 Alguém disse uma vez que “otimização conduzida por dados levada ao
seu extremo apenas leva à pornografia”.
THE PRODUCT BOOK
Você pode recorrer a uma ampla gama de fontes qualitativas para

encontrar oportunidades. O maior desafio é que isso exigirá mais trabalho
do que as oportunidades encontradas quantitativamente, pois elas não vêm
diretamente dos dados: você precisará encontrar dados para apoiá-las.
Falhas Conhecidas
A oportunidade iterativa qualitativa mais simples (que também é
discutivelmente quantitativa) de procurar é como uma falha no sistema
pode estar impedindo os clientes de obter sucesso. Por exemplo, se você
está tentando melhorar a receita, a equipe de controle de qualidade
descobre que, quando os clientes na Europa tentam pagar, seu aplicativo
trava ao lidar com a conversão de taxa de câmbio entre o dólar e o euro,
a ideia a seguir é trabalhar em consertar esta falha que está causando
problemas. A principal maneira de validar uma hipótese de oportunidade
relacionada a panes é procurando dados sobre o tamanho de um problema
que o pane no sistema representa, por exemplo, como isso ocorre e o

impacto que ele tem na métrica de sucesso? Talvez esse erro de conversão
não tenha sido informado por nenhum usuário real, e é realmente algo
na configuração da equipe de controle de qualidade que está causando
isso. Ou, se apenas uma pequena parte de seus clientes estiver na Europa,
provavelmente haverá outras maneiras de melhorar a receita nas quais
você deve se concentrar primeiro.
Pode parecer bobo listar explicitamente os erros no sistema como uma

oportunidade para explorar - se você for um engenheiro, provavelmente
preferiria não ter panes no sistema -, mas um dos desafios de um PM é
avaliar o valor geral de corrigir um pane no sistema em relação a não
consertar o pane no sistema e, em vez disso, fazer outra coisa. A qualidade
é sempre importante, mas nem todo erro no sistema é uma prioridade 105
alta o suficiente para solucionar imediatamente.
Da mesma forma, pode haver “sugestões” existentes ou solicitações de
recursos acumulados em sua lista, que se tornam a base para sua hipótese.
Elas podem ter vindo de diversos lugares, desde ideias aleatórias que as
pessoas tiveram até fontes baseadas em dados, como tíquetes de suporte
ao cliente e visões de estudos de usabilidade, ou seja, estudos em que você
testa como os clientes reais interagem com o produto / recurso existente e
nota o que eles fazem bem e que obstáculos encontram.
Relacionado a isso está o pagamento da “dívida técnica”. Às vezes, a

engenharia tem que fazer mudanças internas que essencialmente trará
benefícios ao código.
É importante priorizar periodicamente esse trabalho de engenharia
porque, se você não fizer isso, será cada vez mais difícil implementar novos
recursos no futuro. Infelizmente, quando você trabalha nestes projetos,
da perspectiva do cliente, nada muda. Para validar essa oportunidade,
certifique-se de que este é um bom momento para trabalhar em uma
limpeza interna, em vez de entregar algo novo aos clientes, e que essa
limpeza interna fornecerá valor para sua equipe, como facilitando a
implementação de outra oportunidade no roteiro.
Intuição
Quantas vezes você já ouviu alguém dizer: “Eu tenho uma ideia para um
aplicativo! Você conhece alguém que possa construí-lo para mim?” Às
vezes, há boas ideias, como usar um aplicativo para chamar facilmente um
carro por um preço atrativo. Outras vezes, alguém quer criar um aplicativo
para ajudar a combinar suas meias com as calças. Claramente, ninguém
tem boas idéias o tempo todo, nem mesmo Steve Jobs - lembra o iPod Sock?
106 Uma fonte comum de hipóteses de oportunidade são as hipóteses

existentes que você ou sua empresa já podem ter baseado em sua
THE PRODUCT BOOK
experiência / conhecimento prévio. Este é um ótimo lugar para começar,

porque você provavelmente tem uma forte ideia do que construir para
seus clientes a partir de sua experiência, mas também é potencialmente
perigoso, porque esse tipo de hipótese não é validado corretamente.
Muitas vezes, as pessoas têm medo de alguém roubar sua ideia - o
que raramente acontece - ou simplesmente não querem descobrir que
ninguém realmente quer a ideia delas.
Infelizmente, o segundo passo para muitos desenvolvedores de

produtos não é validar sua ideia, mas sim pular imediatamente para a
construção. As pessoas gostam de supor que, se tiverem algum problema,
muitas outras pessoas também têm, e essas pessoas vão querer aquela
solução. Isso é arriscado porque pode ser muito caro criar o produto, e
ninguém sabe ao certo se alguém experimenta esse mesmo problema ou
está interessado na mesma solução que eles.

A melhor maneira de criar uma ideia por conta própria é não pensar
no que o indivíduo deseja, mas sim ter empatia com as pessoas-alvo,
combinando o conhecimento dos pontos problemáticos de seus clientes
com seu conhecimento do que você poderia construir metas gerais
e métricas de sucesso que são importantes para o produto e para a
empresa. Como PM, você está em uma posição única para saber quais
são os principais pontos problemáticos para os clientes, como eles estão
reagindo ao seu produto, quais são os problemas técnicos do produto e
quais inovações técnicas ocorreram em sua equipe de engenharia. Em
breve, mostraremos uma ferramenta chamada Quadro de Modelo de
Negócios, para tornar a síntese dessa ideia mais concreta. Um grande PM
também estará prestando atenção ao mundo da tecnologia mais ampla,
pensando em como as inovações em outros lugares podem se aplicar a 107
seus produtos e clientes.
Veja um exemplo simples de uma hipótese derivada da intuição
para a Moover. Eles querem tornar a reserva um movimento tão fácil
quanto chamar um Uber, o que significa tornar simples para as empresas
de mudança fornecerem estimativas precisas. As fotos podem ajudar as
empresas em movimento a fazer estimativas precisas, mas as pessoas
provavelmente não sabem como tirar fotos úteis para mostrar um espaço
para mudança de empresa. E se eles adicionassem um recurso em que o
cliente ficasse no meio de cada sala, movendo lentamente a câmera para
cima/ baixo enquanto o cliente girava, gerando uma foto de 360° na tela?
Assim, cada cliente tira uma boa foto do espaço em questão.
Podemos supor que o resultado tornará mais fácil para as empresas de

mudanças darem uma estimativa precisa. O próximo passo seria validar
se as fotos, especialmente as de 360°, tornam substancialmente mais fácil
para as empresas de mudanças fazer estimativas precisas. Isso poderia ser
feito usando um aplicativo 360° existente para tirar fotos de um espaço e
enviar fotos regulares de um espaço para várias empresas de mudanças,
solicitando a avaliação delas.
Visão
Você, seu chefe, sua empresa, etc., provavelmente têm uma visão geral de
seus produtos e da empresa que você deseja alcançar em um horizonte
temporal mais longo. Especificamente, é uma imagem da versão futura da
empresa que você está tentando criar. Para Walt Disney, isso significava
olhar para algum terreno na Flórida e ter uma visão da Disneilândia,
sabendo que tudo que ele queria fazer em seguida seria sobre a construção
do castelo da Cinderela. Para você, talvez você queira migrar de uma
solução implantada localmente em clientes para uma solução baseada em
108 nuvem. Você precisará tomar medidas ao longo do caminho para alcançar
essa visão de longo prazo e optar por transformar uma dessas etapas em
THE PRODUCT BOOK
sua próxima oportunidade. Como um aparte, espero que alguém tenha

feito alguma validação na visão geral!
O desafio dessas oportunidades é avaliar se você pode fornecer um
valor imediato aos clientes ou se trata-se de uma gratificação atrasada. Se
você acredita que esta oportunidade terá um benefício imediato, valide-a
como qualquer outra oportunidade. Mas se for algo que levará mais
tempo para os clientes se beneficiarem, você poderá fazer apenas algumas
validações internas para garantir que faça sentido trabalhar neste projeto
agora mesmo, pois tira recursos de outros projetos.
Ideias da Equipe
Um dos maiores desafios do PM é sua leve habilidade, agregada a um leve
poder. Ninguém se reporta a um PM: você não pode dizer às pessoas o

que fazer. Em vez disso, você precisa conquistar a confiança das pessoas,
e uma ótima maneira de fazer isso é considerar a criação de um produto
como um esporte coletivo e não como departamentos que trabalham em
silos. Não, não é uma democracia e, no final das contas, muitas vezes
você é quem faz as ligações sobre um produto. Mas, se outras pessoas
souberem que você ouviu e agiu de acordo com a opinião delas, elas se
sentirão incluídas no processo de tomada de decisões e mais felizes com
suas decisões.
Um ótimo lugar para incluir outras equipes está nesta etapa de

idealização. É provável que outras equipes trabalhem de perto com os
clientes, como Design, Suporte ao Cliente, Desenvolvimento de Negócios
109
e Vendas. Entre em contato com as pessoas nessas equipes e veja quais
foram as ideias que eles tiveram com base em sua experiência com os
clientes e o produto. As equipes de suporte apreciam especialmente isso,
pois passam o dia todo trabalhando com clientes reais e têm grande
visibilidade do que os clientes estão fazendo com o produto e falando
sobre isso. Eles geralmente podem fornecer dados como tickets de
suporte para fazer backup de suas ideias.
Além de falar diretamente com outras equipes, você pode organizar

uma sessão de debate em grupo. Existem prós e contras para essas sessões.
Um grande pró é que muitas pessoas se sentem incluídas, e uma ideia
pode inspirar outra pessoa a construí-la com uma ideia diferente. Por
exemplo, a equipe de vendas pode fazer uma solicitação de recurso que
eles acham que ajudaria o produto a vender melhor, e a equipe de suporte
pode mencionar que há muitos tíquetes em torno de todo esse conjunto
de recursos, então talvez deva ser completamente refeito.
Uma grande desvantagem do debate em grupo é que as pessoas, muitas
vezes, se fixam em algumas ideias ou maneiras de pensar, perdendo
outras oportunidades. Como facilitador do grupo, você precisa ajudar
a fazer a criatividade fluir. Uma maneira de fazer isso é fazer com que
todos compartilhem as piores ideias que podem imaginar e, em seguida,
descobrir formas de tornar essas ideias ainda piores. Depois de fazer isso,
aproveite e foque em como melhorar o produto.
Certifique-se de manter essas sessões pelo menos um pouco focadas,
listando suas metas atuais de produto e métricas de sucesso. Se você
quiser debater ideias para aumentar o engajamento, por exemplo, não vai
querer falar sobre colocar mais anúncios no produto.
P&D
Relacionado ao trabalho em equipe, às vezes há novas invenções que um
engenheiro brilhante, ou equipe de engenheiros, cria. O que é legal nessas
110 invenções é que geralmente há um protótipo de alguma forma para que
você possa vê-lo em ação. Adicionar essas invenções ao produto - chamado
THE PRODUCT BOOK
de produtização - geralmente é como os produtos são empurrados para a

próxima geração e podem ser uma grande fonte de satisfação do cliente,
porque o cliente não esperava ou pedia por eles.
No entanto, muitas vezes, pode ser uma estrada difícil, de protótipo

para produto, e o produto inicial pode ter compensações ou limitações
significativas. Se você optar por uma oportunidade como essa, trabalhe
de perto com a Engenharia para entender todos os desafios que você
precisará resolver para tornar esse protótipo útil para os clientes em suas
vidas diárias.
A Competição
Stravinsky, Faulkner, Picasso…independentemente de quem disse isso,
você pode ter escutado a citação: “Bons artistas copiam. Grandes artistas

roubam”. Às vezes, sua concorrência tem uma ótima ideia e roubá-la - e
torná-la melhor - é a sua oportunidade.
Tenha cuidado com essa fonte. “Porque o outro cara fez isso” nunca é
um motivo válido para criar um recurso - isso é apenas copiar. Primeiro
de tudo, como você sabe que a concorrência é inteligente e não está
cometendo um erro com esse recurso? Você também quer garantir que
esse recurso/ produto seja compatível com o contexto de sua empresa.
Além disso, você quer pensar em onde a bola vai estar, e não onde ela
está agora. Se você estiver sempre roubando ideias, você nunca estará à
frente. Mas os benefícios dessa fonte é que você pode ver como o recurso
funciona na vida real, como os clientes reagem a ele e o que você gostaria
111
de fazer de forma diferente.
Veja um exemplo simples: durante anos, muitos fabricantes de PCs

produziram netbooks simples, lentos e pequenos, de baixo custo, e muitos
analistas continuaram pedindo que a Apple fizesse um. No entanto, a
Apple prefere produtos de alta qualidade e alta margem e, em vez de fazer
o que todo mundo estava fazendo e o que os analistas pensavam que a
Apple deveria fazer, a Apple criou o MacBook Air (que era incrivelmente
pequeno, mas tinha um teclado de tamanho normal) e eventualmente
o iPad. Ambos alavancaram os pontos fortes da Apple, ambos foram
amados pelos clientes e ambos tinham as margens que a Apple pretende
manter. Até agora, os netbooks estão inoperantes e muitos fabricantes de
PCs criaram suas próprias imitações do MacBook Air e iPad.
Quadro de Modelo de Negócios e Quadro de Proposta
de Valor
Outra maneira de criar uma hipótese de oportunidade é analisar ex-
plicitamente como um produto se encaixa em um negócio e como o
produto fornece valor para o cliente. Alexander Osterwalder e Yves Pig-
neur criaram duas ferramentas para ajudá-los a determinar esses ele-
mentos, o Quadro de Modelo de Negócios (Business Model Canvas) e
o mais novo Quadro de Proposta de Valor (Value Proposition Canvas),
respectivamente.
Eles também têm dois livros, com os mesmos títulos originais das
próprias ferramentas, que fazem um ótimo trabalho explicando essas
ferramentas com mais profundidade do que cobrimos. Usando essas
ferramentas para analisar seu produto, você pode enxergar aquela
conexão ausente que permite pensar em uma oportunidade.
112
Quadro de Modelo de Negócios

THE PRODUCT BOOK
O Quadro de Modelo de Negócios (ou Business Model Canvas) fornece

uma maneira de olhar para todos os aspectos de sua empresa com
um enquadramento diferente do que mostramos no Capítulo 2. Ele é
muito focado em pessoas, valores e renda, e preenchê-lo exige que você
liste fatos e hipóteses (por exemplo, “Acreditamos que essas pessoas
serão parceiros de distribuição ”). Esta ferramenta foi originalmente
desenvolvida para uma empresa recém-criada com um produto, mas
também para um produto dentro de uma grande empresa. A Figura
3-5 mostra essa tela e você pode encontrar uma versão para imprimir e
preencher em http://strategyzer.com.
Quadro de Modelo de Negócios

Figura 3-5. O Quadro de Modelo de Negócios fornece uma maneira de examinar todos os
aspectos do seu produto.
113
Veja o que cada bloco abrange:
Principais parceiros: Quem são as pessoas de fora da empresa, de

fornecedores a contratados, que fazem o modelo de negócios funcionar?
Quais os principais recursos que obtemos deles e que atividades
principais eles realizam? As empresas raramente fazem tudo sozinhas,
e trabalhar com parceiros permite reduzir o risco e otimizar suas
atividades. Geralmente, existem três tipos de parcerias: alianças
entre não concorrentes, parcerias estratégicas entre concorrentes e
empreendimentos conjuntos para construir algo novo.
Principais atividades: Quais são as tarefas que uma empresa deve

fazer bem para entregar seu valor? Por exemplo, a Apple possui várias
atividades importantes: desenvolvimento de software, gerenciamento
da cadeia de suprimentos, gerenciamento/ distribuição de lojas e mui-
to mais. A unidade de telefone da Samsung está mais focada no geren-
ciamento da cadeia de suprimentos e no desenvolvimento de software.
Principais recursos: Quais são os recursos físicos, financeiros, intelectuais

(patentes, direitos autorais etc.) ou humanos mais importantes que a
empresa precisa para ter sucesso? Eles podem ser de propriedade própria
ou alugados. Para muitas empresas que produzem hardware, recursos
humanos e intelectuais são fundamentais, enquanto a fabricação é
terceirizada para um parceiro asiático.
Proposições de valor: Qual é o benefício/valor que determinado grupo

de seus produtos ou serviços oferece a uma determinada pessoa? Quais
pontos problemáticos do cliente você está resolvendo? O Quadro da
Proposta de Valor também irá aprofundar isso.
114
Relacionamentos com clientes: Que tipo de relacionamento, de pessoal
THE PRODUCT BOOK
a automatizado, você deseja estabelecer com cada pessoa? Por exemplo,

um cliente de alto valor pode ter um e-mail direto para um gerente de
contas, enquanto o cliente médio pode ter apenas fóruns de suporte
on-line disponíveis. Além disso, considere o que cada segmento
espera, o que você tem agora, qual é o custo de cada relacionamento e
como espera manter cada relacionamento.
Canais: Como a empresa alcança cada persona para fornecer o valor,

incluindo marketing, comunicação, distribuição, vendas e suporte? Como
você está alcançando eles agora? O que funciona melhor? Como os
canais integrados, por exemplo, são vendidos apenas pelo seu site?
Segmentos de clientes: Quem são as principais pessoas que a empresa
/produto atenderá? Estas são as pessoas mais importantes para as
quais você acredita que serão mais valiosas e para as quais você deseja

priorizar as oportunidades. O Quadro de Proposição de Valor também
entrará a fundo nesta questão.
Estrutura de custos: De onde vêm os seus custos? Isso se divide em

custos fixos (salários, aluguéis, serviços públicos) e custos variáveis
(compras de equipamentos). Para muitas empresas, os recursos
humanos são a maior despesa, porque as pessoas são necessárias para
realizar atividades-chave para que as empresas possam entregar seu
valor às suas personas.
Fluxos de renda: Representa o caixa de entrada da empresa - renda

menos custos são os ganhos da empresa. Uma empresa pode ter
múltiplos fluxos de renda, dependendo de seus segmentos de 115
clientes, e perguntar a qual valor você entrega e que cada segmento
de cliente pagará, o quanto pagam atualmente e como prefeririam
pagar - por exemplo, menor taxa recorrente versus maior taxa
única - ajuda você a determinar como monetizar cada segmento.
Por exemplo, algumas empresas oferecem edições “Residenciais”
com desconto em seus produtos, que não possuem recursos
importantes para trabalho, como a colaboração de documentos,
que não são úteis para uma família comum.
A edição “Residencial” é um fluxo de renda e a versão regular é outro.

O Quadro de Modelo de Negócios é ótimo porque nos permite escrever
todas as nossas hipóteses, da oportunidade à distribuição, em um só
lugar. Usando o Quadro de Modelo de Negócios sozinho, é preciso uma
reflexão profunda para encontrar uma hipótese de grande oportunidade.
Felizmente, os autores do Quadro desenvolveram uma ferramenta mais
nova, o Quadro da Proposta de Valor (Figura 3-6), também disponível
em http://strategyzer.com, e que detalha os blocos de Propostas de Valor
e Segmentos de Clientes para identificar realmente como o produto está
ou não está fornecendo valor para os clientes, e quais são as necessidades
dos clientes.
QUADRO DE PROPOSTA DE VALOR
Proposta de valor Segmento de cliente
Criadores de Ganhos Ganhos
Produtos & Trabalho(s)

Serviços do Cliente
116
Dores
THE PRODUCT BOOK
Aliviadores de Dor
Figura 3-6. O Quadro de Proposta de Valor está focado na interação entre o cliente e o pro-
duto, e as necessidades do cliente mal atendidas ou não atendidas são uma possível oportuni-
dade de produto.
O objetivo do Quadro de Proposta de Valor é ajudá-lo a obter o ajuste

do produto / mercado. Essa frase significa simplesmente que “um bom
número de clientes quer o que você está vendendo”. Esse conceito é
especialmente importante para as empresas recém-criadas que criam seu
produto inicial, já que as empresas recém-criadas precisam encontrar
os clientes o mais rápido possível. Se elas não conseguirem encontrar
clientes, elas precisarão girar os negócios em eixo para se concentrarem
em novos clientes, possivelmente até com um novo produto, ou precisarão
fechar os negócios. Isso também se aplica a novos recursos em produtos

existentes. Afinal, você quer construir um recurso que um bom número
de clientes usará.
A primeira parte do Quadro de Proposta de Valor é mergulhar no

cliente - concluir essa parte da tela pode ajudá-lo a refinar suas personas!
Existem três aspectos fundamentais quanto aos Clientes: empregos,
ganhos e dores.
Os trabalhos do cliente são simplesmente as coisas que os clientes
estão tentando fazer, em suas próprias palavras, seja uma tarefa que estão
tentando realizar, um problema que estão tentando resolver ou uma
necessidade que desejam satisfazer. Por exemplo, um proprietário do
relógio da Apple provavelmente está interessado em rastrear facilmente
sua boa forma - uma tarefa - e aparência elegante - uma necessidade. 117
Os clientes podem ter vários trabalhos e nem todos os trabalhos têm o
mesmo peso. Se você já ouviu alguém dizer “Moda em vez de função”,
essa pessoa está escolhendo um trabalho social - com aparência de moda
- sobre a tarefa real. Os trabalhos do cliente se alinham bem com os casos
de utilização do produto.
Os ganhos são os resultados que o cliente deseja alcançar, em suas

próprias palavras.
Eles podem ser esperados, e requeridos ou desejados, ou
surpreendentes, idealmente de uma maneira positiva. Ganhos não são
apenas de utilidade funcional: eles podem fornecer valor social (isso me
faz parecer maneiro!), emoções positivas ilícitas (eu amo este produto!), ou
de economia dinheiro (Isso custou apenas 1/10 do preço real!).
Ao conversar com os clientes sobre os ganhos que eles querem, torne
as coisas tão concretas quanto possível. Se o cliente disser que “precisa
ser rápido”, descubra o que significa “rápido”. 1 segundo? 10 segundos?
10 minutos?
Por fim, temos as dores. Estas descrevem os obstáculos que impedem
o cliente de concluir os trabalhos, juntamente com possíveis resultados e
riscos ruins. Apenas como ganhos, tente fazer estes concretos. Se o cliente
disser que esperar por um táxi é um desperdício, pergunte quantos minutos
leva até que pareça um desperdício. Também tente medir o quão ruim
cada dor realmente é. Esperar 10 minutos por um táxi é uma dor, mas isso
impede você de tentar chamar um táxi ou entrar uma vez que chega?
A segunda parte do Quadro de Proposta de Valor é o(s) seu(s)

produto(s) e que também tem três aspectos: produtos e serviços, criadores
de ganhos e analgésicos.
Produtos e serviços são bastante diretos: quais são os produtos e
118 serviços disponíveis para cada segmento de persona / cliente?
Os criadores de ganhos referem-se a como seus produtos e serviços criam
THE PRODUCT BOOK
benefícios e resultados que o cliente deseja, sejam eles exigidos, desejados

ou surpreendentes. Novamente, esses ganhos podem ser funcionais,
resolução de problemas ou sociais (incluindo redução de custos).
Os analgésicos são a forma como o seu produto aborda as principais
dificuldades do cliente. Você não precisa lidar com todas as dores, mas deve
ficar claro na Tela como o seu produto aborda as principais dificuldades.
Analgésicos e criadores de ganhos são as partes do seu produto
que criam valor para o segmento de clientes. O objetivo do Quadro de
Proposta de Valor é fazer essas duas categorias - para tornar essa criação
de valor - explícitas. Se não estiver claro ou estiver faltando uma peça, você
provavelmente terá uma ótima oportunidade de melhorar seu produto.
No final do dia, o ajuste do produto/ mercado ou ajuste do recurso /
mercado resume-se a abordar os principais ganhos e esforços do cliente
com êxito. Se o cliente deseja ganhos importantes que você não oferece ou
tem um grande problema que você não resolve, essas incompatibilidades
criam uma oportunidade muito boa para você melhorar seu produto.

Observe também que alguns produtos, especialmente produtos B2B,
podem ter várias personas, portanto, você precisará de vários quadros
de Proposta de Valor, um para cada persona. Ao trabalhar para validar
sua oportunidade e aprender mais, refaça seu Modelo de Negócios e os
Quadros de Proposta de Valor para incorporar as novas informações.
Você pode até querer especificamente apontar o que é validado e o que
ainda é uma hipótese.
Fatores Externos
Embora todas as formas de criar uma hipótese de oportunidade nos
forneçam hipóteses boas e educadas, às vezes há fatores externos -
digamos - que forçam uma oportunidade. A mais simples e compreensível 119
é quando surge uma boa oportunidade de negócio. Por exemplo, talvez
um parceiro ofereça um contrato grande se um determinado recurso for
adicionado ao produto dentro de um determinado período de tempo.
É provável que até o PM tenha certeza de que esse recurso vale a pena,
geralmente medindo o custo da adição do recurso em relação ao valor do
contrato, mas esse tipo de organização geralmente terá prioridade sobre
os planos anteriores. Em seguida, às vezes em indústrias regulamentadas,
os regulamentos mudam e você tem que priorizar o cumprimento desses
regulamentos ou o produto pode ser retirado da venda.
O último método qualitativo é também o mais frustrante. É quando
seu chefe ou alguém acima de você diz: “Apenas faça isso.” Um bom líder
terá um raciocínio por trás da demanda ou até mesmo estará disposto
a mudar de idéia se você provar que é uma oportunidade inválida, mas
nem todo líder é racional, e nem todas as pistas racionais são capazes de
explicar seu pensamento o tempo todo. Às vezes, você só precisa priorizar
o que seu chefe quer, mesmo que não seja a melhor oportunidade.
USANDO O MODELO DE KANO PARA ENCONTRAR

OPORTUNIDADES
Nos anos 80, o professor Noriaki Kano criou uma estrutura para ajudar as
equipes a descobrir e classificar três categorias de necessidades / atributos
do cliente. Observar a localização do seu produto pode ajudá-lo a descobrir
oportunidades para trabalhar em seguida, com base em necessidades não
atendidas ou não mencionadas. Além disso, ajuda a avaliar se investir em
sua oportunidade proporcionará um retorno que vale a pena, ajudando
você a fazer a transição para priorizar suas oportunidades.
O modelo Kano define três princípios que um produto precisa atingir
para ser bem-sucedido ao longo do tempo:
120 1. Valor atrai clientes.

2. A qualidade mantém os clientes e cria lealdade.
THE PRODUCT BOOK
3. A inovação diferencia seu produto dos outros e o mantém

competitivo.
Em seguida, o modelo mapeia esses princípios em categorias de recursos.
Recursos básicos. Essas são as coisas que os clientes esperam de um

produto, geralmente ao mapear o princípio de valor, e os clientes ficarão
muito insatisfeitos se forem mal executados ou estiverem faltando.
Infelizmente, fazer isso muito bem não deixará seus usuários satisfeitos,
mas minimizará a infelicidade deles. Se você pressionar o pedal do
acelerador em seu carro e o carro mal se mover, você ficará infeliz. Se
seu carro não tiver o pedal de freio, você ficará muito infeliz. Se um
aplicativo no qual você precisa fazer login não tiver um recurso de
recuperação de senha, você ficará muito insatisfeito quando precisar. Se
você tiver o recurso de recuperação de senha mais rápido e mais bem
projetado de todos os seus aplicativos, seus clientes não ficarão muito
mais felizes do que se você tivesse um recurso básico de recuperação.

Os recursos básicos podem ser difíceis de identificar quando se fala
com os clientes, pois os clientes esperam que eles estejam lá e não os
mencionam explicitamente. Com que frequência você procura “papel
higiênico incluído” ao reservar um Airbnb? Geralmente você descobre
a falta de recursos básicos de sistemas de reclamações, pesquisas com
clientes perdidos e análises de atrito.
Recursos de desempenho (satisfatórios). Essas são as coisas que os

clientes estão julgando frequentemente em seu aplicativo e as coisas
que eles procuram antes de comprar. A satisfação de seu cliente com
esses recursos será proporcional ao desempenho dos mesmos. É
bastante fácil encontrar informações sobre como falar com os clientes,
seja por meio de entrevistas ou pesquisas, porque são coisas que um 121
cliente frequentemente pedirá, elogiará ou reclamará. Por exemplo,
um desempenho mais rápido em um aplicativo leva a uma maior
satisfação. Ter menos etapas para atingir uma meta também aumenta
a satisfação.
Recursos de excitamento (encantamento). Esses são os recursos

inesperados que se tornam diferenciadores de produtos, inovações
e pontos de venda exclusivos, como a tela de toque capacitiva do
iPhone, o painel de notificações do Android ou o Wi-Fi em um vôo
aéreo. Quando você faz isso bem, eles criam uma excitação e prazer
significativos. Se eles estiverem ausentes, os clientes permanecerão
neutros: eles não sabem o que estão perdendo. Esses recursos são os
mais difíceis de descobrir e realmente exigem uma compreensão da
necessidade do cliente. Eles são frequentemente encontrados apenas
qualitativamente.
Essas três categorias de recursos são geralmente representadas graficamente
(Figura 3-7) para mostrar como a satisfação do cliente se compara ao seu
nível de investimento/ execução. É uma maneira útil de ajudar a avaliar
quanto esforço você deve gastar em vários recursos, além de avaliar em que
categorias de recursos vale a pena se concentrar a seguir.
Encantamento
Investimento
Satisfatórios
122
Básicos
THE PRODUCT BOOK
Figura 3-7. O modelo Kano oferece uma maneira de avaliar a satisfação que cada recurso
oferece, em comparação com o tipo de recurso e com a eficiência com que ele é executado.
Com o tempo, cada recurso se move para baixo em sua categoria. Os

recursos de excitação tornam-se recursos de desempenho e os recursos de
desempenho tornam-se necessidades básicas. A primeira vez que você teve
Wi-Fi em um voo, provavelmente ficou feliz em verificar seu e-mail durante
o vôo. Agora você provavelmente espera que todos aviões tenham Wi-Fi e
ficará desapontado quando houver um sinal ruim ou não tiver Wi-Fi.
No geral, a primeira versão do seu produto precisa cobrir os recursos

básicos. Cada geração sucessiva deve se concentrar em uma mistura de
satisfatórios e delatores, além de garantir que você continue cobrindo os
recursos básicos.
Para encontrar oportunidades de recursos usando o modelo Kano,
mapeie seu produto e seus recursos em relação ao modelo. Quais são os
recursos para atender às expectativas básicas? Eles estão atendendo às

expectativas? Você cobriu todos os fundamentos? Se assim for, passe para
um recurso satisfatório ou de encantamento.
Uma grande frustração para os Product Managers é que os recursos
básicos podem exigir um investimento significativo para chegar a um
nível razoável. Enquanto você quer gastar seu tempo trabalhando com
os recursos satisfatórios e de encantamento, pular os recursos básicos
ou fazê-los mal, muitas vezes levará a uma menor satisfação do cliente,
mesmo se você tiver um ótimo recurso de encantamento.
Se você estiver trabalhando em uma nova versão de um produto
existente, considere quais recursos começaram como recursos de excitação,
mas agora são esperados e algo que a concorrência também tem. Ou, de
forma semelhante, o que a concorrência acrescentou que seus clientes
agora também esperam? Como isso afeta sua hipótese de mapeamento 123
/ oportunidade de recursos? A identificação pelo toque começou como
um recurso de excitamento do iPhone, e agora o desbloqueio através de
impressão digital é bastante comum e esperado em smartphones. Que
novos excitamentos você pode encontrar para alcançar uma satisfação
significativa do cliente?
HIPÓTESES DA MOOVER.IO
No Capítulo 2, mencionamos que, quando você faz uma mudança com a
Moover, a empresa de mudanças faz uma ligação para planejar os detalhes.
Com base em pesquisas de satisfação do cliente, constatou-se que é isso
que os clientes atuais, que dão à empresa um NPS menor, reclamam mais.
Sendo uma empresa jovem, a Moover tem que equilibrar o crescimento
do negócio em relação à satisfação do cliente.
A equipe se reuniu e debateu ideias, e a outra possibilidade que emergiu
foi algum tipo de programa de referência para ajudar no crescimento. No
entanto, considerando o quão raramente as mudanças acontecem no geral,
a equipe decidiu se concentrar em tornar os clientes mais felizes primeiro. A
ideia é que os clientes satisfeitos fornecerão naturalmente boas referências
boca a boca e, posteriormente, se a Moover não tiver um crescimento
suficientemente bom, poderá experimentar várias técnicas de crescimento.
Depois de analisar os resultados da pesquisa de satisfação e o fluxo de
trabalho do produto, foi assim que eles planejaram:
• Meta da empresa: melhorar a satisfação do cliente.

• Objetivo do produto: reduzir o atrito no fluxo de trabalho atual.
• Hipótese de oportunidade: podemos melhorar a satisfação do
Beto Realmente-Ocupado se eliminarmos as ligações telefônicas
com as empresas de mudanças e consolidarmos a comunicação em
uma ferramenta de mensagens no próprio aplicativo.
124 • Métricas de sucesso: Como a satisfação do cliente é nosso principal
objetivo, podemos medi-lo rastreando nosso NPS.
THE PRODUCT BOOK
• Outras métricas principais: Outros fatores-chave que indicam se

os clientes estão atingindo suas metas e usando o a a esse recurso
está a porcentagem de caplicativo são as percentagens de clientes que
concluem o funil da reserva para a mudança concluída e o número
de mensagens enviadas por cliente.
Neste ponto, como fizemos com a Moover, você deve ter uma hipótese sobre
o cliente não atendido que deseja abordar para suas personas, uma ideia sobre
por que você está aquém agora, as principais métricas que deseja melhorar
e, possivelmente, uma idéia do que você quer fazer para tentar resolver esse
problema. Todos esses elementos devem ter alguma evidência de apoio,
mesmo para oportunidades de céu azul. Continue lendo para saber como
validar essas oportunidades e ver se elas valem a pena.
4. Validando suas Hipóteses
CAPÍTULO QUATRO
VALIDANDO SUAS HIPÓTESES
Agora que temos uma ideia, precisamos nos certificar de que é a coisa 125
certa a fazer em seguida. Toda ideia tem um custo de oportunidade.
Trabalhar no Recurso A significa que você não está criando o Recurso B.
A marca de um Product Manager eficaz é poder separar as grandes ideias
das meramente boas.
Continuando nossa analogia com o método científico, agora que
temos uma hipótese sobre o que fazer a seguir, precisamos projetar e
executar um experimento para provar ou refutar nossa hipótese. Em
outras palavras, queremos validar se nossa ideia - não importa quão
grande ou pequena - realmente nos ajudará a alcançar nossos objetivos.
O experimento ideal para validar nossa hipótese seria construir o

produto completo e ver como nossas métricas de sucesso mudam. Às
vezes, essa é a coisa certa a fazer, como se sua hipótese fosse que corrigir
um pane no sistema ou adicionar um recurso pequeno ajudaria você a
atingir suas metas. Mas muitas vezes, construir o produto completo é
um grande investimento em tempo e custo. Isso significa que é muito
arriscado sempre criar o produto completo para ver se ele atinge seus
objetivos. Em vez disso, as empresas começaram a adotar os princípios
enxutos que discutimos, encontrando maneiras menos caras de validar
uma ideia antes de criar o produto.
Essas abordagens de validação assumem várias formas. Algumas ideias

precisam apenas de validação interna, examinando os dados existentes,
como análises, e discutindo com os principais interessados sobre o custo
/ benefício dessa oportunidade antes de decidirem prosseguir ou não.
Com outras ideias, especialmente para novos produtos ou novos
recursos importantes, você deseja conversar com clientes reais, atuais
e potenciais, diretamente por meio de entrevistas e indiretamente por
meio de pesquisas. Essa abordagem, chamada de desenvolvimento do
126 cliente, ajudará você a entender os pontos de aflição e as metas de seus
clientes mais detalhadamente, para que você possa validar se sua ideia
THE PRODUCT BOOK
atenderá às necessidades deles. Você pode até descobrir que uma ideia
diferente que muitos clientes reclamam vale a pena perseguir, em vez de
sua hipótese original.
O último método de validação de ideias que abordamos é executar

uma experiência real e ver como suas métricas são alteradas. Para um
novo produto ou recurso, você pode optar por criar um produto viável
mínimo de baixo custo (MVP, abordado resumidamente no Capítulo 1).
Não confunda a criação de um MVP com a criação do produto completo.
Como falaremos mais adiante, os MVPs podem até ser movidos por
pessoas. Como alternativa, se sua ideia estiver centrada na alteração de
um fluxo de trabalho, você poderá executar um teste A/ B, que permita
comparar duas versões de algo, como dois fluxos de trabalho de inscrição
diferentes, para ver qual deles atinge métricas de sucesso melhores.
O caminho certo para validar sua hipótese de oportunidade depende
da sua situação específica. Em geral, para cada nova ideia, você deseja ter
dados objetivos, dados anedóticos e dados de custo/ benefício para poder
avaliá-la totalmente. Isso significa que você terá que fazer vários tipos de
validação. Você pode executar um teste A/ B para reunir dados analíticos,
determinar o custo conversando com o líder de engenharia e, em seguida,

ter uma discussão interna com os principais interessados sobre o custo/
benefício. Apenas mostrar que a ideia atingirá seus objetivos, o que um
teste A / B pode fazer, não significa que seja a coisa certa a ser feita se o
produto for muito caro para ser construído.
Por fim, depois de encontrar e validar uma ideia, você precisa avaliar
onde ela se encaixa no roteiro. Só porque você encontrou uma ótima
oportunidade não significa que é a melhor coisa para a empresa trabalhar
em seguida. Colocando essas ideias em conjunto com a Moover, como
você pode validar sua ideia sobre como melhorar a satisfação do cliente 127
criando uma ferramenta de mensagens no aplicativo? Você já tem dados
de uma pesquisa do NPS, então concentre sua energia no desenvolvimento
do cliente, entrevistando clientes reais e potenciais para coletar dados
anedóticos e garantir que você realmente entenda suas necessidades e
pontos problemáticos / como deixá-los mais satisfeitos com a Moover. Se
essas entrevistas indicarem que mensagens realmente são o maior ponto
problemático, converse com a Engenharia e Design sobre o que será
necessário para construir um MVP desse recurso, e se a equipe concordar
que isso dará o maior valor comercial pelo custo, vá construí-lo .
Vamos nos aprofundar em cada um desses métodos de validação com
mais detalhes.
ANÁLISE SWOT
Uma análise SWOT é um método comum para observar como uma
hipótese de oportunidade se encaixa. SWOT significa forças, fraquezas,
oportunidades e ameaças. Essa estrutura o ajudará a identificar os elementos
internos e externos mais importantes para alcançar seus objetivos.
Para fazer uma análise SWOT, primeiro identifique seus principais
objetivos e métricas de sucesso. Em seguida, crie uma tabela dois-por-dois,
como na Tabela 4-1. A linha superior será seus elementos internos - os
pontos fortes e fracos do produto/ empresa a fim de alcançar seus objetivos.
A linha inferior examinará elementos externos - as oportunidades e
ameaças, incluindo tendências culturais, governamentais e tecnológicas.
Forças: Visão internamente Fraquezas: Visão internamente

128 focada naquilo em que você se
focada de seus pontos baixos
destaca
THE PRODUCT BOOK
Oportunidades: Visão
externamente focada no que você Fraquezas: Visão internamente
está bem posicionado para ir atrás focada de seus pontos baixos
Tabela 4-1. A análise SWOT fornece uma boa maneira de colocar uma oportunidade no
contexto em um alto nível, observando os elementos internos e externos.
Se sua oportunidade ajudar a melhorar uma força específica, aproveite

essa oportunidade. Ou, inversamente, se uma oportunidade limitar ou
converter uma fraqueza ou ameaça, provavelmente valerá mais a pena
continuar persistindo. Se não levar em consideração ou não abordar um
dos itens de alta prioridade, provavelmente não valerá a pena agora.
VALIDAÇÃO INTERNA
Como PM, você descobrirá que não há falta de boas ideias sobre o que fazer
em seguida. Em um mundo ideal, faríamos uma validação abrangente de
cada ideia, mas isso é bastante impraticável. Em vez disso, podemos fazer
uma validação interna preliminar para ver se vale a pena prosseguir com
uma ideia. Veja uma lista de perguntas de verificação que lhe ajudarão a

validar uma oportunidade. Se a resposta a qualquer um desses itens for
negativa, provavelmente você não deve buscar essa oportunidade.
• Esta oportunidade está alinhada com a nossa visão?

• Ela suporta a visão e a função principal do produto?
• Podemos fazê-la bem com nossas capacidades (ou é viável e desejável
expandir nossas capacidades para atender a oportunidade)?
• Como isso contribui para as nossas principais métricas?
• Temos algum dado, seja de análises, pesquisas ou relatórios de erros,
129
para dar suporte a essa oportunidade?
• É necessário atender a uma iniciativa empresarial crítica?
• Como isso contribui para a vitória dos nossos usuários?
• Está no nosso roteiro para este ano, mesmo indiretamente, como
parte de outra coisa?
• Será importante em dois anos? (Tudo bem se o recurso for atender
a uma necessidade imediata, mas você vai querer limitá-los, já
que deseja priorizar itens que tenham um valor mais alto ao longo
do tempo.)
• Todos se beneficiarão? Se isso apenas ajuda um grupo de clientes de
nicho, vale a pena o custo?
• Se for bem sucedido, podemos apoiá-lo?
Nossos amigos da Intercom (apresentados no Capítulo 3) também
sugerem observar seu retorno sobre o investimento em desenvolvimento
para validar uma oportunidade. Crie uma grade de dois por dois, como
na Figura 4-1, analisando o esforço de desenvolvimento (alto/ baixo)
versus como os usuários valorizam o recurso/ produto (alto/ baixo) e
descubra onde essa oportunidade se encaixa.
Valor de Usuário
Recurso A Recurso B
Esforço de Desenvolvimento
130
Recurso C
THE PRODUCT BOOK
Figura 4-1. Criar uma grade para comparar o esforço de desenvolvimento com o valor do
usuário é uma maneira fácil de visualizar e comparar diferentes oportunidades. O ideal é que
você faça tarefas de baixo esforço/ alto valor de usuário primeiro (Recurso A) e evite tarefas de
alto esforço/ baixo valor de usuário (Recurso C) o máximo possível.
Infelizmente, esse não é um teste decisivo para as oportunidades, porque às

vezes precisamos fazer coisas de alto nível que os usuários não valorizam,
como reconstruir um sistema de retaguarda, mas essa grade ajudará você
a colocar as coisas em contexto. Recursos ou produtos altamente valiosos,
de baixo esforço, quase sempre valem a pena. Para algumas hipóteses de
oportunidade, como “consertar um erro no sistema nos ajudará a atingir
nosso objetivo”, esse nível de validação pode ser tudo o que você precisa.
Se estiver claro pelos dados que o erro afeta significativamente muitos
usuários, isso impede que os usuários ganhem, você tem os recursos para
isso, e o custo versus valor não supera algo que você quer fazer, então
ótimo - você validou que vale a pena consertar o erro do sistema! Outras
hipóteses exigem mais esforço para validá-las.

Essa validação interna também pode ajudar com uma habilidade
leve: Respeito. Com frequência, você tem pessoas em toda a empresa que
oferecem ideias de produtos. Na verdade, você terá mais ideias do que
pode implementar. Isso significa que você passará a maior parte do tempo
dizendo “não” a boas ideias porque deseja se concentrar nas melhores
ideias. Mas se você simplesmente disser “não” sem uma razão, as pessoas
sentirão que você não as escuta, afetando o quão bem vocês trabalham
juntos, e elas vão parar de abordá-lo com idéias, o que poderia impedir que
você encontrasse uma ótima. Ao fazer uma validação interna, você poderá
explicar de maneira fácil e explícita por que está buscando uma ideia em 131
detrimento da outra, fazendo com que as pessoas sintam que você as
escutou e não está apenas tomando decisões arbitrárias sobre os produtos.
DICA DO CAPÍTULO QUATRO
A dica deste capítulo nos foi dada pelo Nik Laufer-Edel. Nik leciona
na Product School e ajudou a projetar o currículo. Além da Prod-
uct School, Nik lidera a equipe principal de experiência em pas-
sageiros da Lyft. Anteriormente, aproveitando sua experiência em
design e pesquisa, liderou a iniciativa de reimaginar a experiência
de aprendizado on-line na Udemy, um mercado de 13 milhões de
estudantes em todo o mundo. Ele adora discutir o processo de descob-
erta de produtos, aprender ciência, design de comunicação e o futuro
do trabalho, e você pode encontrá-lo em cafeterias em San Francisco
ou no Twitter @nikdotca.
132
VOCÊ PRECISA DE CONTEXTO PARA FAZER BOAS DECISÕES
DE PRODUTOS
THE PRODUCT BOOK
No final do dia, sabemos que o mais importante é se concentrar em

ajudar nossos usuários a vencer. Para fazer isso, sabemos que primeiro
precisamos entender nossos usuários. Sabemos que devemos validar
nossas suposições mais arriscadas. Sabemos que devemos ganhar
confiança de que nosso problema faz sentido para trabalhar e que nossas
soluções realmente resolvem o problema. Mas precisamos saber mais para
tomar boas decisões sobre produtos.
Ao longo dos anos, projetei um modelo simples de jornada do cliente

para me lembrar do contexto necessário para definir problemas e avaliar
soluções. A base do modelo surgiu durante os dois anos que passei fazendo
pesquisa de desenvolvimento de clientes em uma fase inicial de uma
empresa recém-criada. Ela evoluiu desde então para incorporar algumas
das pesquisas em torno da teoria da motivação, bem como os conceitos
discutidos no âmbito do enquadramento de Trabalhos a Serem Feitos.
What motivates the user

to make process

Current Desired
state and Custumer’s journey states and
perception and user flow success
of the criteria as
problem definted by
user
What hinders the user

from making progress
Supondo que você não esteja tentando criar um comportamento totalmente 133
novo, o modelo age como um lembrete de que seus usuários já têm uma
perspectiva do problema que você está resolvendo, uma maneira de avaliar
o sucesso e um meio pelo qual eles trabalham esse estado desejado.
Esses são os blocos básicos de compreensão dos usuários e hoje essas
informações são geralmente capturadas em personas, métricas e fluxos de
usuários. O que pode estar faltando nesses artefatos é o que motiva os
usuários a progredirem em direção a um estado desejado e o que os retém.
Você pode usar esse modelo da jornada do cliente como sua Estrela do
Norte ao articular ou refletir sobre qualquer iniciativa de produto.
ESTADO ATUAL
• Qual é a perspectiva atual dos usuários sobre o problema? Como
eles pensam e se sentem sobre isso?
• Jornada
• Quais são os passos atuais que eles tomam? Geralmente, esse é o
fluxo do seu aplicativo, mas também pode incluir etapas fora do seu
aplicativo ou usando os concorrentes.
MOTIVAÇÃO
• E sobre a solução atual, eles não estão satisfeitos?
• E a nova solução é excepcionalmente atraente?
• Eles acreditam que seguir a jornada os levará ao estado desejado?
• Eles acreditam que têm a capacidade de fazer o que lhes será pedido
em cada etapa?
• Eles acreditam que serão apoiados se tiverem problemas?
IMPEDIMENTOS
• E sobre a solução atual, eles gostam?
• Mudar para a nova solução, os deixam preocupados?
• Estado desejado
• Como eles medem o sucesso? O que estão ganhando?
134 • Como chegar a esse estado os aproxima de outros objetivos maiores?
THE PRODUCT BOOK
Eu começo todas as iniciativas desenhando o modelo para alinhar a equipe

e desenvolver perguntas de pesquisa. Para produtos maduros e iterações
em recursos existentes, você já poderá falar com todas as partes do modelo.
Para novos produtos ou recursos, você descobrirá lacunas no conhecimento
da equipe ou nas premissas arriscadas para enfrentar a validação interna
ou externa. Em última análise, compreender o que a vitória é para o seu
cliente, a situação atual e os fatores que irão ajudá-los ou impedi-los de
progredir, o equiparão e a sua equipe para tomar melhores decisões sobre
os produtos. Boa sorte!
VALIDAÇÃO EXTERNA
A validação externa significa simplesmente obter avaliação de clientes
reais para ver se sua ideia faz sentido. Mesmo que você pense que sabe o
que eles dirão, você não tem certeza até verificar.
Existem muitas maneiras de obter avaliações. A mais simples é ser um
detetive de dados. Quais dados externos sobre clientes reais você pode

encontrar em fontes de pesquisa existentes para validar sua ideia?
Há relatórios de pesquisa relevantes, seja o relatório Tendências da
Internet de Mary Meeker (disponível gratuitamente), os relatórios do NPD
Group sobre o que as pessoas estão comprando e seu comportamento
(esses relatórios são caros, mas os dados são muito valiosos e abrangem
inúmeras indústrias), dados censitários ou até mesmo o Google Trends
para ver o que as pessoas estão procurando?
Às vezes, pode não ser óbvio onde procurar e você precisará ver se
há uma vertical semelhante ou análoga cujos dados informarão suas
135
decisões. Seu principal objetivo é focar na necessidade que as pessoas estão
tentando atender e encontrar pesquisas relevantes para essa necessidade.
Esses dados nem sempre são fáceis de encontrar e podem estar espalhados
em vários relatórios de pesquisa. Os relatórios de analistas financeiros
geralmente são ótimas fontes adicionais das tendências gerais do setor.
Por exemplo, quando os serviços de entrega de comida sob demanda,
como Postmates, estavam apenas começando, eles poderiam ter olhado
os relatórios da indústria alimentícia sobre quantas vezes as pessoas
encomendam entregas de comida, quanto gastam por pedido, o que os
dados demográficos tendem a fazer mais pedidos e onde eles moram,
quais segmentos da indústria alimentícia estão crescendo vs. encolhendo,
e mais. Em segundo lugar, os Postmates poderiam ter pesquisado um
mecanismo de interação específico, pedidos através de alguns botões em
aplicativos móveis, observado aplicativos em demanda como o Uber. Se
a hipótese do Postmates fosse de que as pessoas gostariam de receber
entregas de comida em seus domicílios, elas teriam agregado esses dados,
usando os relatórios da indústria alimentícia para validar a demanda por
entrega de comida junto com os dados do mecanismo para validar que as
pessoas estariam dispostas a pedir de um aplicativo.
Certifique-se de estar atento ao viés de confirmação. É quando
procuramos apenas evidências que confirmem nossa hipótese e ignoramos
as evidências que a contradizem. Mais uma vez, nossa hipótese pode estar
errada, e tudo bem se estiver.
A leitura de dados de mercado pode ser muito útil, mas nem
sempre lhe dá uma boa ideia do que seus clientes estão sentindo e de
suas necessidades não capturadas pelos dados. A empatia pode ser uma
poderosa ferramenta de validação: existe alguma maneira de você ser o
seu cliente para poder entender com precisão as necessidades dele? Às
vezes, isso é fácil; Por exemplo, se você é um PM no Slack, você usa o
Slack internamente para se comunicar. Você saberá como as pessoas
136 usam o produto, porque você o utiliza diariamente, e pode validar sua
ideia analisando a utilidade dela para a sua vida e se há uma compensação
THE PRODUCT BOOK
ou custo que reduziria o valor. Tenha cuidado aqui, pois você precisará
garantir que a maneira como usa o Slack é semelhante à maneira como
seus clientes o usam.
Outras vezes, se colocar no lugar do seu cliente é alcançável, mas exige
esforço. A Ford Motor Company construiu um traje especial, o Traje da
Terceira Idade, que efetivamente simula o que parece ser um motorista
idoso, com mobilidade articulada reduzida, um sentimento simulado de
artrite, condições simuladas de visão prejudicada e muito mais. Este traje
permite que os funcionários da Ford “sejam” um cliente idoso para testar
recursos em seus carros sem ter que trazer um grupo de motoristas de
teste idosos para observar e conversar.
O truque em se colocar no lugar do seu cliente é ter certeza de que
você seja um representante de um cliente real. Mesmo que todos nós
gostamos de pensar que somos um cliente comum, não somos - você é
um PM, você está acima da média! E, especialmente, se o seu produto
tiver várias personas, você provavelmente representará apenas uma
delas. Infelizmente, às vezes, não é realista se colocar no lugar do cliente,

especialmente para produtos empresariais e de nicho. Nesses casos, você
só precisa encontrar outra abordagem para entender seus clientes.
Desenvolvimento do Cliente
Por fim, às vezes é necessário sair do prédio para conversar com os
clientes, atuais e potenciais. Tenha em mente que o objetivo agora é
descobrir se devemos construir uma determinada coisa, não realizar
testes/ pesquisas com usuários para ver se criamos bem uma determinada
coisa. O primeiro acontece no início do processo do produto, e o segundo
acontecerá quando começarmos a construir algo. 137
Então, o que é desenvolvimento de clientes? É uma forma de validar

se as pessoas que você considera realmente seus clientes são os clientes
certos e confirmam que você está no caminho certo. Isso inclui descobrir
quais problemas os clientes estão tentando resolver, o que eles estão
fazendo agora que criam esses problemas e tentam resolvê-los, o que
podem fazer (tecnicamente, financeiramente, socialmente, etc.) e como
eles descobrem e decidem se um novo produto/ recurso vale a pena.
Fundamentalmente, é uma conversa e uma troca de informações.
Também é útil saber o que o desenvolvimento do cliente não é. Não é
uma maneira das pessoas te darem uma lista de desejos. Não é um grupo
de foco para ver apenas como as pessoas respondem às ideias. Não é um
lugar para observar como os clientes usam seu protótipo. Também não é
um substituto para a visão do produto.
Os clientes lhe darão uma enorme lista de desejos, mas eles geralmente
pedem mais do que realmente precisam, acabam não usando recursos e,
em casos realmente ruins, podem ficar confusos com todos os recursos
extras. Esta é uma grande parte da razão pela qual recomendamos ter
algumas hipóteses de oportunidade em mente primeiro.
Entrevistas
Descobrimos que, das várias etapas do ciclo de vida de desenvolvimento
de produtos, as pessoas que são novas no Product Management têm
menos experiência com entrevistas com clientes. Mas entrevistar é uma
habilidade incrivelmente valiosa porque é uma maneira eficaz e de baixo
custo de validar sua hipótese de oportunidade. E como o objetivo final de
um Product Manager é ajudar o cliente a ser incrível, gastar tempo com
os clientes é fundamental para sua função.
Há livros inteiros, como o excelente Desenvolvimento Enxuto de
138 Clientes (Lean Customer Development) de Cindy Alvarez, que aborda
detalhadamente como preparar, fazer e aprender com entrevistas
THE PRODUCT BOOK
com clientes. Faremos o nosso melhor para fornecer uma visão geral
detalhada, mas recomendamos fazer mais pesquisas e praticar suas
próprias entrevistas antes de conversar com os clientes.
Preparando-se para Entrevistas

Assim como você não entra em uma entrevista de emprego sem se preparar,
ou em uma reunião sem antecipar um resultado desejado, as entrevistas
com o cliente são preparadas. Essas etapas são amplamente baseadas no
Desenvolvimento Enxuto de Clientes, porque acreditamos nelas!
Para começar, escreva uma lista do que você sabe de fato e do que está
assumindo sobre nossos clientes, incluindo suas necessidades e como seu
produto as satisfaz.
O Quadro de Modelo de Negócios pode ajudá-lo a identificar as
principais suposições. Naturalmente, os clientes podem ajudá-lo a validar
apenas partes do quadro que se aplicam a eles: segmentos, proposições de
valor, canais, relacionamentos e talvez fluxos de renda. Mas, considerando
o quanto isso é fundamental para o seu negócio/ produto, é muito
importante passar das estimativas para os fatos.

Use o Quadro de Proposta de Valor para identificar o que você
sabe com certeza e o que você está supondo que sejam as dores e os
ganhos desejados de seus clientes. Além disso, tente identificar quais
compensações eles estão dispostos a aceitar para esses ganhos. Por
exemplo, um relógio inteligente fornece ganhos funcionais e de moda
suficientes para que eles estejam dispostos a negociar o valor sentimental
de seu relógio existente? Ou o seu capacete de realidade aumentada
fornece valor suficiente para que seus clientes estejam dispostos a fazer o
sacrifício social de usá-lo? O Google Glass aprendeu os sentimentos dos
clientes sobre essa troca de maneira muito pública e cara. 139
Pode ser útil escrever explicitamente sua hipótese de oportunidade

nos termos deste esquema: “Eu acredito que <personas/ segmentos>
experimentam <essa dor> ao fazer <tarefa> por causa de <limitação>,
e aliviar essa dor deixaria o cliente <alcançar esse ganho>, embora ele
tivesse que <aceitar essas limitações>.”
Não se esqueça do que você pensa que suas principais métricas sejam
e quem você acredita que seus concorrentes são. Seus clientes podem não
ver as mesmas pessoas como concorrentes ou podem saber de soluções
existentes que você ainda não conhece.
Além disso, é útil conhecer sua empresa e o roteiro de produtos: como
você chegou onde está, aonde está pensando em chegar, quais são as
questões pendentes e quais informações dos clientes podem ajudá-lo a
tomar decisões melhores?
É útil analisar qualquer outro traço de persona relevante para sua
hipótese de oportunidade para pensar em com quem conversar e se há
clientes em potencial suficientes para buscar essa oportunidade. Por
exemplo, se o seu produto oferece um serviço de conveniência por uma
taxa, você deve se concentrar nos clientes que pagarão pela conveniência,
em vez de em pessoas que tenham coupons.com como sua página inicial
- no entanto, não deixe de falar com algumas pessoas que valorizam mais
dinheiro do que conveniência para ter uma noção de onde seu ponto de
inflexão pode estar. Outros traços a serem considerados incluem onde os
clientes em potencial se enquadram no risco versus recompensa, de baixo
conhecimento em tecnologia versus experiente em tecnologia, entediado
versus ocupado e espectro de compra frequente versus esporádico.
Uma técnica - esperamos que óbvia - para ajudá-lo a garantir que

você esteja encontrando os clientes certos, é criar perguntas para quem
140 faz a triagem e perguntá-las a possíveis entrevistados. Tente esconder
a resposta "certa" para que as pessoas não respondam com o que elas
THE PRODUCT BOOK
acham que você quer ouvir. Se você quiser pessoas que usem serviços
de transmissão de música, pergunte qual produto elas usam para escutar
música. Também faça perguntas para excluir pessoas, como: "Com que
frequência você escutou música na semana passada?" Braden Kowitz,
do Google Ventures, criou um modelo útil para ajudá-lo a selecionar os
participantes, disponível em https://goo.gl/uPBXD6.
Depois de descobrir com quem você quer conversar (falaremos mais

sobre como encontrar essas pessoas em breve), vamos descobrir o que
perguntar a elas. A coisa mais importante a saber é que, percebam ou
não, as pessoas vão tentar agradá-lo. A coisa mais importante que você
pode fazer é fazer o cliente falar sobre como ele lida com o problema
que você está pensando em resolver. Mesmo se você achar que tem um
novo serviço (imagine alguém considerando um serviço de entrega de
comida como o Postmates pela primeira vez), seu cliente já pode fazer
algo nesse espaço (pedidos de restaurantes que não são seus favoritos
especificamente apenas porque eles oferecem, ou de buscar as comidas
prontas no local, etc.) que você desejará perguntar sobre. Há um
fenômeno chamado "eu ideal", onde se você perguntar a alguém sobre

o que ele pode fazer, ele nunca dará uma boa resposta. Você gostaria de
perder peso? Você gostaria de economizar tempo? Gostaria de receber
comidas dos seus restaurantes favoritos que não entregam atualmente?
Claro que a resposta é sim para todas estas perguntas!
Em vez disso, se você fizer perguntas sobre o que as pessoas fazem
atualmente, verá o que realmente acontece em suas vidas, o que é um
indicador muito melhor do que elas farão no futuro. Com que frequência
você vai a uma academia? Que dietas você fez nos últimos seis meses?
Você paga um trabalhador braçal ou conserta coisas em sua casa por si
mesmo? Quando você fez o último pedido de entrega de comida? Você 141
fez uma escolha de restaurante com base apenas em quem faz entregas?
Da mesma forma, perguntar o que alguém vai pagar é inútil porque

ninguém lhe dará uma resposta honesta e significativa. Mas é útil
perguntar o que eles já pagaram para tentar responder a essa pergunta.
Se eles não gastaram nada na área sobre a qual você está perguntando,
provavelmente não é um problema para eles.
Em vez de perguntar aos clientes se eles gostavam de seu recurso/

produto, porque eles dirão que sim, é melhor saber como eles lidam com
o problema fundamental que você está tentando resolver. A maneira mais
simples de fazer uma pergunta como esta é "Conte-me sobre como você
faz <tema> hoje".
Infelizmente, será necessário receber algumas informações úteis.
Por exemplo, alguém pode ter uma situação ou limitação que ele não
considera relevante para sua discussão, mas que pode ter um papel
enorme. Talvez seu produto precise de uma conexão de celular rápida
para funcionar bem, mas a pessoa que você está entrevistando tem
apenas 3G onde ela mora. É muito útil obter contexto. Aqui estão alguns
exemplos de perguntas:
• Com que frequência você lidou com este tema?

• O que você estava fazendo antes de este tema surgir?
• Depois de terminar, o que você faria?
• Quanto tempo demorou para lidar com o tema?
• O que fez você comprar o produto relevante para este tema?
• Com que frequência você compra o produto?
• Onde você vai para comprar o produto?
142
THE PRODUCT BOOK
Também é muito útil quando você faz perguntas que fazem os clientes
contarem histórias, em vez de dar respostas simples de sim / não. Eles
fornecerão automaticamente algum contexto de fundo ou você poderá
interromper educadamente e solicitar que eles esclareçam qualquer contexto
necessário. As histórias ajudam você a chegar a um nível ligeiramente
abstrato, pois muitas vezes você descobre por que alguém estava usando
o produto, quais eram seus objetivos e o que priorizavam. Você também
descobrirá que as pessoas dizem coisas implicitamente nas histórias para
que você não precise solicitar mais, por exemplo, eles podem mencionar o
uso do Siri, o que significa que eles são usuários do iPhone.
Às vezes, você tem clientes que acham que sabem exatamente o que
querem e lhe dirão especificamente. Para produtos de nicho com usuários
avançados, essas pessoas provavelmente sabem exatamente o que querem
e sabem o suficiente sobre como o produto funciona para saber o que é
possível. Mas esse é um grupo muito pequeno. A maioria dos clientes
não sabe o que é possível ou impossível e você provavelmente desejará
ignorar solicitações de recursos específicas. Em vez disso, é seu trabalho
descobrir as dores subjacentes das pessoas e ver se sua ideia as abordará.
Pense no exemplo do "cavalo mais rápido" de Henry Ford aqui: O pedido

de recurso é um cavalo mais rápido. O desejo subjacente é o desejo de
chegar mais rapidamente a um destino.
Reafirmar a solicitação de recurso de alguém para ter certeza de

que você a entende e perguntar o que ele acha que ele faria ou como ele
visualiza o uso desse recurso é uma maneira fácil de começar a alcançar o
desejo subjacente. Você também pode usar a pergunta "varinha mágica":
se você pudesse acenar com uma varinha mágica e fazer qualquer coisa
que você não pode fazer hoje, qual seria? Qualquer coisa que você possa
imaginar é possível. O que você gostaria? Isso pode parecer uma pergunta 143
ideal, mas não é, porque não estamos perguntando se um cliente faria
alguma coisa. Na verdade, estamos perguntando: "Qual é o seu maior
ponto de dor em torno deste tema?" De uma maneira mais divertida.
Espero que nossa hipótese resolva isso!
Também é relevante perguntar sobre compensações. “Se <novo
recurso/produto> fosse criado, mas custaria <compensação>, como você
se sentiria?” Isso começa a afetar a questão do eu ideal, mas pode lhe dar
uma ideia do que um cliente valoriza.
Às vezes, os clientes estão acostumados a ver o mundo de um jeito, e
podem não perceber que têm um verdadeiro problema. Você percebeu
como a experiência do táxi era irritante antes de experimentar o Uber ou
o Lyft? Você pode precisar pensar em perguntas para descobrir se há um
ponto de dor não realizado, como perguntar com que frequência alguém
vai até um hotel para encontrar um táxi em vez de tentar pegar um na rua.
Se você tiver um produto existente e um produto razoavelmente
detalhado hipótese de oportunidade, você também pode usar uma
situação hipotética. Participe da entrevista onde você diz algo como:
“Quero contar uma história sobre como imaginamos alguém como você
usando a próxima versão do nosso produto com base no que ouvimos
de outros clientes. Por favor, me interrompa se tiver alguma dúvida, se
você não concordar com qualquer coisa que eu esteja dizendo ou se eu
estiver simplesmente errado”! Essa abordagem pode ajudá-lo a descobrir
quaisquer limitações que os clientes tenham, se o produto tiver recursos
não utilizados e seus clientes estiverem usando seu produto como você
imagina que eles estão usando.
Geralmente, evite mostrar quaisquer produtos ou protótipos
existentes, pois isso concentra a conversa no que você tem e não no que
o cliente precisa. No entanto, pode ser útil para os clientes mostrarem
as soluções existentes que possuem e você poderá notar aspectos das
144 soluções que os clientes não percebem explicitamente.
Você também deve evitar perguntas carregadas e direcionadas, ou
THE PRODUCT BOOK
seja, perguntas que impliquem uma resposta ou incentivem o cliente a

responder de uma maneira específica. "Sr. Souza, você ainda bate na sua
esposa? ” É uma pergunta carregada porque implica culpa mesmo que o
Sr. Souza não fosse capaz de machucar uma mosca e nunca batesse em
sua esposa. "Você tem problemas com o seu PC?" é uma pergunta líder
neste aspecto porque implica que o cliente usa um PC e que seu PC tem
problemas. "Conte-me sobre seu computador principal" é melhor porque
não implica nenhum julgamento e permite que os clientes respondam
com o que eles se importam.
Crie sua primeira lista de perguntas, mas não se preocupe em torná-la
perfeita. À medida que você começar a fazer entrevistas reais, refine suas
perguntas com base nas informações que deseja, isso não significa que
você terá as respostas que espera ouvir. Sua lista nunca será perfeita, mas
manter esse conselho em mente lhe ajudará a ter um ótimo começo.
Recomendamos dar um passo atrás quando você tiver montado uma
lista e realmente pensar se essas perguntas fornecerão as informações que
você espera aprender nas entrevistas. Uma maneira de fazer isso seria
imaginar como seriam os resultados mais úteis - o que você poderia
derivar pensando em como pretende usar os resultados das entrevistas
- e trabalhando para trás para ver se as suas perguntas serão suficientes.

Há uma pergunta que você deve sempre fazer ao final de uma
entrevista: “Há mais alguma coisa sobre <este tema> a qual eu deveria
ter perguntado?”
É aqui que você explica as incógnitas conhecidas - ou seja, a categoria
de coisas com as quais o cliente se importa, e que você sabe que existe,
mas você não tem idéia do que mais pode estar lá além do que você pediu.
Por exemplo, talvez você estivesse focado na rapidez com que um cliente
pode acessar o Google Now ou a Siri em seu telefone, mas acontece que
o cliente odeia o reconhecimento de voz porque não funciona com o 145
sotaque dele.
Depois de ter sua lista de perguntas montada, comece a preparar a
logística. Aqui estão algumas questões importantes a serem consideradas:
• Qual é a última data em que as entrevistas possam fornecer

informações úteis? O desenvolvimento do cliente leva tempo
e, muitas vezes, há marcos internos além dos quais novas
informações não serão mais úteis. Conhecer esses marcos com
antecedência o ajuda a criar um cronograma de entrevistas eficaz.
• Qual nível de qualidade e confiança nos resultados você

precisa? Você tem algum tempo para realmente fazer um
trabalho completo ou precisa trabalhar o mais rápido possível,
mesmo que os resultados sejam imperfeitos?
• Qual é o meio certo para as entrevistas: pessoalmente ou ao
telefone? Pessoalmente, é sempre melhor, mas isso pode não ser
viável se seus clientes não estiverem todos na mesma cidade. Os
bate-papos por telefone costumam ser mais fáceis de programar e
mais convenientes, mas você perderá algumas dicas não verbais,
como expressões faciais. O bate-papo por vídeo resolve esse
problema, mas pode ser frustrante se não estiver funcionando ou
se o entrevistado não tiver experiência em tecnologia. Você não
quer gastar seu tempo de entrevista depurando uma conexão.
• Quanto tempo cada entrevista levará? As entrevistas tendem a

durar muito tempo - as pessoas se atrasam, você encontra coisas
interessantes sobre o que perguntar, etc. - então, se você planeja
realizar uma entrevista de 20 minutos em vez de uma de 30
minutos, provavelmente atingirá suas metas de tempo. Certifique-
146 se de comunicar claramente as suas expectativas de tempo aos
seus entrevistados.
THE PRODUCT BOOK
• Você deve pagar seus entrevistados? Em geral sim. Algum valor

entre US$ 50 e US$ 100 por hora é comum, e geralmente é como
um cartão-presente em vez de dinheiro. Você está pedindo que as
pessoas trabalhem para você e forneçam a experiência delas, e você
usará essa informação para ganhar dinheiro. A única exceção seria
se você estivesse conversando com alguém que entrou em contato
com você, como um cliente atual que enviou um email à equipe
de suporte. A melhor maneira de pagar essas pessoas é tornar o
produto ainda melhor para elas! Você também pode fazê-los se
sentir especiais, incluindo-os em programas de acesso antecipado.
Encontrando Pessoas para Conversar
Nós temos nossa hipótese, temos nossos objetivos de entrevista, temos
nossas perguntas e sabemos o tipo de entrevistados com quem queremos
conversar. Agora tudo o que precisamos são os entrevistados! Isso pode
parecer um pouco assustador, mas é mais fácil do que você espera. As
pessoas gostam de ajudar os outros, especialmente se elas puderem soar

como especialistas no assunto. Aproxime-se das pessoas com humildade,
dizendo que adoraria a ajuda delas e que gostaria de receber informações
sobre a experiência delas, e você encontrará entrevistados dispostos.
Procure em suas conexões primeiro. Você conhece alguém diretamente
que tenha os requisitos da sua persona alvo ou conhece alguém que
possa conhecer? Não hesite em perguntar suas conexões diretamente.
Deixe sua solicitação explícita: diga-lhes por que você está perguntando,
deixe claro o que a entrevista envolveria (horário, formato - como no
local versus telefonema) e mencione como isso seria útil. Se você estiver
147
solicitando uma conexão para entrar em sua rede de amigos, crie um
e-mail facilmente encaminhado para que seja simples para seu amigo
pressionar "Encaminhar" e enviar o e-mail para qualquer pessoa que ele
conheça sem ter que adicionar uma longa nota de explicação.
As redes sociais também podem ser ótimos recursos. Entre em

contato com o LinkedIn, Quora, fóruns relevantes ao assunto ou até
mesmo no Twitter para ver se você pode encontrar pessoas dispostas a
ajudar. Se houver um local físico específico para seus clientes, tente ir até
lá pessoalmente e conversar com as pessoas ou, pelo menos, postar um
aviso pedindo às pessoas para entrar em contato com você, caso desejem
fornecer informações.
Craigslist e outros classificados on-line são do tipo que você acerta
em cheio ou erra muito, e é provável ter mais erros do que acertos.
Você realmente não sabe quem vai se deparar com sua postagem, pois o
Craigslist tem um público tão amplo e pode levar mais tempo para filtrar
os entrevistados certos do que vale a pena.
Se você estiver realmente desnorteado, pergunte a si mesmo: depois
de criar o produto, como você planeja encontrar clientes para os quais
vender? Ou, se você já tem um produto, como você alcança seus clientes
atuais? Use técnicas semelhantes para alcançar seu público, mas em vez
de pedir-lhes para abrir suas carteiras, peça sua sabedoria.
Para produtos existentes, você já deve ter clientes entrando em

contato com você para oferecer opiniões. As pessoas que falam em voz
alta podem não representar a maioria silenciosa que não vai reclamar ou
comentar, então você ainda vai querer encontrar o que as pessoas mais
silenciosas querem. Sua equipe de venda e de suporte podem indicar
bons clientes para conversar com você. Ao entrar em contato com essas
pessoas, deixe claro que você está explorando oportunidades e não está
148 alterando o produto, além de dar permissão para reclamar. Elas vão lhe
deixar saber sobre suas dores.
THE PRODUCT BOOK
Há também muitas empresas de pesquisa de mercado que você

pode contratar para ajudá-lo a encontrar os clientes certos com quem
conversar e, com frequência, também ajudam a conduzir entrevistas.
Essas empresas podem ser um pouco caras e demorar um pouco para
produzir resultados, mas facilitam muito a sua vida.
Não importa como você encontre seus entrevistados, lembre-se de

usar suas perguntas de triagem para ter certeza de que esses assuntos em
potencial atendem aos seus critérios. Depois de encontrar os assuntos
certos, agende as entrevistas. Forneça instruções muito claras sobre
tudo o que seus entrevistados precisam saber, como disponibilidade de
estacionamento para visitas no local e suas informações de contato direto.
Depois de agendado, confirme a entrevista e considere um lembrete ou
envie um e-mail no dia da entrevista. Várias ferramentas que ajudam você
a agendar entrevistas, como o PowWow, enviarão os lembretes para você.
Conduzindo Entrevistas

Agora vem a parte divertida - conversar com pessoas reais. Antes de
começar, respire fundo e sorria - você é um pesquisador amigável no
momento, não importa o que esteja acontecendo durante o dia. Assim
que você cumprimentar seus entrevistados, faça com que eles se sintam à
vontade. Você quer que eles se abram e conversem com você, e não que se
sintam como se estivessem sendo interrogados ou apressados. Controle o
tempo, mas de forma educada. Converse com eles como um ser humano
e os chame pelo nome. Não os chame de "cliente". Deixe claro que não
há respostas certas ou erradas: você quer o conhecimento deles e você
aprecia o tempo deles. 149
É útil fazer com que os entrevistados falem imediatamente, começando

com perguntas simples que os clientes não precisarão pensar muito, como
perguntar a eles como lidam com o tópico que você está visualizando
agora. Imagine um arco: comece com uma conversa fiada, faça perguntas
fáceis, avance para perguntas mais delicadas, recapitule os pontos-chave
e, em seguida, agradeça pelo tempo que eles dedicaram.
Seu trabalho é ficar quieto e ouvir - não os interrompa, e comece a falar
enquanto a outra pessoa recupera o fôlego. Você vai querer esperar algum
momento depois de alguém terminar um pensamento antes de dizer algo
mais, caso a pessoa esteja pensando e planejando elaborar sua resposta. Se
alguém criticar seu produto, não fique na defensiva; permaneça neutro e
encorajador, fazendo com que a pessoa fale. Até sorria e tente simpatizar!
Para ter certeza de que você entende o que seus entrevistados disseram,
peça esclarecimentos para qualquer coisa que você queira e até mesmo
reformule o que eles disseram em suas próprias palavras. Você também
vai querer esclarecer expressões vagas. Se alguém disser “Eu odeio esperar
por isso”, descubra onde está o ponto de virada - ele está de acordo em
esperar um minuto, mas cinco minutos parece um desperdício?
Em termos de anotações, você geralmente desejará gravar o que seu

entrevistado diz textualmente, em vez de resumir. Isso lhe ajudará a evitar
o viés de confirmação e facilitará a análise da conversa mais tarde. É muito
útil ter um anotador para que você possa se concentrar na pessoa em vez
de escrever. Caso contrário, use uma caneta inteligente como o Livescribe,
que registra sua conversa e permite que você toque em quaisquer notas
para pular imediatamente para essa parte da conversa.
150 Certifique-se de anotar quaisquer reações não-verbais e favoritar

quaisquer expressões emocionais ("Eu odeio / amo isso"). Uma exceção ao
THE PRODUCT BOOK
objetivo da gravação literal é se eles dizem “talvez”; anote-o como “não”.

No final de uma entrevista, agradeça ao entrevistado pelo seu tempo, e
pergunte se você poderá fazer um acompanhamento mais tarde.
Se você nunca fez uma entrevista antes ou não tem certeza sobre
suas perguntas, faça uma ou três entrevistas práticas com alguém que
você conhece. Geralmente, são necessárias de cinco a dez entrevistas
para conseguir pegar a manha e, a menos que você esteja alterando suas
perguntas, de 15 a 20 entrevistas geralmente é quando você para de ouvir
coisas novas.
Tirando Conclusões das Entrevistas
Tire algum tempo imediatamente após cada entrevista para anotar de
5 a 10 dos pontos mais interessantes. Concentre-se nas coisas que o
entrevistado disse que validaram ou invalidaram sua hipótese, carregaram
emoção ou surpreenderam você.
Cada entrevista deve ajudá-lo a descobrir se a sua hipótese aborda

um ponto de dor válido que o cliente tem: se o cliente tentou resolver
esse ponto negativo antes, se o cliente se preocupa o suficiente com esse
ponto doloroso para corrigi-lo, e se não há nada que impediria o cliente
de usar sua solução. Você deve ter uma boa noção de como seu produto
se encaixaria no dia a dia da pessoa, se substituísse qualquer coisa, e, se
ela não compraria seu produto, os motivos específicos para isso.
Certifique-se de prestar atenção às palavras acionáveis ou indecisas

que seus clientes usam. Se eles disserem: "Eu continuo querendo", eles não
151
se importam realmente com o tema em questão. Se eles disserem "Aqui
está o que eu tentei e o que faço", eles se importam. " <Isso> ajudaria
a alcançar" é significativo, enquanto "<Isso> seria interessante ter" e
"acho que posso descobrir como usá-lo" significa que essa pessoa não
usará o produto. Se eles disserem: "Eu não usaria, mas outros o fariam",
significa que ninguém irá usá-lo. Da mesma forma, "Talvez seja apenas
eu" significa que muitas pessoas se sentem da mesma forma.
Puxe os dados de todas as suas entrevistas juntos em um resumo geral
que você atualiza conforme avança. Categorize o que os clientes dizem
como apropriado, incluindo pontos problemáticos, emoções, soluções
existentes e assim por diante. Tente até classificar suas palavras em “valida
a hipótese” e “invalida a hipótese”. Tente ver se você consegue identificar
tendências em vários clientes com comentários semelhantes.
Se você não encontrou ninguém entusiasmado com sua ideia em
cinco ou mais entrevistas, está falando com as pessoas erradas ou seu
problema não é um problema real para os clientes. Tente mudar quem
são seus entrevistados-alvo, e se a tendência continuar, você invalidou sua
hipótese. Além disso, se suas perguntas não fornecerem as informações
desejadas, altere as perguntas.
Se apenas algumas pessoas enxergarem sua oportunidade como um
ponto de dor com o qual se importam, o mercado potencial para o seu
produto pode não ser grande o suficiente para ser importante. Você vai
querer fazer mais (como uma pesquisa, que abordaremos a seguir) para
tentar avaliar o tamanho do mercado, mas isso deve ser um sinal de alerta.
Às vezes, você notará os clientes discutindo o mesmo ponto

problemático várias vezes, mesmo que seja diferente da sua oportunidade.
Observe claramente esse ponto problemático e analise se é uma
152 oportunidade melhor (tem um valor maior, um custo mais baixo e
etc.) do que a oportunidade que você está vendo agora. Depois de 15
THE PRODUCT BOOK
a 20 entrevistas, você deve ter uma boa ideia sobre a validade da sua
oportunidade hipotética.
Pesquisas
“O plural de 'anedota' não é 'dados'”, esta frase é atribuída a Frank Kotsonis
e Roger Brinner. As entrevistas são ótimas porque ajudam a descobrir
os pontos de dor e motivações subjacentes dos clientes, mas são apenas
uma pequena amostra da sua base de usuários (ou base de usuários em
potencial). Elas não vão ajudá-lo a quantificar problemas nem avaliar
atitudes gerais. Análises também não fornecem esse tipo de informação.
As análises são ótimas para expor o que os clientes realmente fazem, mas
não dizem nada sobre o que está acontecendo na mente do cliente.
Pesquisas ocupam essa área obscura, onde podemos ter uma visão
dentro da mente de muitos clientes. Em geral, os dados que as pesquisas
oferecem não são de alta qualidade como os dados de entrevistas com
clientes, mas é uma maneira barata de ver se nossas conclusões de
entrevistas com clientes aumentam para um grande número de pessoas.

Existem várias maneiras de usar pesquisas - um exemplo é como as
usamos no Capítulo 3 para avaliar seu NPS geral como um potencial ponto
de partida para encontrar uma oportunidade. Vamos nos concentrar
agora em usá-las para validar uma hipótese.
Na etapa de validação do ciclo de desenvolvimento do produto, nunca

comece com uma pesquisa - você descobrirá perguntas melhores para
fazer e obter mais dados reais sobre as necessidades das pessoas com
entrevistas, mas, quando achar que as entrevistas validaram sua hipótese,
as pesquisas lhe ajudarão a ver se a maioria dos seus clientes concorda. 153
Criando Pesquisas
Um bom modelo de pesquisa também é uma arte, de certa forma. Como
você não estará lá para fazer perguntas esclarecedoras ou prestar atenção
a pistas não verbais, precisa ter cuidado com a forma como as elabora.
Você também deseja testar qualquer pesquisa antes de enviá-la para um
grupo amplo.
Da mesma forma como você faria com uma entrevista, comece focando
explicitamente no seu objetivo. E o objetivo deve ser “validar ainda mais
minha hipótese vendo quantas pessoas têm essa dor, investiram recursos
significativos tentando resolvê-la, estão insatisfeitos com a solução e
podem implementar minha solução”.
Em geral, mantenha as pesquisas breves! Elas devem levar apenas
alguns minutos para preencher. Fadiga de pesquisa é algo real, e a
qualidade das respostas no meio de uma pesquisa cai em comparação
com o início e o fim, especialmente em pesquisas mais longas. Para ajudar
a compensar essa fadiga, sempre que possível, escolha aleatoriamente
suas perguntas (ou, mais comumente, escolha aleatoriamente a ordem
dos grupos de perguntas que você apresenta).
Você também deverá escolher de forma aleatória como as respostas
são apresentadas para dar conta de um preconceito que alguém tenha em
relação a apenas escolher um número de resposta específico. Lembra de
quando você adivinhou "C" em todas as perguntas que você não sabia a
resposta na escola?
É essencial manter suas perguntas e opções de resposta muito claras.
Você pode saber o que o jargão da indústria significa, mas seus clientes
talvez não saibam. Mesmo termos que parecem óbvios, como "Quinzena",
podem ser ambíguos - você quer dizer quinze dias ou se refere a uma
154 espécie de casaco? Apenas especifique os dias em vez disso.
Ao escolher perguntas, você também deve usar um molde para a
THE PRODUCT BOOK
pesquisa. Comece com perguntas amplas, passe para perguntas detalhadas

e feche com um local para o cliente adicionar ideias extras. Agrupe
categorias relacionadas também para ajudar o cliente com o contexto.
Como nas entrevistas, sempre busque questões reais, em vez de ideais,
ou seja, pergunte o que os clientes fizeram, não o que eles poderiam fazer.
Além disso, evite perguntas importantes e carregadas. Por exemplo, em
vez de perguntar se o cliente usou recentemente ferramentas de cobrança
on-line, pergunte como um cliente paga as contas, com uma opção de
faturamento on-line.
Questões comparativas, seja entre o que o cliente usa agora e outra
coisa ou entre dois produtos hipotéticos, são questões que implicitamente
o direcionam, porque analisar uma questão hipotética é muito difícil. É
melhor apresentar as duas opções separadamente e fazer com que as pessoas
avaliem sua experiência ou pensamentos sobre cada opção específica.
Mais tarde, você pode comparar os resultados. As perguntas de
comparação também costumam fazer duas perguntas em uma, porque
você está avaliando o valor de cada produto. É sempre melhor fazer
perguntas simples e separadas, em vez de uma pergunta que realmente
inclua várias perguntas.
Tabelas que pedem explicitamente que um usuário classifique seus

pensamentos sobre itens específicos são úteis para descobrir quantos
clientes valorizam esse ponto potencial de sofrimento e quanto, e
para analisar como as tendências mudam com o tempo. Por exemplo,
“Você está completamente insatisfeito, ligeiramente insatisfeito, neutro,
satisfeito, completamente satisfeito ou nenhuma das alternativas com a
velocidade de download do seu provedor?” é uma pergunta útil, e você
poderá perguntar repetidamente, ao passo que a velocidade e o que os
clientes fazem na internet muda. Classificações como estas também
são ótimas porque permitem construir um gráfico de importância /
satisfação com dados reais. Perguntas simples de concordo/ discordo são 155
frequentemente tendenciosas porque as pessoas querem agradar a você
e têm maior probabilidade de escolher “concordo”. Use uma escala para
obter respostas mais precisas.
Peça detalhes quando uma questão tiver muita variabilidade. A idade

é um ótimo exemplo, porque as pesquisas costumam fazer perguntas
sobre qual faixa etária você deve encontrar. Mas entre 18 e 40 anos, há
muita variação potencial em sua vida, especialmente dependendo de
onde você mora. As pessoas nas cidades ainda podem ser solteiras, morar
com colegas de quarto e ter muita renda disponível aos 30 anos, enquanto
uma pessoa em uma área rural pode ser casada e ter três filhos. Em vez
disso, pergunte especificamente a idade da pessoa e peça informações
específicas sobre qualquer outro dado que você precise para segmentar
corretamente o cliente. E, claro, não se esqueça do que temos mencionado
repetidas vezes sobre a segmentação em torno da dor/ necessidades/
empregos sendo mais eficaz do que em torno da demografia.
Ao mesmo tempo, permita flexibilidade quando necessário. Cinquenta

anos atrás, as pessoas eram muito mais propensas a se juntar a uma
empresa, ficar lá toda a sua carreira e depois se aposentar. Hoje, você
poderia estar empregado e ao mesmo tempo procurando outro emprego,
ou trabalhando por conta própria, mas entre contratos (essencialmente
desempregado).
É totalmente razoável ter campos de texto vazios onde as pessoas
possam escrever histórias, em vez de botões de opção, onde elas estão
restritas a respostas fixas. Perguntar como a última experiência de
vôo de alguém em uma operadora americana vai produzir resultados
mais interessantes do que, "Quão satisfeito você estava com seu vôo?"
Certifique-se de que se você pedir uma resposta detalhada, você não
156 defina um limite de caracteres baixos em sua caixa de resposta da pesquisa.
THE PRODUCT BOOK
Perguntar questões como “por que” pode ser perigoso porque as

pessoas não são muito conscientes. Tal como acontece com as perguntas
da entrevista, o escopo de compreender os objetivos de um cliente ajuda
a mergulhar na motivação de forma mais explícita. “Qual é a principal
coisa que você espera aprender com este livro?” é uma pergunta melhor
do que “Por que você comprou este livro?” (Por favor, envie um e-mail
para os autores se não atendermos suas necessidades!).
Ao conduzir uma pesquisa sobre um produto existente, é bom

fazer uma pergunta sobre a Pontuação Líquida do Promotor (consulte
o Capítulo 2), pois isso implicitamente ajudará a medir a pontuação ao
longo do tempo, à medida que realizar mais pesquisas.
Realizando Pesquisas
Existem muitas ferramentas para criar pesquisas: Formulários do Google,
SurveyMonkey, Typeform, etc. As melhores ferramentas permitem
adicionar seções condicionais para que você possa fazer perguntas de
acompanhamento com base em como seus clientes respondem às perguntas.
Se eles estiverem insatisfeitos com algo, você pode querer se aprofundar

mais sobre por que ajuda a validar sua hipótese, mas se eles estiverem
completamente satisfeitos, não será necessário fazer mais perguntas.
Encontrar pessoas para responder a sua pesquisa é semelhante, mas
provavelmente mais fácil do que uma entrevista, porque uma pesquisa
é muito menos exigente do que entrevistar alguém. Se você tiver um
aplicativo existente, adicione um pop-up no aplicativo ou envie um
e-mail para clientes existentes que atendam aos requisitos de filtro para
perguntar se eles têm cinco minutos para responder a uma pesquisa para
ajudar a melhorar o produto. Observe como esse texto de exemplo tem a
157
meta da pesquisa, "ajudar a melhorar o produto", o que explica por que é
valioso para os clientes fazer isso. Isso torna mais provável que um cliente
conclua a pesquisa.
Postar em vários formulários e redes sociais onde seu mercado-alvo
reside também é útil. No entanto, se você estiver fazendo um filtro manual
mínimo ao enviar o link de questionário, precisará de mais perguntas
de filtro no início de sua pesquisa para ter certeza de que apenas as
pessoas que você deseja ouvir estejam realmente avançando na pesquisa
e respondendo às principais questões. Há também serviços como o Ask
Your Target Market, que tem uma grande lista de discussão, e você pode
pagar para enviar o seu link de pesquisa para as pessoas certas. Pagar por
anúncios segmentados no Google, LinkedIn, Twitter, Facebook, entre
outros, é outra maneira de encontrar possíveis respondentes.
Geralmente as pesquisas não são pagas, mas as empresas, muitas
vezes, oferecem uma recompensa tipo loteria no final para adicionar um
incentivo para as pessoas participarem (“Forneça seu endereço de e-mail
para participar em uma rifa para ganhar um cartão-presente de $100”).
Analisando Dados
Execute sua pesquisa até sentir que você tem resultados estatisticamente
significativos ou até que você pare de obter resultados novos/ úteis/
diferentes.
Quando você estiver pronto para começar a analisar os resultados, a
primeira coisa a fazer é validar os dados. O que você faz com pesquisas
incompletas? Você quer ignorar ou averiguar manualmente para ver
onde - e talvez por quê - as pessoas pararam de responder?
Se você usar os dados, terá um tamanho de exemplo diferente para
cada pergunta.
Em seguida, você deverá fazer algum particionamento baseado em

158 questões de segundo plano? As pessoas que escutam transmissões de
música diariamente podem ter respostas diferentes das que escutam uma
THE PRODUCT BOOK
vez por semana. E quanto à análise de coorte? As pessoas que vieram de

um fórum profissional podem ser diferentes das pessoas que começaram
a responder somente quando você adicionou um sorteio.
É provável que você queira fazer uma análise básica de dados com
qualquer pergunta numérica, ou seja, converter escalas em números,
analisar a média, a mediana, a variância etc. Você também vai querer
analisar a distribuição para ver se ela é padrão/ normal - isto é, a maioria
das pessoas está em torno de uma média - é o que diz as tendências
de dados até certo ponto. No entanto, se for bimodal, as respostas se
encaixam em duas categorias distintas, isso indica alguma outra coisa e
uma média não será útil para essa pergunta.
Em geral, assim como nas entrevistas, você ainda estará procurando
por algo que valide ou invalide sua hipótese de oportunidade. Mas o outro
aspecto que você deverá procurar com uma pesquisa é quantas pessoas
sentem que isso seja um ponto problemático, e quão significativo é como
um ponto doloroso. Se todos concordarem que é um problema, mas
ninguém gastou tempo ou dinheiro tentando resolver, sua oportunidade

provavelmente não vale a pena ser construída, a menos que uma solução
seja muito barata de construir ou você tenha motivos para acreditar
que sua solução fará com que os clientes percebam a dor. O ponto é
maior do que eles pensavam. Você poderia imaginar como seria uma
pesquisa sobre o correio de voz antes do correio de voz visual no iPhone
- encontrar, ouvir e salvar uma mensagem de correio de voz específica
era trabalhoso, mas nenhum fabricante de aparelho gastava dinheiro
para resolvê-la porque exigia cooperação da operadora . Se você usou
perguntas de satisfação para criar um gráfico de importância / satisfação,
tanto em termos de como os clientes percebem a importância e como 159
você classifica a importância, você pode ver se a oportunidade é a certa
a seguir ou se há algo mais importante. Como é muito fácil ser vítima do
viés de confirmação, tente se concentrar apenas em dados que invalidem
sua hipótese antes de procurar dados que a validem. Neste ponto, você
deve ter uma boa noção se sua hipótese é válida e se é uma oportunidade
valiosa o suficiente para prosseguir.
Experimentos
Uma maneira adicional de validar uma hipótese é executar um
experimento no qual você constrói algo para testar sua hipótese. Isso
nem sempre é possível, mas se você conseguir executar um, ele produzirá
resultados incrivelmente informativos.
Os experimentos são complementares ao desenvolvimento do cliente,
e não um substituto, pois ajudam a ver o que as pessoas fazem quando
você faz uma alteração, mas não ajudam você a entender por que as
pessoas fazem isso ou quais são suas necessidades fundamentais.
Testes A/B
Um dos experimentos mais comuns para testar um produto existente é
chamado de teste A/ B. A ideia é simples: se você fizer uma alteração em
seu produto existente e abordar a oportunidade em que está concentrado,
qual será o impacto em sua métrica principal? Você implementará
a alteração, dará aleatoriamente a alguns usuários a versão "A" atual e
alguns usuários a nova versão "B" e, em seguida, verificar se a métrica foi
alterada de maneira significativa.
A parte mais difícil de um teste A/B para as pessoas entenderem é
que você não está construindo totalmente a versão B de uma maneira
bem projetada. O objetivo é hackear algo de maneira rápida e barata,
permitindo que você determine se vale a pena perseguir essa oportunidade
160 de maneira mais completa.
Os testes A/ B são uma ótima maneira de validar se sua hipótese
THE PRODUCT BOOK
alcança seus objetivos com oportunidades iterativas/ de refinamento.

Por exemplo, o Google tinha a hipótese de que o tom de azul usado nos
links de publicidade afetava as taxas de cliques e A/B (e C/ D/ E, etc.).
Testar diferentes tons permitiu que o Google encontrasse um tom que
gerasse uma renda extra de US$ 200 milhões, de acordo com Dan Cobley,
diretor-gerente do Google no Reino Unido.
É mais comum para navegação de teste A/ B, fluxos de usuários,
layout e mensagens/ conteúdo. Se a sua oportunidade não se encaixa
nesses intervalos, mas você acha que pode fazer o teste A/ B, vá em frente!
Na verdade, às vezes as empresas testam uma versão completamente
redesenhada do seu site, que pode direcionar aleatoriamente parte do
tráfego para o novo site e ver como o comportamento geral dos usuários
difere do comportamento no site principal.
O Optimizely é uma ferramenta muito comum para implementar
testes A/ B, e seu conjunto de recursos em expansão inclui suporte para
aplicativos da rede, de celulares e de computadores, segmentação por
segmentação/ teste personalizado, análises e muito mais.
MVPs Simples

Gostamos de falar sobre dois tipos de produtos viáveis mínimos,
semelhantes a uma Nova Empresa Enxuta (discutido no Capítulo 3).
Aquele que as pessoas mais falam é a versão que você realmente criará
e lançará (abordada no Capítulo 5). O outro tipo é um MVP muito simples
que você pode criar para ajudar a validar sua hipótese - uma versão reduzida
da sua visão completa do produto. Esses MVPs super-simples serão baratos
de montar e, de fato, não serão implementados como o produto real será.
Mas eles devem fornecer o suficiente para um possível cliente final que
você possa avaliar se vale a pena perseguir sua oportunidade.
161
O MVP mais simples é um MVP de pré-encomenda. Isto ajuda a
avaliar se as pessoas estão interessadas o suficiente na sua ideia para
gastarem seu dinheiro com isso. Crie um site de marketing falso para o
seu produto, descrevendo-o como se ele já existisse com os recursos que
considera importantes e coloque um botão "Comprar" na parte inferior
do site. Em seguida, comercialize esse produto como se ele realmente
existisse, faça anúncios de exibição diferentes e veja quantas pessoas
clicam em "Comprar".
Para evitar ser completamente enganoso, recomendamos que você

adicione uma observação quando alguém clicar em "Comprar" dizendo
que você ainda não concluiu a criação deste produto e está trabalhando
para isto, e que ele poderá inserir seu e-mail para ser atualizado quando
você tiver novas informações. Essa também é uma boa maneira de
capturar uma lista de endereços de e-mail de clientes que você poderá
comercializar quando seu produto estiver disponível.
Para um produto existente, você pode criar uma seção "Novo

recurso" no seu site, ver quantas pessoas assistem a um vídeo explicativo
mostrando como você pretende que o recurso funcione e usar um botão
"Saiba mais" em vez de um botão "Comprar" para revelar a verdade e
novamente capturar endereços de e-mail.
Outro tipo de MVP é um MVP concierge (esses nomes são do Eric
Ries em A Startup Enxuta). Nele, você trabalhará manualmente com o
cliente da mesma forma que um concierge real executaria uma tarefa, em
que a tarefa é o foco geral da hipótese de sua oportunidade. Se você tem
uma hipótese de que as pessoas querem um aplicativo de recomendação
de restaurante, você agirá como um concierge para ajudá-las a escolher
um restaurante.
162 Durante esse processo, você deve se concentrar explicitamente nas
etapas que você segue para descobrir uma resposta - quais perguntas são
THE PRODUCT BOOK
importantes e quais não são, e o que está envolvido no preenchimento de

cada etapa - para que você possa automatizá-las. Observando essa ideia de
restaurante-aplicativo, se ninguém pedir a ajuda do seu concierge, isso é um
grande sinal inicial de que algo está errado. Você não está apelando para os
clientes certos ou não está deixando sua proposta de valor clara. Então,
quando alguém manifestar interesse, você discute manualmente com essa
pessoa que tipo de comida ela gosta e não gosta, que tipo de ambiente de
restaurante/ preço/ etc. ela está procurando, e você executará uma busca no
Yelp por ela. Você poderia até oferecer providenciar transportes.
À medida que você passa por esse processo, descobre se os clientes estão
interessados na ideia geral, quais etapas são mais úteis e o que acontece
nelas, quais etapas são inesperadas, mas proveitosas (como organizar o
transporte) e quais etapas os clientes não se importam. Isso lhe ajuda a
refinar sua hipótese e criar uma melhor estimativa de custo/ benefício. Por
exemplo, talvez você ache que seus clientes realmente querem um recurso
que permita que eles pressionem um botão e magicamente apareça um Lyft
para levá-los a um restaurante aberto próximo do qual eles provavelmente
gostarão: eles se preocupam com a satisfação instantânea em vez de

planejamentos ou fazer uma reserva por si próprios.
Muitas empresas recém-criadas de serviços começaram inicialmente

com um MVP de concierge, ajudando-as a avaliar o interesse e a entender
melhor o espaço geral do problema e as necessidades do cliente. O
Wealthfront, um serviço de investimento automatizado, até começou
com um MVP de concierge ao ter consultores financeiros trabalhando
manualmente com os clientes.
Um MVP de Mágico de Oz é um outro tipo simples, às vezes o 163

próximo passo depois do MVP concierge. Aqui, você criará um produto
que parece estar totalmente construído para um cliente final, mas os
pessoas reais estarão fazendo o trabalho nos bastidores. O fundador
da Zappos não começou fazendo um site de comércio eletrônico ou
armazenou toneladas de estoque: ele apenas tirou fotos de sapatos em
diferentes lojas (com permissão), colocou as fotos na internet e, quando
chegava um pedido, comprava manualmente e enviava os sapatos. Mas
para um cliente, parecia que a Zappos tinha um estoque completo e era
uma loja por si só.
Esse estilo de MVP também não é dimensionado, mas é outra
maneira de validar a demanda por sua oportunidade. Se você conseguir
acompanhar a demanda manualmente, essa ideia provavelmente não
valerá a pena. Mas se as pessoas o amarem e você estiver sobrecarregado,
é uma boa dica que é hora de automatizar a ideia.
O último tipo é um MVP de porta falsa. Se você está pensando em
criar um novo recurso para o seu produto, adicione os elementos UX que
você usaria para acionar a interação, mas, em vez de entregar o recurso,
forneça uma notificação de que o recurso será lançado em breve. Veja
quantas pessoas usam sua “porta falsa”. Por exemplo, se sua hipótese é
que as pessoas encontrariam um recurso de bate-papo em grupo útil
em seu site de educação on-line, adicione um botão “Bate-papo” e veja
quantas pessoas clicam nele. Se apenas uma pequena porcentagem clicar,
reconsidere se vale a pena buscar essa oportunidade, dependendo do
valor desses clientes em relação ao custo de implementação do recurso.
A dica a ser lembrada em cada experimento é que você quer mantê-lo
simples e barato. Você não quer gastar tanto tempo projetando o teste A/
B perfeito ou o MVP de pré-encomenda a ponto de você estar esgotado
antes mesmo de executar o experimento. Você vai jogar fora todos os
experimentos, independentemente do resultado. Se o resultado for
164 positivo, você terá que criar o produto ou o recurso de verdade.
THE PRODUCT BOOK
SEGUINDO EM FRENTE
Nesse ponto, mesmo que tenha sido necessário fazer muitas alterações e
novas tentativas, pois sua hipótese inicial estava errada, você deve ter uma
hipótese de oportunidade que vale a pena. Isso aí! É hora de seguir em
frente no seu roteiro! Há mais um passo para pensar e essa é a prioridade
da sua oportunidade no roteiro.
Mesmo que você tenha encontrado uma grande oportunidade, você
tem recursos limitados e outro PM pode ter encontrado uma prioridade
diferente que seja mais importante para as metas da empresa. Cada recurso
tem um custo de oportunidade: trabalhar em uma coisa significa que você
não estará trabalhando em outra coisa. Como PM, você preferirá pensar
estrategicamente para se certificar de que esteja sempre trabalhando nas
coisas mais importantes. Você pode ter uma ótima ideia que você validou,
mas será que a empresa deve realmente trabalhar nisto em seguida?
Um teste útil decisivo é se esse produto ou recurso ajudará a empresa
a atingir suas metas atuais. Caso contrário, você provavelmente deverá
apresentá-lo e trabalhá-lo quando a empresa estiver focada no objetivo
apropriado.
O modelo de Kano (Capítulo 3) fornece uma maneira útil de avaliar
a importância do seu produto ou recurso. É um recurso básico? Em

caso afirmativo, é provável que seja uma prioridade alta, porque seus
usuários esperam isso e você não está fazendo isso - ou pelo menos não
o suficiente. Se for satisfatório ou otimizador, você pode priorizá-lo com
base em seu valor (quanto você acha que ele fornecerá em relação ao seu
objetivo) versus seu custo.
Uma maneira simples de comparar prioridades é obter um valor versus

o número de custo. Trabalhe com um líder da equipe de engenharia para
colocar valores difíceis em diferentes oportunidades. A partir do seu
trabalho de desenvolvimento de clientes e outras análises internas, crie 165
números de valor de negócios para cada oportunidade. Use números
mais altos para indicar custo mais caro, ou oportunidade mais valiosa.
Como é difícil estimar o valor e a dificuldade com precisão, use uma série
exponencial em vez de linear - por exemplo, use 1, 2, 4, 8 e 16 em vez de
1 a 5. Assim, fica muito claro quando uma oportunidade é mais difícil ou
mais valiosa do que outra. Em seguida, para cada oportunidade, descubra
uma pontuação usando a fórmula pontuação = valor ÷ custo. Concentre-
se nas oportunidades de maior pontuação, pois elas fornecem o maior
valor pelo menor custo. Você pode optar por alterar as prioridades com
base em outros fatores, mas isso lhe dará um bom ponto de partida.
Concluiremos esta seção com um aviso: você pode ter uma onda de boa
sorte enquanto cria hipóteses que os clientes veiculam com veemência.
Mesmo assim, continue validando suas ideias; só porque você estava
certo antes, não significa que você sempre estará certo. Ter tempo para
validar sua ideia é muito mais eficaz do que pular essa etapa, construir o
produto/ recurso e descobrir que você estava errado.
ESTRATÉGIA DE VALIDAÇÃO DE OPORTUNIDADE DA MOOVER

No Capítulo 3, criamos uma hipótese para a Moover de que, se integrarmos
no aplicativo tudo o que aconteceu na chamada de acompanhamento para
planejarmos uma mudança, nossos clientes ficarão mais felizes. Fizemos
isso com dados - resultados da pesquisa do NPS - mais discussões internas.
Durante a discussão interna, fizemos essencialmente a validação interna
e concordamos que fazia sentido continuar a trabalhar nisso.
Mas a Moover tem muitas possibilidades para trabalhar em seguida e
queremos garantir que as mensagens no aplicativo sejam as certas. Isso
significa que queremos fazer o desenvolvimento do cliente, entrevistando
clientes reais. Queremos saber se as mensagens realmente são um
aborrecimento, se nosso recurso de mensagens no aplicativo resolverá
166 esse problema, e se há algo mais que, talvez, não tenhamos percebido e
que devemos trabalhar em vez disso.
THE PRODUCT BOOK
Aqui está a primeira versão do nosso modelo de entrevista:
• Você já se mudou antes, sem a Moover? Se sim, como foi?
• Como você ficou sabendo sobre a Moover?
• Como foi sua experiência usando a Moover?
• Qual empresa de mudanças você escolheu e o que fez você

selecioná-las?
• Como você se comunicou com a empresa de mudanças fora da
Moover?
• (Se eles disserem “telefone”): Quantas vezes você tentou entrar
em contato antes de realmente falar? (Ou seja, você liga para eles
e a ligação cai no correio de voz e você perde sua chamada de
retorno.)
• Como você se sente falando com alguém ao telefone?

• Você poderia me dizer quais são a sua primeira e segunda formas
de comunicação preferidas (por exemplo, telefonemas, e-mail,
SMS, outra coisa)?
• Que informações adicionais a empresa de mudanças precisou

para lhe dar uma estimativa final?
• Quanto tempo demorou para começar a se comunicar com a

empresa para fornecer suas informações a fim de obter uma 167
cotação final? Esse atraso afetou seu planejamento?
• Você tem algum item especial, como um piano? Se sim, como foi
organizar a mudança?
• (Se a mudança já aconteceu): Como foram as coisas no dia da

mudança? Houve alguma preparação que a empresa de mudanças
que não tenha feito e que se tivesse feito teria tornado a mudança
mais fácil? Pós-mudança, como foram as coisas com a empresa de
mudanças?
• (Se eles se mudaram anteriormente): quais partes da Moover

economizaram seu tempo em relação a quando você se mudou
anteriormente?
• Se eu pudesse mover uma varinha mágica e mudar qualquer parte
da sua experiência com mudanças (além de empacotar e desfazer
as malas - diga isso com uma risada), o que você gostaria que
mudássemos?
• Em uma escala de 1 a 10, 10 sendo "com certeza" e 1 sendo

"nenhuma", qual a probabilidade de você recomendar a Moover
a um amigo? (Se você acha que não obteve respostas que reflitam
esse número, faça uma pesquisa mais detalhada e pergunte sobre
o maior fator que levou à escolha desse número.)
• Existe alguma coisa que eu não perguntei sobre a comunicação

com a empresa de mudanças que eu deveria saber?
Vamos refinar isso à medida que fazemos entrevistas, mas esse é um bom
168 ponto de partida que nos dará uma ideia do que os clientes pensam sobre
toda a experiência, se houver outro ponto problemático que aconteça
THE PRODUCT BOOK
comumente e se comunicar os detalhes com as empresas de mudanças

realmente foram um ponto doloroso.
Também queremos entrar em contato com os clientes que foram

perdidos no funil na etapa da ligação telefônica para ver o que foi doloroso
nessa etapa.
Essas perguntas da entrevista serão semelhantes, mas faremos

perguntas sobre o que eles fizeram para agendar a mudança em vez de
usar a Moover e o que aconteceu na etapa da ligação telefônica que fez
com que eles escolhessem essa alternativa.
Depois de fazer essas entrevistas com os clientes, se as mensagens no
aplicativo ainda parecerem o maior ponto problemático, analisaremos
o esforço de desenvolvimento necessário para desenvolvê-lo. Se é
relativamente baixo, vamos seguir a construí-lo. Se for alto, vamos
implementar um MVP do Mágico de Oz em seguida. O cliente enviará
uma mensagem, entraremos em contato com a empresa de mudança em
nome do cliente e responderemos ao cliente em nome da empresa. Essa
experiência será executada por um tempo e veremos como os números

do NPS mudarão e se qualquer cliente comentará explicitamente sobre
as mensagens no aplicativo. Então, usaremos esses dados para decidir se
devemos criar esse recurso de verdade.
169
CAPÍTULO CINCO
COLOCANDO IDEIAS EM AÇÃO
170 Encontrar e validar a oportunidade certa para trabalhar em seguida o levou

à linha de partida do ciclo de vidaSCRU do desenvolvimento do produto.
THE PRODUCT BOOK
Agora precisamos executar a corrida e realmente construir o produto.

Neste capítulo, veremos como fazer a transição de uma oportunidade
para algo que pode ser acionado e, nos Capítulos 6 a 8, mergulharemos
em todo o processo de "desenvolver e iniciar". Fundamentalmente, este
capítulo trata de uma importante habilidade de um PM - comunicação - e
de como comunicar, discutir e finalizar com eficácia a oportunidade que
você encontrou com as principais partes interessadas.
POR QUE NOVAS IDEIAS VÊM COM DIFICULDADES

O trabalho de um Product Manager inclui antecipar o que pode fazer com
que o produto seja aprovado e lidar com esse risco antecipadamente. A
maior razão pela qual os novos produtos passam por dificuldades não
é uma razão técnica: é porque os clientes não querem ou precisam do
produto que você acaba criando. Em outras palavras, isso acontece porque
você não alcança o produto/ mercado. Felizmente, há coisas que você
pode fazer para dar ao seu produto a melhor chance de sucesso possível.
Tomar medidas para validar a sua ideia, como abordamos no Capítulo

4, ajudará com que o seu produto seja iniciado da maneira correta, pois
5. Colocando Ideias em Ação

você terá certeza de que haverá alguma necessidade de seu produto ou
recurso - a partir desse ponto, diremos “Produto” por simplicidade. Mas
vários problemas que podem surgir e impedir que o produto acabado
atinja o patamar do produto/ mercado, conforme você passa da “ideia
que acreditamos que os clientes querem” para o produto lançado. É seu
trabalho antecipar e prevenir esses problemas antes que eles causem
danos ao seu produto.
Aqui está um exemplo. E se houver uma barreira oculta da qual você

nunca tenha aprendido ou abordado que impeça os clientes de usar seu 171
produto? Lembra do modelo de Kano do capítulo 3? Muitas vezes há
expectativas básicas que um cliente não menciona explicitamente, mas
se o seu produto não tiver esses recursos, o cliente ficará insatisfeito e
poderá até não usá-lo. Imagine se você reservasse um quarto de hotel
e não houvesse cama. Ou papel higiênico. Ou torneira. Você ficaria ou
você iria imediatamente para outro hotel? As fases de teste iniciais com
os principais clientes à medida que você cria seu produto podem ajudar a
garantir que você não perca uma barreira oculta.
Mas as barreiras ocultas são apenas uma das coisas que pode impedi-
lo de alcançar o produto/ mercado. Outros obstáculos incluem o seguinte:
• Leva muito tempo para criar e liberar seu produto para que as
necessidades de seus clientes mudem ou eles encontrem uma
solução melhor.
• Seu produto tem muitos recursos, novos clientes não conseguem
descobrir como usá-lo, ficam frustrados rapidamente e o
abandonam. Ou se você estiver adicionando um novo recurso
a um produto existente, talvez ele acabe ficando oculto, onde
ninguém o consegue encontrar.
• O valor do produto não estava claro desde o início e os clientes
não o compraram porque não perceberam que ele atenderia às
necessidades dele.
Para ser justo, você não poderá antecipar todos os obstáculos possíveis, nem
ninguém espera que você consiga, é por isso que precisamos da iteração.
No entanto, à medida que você começa a desenvolver seu produto,
há etapas que você pode adotar para dar ao produto a melhor chance
de sucesso possível. Essas etapas começam com a redação de alguns
documentos importantes que ajudarão você a estabelecer claramente suas
172 metas e resultados desejados, criar empatia com seus clientes e permitir
uma comunicação clara com as partes interessadas. Essas características
THE PRODUCT BOOK
se combinam para ajudar você e sua equipe a tomar decisões inteligentes à

medida que você cria seu produto, dando a ele a melhor chance de sucesso.
RETROCEDENDO AO IMAGINAR O FUTURO

Construir algo novo envolve imaginar o futuro e fazer acontecer.
Frequentemente, achamos útil iniciar o desenvolvimento de um novo
produto descrevendo como será o mundo quando o produto for concluído.
Imagine que você está escrevendo uma história de ficção científica sobre
um mundo em um futuro próximo com seu produto.
Existem dois grandes documentos de "imagine o futuro" para
tentar escrever antes que alguém escreva uma linha de código. Estes
documentos são um comunicado de imprensa e uma revisão do
produto. A Amazon, muitas vezes, faz com que seus Product Managers
escrevam um comunicado de imprensa ao iniciar o desenvolvimento.
Mas os comunicados de imprensa são focados internamente e abordam
como você imagina falar sobre o produto quando ele estiver pronto.
Escrever a resenha do produto que você deseja receber antes de iniciar
o desenvolvimento do mesmo, obriga a pensar em como deseja que o
produto seja percebido externamente quando estiver pronto.

Ambos os documentos são úteis para escrever, pois ajudam a
responder perguntas-chave e ajudam a se comunicar com os principais
interessados. Quando você começa a criar um novo produto, escrever
esses documentos o obrigam a tirar suas ideias de produto da cabeça
e colocá-las no papel, facilitando muito o compartilhamento de ideias
com outras partes interessadas. Além disso, anotar suas ideias ajudará
a garantir que você tenha respostas iniciais para perguntas importantes
sobre o produto, como: “Quais são os principais recursos que os clientes
vão querer promover?” 173
Ao longo do tempo, ao criar o produto, volte para a revisão e o

comunicado de imprensa, e atualize-os sempre que você estiver em um
ponto crítico de decisão. Como esses documentos mudam se você optar
por não criar um recurso específico, por exemplo? Se você não estiver
satisfeito com a alteração do seu comentário, o que você pode fazer para
recuperá-lo?
Escrevendo um Futuro Comunicado Interno de Imprensa

Embora não seja a prosa mais divertida de se escrever, escrever um
comunicado de imprensa antes de iniciar o desenvolvimento de produtos
obriga a escrever explicitamente seu mercado-alvo, o problema que você
está abordando, como você está resolvendo e os principais recursos da
solução - de maneira sucinta, em menos de uma página.
Compartilhar o comunicado de imprensa com as partes interessadas,
incluindo os chefes de engenharia e design, também lhe ajudará a começar
a descobrir quaisquer barreiras internas e a descobrir quais perguntas
você precisa responder antes que a equipe possa começar a construir esse
produto. Talvez este produto se baseie na criação de uma nova tecnologia e
você precise da ajuda da equipe de engenharia para criar um protótipo para
ver se é tecnicamente viável. Você precisará encontrar tempo na agenda
deles, e esse protótipo será um marco para o projeto geral, afetando a data
de lançamento antes mesmo de você começar a planejar o projeto.
Escrever um comunicado de imprensa também vai ajudá-lo a começar

a determinar como você comunica o valor do produto aos clientes, além
de como os clientes encontrarão e começarão a usar o produto. É provável
que você altere as duas coisas ao criar o produto, mas pensar nisso de
antemão ajuda a resolver dois principais motivos pelos quais os produtos
174 estão em alta.
Além disso, é uma etapa final de validação para garantir que isso seja
THE PRODUCT BOOK
realmente o que você deseja fazer a seguir. Se você não está entusiasmado
para escrever este comunicado de imprensa, e ninguém está entusiasmado
para lê-lo, você está realmente trabalhando na oportunidade certa? Há
algo mais que o deixaria entusiasmado para escrever e ou deixaria seus
clientes entusiasmados para lerem? Da mesma forma, pergunte a si
mesmo se o produto descrito no comunicado de imprensa realmente vai
ajudá-lo a atingir seus objetivos.
Você poderia tentar escrever um comunicado de imprensa como

se tivesse alcançado seu objetivo. Por exemplo, se sua meta é aumentar
sua base de clientes engajados para um determinado número de meta,
escreva um comunicado de imprensa sobre como você atingiu esse
marco e o papel que esse produto desempenhou para atingi-lo. Se o
comunicado de imprensa parecer complicado ou muito difícil de
escrever, talvez esse produto não seja a coisa certa a ser construída para
ajudá-lo a atingir suas metas.
Um comunicado de imprensa de produto básico geralmente inclui

esses elementos:

Título: Se você dissesse a seu amigo sobre este produto em uma
frase, o que você diria? Incluído nisso está o principal mercado-alvo,
como ele os ajuda a vencer e um nome de produto provisório que
o mercado-alvo possa entender. Às vezes, você precisará de duas
frases, caso em que você deve escrever um título e um subtítulo.
Parágrafo de resumo: O primeiro parágrafo completo em seu

comunicado de imprensa deve mencionar os aspectos mais
importantes do produto e como ele resolve o problema do cliente. 175
Imagine que você esteja lendo este comunidade de imprensa no
Flipboard ou na Apple News - a maioria das pessoas lerá apenas este
primeiro parágrafo, por isso ele precisa ser conciso, mas completo.
Problema e solução: A próxima seção deve detalhar o problema e

sua solução em mais detalhes.
Citação do porta-voz: inclua uma cotação sua, o Product

Manager, sobre como esse produto é ótimo para seus clientes. Não
há problema nenhum em incluir isso no texto da solução.
Citação de um cliente: Inclua uma citação de um cliente fictício

sobre como o produto influencia sua vida.
Conclusão/ Como começar: Explique como os novos clientes
podem encontrar/ inscrever-se/ comprar/ usar este produto e
reúna tudo com uma única ação.
Se você precisa escrever mais para ajudar a esclarecer seus pensamentos

sobre o produto, especialmente em torno de questões relacionadas
internamente à sua empresa e como você obterá o produto, e não em torno
de questões relacionadas ao cliente, então também escreva Perguntas e
Respostas Frequentes para o produto.
Escrevendo uma Resenha

O outro documento “imagine o futuro” que você pode escrever no início
do projeto, especialmente para uma nova versão principal de um produto
ou um novo produto, é a resenha que você deseja que seu produto receba.
Imagine se a Recode, ou quem for apropriado, estivesse revisando a
176 versão lançada do seu produto - o que eles diriam?
THE PRODUCT BOOK
Em um comunicado à imprensa, você pensa em como deseja falar

sobre seu produto, mas uma análise exige que você pense sobre o que
os clientes escutarão e como eles experimentarão o produto. Portanto, é
aqui que você precisa ser honesto sobre quais compromissos você deseja
impor ao produto. Talvez seu produto seja incrível, mas também mais
caro do que os concorrentes. Os críticos vão chamar a atenção para isto
- você está de acordo com isso? Se não, e você começar a tomar medidas
para reduzir seu preço, quais trocas ocorrerão? Você precisará de mais
clientes para compensar a renda perdida? Isso é possível? Você precisará
reduzir o conjunto de recursos? Que impacto isso teria nas resenhas?
Da mesma forma, em que partes do seu produto você acha que um

revisor ou crítico se concentrará e quais ignorará? As partes que você
mais discute são as partes em que mais tarde você passará a maior parte
do seu esforço de design e engenharia.
O mais importante é que a resenha deve ter uma conclusão sobre

por que um cliente deve comprar seu produto, especialmente sobre um
concorrente ou o que o cliente estiver fazendo agora. Essa conclusão deve

refletir o valor único e diferenciado que seu produto oferece. Se for algo
insignificante, como recursos idênticos a um custo ligeiramente inferior,
seu produto poderá ter dificuldades em se destacar. Se um concorrente
fizer uma liquidação, de repente não haverá mais diferença em seus
produtos, e você será visto como um imitador.
Escrever essa conclusão o forçará a relacionar os conceitos dos três

capítulos anteriores: Quais são as principais competências da sua empresa?
Como se conectam a essa oportunidade? Por exemplo, especialmente no
início, o Google Docs era muito mais limitado que o Microsoft Word. 177
Mas era baseado em nuvem, colaborativo e independente de plataformas
- além de ser gratuito. Esses três fatores são como o Google usou seus
pontos fortes para construir um processador de texto diferenciado. Se
tivesse sido um aplicativo gratuito que você baixou e instalou no seu Mac
ou PC, uma análise concluiu que era um processador de texto gratuito
muito limitado, e é isso - esse produto não teria tirado proveito dos
pontos fortes do Google.
Assim como seu comunicado de imprensa, sua resenha deve ser
concisa. A maioria das análises de produtos não analisa exaustivamente
todos os recursos. Eles fornecem aos clientes informações suficientes
para ajudá-los a saber qual problema o produto resolve, se ele resolve
bem o problema, o que ele oferece e se devem comprar o produto.
Definindo um Produto Mínimo Viável
Definir claramente o MVP que você deseja enviar e trabalhar ao contrário
para determinar como alcançá-lo é outra maneira de ajudar a configurar
seu produto para o sucesso. No Capítulo 4, falamos sobre o uso de um tipo
de MVP - simples, cortado em conjunto e não construído como o produto
real - para validar sua hipótese de oportunidade. Agora, vamos observar
os MVPs de uma perspectiva "o que vamos realmente construir?".
Como você escreveu o seu comunicado de imprensa e resenha do

produto, você foi forçado a escolher as partes mais importantes do seu
produto para falar. O aspecto mais importante do seu produto, aquele que
oferece o valor real para seus clientes, é o ponto de partida para definir
o MVP. Você priorizará a criação dessa parte primeiro e, em algumas
empresas, esse também será o produto inicial que você lançará.
178
Antes de prosseguirmos, vamos esclarecer um grande equívoco sobre
os MVPs. Mínimo não significa ruim. Seu produto ainda será projetado
THE PRODUCT BOOK
e bem projetado, testado completamente e, o mais importante, fornecerá

valor ao usuário. Deve ser um produto que as pessoas estejam dispostas a
comprar e usar. Mesmo que não seja totalmente exibido, ele deve funcionar
bem o suficiente para tornar-se a solução personalizada de seus clientes.
Imagine um produto que tenha apenas um botão. É fácil para os

clientes usarem este produto, porque sua única opção é pressionar um
botão. Agora imagine que você adicione um segundo botão. De repente,
o produto é muito mais difícil de usar porque os clientes precisam
escolher qual botão apertar. Cada botão ou recurso adicionado aumenta
a dificuldade para os clientes. Isso faz com que eles tenham que pensar
mais sobre o que estão fazendo.
Mínimo significa simplesmente o menor número de botões ou recursos
que você precisa construir para fornecer o valor mais importante. Isso
evita que você crie recursos que ninguém usará ou, pior, tornará o
produto tão complexo que um cliente não o utilizará. Em um mundo
ideal com metodologia enxuta, você libera seu MVP para clientes reais
e, em seguida, determina o que fazer a seguir com base no que eles estão

realmente fazendo com o produto e quais limitações eles encontram. Em
outras palavras, você está sempre criando MVPs e iterando.
Infelizmente, muitas vezes, acabamos em situações não ideais em que

fazemos iterações com menos frequência, como a criação de uma nova
versão importante do nosso produto, e esperamos que você envie mais
do que apenas o MVP puro. Nesses casos, definir o MVP o ajudará a
priorizar as peças que você precisa construir para entregar o produto.
Para os recursos além do MVP, em vez de escolher arbitrariamente os
recursos a serem criados, teste seu MVP com os principais clientes antes 179
do lançamento. Então, use a avaliação deles para descobrir quais recursos
extras priorizar. Mesmo que a versão final seja mais do que um MVP, essa
abordagem o ajudará a usar um MVP internamente, de forma eficaz.
Então, como você cria seu MVP? Usando seu comunicado de

imprensa e análises de produtos como um guia, vamos fazer uma lista
sobre seu produto.
1. Anote tudo o que você está fazendo e por que está fazendo. Isto
é, qual o valor que isso oferecerá aos seus clientes e qual objetivo
isso o ajudará a alcançar? Explicitamente, coloque esta afirmação
no topo.
2. Liste os recursos que você acha que precisa para atingir essa meta
de nível superior, além de saber por que esse recurso é importante.
Em vez de apenas escrever “armazenamento de dados em nuvem”,
escreva “armazenamento de dados em nuvem para que os clientes
possam acessar seus dados de qualquer dispositivo”.
Agora, aqui vai uma dica importante: enquanto você trabalha

nesta etapa, não é permitido adicionar nenhuma nova categoria
de recurso não listado no comunicado de imprensa e resenha
do produto. Você definirá cada recurso com mais detalhes (por
exemplo, você pode precisar de uma maneira de fazer login,
para que as pessoas possam acessar seu serviço e uma maneira
de redefinir senhas), mas não é possível adicionar algum recurso
principal. Por exemplo, se você escreveu um comunicado de
imprensa fictício sobre o iPhone 5S e nunca mencionou a
identificação por impressão digital, não é possível listar esta
identificação por digital como parte do MVP. Quer você tenha
180 percebido ou não, escrever o comunicado de imprensa e a
resenha ajudaram você a priorizar as partes mais importantes de
THE PRODUCT BOOK
seu produto, o que, por sua vez, ajuda a definir o MVP.
3. Percorra sua lista de recursos e retire todos os itens que os clientes

realmente não precisam para atender a necessidade principal. Essa
etapa é, de fato, a parte difícil - os MVPs devem ser desconfortáveis.
Você, como Product Manager, deve se sentir como se o MVP
não fosse suficientemente rico em recursos, mas deveria haver
funcionalidade suficiente para que os clientes pudessem atingir
suas metas. Por exemplo, mesmo que a autenticação de dois
fatores seja mais segura, ela é realmente crítica para seu cliente ou
pode ter uma prioridade mais baixa?
A eliminação de recursos pode até mesmo eliminar o uso do seu produto
por certas pessoas. Tudo bem, desde que isso não impeça seu principal
mercado-alvo de usar o produto. Se o seu produto é muito arriscado,
como confiar em uma engenharia de tecnologia ainda não criada, você
pode até mesmo definir um "MVP de caso de uso único", que pode ser
usado por apenas uma pessoa para uma situação, uma situação arriscada.

Se o MVP funciona para o mercado chave, com o tempo você pode
construir os recursos necessários para suportar mais personas.
Quando terminar, você deve ter o que acredita ser um MVP claramente
definido, além de explicações sobre por que cada recurso faz parte do MVP.
MVPs, Plussing e o Modelo Kano

Adoramos os MVPs porque eles permitem que você se concentre em
entregar um produto que seus clientes desejam e usarão. Mas lembre-
se, o mínimo não significa que seja ruim. Você precisa procurar 181
continuamente maneiras de se certificar de que o que está fazendo seja
ótimo. No Capítulo 3, falamos sobre o modelo Kano e apresentamos a
ideia de recursos de excitamento, recursos que os clientes não pedem,
mas que geram um enorme retorno na satisfação do cliente.
À medida que você define seu MVP, é fácil rejeitar inadvertidamente

os recursos de excitamento como um trabalho não essencial, afinal, os
clientes não estão solicitando isso explicitamente. Mas é seu trabalho,
como PM, defender e manter esses recursos como parte do MVP
quando possível, pois eles são essenciais para criar produtos inovadores e
diferenciados que seus clientes adorem.
Para ajudá-lo a pensar sobre esses recursos, queremos compartilhar

uma ideia do Walt Disney. Ele surgiu com a ideia de “plussing”, que é
simplesmente encontrar maneiras de ter uma boa ideia e entregar além
do que as pessoas esperam. Soa familiar?
O historiador da Disney, Les Perkins, conta uma história dos

primórdios da Disneilândia. Walt estava realizando um desfile de Natal,
que custou US$350.000. Seus contadores imploraram que ele não gastasse
esse dinheiro, porque as pessoas já estariam no parque. A resposta
de Walt foi: "Essa é exatamente a razão. Nós devemos fazer o desfile
precisamente porque ninguém estará esperando por isso. Nosso objetivo
na Disneilândia é sempre dar às pessoas mais do que elas esperam.
Enquanto continuarmos a surpreendê-los, eles continuarão voltando.
Mas se eles deixarem de vir, isso nos custará dez vezes mais para fazer
com que eles voltem.”
Até hoje, a cultura da Walt Disney Company integrou o “plussing”
em tudo o que faz. Em um parque, um membro do elenco pode parar o
182 que está fazendo para ajudar inesperadamente uma família a pular uma
longa fila, e esse prazer inesperado torna seu dia ainda mais divertido.
THE PRODUCT BOOK
A sequência de explosões do navio naufragado e dos tubarões em

Encontrando Nemo foi muito divertida, e o tiro final com dois pássaros
sentados na água realmente agrega ainda mais à experiência (não vamos
estragar a surpresa, caso você não tenha visto). Os resultados de entregar
continuamente mais do que as pessoas esperam, tanto em rendimento
quanto em satisfação do cliente, falam por si mesmos.
Quando você está definindo seu MVP, um filtro extra ao cortar

recursos em potencial é perguntar: “Isso acrescenta a ideia central? Se
isso realmente acontecer, gaste algum tempo extra considerando se você
deve cortá-lo ou não. Por outro lado, se você está lutando para encontrar
maneiras de definir ideias, pergunte-se: "Como eu poderia agregar mais
valor a isto?" Embora o questionamento não esteja totalmente de acordo
com o pensamento lean, você provavelmente descobrirá que o seu MVP
inicial é fundamental para construir produtos que os clientes não apenas
usem, mas que também amem.
Em seguida, vamos ver como discutir efetivamente o MVP e o projeto
como um todo com outras partes interessadas.

COMUNICANDO PELO DOCUMENTO DE REQUISITOS
DE PRODUTO
Uma das ferramentas mais importantes para ajudá-lo a se comunicar é
um documento de requisitos de produto (PRD) bem escrito. Um PRD é
uma explicação do produto específico que você está criando. Isso explica
claramente por que você está criando este produto, tanto para suas metas
internas quanto para seus clientes, junto com o escopo exato - os recursos
e a funcionalidade - do produto. Da mesma forma, deve transmitir o que
você não está criando. Para melhor ou pior, os PRDs tornaram-se um
tema controverso no mundo da gestão de produtos. Em empresas muito 183
voltadas para o método de cascata, um PM gastará muito tempo escrevendo
um PRD muito detalhado. Esses documentos enormes, de 20 páginas ou
mais, especificam todos os aspectos de um produto antecipadamente,
são difíceis de ler e são essencialmente imutáveis depois de concluídos
- é isso que a equipe vai implementar, não importa o quê. Os defensores
da metodologia enxuta usam o PRD como um exemplo de tudo errado
com o desenvolvimento em cascata. Especificamente, eles acreditam em
iterações rápidas e usam novos conhecimentos para planejar o que fazer
em seguida, e especificações longas e detalhadas sobre o que você fará são
contrárias a essa abordagem.
Acreditamos que um PRD, se bem feito, seja uma fantástica ferramenta

de comunicação, e nós vamos ajudá-lo a criar uns eficazes que os outros
irão ler. Além disso, vemos um PRD como um documento vivo. Você vai
atualizá-lo à medida que o projeto avança, documentando mudanças no
escopo junto com as principais decisões e desenvolvendo informações
relevantes, como testes de design do usuário. Diferentemente de quando
o Product Management surgiu pela primeira vez e as pessoas criaram
PRDs detalhados antes do início de um projeto, acreditamos que o PRD
está concluído somente quando o produto for lançado.
O PRD é uma ferramenta para todos os envolvidos no produto. No

começo, você o usará para reunir todos os principais interessados na
mesma página e ajudar a equipe a entender o projeto. Ter um PRD inicial
pode ser reconfortante e inspirar confiança em seu projeto, pois fica claro
para outras pessoas na empresa que você tem uma ideia de onde realizar
o projeto. Acreditamos que, durante todo o projeto, o PRD deve ser a
página inicial do projeto ou, pelo menos, o primeiro elo na página inicial
do projeto. Quando você estiver perto do lançamento, suas equipes de
184 suporte e vendas o usarão para descobrir tudo o que precisam saber sobre
o produto. E quando você termina, é uma referência histórica de por que
THE PRODUCT BOOK
você tomou certas decisões.
Devemos mencionar que você não precisará de um PRD, nem de um

comunicado de imprensa imaginário/ resenha de produto, para todas as
oportunidades que busca. Um erro no sistema, por exemplo, não precisa
de um PRD. Não há uma divisão exata de quando você deverá resolvê-lo
e você não precisará escrever um PRD. Nossa recomendação é escrever
um PRD para qualquer oportunidade que seja mais do que um projeto,
para não envolver comunicação entre várias equipes e uma confusão em
potencial, quanto a uma pequena mudança. Vejamos o que acontece em
um PRD e como usá-lo como uma ferramenta de comunicação.
Explicando o PRD
Estas são as seções principais em um PRD:
Título: Dê a este projeto um nome distinto.
Histórico de alterações: forneça uma descrição de cada alteração

importante no PRD, incluindo quem a alterou, quando e de que
maneira específica.
Resumo: De forma resumida, sobre o que é este projeto? Por que você
está fazendo isso?
Objetivos: O que isso permitirá ao cliente? Quais são os nossos

objetivos internos de alto nível para fazer este projeto?
185
Métricas de sucesso: Quais são as métricas de sucesso que indicam
que você está atingindo suas metas internas para o projeto?
Mensagens: O que o marketing por trás das mensagens do produto

usará para descrever esse produto para os clientes, novos e existentes?
Cronograma/ Planejamento de lançamento: Qual é a programação

geral para a qual você está trabalhando?
Personas: Quem são as personas-alvo deste produto e qual é a persona

principal?
Cenários do usuário: São histórias completas sobre como várias

pessoas usarão o produto em contexto.
Características: O que você decidiu explicitamente não fazer e por quê?
Modelos: inclua todos os esboços antigos necessários e vincule-os aos

modelos reais assim que estiverem disponíveis.
Questões Pendentes: Quais fatores você ainda precisa descobrir?
Perguntas e Respostas: Quais são as perguntas mais comuns sobre o

produto e as respostas a essas perguntas? Este é um bom lugar para
tomar decisões importantes.
Outras Considerações: Esta parte servirá para todo o resto, como,

por exemplo, se você tomar uma decisão importante de remover ou
adicionar ao escopo do projeto.
186 O formato exato de um PRD varia de empresa para empresa, mas o

conteúdo geral é semelhante. Vamos nos aprofundar em cada seção com
THE PRODUCT BOOK
mais detalhes.
Título e Histórico de Alterações

O cabeçalho do PRD contém o título, que é um nome de identificação
exclusivo para o projeto. Este pode ser um nome de código ou pode ser
algo simples, como "Aplicativo Moover na Rede" para a primeira versão.
O histórico de alterações é apenas uma maneira de informar

rapidamente se há novas informações para que os leitores não tenham
que reler todo o documento apenas para descobrir que nada foi alterado.
Algumas ferramentas wiki têm widgets de rastreamento de mudança
automáticos, portanto, se você estiver escrevendo seu PRD on-line, essa
seção será escrita automaticamente para você.
Visão Geral e Objetivos
Em seguida, você escreve um parágrafo geral que será muito semelhante
ao primeiro parágrafo do comunicado de imprensa que você escreveu.
Ele descreverá o que é esse projeto e por que você está fazendo isso
agora. Você também criará uma lista com marcadores curtos listando

explicitamente o que deseja que o cliente obtenha deste projeto e quais
metas internas você está tentando alcançar: seus objetivos.
Métricas de Sucesso
Você também listará explicitamente as métricas de sucesso mais
importantes, os principais indicadores de desempenho necessários para
avaliar se você atingiu suas metas. Quando você começa a escrever o PRD,
você pode achar que tem um senso geral de seus objetivos (aumentar o
número de usuários), mas não necessariamente um objetivo detalhado
(aumentar nossa base de usuários em 10%). Escreva o que puder e 187
adicione um indicador de espaço reservado, como "???", se você não
tiver certeza ou precisar definir algo mais claramente. Você também vai
chamar a atenção para essa incerteza na seção “Questões pendentes”.
Novos PMs frequentemente cometem o erro de listar todas as
métricas possíveis que poderiam medir. Em vez disso, se concentre nas
principais métricas de sucesso que deseja observar e, posteriormente,
no PRD como parte da seção de recursos ou na seção de perguntas e
respostas, relacione as métricas específicas que você deseja avaliar que
afetarão as métricas de sucesso.
Mensagens
Mensagens são como você explica o produto para um cliente atual ou
novo em uma frase curta, e nós abordaremos mais sobre isto no Capítulo
8. É bem provável que a mensagem do seu produto não seja claramente
definida no início do projeto. Faça uma tentativa de escrever algo,
indique que é algo experimental/ incerto, se for, e adicione para descobrir
a mensagem exata na seção "Questões pendentes".
Cronograma/ Planejamento de Lançamento:

Mesmo que você provavelmente não atue como gerente de projeto
e seja proprietário do cronograma do projeto, inclua aqui algumas
informações aproximadas de prazo e, eventualmente, forneça um link
para o cronograma completo. Talvez sua equipe de marketing e vendas
queira liberar o produto para um impulso de fim de ano - isso significa
que ele precisa estar à venda em meados de novembro. Saber essa data
pode afetar significativamente seu planejamento de desenvolvimento e o
quanto você pode criar e testar a tempo.
Personas
188 Cite as personas-chave para as quais este produto é destinado. Se você
tem personas definidas em outro lugar, crie um redirecionamento para
THE PRODUCT BOOK
as personas completas e lembre ao leitor as principais características do

PRD. Se elas não estiverem totalmente definidas em outro lugar, você
deve definir aqui para que o leitor entenda como serão os possíveis
clientes e seus objetivos.
Cenários de Usuários e Narrativa de Histórias

Agora chegamos ao molho secreto do nosso formato PRD: cenários
do usuário. Acreditamos que os cenários do usuário ajudarão você a
escrever os PRDs acima de todos os outros, fazendo com que as pessoas
queiram lê-los. Em um cenário de usuário, você pode combinar personas,
desenvolvimento do cliente e empatia para escrever histórias completas
sobre como seus clientes usarão seu produto em diferentes cenários.
As histórias são a forma mais antiga de entretenimento que temos,
e os cientistas argumentam que as experiências narrativas são a base de
muito mais de nossas vidas do que a lógica sistemática. Pense na última
apresentação ruim que você viu. É provável que o apresentador tenha
slides repletos de marcadores e apenas leia cada um deles. Depois de três
minutos, você estava checando seu e-mail, sonhando acordado em estar

em qualquer lugar, menos ali naquela cadeira. E quando você olhou bem
para os slides e viu “3/101”, você começou a rezar por um incêndio para
ter uma desculpa para sair da sala. O conteúdo mal apresentado pode
tornar chato até mesmo o mais fascinante dos assuntos.
Por outro lado, pense em uma palestra motivacional. Esses palestrantes

facilmente prendem sua atenção por 15 a 20 minutos e fazem com que
você queira ouvir mais. Cada uma delas começa com o palestrante
compartilhando um detalhe pessoal sobre sua vida, e os slides, se houver
algum, são imagens sem texto. Em vez de exaustivamente ler, ouvimos o 189
mundo que o apresentador cria para nós e nos imaginamos dentro dele.
As palestras TED são formatadas como histórias e essas histórias deixam
nossos cérebros envolvidos.
Há evidências científicas de que nossos cérebros estão preparados
para pensar em histórias, e não em listas de enumeração de tópicos. Os
cientistas descobriram que a leitura de uma lista de pontos de tópicos
apenas ativa as partes do cérebro do processamento de linguagem (área
de Broca e área de Wernicke), mas quando lemos uma história, as áreas
no cérebro que usamos quando vivenciamos os eventos também são
ativadas. Se lermos sobre uma pessoa andando pela rua, as mesmas
partes do cérebro que se ativam quando descemos a rua serão ativadas.
As histórias nos deixam imaginar a experiência de outra pessoa.
Uma das grandes razões pelas quais um Product Manager precisa
se comunicar de forma eficaz é fazer com que todos da equipe tenham
empatia com o cliente, de modo que ele possa entender claramente as
necessidades do cliente e como ele se encaixa em sua vida. Escrever
histórias para falar sobre o cliente e o produto que você está criando é
a maneira mais eficaz de ajudar sua equipe a ter empatia com o cliente,
pois isso faz com que o cérebro da sua equipe se comporte como se fosse
o cliente, comunicando implicitamente os resultados de seu trabalho de
desenvolvimento de cliente.
A narração de histórias também fornece uma maneira de aproveitar

oportunidades vagas e dados brutos e dar sentido a isso. Quando somos
jovens, aprendemos que há uma resposta certa para um problema. 2 + 2
= 4. Mesmo na aula de inglês, somos ensinados a escrever uma resposta
certa: escrever uma introdução, hipótese, dados de apoio e conclusão. A
maneira como a maioria das escolas trabalha é uma relíquia de preparar
os alunos para trabalhar nas linhas de montagem, onde há apenas uma
190 maneira de realizar cada tarefa.
O Product Management não é assim. Temos muitos dados
THE PRODUCT BOOK
aparentemente desconectados que temos que unir para criar uma

narrativa de produto. E nem sempre há uma resposta perfeitamente
clara para cada problema. Em vez disso, queremos nos concentrar nas
necessidades e motivações subjacentes do cliente para garantir que
as respostas que o Design e a Engenharia apresentarem resolvam o
problema. As histórias são uma maneira eficaz de dar significado aos
dados e expressar essa necessidade de uma maneira compreensível. Elas
nos permitem imaginar um mundo que não existe e pensar sobre as
etapas que faremos para chegar lá - o que também é útil ao elaborar um
roteiro de produtos.
Escrever cenários de usuário é uma ótima maneira de transformar uma
lista de necessidades de clientes e requisitos de produtos em um formato
que os outros entendam e queiram ler. A narração de histórias irá ajudá-
lo não só a criar excelentes PRDs, mas também a fazer apresentações
eficazes, explicar claramente o seu produto e muito mais.
Escrevendo Ótimas Histórias

Felizmente, boas histórias não são difíceis de escrever! Ao ler livros,
assistir filmes e simplesmente ao ser humano, você já sabe implicitamente

contar uma ótima história. Vamos tornar esse conhecimento explícito.
Todas as histórias têm uma estrutura semelhante. Elas primeiro dão
contexto: eles montam um mundo. Para um cenário de usuário, quem
é a persona? Lembre-nos rapidamente sobre os clientes que a persona
representa. Em que situação ele está? Quais são os principais detalhes que
precisamos saber - ele está em seu carro? Segurando um bebê?
A transição da configuração para a próxima parte da história, ação, é

o “incidente incitante”. O incidente incitante é quando o conflito aparece.
Qual problema faz com que a persona precise de seu produto ou precise 191
de um recurso específico em seu produto se ele já o estava usando na
configuração? Por que ele pensa em usar seu produto? Se ele é um novo
cliente, como ele encontrará/ comprará seu produto?
Agora entra a seção de ação. É aqui que acontecem as coisas. Quando

a persona está usando o produto, o que ela está fazendo? O que acontece
quando ela tenta usá-lo? Quais bloqueios ou conflitos ela encontra ao
tentar usar o produto e quais recursos do produto a ajudam a eliminar
esses obstáculos? Em um cenário de usuário, é aí que você justificará
porque vários outros recursos são importantes.
Finalmente, qual é o resultado? Agora que ela abordou sua necessidade,

como o mundo dela muda? Tudo bem, se é uma pequena mudança, nem
todo produto está salvando o mundo. "Tendo coçado a coceira com um
coça-costas Acme, Cláudio coloca seu coça-costas ao alcance, sabendo
que é a ferramenta perfeita para coçar as costas". Esperamos que você
tenha notado como até mesmo esse simples resultado implica que
alcançamos uma meta de satisfação/ engajamento do cliente no final.
Configuração. Ação. Resultado. É bem isso. O desafio está na execução!

Ao escrever a história, inclua os detalhes relevantes para ajudar o leitor
a imaginar a situação que você está descrevendo, mas, assim como ao
escrever personas, você não precisa incluir todos os detalhes possíveis.
Se você não tiver certeza do que incluir, comece escrevendo uma história
detalhada e comece a eliminar os detalhes. Se o significado geral não
mudar e a necessidade do cliente/como o produto resolve o problema do
cliente ainda estiver claro, é provável que você não precise desses detalhes.
Escreva suas histórias para que, se um cliente em sua persona-alvo o

192 lesse, ela dissesse: “Eu já estive nessa situação antes, e esse produto parece
fantástico”! Além disso, seus clientes provavelmente não conhecem seu
THE PRODUCT BOOK
jargão. Portanto, evite usá-lo o máximo possível.

Isso também ajudará outras partes interessadas a entender a história
claramente - não deve haver ambiguidade por você ter usado um jargão
que eles não reconheçam. Por último, como mencionamos antes, seja
autêntico. Você quer que suas histórias sejam reais e confiáveis, pois isso
ajudará você a descobrir suas fraquezas potenciais, tanto em termos de
execução quanto de fricção. Depois de conhecer suas fraquezas, você
pode tomar medidas para resolvê-las!
Assim como o Product Management, criar ótimas histórias é fácil
de aprender, mas pode levar uma vida inteira para dominar. Continue
usando histórias para seus PRDs, apresentações e muito mais, e você se
tornará um contador de histórias cada vez melhor.
Escrevendo Cenários de Usuários
Em um PRD, você provavelmente escreverá vários cenários de usuários
cobrindo diferentes personas e seus casos de uso. Sua definição de MVP
o ajudará a descobrir as histórias mais importantes a serem escritas e os
recursos a serem focados nessas histórias. Cada caso de utilização ou
aspecto principal de um caso de utilização será um cenário de usuário.

Se você não estiver mencionando recursos que estão na sua lista de
MVPs, ajuste sua lista de acordo. Tudo na sua lista de MVPs deve estar
nos cenários do usuário, mas nem todo recurso citado nos cenários do
usuário fará parte do MVP. Se você narrar como cada recurso ajudará
o usuário a vencer, ou seja, como os clientes o usarão para solucionar
seus problemas, você tornará o valor do recurso claro para seus leitores.
Para novos produtos ou recursos, não se esqueça da parte de integração
do cenário do usuário: como um cliente encontrará esse produto pela
primeira vez e aprenderá a usá-lo?
193
Existem três dicas importantes a serem lembradas ao escrever

cenários de usuários. Primeiro, lembre-se de que seu objetivo é fazer
com que os leitores sintam que estão sentados ao lado de cada pessoa,
usando o produto em cada cenário. Forneça os detalhes relevantes para
que os leitores saibam o que está acontecendo na vida do cliente ao usar o
produto, mas não afunde o leitor em detalhes desnecessários.
Segundo, você quer que essas histórias sejam tão verdadeiras quanto
você possa imaginar, já que ser autêntico ajudará com que você obtenha
o melhor entendimento possível de seu cliente para poder tomar decisões
inteligentes sobre produtos - estamos reiterando isso porque é importante.
Se um dos requisitos do seu produto é um manual de usuário de 100
páginas, isso é razoável? Quando foi a última vez que você leu um manual
de produto? Por que devemos acreditar que os personagens em seu cenário
de usuário lerão um longo manual? Uma vez lemos um PRD no qual cada
cenário de usuário terminava com "e o cliente fala para todos os amigos
sobre o produto e todos compram um". Embora seja bom ter um final feliz,
isso não é autêntico quanto ao que as pessoas realmente fizeram! Em vez
disso, tente ser realista sobre o impacto que a utilização do produto por
cada persona terá em relação ao seu objetivo. Uma afirmação realista é:
“Como esse é um problema contínuo e o cliente ficou tão feliz com nosso
produto de teste, ela se inscreveu no nosso plano mensal”.
Ser autêntico também pode ajudá-lo a eliminar recursos desnecessários

do produto. Se você está tentando forçar o que você achava ser uma
característica fundamental da história, é uma ótima dica que o recurso
não é essencial.
Por último, não defina demasiados detalhes ou seja demasiado

194 prescritivo sobre o que a solução implica. Como discutiremos mais
adiante, queremos deixar o PRD focado em metas e requisitos, em
THE PRODUCT BOOK
vez de soluções específicas para um problema. As equipes de Design e

Engenharia descobrirão a solução certa para ajudar o cliente a atingir
seus objetivos e a atender às suas necessidades. Por exemplo, em vez de
descrever como um cliente vira uma maçaneta na porta de um banheiro
para sair, descreva como o cliente sai do banheiro com as mãos limpas.
Talvez a equipe de Design conclua que usar o pé para abrir a porta é uma
solução muito melhor do que uma maçaneta, neste caso. Ser prescritivo
com as equipes de Design ou Engenharia é uma maneira fácil de deixá-
las irritadas com você - você apenas precisa confiar que elas sabem como
fazer seus trabalhos.
Requisitos/Recursos Incluídos e Removidos

Em seguida, na estrutura do PRD, há uma lista de recursos, que às vezes
também é chamada de lista de requisitos ou, mais confusamente, de
histórias de usuários (mas, na verdade, não são histórias). Esta seção é
uma lista de quais recursos você incluirá no produto, de preferência com
algumas prioridades básicas em relação a essencial, realmente desejado e
bom de se ter.

Você já tem a base para isso: sua lista de definição de MVP. Cada um
dos itens da sua lista de MVPs deve ser priorizado como essencial. Seus
cenários de usuário fornecerão o restante da lista - retorne a eles e divida
explicitamente a prosa em tarefas. Tenha em atenção que os marcadores
de prioridade não estão definidos em pedra. À medida que você
desenvolve o produto e compartilha as primeiras versões com os clientes
para avaliação, a priorização do recurso provavelmente será alterada.
Tudo bem se você não tiver total conhecimento sobre como dividir
as tarefas de nível superior em subtarefas específicas. Quando você 195
compartilha o PRD com os chefes das equipes de design e engenharia,
pode trabalhar com eles para dividir cada item em histórias de usuário
mais específicas.
Assim como os cenários do usuário, você deve evitar ser prescritivo e,
em vez disso, se concentrar nas metas e nos requisitos. Uma maneira fácil
de fazer isso é escrever cada item neste formato: “Como <uma persona>,
eu quero <objetivo de recurso específico> para que <motivo>”. Alguns
PMs preferem usar o formato “Dado-Quando-Então”:
“Dado <algum contexto>, quando <alguma ação acontece>, então
<um conjunto de comportamentos observáveis acontece>”. Ao passo que
“Dado-Quando-Então” torna mais fácil escrever do que outras formas
de requisitos para dizer quando a história do usuário foi implementada
completamente, tenha cuidado, pois os blocos “Quando” e “Então”
podem se tornar prescritivos.
Independentemente do formato escolhido para suas histórias de
usuário, deve ficar claro o que o recurso fará e como avaliar o sucesso da
implementação adequada do recurso.
Também achamos útil listar explicitamente "recursos removidos", ou

seja, o que você não está fazendo e por quê. Por um lado, vários leitores
podem perguntar sobre a adição de um recurso/ apoiar um caso de
utilização, e isso antecipa a questão. Segundo, se você optar por reduzir
o escopo do produto e remover um recurso, você observará o recurso,
essa decisão e a data nesta lista. Essa lista também pode ser uma fonte
de inspiração para a próxima iteração do produto. Também é um ótimo
lugar para escrever sugestões que outras pessoas não ajustam no escopo
atual, para que as pessoas que fizeram as sugestões sintam que você
escutou a avaliação delas.
196 Modelos
Depois de definir os requisitos do produto, na seção de modelos você
THE PRODUCT BOOK
começa a analisar as soluções. Mesmo que você não queira ser prescritivo,
às vezes é eficaz criar um "esboço de guardanapo" de baixo nível e de
alta qualidade de um possível modelo para ajudar todos a entender o
que você está falando. Uma imagem pode valer mais que mil palavras! A
seção de modelos é o lugar para incluir estes esboços.
Vamos abordar o trabalho com a equipe de design no próximo capítulo,

mas recomendamos que esses esboços sejam rudes para que os designers
não pensem que você está tentando fazer o trabalho deles! E mesmo se
você fosse um designer antes de se tornar um Product Manager, você faria
seus esboços de forma rudimentar. Você precisa confiar que a equipe de
design fará uma solução de projeto melhor do que você. Você adicionará
links aos designs reais assim que estiverem disponíveis.
Questões Pendentes, Perguntas e Respostas, e Outras Considerações
As últimas seções do PRD são um resumo geral. Especialmente em seu
primeiro rascunho, provavelmente há algumas partes do projeto que você
não tem certeza, desde as metas específicas da sua métrica de sucesso até
a inclusão de um caso de utilização ou não. Anote essas perguntas em
Problemas Pendentes.

Ao discutir seu PRD com outras pessoas, você encontrará algumas
perguntas comuns repetidas vezes. Inclua uma seção de Perguntas
e Respostas para fornecer as respostas. Se você criou as Perguntas e
Respostas do produto para acompanhar o comunicado de imprensa,
você já pode ter um bom começo para esta seção! A seção de Perguntas
e Respostas também é um ótimo lugar para tratar de casos específicos -
como você lidará com eles?
A última parte do PRD é uma generalizada seção Outros, caso surja

197
algo que não acontece em nenhum outro lugar. Conforme você escreve
o PRD, recomendamos a inclusão de todos esses cabeçalhos, mesmo que
o único conteúdo seja "nada ainda", para que eles estejam disponíveis
quando você precisar deles.
Usando um PRD
Agora que você tem um PRD, veja como usá-lo para obter a adesão das
partes interessadas e como uma ferramenta de comunicação com sua
equipe/ empresa. Recomendamos que você escreva o primeiro rascunho
do seu PRD em um formato particular, como um documento do Word
ou um documento privado do Google Doc. Ele será demasiadamente
alterado nos primeiros rascunhos, e você não quer que alguém, por acaso,
o encontre e entre em pânico! Você definirá o núcleo do produto nesses
primeiros rascunhos e terá certeza de que tudo na página está vindo do
trabalho que você fez para identificar, validar e aproveitar a oportunidade.
Depois de tê-lo escrito, você começará a compartilhá-lo com outras
pessoas para receber avaliações. Mesmo que você queira ouvir e comentar
seus comentários de forma colaborativa, lembre-se de que o produto não
é criado por um comitê. Você é a pessoa responsável pelo produto e deve
abordar essas discussões a partir de uma perspectiva de "É nisso que
acredito estar certo. Senti falta de alguma coisa?”, ao contrário de “ O que
você acha que devemos construir?”
No entanto, isso não significa que você deva abordar esse processo
de compartilhamento apenas dizendo às pessoas: “É isso que estamos
construindo. Agora, mãos à massa”. Você desejará solicitar e receber
comentários, tanto para tornar o produto melhor quanto para manter seu
relacionamento produtivo e respeitoso com várias partes interessadas.
As primeiras pessoas com quem compartilhar seu PRD são os chefes e

outros Product Managers. As pessoas que estiveram na empresa por mais
198 tempo, têm experiência com o produto ou têm mais experiência em geral,
podem ter uma visão valiosa para tornar o produto - ou o caminho para
THE PRODUCT BOOK
obtê-lo - melhor.
Uma vez que sua equipe esteja a bordo, envolva outras partes
interessadas importantes, como os chefes das equipes de design e
engenharia. Novamente, veja isso como uma conversa - você está
buscando a avaliação deles e incorporará os pensamentos deles no PRD.
Talvez o gerente de engenharia observe um problema técnico que você
precisa ressaltar e você adicionará isso à seção de "Problemas Pendentes".
Ou talvez o chefe de design tenha uma ideia para uma solução que altere
o escopo técnico. Talvez o chefe de marketing realmente queira que você
tenha algo para uma certa data de lançamento. Eles também podem
solicitar que você minucie uma das suas histórias de usuário em mais
detalhes para tornar o escopo do projeto explicitamente claro.
Às vezes, você ouve as pessoas dizerem que um PM é o dono de todos
problemas, Design é dono da solução e a Engenharia a implementa.
Descobrimos que uma abordagem muito melhor é definir o problema e
gerar soluções juntos. Você, o PM, pode dar o primeiro passo na definição
do problema, mas isso não significa que o que você escreve é perfeito e que
o Design não tenha palpites válidos. Da mesma forma, se você costumava

ser engenheiro, talvez tenha uma visão valiosa de como a Engenharia
poderia implementar uma solução. Quando surgirem conflitos, lembre-se
de seu papel principal e concentre-se nos requisitos do produto, e não em
como criá-lo. Um monte de conflitos ocorre quando alguém tenta fazer
o trabalho de outra pessoa, como um PM tentando projetar a solução ou
um designer que deseja alterar o escopo do produto.
Depois de discutir o PRD com esse grupo, todos devem estar de acordo
sobre o que você está tentando construir e por que, além de quais são suas
principais métricas de sucesso. Você deve ter uma ideia básica sobre se o 199
projeto é viável com o escopo definido e no cronograma desejado. Você
provavelmente também terá várias perguntas e respostas para a seção de
Perguntas e Respostas, e os outros líderes de outros setores podem ter
ideias que afetam os cenários do usuário e a lista de recursos.
Agora é a hora de começar a compartilhar o PRD mais amplamente.

Se você tiver um wiki interno, mova o PRD para uma página wiki e
monte a página inicial do produto, ou, no mínimo, crie um link para
ele na página inicial do produto. Comece a compartilhar o PRD com
as equipes que estarão trabalhando nele. Certifique-se de incorporar as
avaliações delas, já que as pessoas no dia a dia das ervas daninhas têm
visões práticas valiosas.
Por fim, é bem possível que você seja solicitado a compartilhar o PRD
com um grupo mais amplo, seja em uma reunião de toda a empresa ou
até mesmo em uma reunião do conselho administrativo. Nessa situação,
não leia o PRD ou seus cenários de usuário para o público na íntegra. Em
vez disso, destile o PRD até a essência do que você está fazendo e por quê,
e apresente essa informação ao grupo. O comunicado de imprensa que
você escreveu pode ser um ótimo guia. Não há problema em falar sobre
coisas específicas para esclarecer o escopo do projeto, mas deixe bastante
tempo para perguntas.
E enquanto você compartilha o PRD com públicos mais amplos, as

equipes de design e engenharia estão começando a trabalhar no produto!
Nos próximos capítulos, veremos como você trabalhará com eles para
orientar o produto.
200
THE PRODUCT BOOK
DICA DO CAPÍTULO CINCO
USANDO A IMERSÃO EXPERIMENTAL PARA PREPARAR SUA

EQUIPE
A comunicação dentro de sua organização interna de produtos é talvez
um dos fatores mais negligenciados, porém importantes, que determina o
sucesso de seu produto. Como Product Manager, é fácil se concentrar no
lado voltado para o cliente para definir o problema inicial e, posteriormente,
supervisionar o desenvolvimento da solução. Mas a parte do trabalho e a
preparação intermediária pode ser a diferença entre o lançamento correto
de um produto para resolver o problema real e o desenrolar da trajetória
antes mesmo do início da construção.
201
A definição clara do problema e dos requisitos por meio de
documentação bem organizada, conforme descrito neste capítulo, é uma
maneira de preparar adequadamente sua equipe. Considere complementar
sua documentação com uma imersão experimental com sua equipe.
Uma imersão experimental é simplesmente encontrar uma experiência

do mundo real que a sua equipe possa atravessar em conjunto, permitindo
que todos vivam realmente o problema pelo qual você está resolvendo.
Mesmo que os membros de sua equipe geralmente não sejam seu mercado-
alvo e não sejam para quem você está projetando sua solução, todos vocês
devem se tornar atores de método e viver como se vocês fossem.
No caso da Moover, sua equipe pode se tornar uma empresa de

mudanças por um dia. Configure um departamento simulado para sua
empresa de mudanças. Atribua papéis a pessoas diferentes, incluindo
aqueles que fazem o papel do cliente. Passe algumas horas fazendo o
tipo de trabalho de área administrativa que você possa imaginar em
uma empresa de mudanças para os clientes da Moover. Se a equipe da
Moover passasse por essa imersão experimental, eles poderiam começar
a entender ainda mais por que o problema para o qual estão resolvendo
precisa, de fato, ser resolvido. Ou, ainda melhor, poderia levantar questões
sérias sobre se alguma das suas principais suposições sobre o problema
pelo qual você está resolvendo deve ser reconsiderada.
Como fazer isso?
1. Em equipe, escolha o problema central para o qual você acha que

está resolvendo.
2. Identifique uma persona de cliente que tenha esse problema com
frequência.
3. Crie um cenário em que sua equipe possa “agir” e simular, na
202 verdade, o cliente que está enfrentando o problema.
4. Permita que sua equipe viva esse problema por um tempo - pelo
THE PRODUCT BOOK
menos por duas horas.

5. Discuta em equipe como foi a sensação de viver o problema e se
alguma de suas principais premissas foi ainda mais validada ou
precisa ser corrigida.
DOCUMENTOS DA MOOVER.IO
Depois de validar a ideia que surgiu no Capítulo 3, de que a Moover deve
adicionar mensagens no aplicativo para que os clientes não precisem ficar
presos em longas chamadas com as empresas de mudanças, definiremos
nossas ideias com clareza. Faremos isso escrevendo um comunicado
de imprensa imaginário, trabalhando em uma lista de MVPs e depois

escrevendo o PRD.
Exemplo de Comunicado à Imprensa
Siga Sua Programação Com a Atualização Mais Recente da Moover

O principal serviço de mudanças baseado em aplicativo agora oferece
fácil comunicação no aplicativo com empresas de mudanças.
Moover, o aplicativo para iPhone que traz as empresas de mudanças
para a era do smartphone, se orgulha de lançar sua última atualização. Esta
203
atualização elimina a necessidade de trocar chamadas telefônicas e e-mails
com empresas de mudanças, digitalizando completamente a experiência
de mudança. Em vez de agendar um telefonema e enviar fotos por e-mail
de volta, com a Moover, você pode enviar uma mensagem para cada
empresa em movimento, lidando com perguntas e contratos conforme sua
conveniência para concluir o planejamento da sua mudança. Desde o seu
lançamento há seis meses, a Moover transformou as mudanças urbanas.
Em vez de procurar empresas de mudanças, ligar para elas e lidar com
um jogo irritante de ligações telefônicas apenas para obter uma cotação
precisa, a Moover leva as empresas de mudanças até você. Insira alguns
detalhes sobre sua casa e quando você deseja se mudar, e as empresas de
mudanças competirão para tê-lo como cliente, com cotações exibidas no
próprio aplicativo. A atualização mais recente simplifica o processo ao
fornecer mensagens no aplicativo para cada empresa de mudanças, para
que você possa compartilhar fotos e abordar as características exclusivas
da sua casa. Esse novo recurso garante a responsabilidade e permite que
a Moover garanta que a cotação que você receber será, de fato, o preço
que você pagará.
A Product Manager, Ana Souza, acredita que “as mensagens no
aplicativo são a maior vitória para os clientes desde que lançamos a
Moover. Isso significa que você pode fornecer respostas para as perguntas
da empresa de mudanças quando estiver em casa à noite, pensando sobre
a mudança, em vez de ter que se esforçar durante o dia para ligar para a
companhia de mudanças no trabalho entre as reuniões”.
O mais novo cliente, Luiz da Silva, experimentou uma versão de pré-
lançamento das mensagens e "começou a planejar a sua mudança às 11
da noite, enviou fotos do apartamento dois dias depois às 2 da manhã e
mudou-se no próximo fim de semana". Ele passou a compartilhar: "Esta
é a terceira vez que me mudei, e embora eu tenha mais móveis agora do
que nunca, esta foi a primeira mudança livre de problemas que eu já tive”.
204
Baixe Moover na App Store hoje para começar a planejar sua primeira
THE PRODUCT BOOK
mudança livre de problemas.
Exemplo da Lista de MVPs:

Meta: Adicione recurso de mensagens ao aplicativo para que os clientes
fiquem no aplicativo e não precisem trocar telefonemas/ e-mails com uma
empresa de mudanças para obter uma cotação ou concluir uma mudança.
Requisitos do MVP
• Iniciar uma conversa com a outra parte para que eu possa abordar
as perguntas para fornecer uma cotação mais precisa ou finalizar
os detalhes da mudança.
• Ver quando há novas mensagens para que eu saiba que tenho
informações para lidar.
• Responder a mensagens para manter um segmento em andamento.
Recursos que Removemos do MVP da Moover

• Envio de documentos como fotos, vídeos e PDFs como anexos
para ajudar ainda mais a evitar e-mails durante uma comunicação
ilustrativa.

• Ver um histórico de todas as comunicações/ anexos com cada
empresa para prestação de contas e referência.
Exemplo de PRD
Veja como é a primeira versão de um PRD para o nosso recurso de
mensagens da Moover. Observe como chamamos um MVP com nossa
lista de recursos priorizados no PRD, e definitivamente é um MVP
desconfortável. No entanto, o PRD não fala apenas sobre os recursos do
MVP. Ele fala sobre uma variedade de recursos para fornecer uma visão
completa do produto e como o Product Manager espera que os clientes 205
usem todos os recursos juntos. Recursos não-MVP têm apenas uma
prioridade menor na lista de requisitos.
Como Product Manager, você realmente espera que a equipe

de Engenharia possa fazer alguns dos recursos de prioridade mais
baixa para tornar o recurso de mensagens geral mais funcionalmente
completo. Mas, desde que você tenha os recursos de maior prioridade,
todas as pessoas serão capazes de atingir seus objetivos, mesmo que seja
necessário um pouco mais de trabalho do que se todos os recursos fossem
implementados. Isso também lhe dá flexibilidade para liberar apenas a
versão do MVP, obter avaliação e, em seguida, ajustar o que você estará
fazendo em seguida, em vez de criar toda a lista de recursos do PRD antes
de considerar o lançamento do produto pronto.
Título
Aplicativo de Mensagens
Histórico de Alterações
Primeira versão
Visão geral
Nossa missão é ser o Uber das empresas de mudanças, tornando
conveniente registrar uma mudança em seu smartphone. Fizemos um
excelente trabalho ao trazer a primeira parte da mudança para a ponta
de seus dedos, encontrar fornecedores e receber cotações iniciais difíceis,
mas descobrimos que há uma segunda parte.
Apesar de usar a Moover, nossos clientes ainda precisam falar ao
telefone para descobrir detalhes, obter cotações exatas e finalizar seus
processos de mudança. Isto significa que a preparação da mudança ainda
206
deve ocorrer de 9am a 5pm. Vamos trazer a segunda parte do processo de
mudança para a era do smartphone adicionando mensagens no aplicativo.
THE PRODUCT BOOK
Isso fará com que seja conveniente para as empresas de mudanças e seus
clientes interagirem para planejar os detalhes, permitindo que a empresa
de mudanças envie mensagens de 9am a 5pm e que o cliente responda
quando for conveniente.
Objetivos
• Melhorar a satisfação do cliente, continuando a reduzir o
incômodo do processo de mudanças.
• Aumentar a renda ao completar mais mudanças.
• Métricas de sucesso
• Melhorar o número de mudanças concluídas por uma margem
significativa. [??? Qual é o nosso objetivo preciso? 10%?]
• Mensagens
• Mudanças que sigam a sua agenda [???]
Planejamento de Cronograma / Lançamento
O verão é uma época popular para se mudar, então queremos ter
pelo menos o MVP feito até maio. Isto nos dá cerca de oito semanas.
Idealmente, lançaremos o MVP até abril, para que tenhamos uma
iteração ou dois dos recursos no momento em que a temporada de
mudança realmente começar.

Personas
Nosso alvo principal é a Ant Moving, nossa empresa de mudanças de
tamanho médio. Eles são os que terão que pedir mais informações, por
isso precisamos facilitar isso para que eles não precisem usar o telefone.
O Beto Realmente-Ocupado é o nosso segundo alvo, a nossa persona que
não se importa em pagar caro para usar os serviços de aplicativos nos
serviços tradicionais. Precisamos fornecer um sistema de mensagens/
notificação intuitivo para que ele não precise procurar uma página de
207
ajuda sobre como falar com a empresa de mudanças.
Cenários do Usuário
A Ant Responde uma Cotação

Luísa é gerente de escritório na Ant Moving. A Ant Moving se inscreveu
na Moover assim que ela se tornou disponível, e deu à empresa um bom
impacto em seus negócios: a Moover está promovendo a Ant para clientes
em potencial, sem que a Ant tivesse que fazer mais nada. Luísa está feliz
com a Moover e está disposta a ser a primeira a adotar novos recursos
para ajudar a empresa a continuar crescendo.
Atualmente, Luísa recebe um e-mail da Moover quando há uma nova

solicitação de cotação. O email contém as informações básicas para a
cotação e um link para o painel da rede da Moover. Quando Luísa clica
no link, ela é direcionada para um site que permite que ela responda
a cotação, veja seu status: sem resposta, cotação enviada ou aceitação/
rejeição do cliente. Ela pode vincular de volta a uma lista principal de
todas as solicitações de cotações recebidas e o status de cada uma.
Se o cliente aceitar a cotação, Luísa receberá as informações de contato

do cliente e poderá ligar para ele para finalizar os detalhes e fornecer uma
cotação mais precisa. Embora as cotações de Luísa sejam muito boas,
às vezes, algo inesperado acontece. A Moover tem o padrão de quantos
degraus existem em cada local, mas não leva em conta as escadarias
apertadas nas quais você não pode passar com móveis, por exemplo.
Agora, com a versão mais recente da Moover, quando Luísa recebe

uma solicitação de cotação, ela ainda examina as informações básicas
e clica em um link para abrir o painel. No entanto, há um novo grupo
208 na página do cliente com informações sobre mensagens. Desde que
ela percebeu que o cliente disse que ele tem escadas dentro da unidade
THE PRODUCT BOOK
atual, Luísa usa a ferramenta de mensagens para perguntar ao cliente se

ele poderia tirar uma foto da escadaria e dos quartos no andar de cima,
com os móveis dentro deles, para que Luísa possa procurar quaisquer
problemas potenciais.
Beto é o cliente que reserva a mudança. Ele recebe uma notificação de

que há uma nova pergunta esperando por ele na Moover. Ele verifica e
cria um lembrete para tirar fotos quando estiver em casa naquela noite.
Em casa, Beto tira as fotos solicitadas e as envia para a Ant.
No dia seguinte, Luísa recebe um email de Beto, pela Moover, com

as informações solicitadas. A escadaria parece bem grande, sem curvas
fechadas, e não há móveis desagradáveis no andar de cima que possam
causar problemas. Luísa decide sua cotação, fornece ao Beto através do
painel e passa para o próximo cliente em potencial. Ser gerente de uma
empresa de mudanças mantém Luísa ocupada! Mas ela está contente que
o novo recurso de mensagens da Moover permite que ela também não
tenha que fazer longas ligações para os clientes!

A Moover arquiva a conversa para que, mais tarde, Beto aceite a
cotação e, se precisar fazer referência a suas fotos, ele pode consultá-las
na página do cliente no painel da rede. Além disso, Luísa pode continuar
a conversa com Beto, já que ele aceitou a cotação, finalizando todos os
detalhes. Se ele tivesse rejeitado a cotação da Ant, Luísa poderia ver a
conversa anterior, mas não poderia iniciar uma nova conversa. Embora
isto signifique que ela não possa abordá-lo mais tarde e oferecer um
cupom, também fornece um incentivo para que ela sempre dê ao Beto o
seu melhor preço.
209
Beto Responde às Questões da Ant e Pede à Ant Mais
Informações Sobre Seguros
Morando bem no centro de uma Metrópole, Beto adora serviços de

aplicativos. Ele usa Lyft para se locomover, Rinse para lavar suas roupas, e
muito mais. Ele está prestes a mudar de apartamento no centro da cidade
e está experimentando a Moover pela primeira vez.
Depois de baixar a Moover e responder a algumas perguntas sobre
seu antigo e novo endereço, ele se senta e espera receber as cotações. No
dia seguinte, ele recebe uma notificação da Ant Moving pedindo para ver
fotos de sua escadaria e quartos no andar de cima. Sem problemas - ele
tira as fotos naquela noite e as envia para a Ant. A Ant lhe dá uma cotação
e parece bom.
No entanto, naquela tarde, ele recebe um e-mail de seu locador, o
lembrando de que as empresas de mudanças precisam atender a um
requisito mínimo de seguro para cumprir as regras da associação de
proprietários de imóveis (HOA) e fornecer uma cópia do certificado de
seguro, caso se trate de uma empresa de mudanças aprovada pela HOA.
Caramba! A Ant não está na lista aprovada, mas sua cotação é metade do
valor das empresas aprovadas pela HOA.
Beto acessa a seção "Abrir Cotações" em seu aplicativo e envia uma
nova mensagem para a Ant. Ele fornece a eles os requisitos, pergunta se
eles os encontram e pergunta se eles estariam dispostos a fornecer uma
cópia de suas informações de seguro para a HOA, em caso afirmativo.
Luísa da Ant recebe a nova notificação de mensagem e está preparada.
Ela recebeu essa solicitação de outros clientes. Ela checa duas vezes os
números, Ant atende-os e responde com aquela confirmação.
Como ela já tem uma cópia do seguro da Ant como PDF, ela também
envia isto ao Beto. Beto recebe uma notificação sobre esta resposta, e
210 quando ele verifica, ele vê que tudo parece bem. Ele ainda pode abrir e
salvar o anexo em PDF. Ele aceita a cotação e envia o PDF do seguro para
THE PRODUCT BOOK
seu locador e HOA do prédio para iniciar o processo de mudança.

Luísa prontamente lhe envia o PDF do contrato. Ele o salva e assina
usando um aplicativo PDF em seu telefone e envia o contrato completo
de volta para o recurso de anexo de mensagem de Luísa pelo recurso da
Moover. Beto está empolgado com o fato de que essa cotação acabou se
tornando real e foi fácil de organizar com um ótimo preço, graças à Moover.
Histórias do Usuário/ Recursos/ Requisitos

• P0: O produto mínimo viável.
• P1: Prioridade média.
• P2: Baixa prioridade.
P0
Painel da Web
• Como a empresa Ant Moving, quero iniciar uma conversa com
um cliente em potencial para que eu possa fazer perguntas para
fornecer uma cotação mais precisa ou finalizar os detalhes da

mudança.
• Como a empresa Ant Moving, quero ver que há uma mensagem
pendente para que eu saiba que preciso responder a um cliente
em potencial.
• Como a empresa Ant Moving, quero ler mensagens para saber o
que um cliente pediu / enviou.
• Como a empresa Ant Moving, quero responder a uma pergunta
para que eu possa fazer perguntas de acompanhamento e enviar
respostas.
211
Aplicativo Móvel
• Como o Beto Realmente-Ocupado, quero receber uma notificação
de uma nova mensagem/ resposta para que eu saiba que há uma
mensagem pendente.
• Como Beto Realmente-Ocupado, eu quero poder ler uma nova
mensagem para que eu saiba qual é a pergunta ou resposta.
• Como Beto Realmente-Ocupado, quero criar uma nova
mensagem para que eu possa enviar mensagens e respostas para
cada empresa de mudanças.
P1
Painel da Web
• Como a empresa Ant Moving, quero ver meu histórico de
conversas com cada cliente separadamente para que eu possa
lembrar facilmente o que falei com cada cliente.
• Como a empresa Ant Moving, quero receber notificações por
e-mail de mensagens pendentes para que eu não precise fazer
login no painel para saber que um cliente acabou de me enviar
um e-mail.
Aplicativo Móvel
• Como Beto Realmente-Ocupado, quero ver meu histórico de
conversas com cada empresa para que eu possa lembrar quais
detalhes eu discuti com cada uma delas e encontrar meu contrato
para assinar quando for conveniente.
P2
Painel da Web
• Como a empresa Ant Moving, quero ver e salvar anexos para que
212 eu possa ver as fotos que um cliente tirou de seu espaço ou ver um
contrato assinado.
THE PRODUCT BOOK
• Como a empresa Ant Moving, quero responder a uma pergunta

com meus próprios anexos para que eu possa enviar imagens
anotadas para solicitar medições ou enviar contratos.
• Como a empresa Ant Moving, quero ver anexos no meu histórico
de conversas para que não seja necessário salvar e organizar
manualmente todos os anexos enviados por um cliente.
Aplicativo Móvel
• Como Beto Realmente-Ocupado, quero enviar anexos para que
eu possa enviar rapidamente uma foto do meu espaço, entre
outras coisas, em vez de tentar descrevê-lo, além de retornar os
contratos assinados.
• Como Beto Realmente-Ocupado, eu quero receber anexos (JPEG,
PDF) para que eu possa fornecer respostas mais específicas e lidar
com o contrato da mudança no aplicativo.
Recursos Removidos
• Suporte de armazenamento em nuvem para anexos: Embora
seja interessante salvar um contrato na nuvem, abrir/ assinar

em outra máquina e enviar o contrato concluído via Moover, há
vários sistemas de armazenamento em nuvem possíveis para que
possamos dar suporte para nossos clientes (Dropbox, iCloud,
Google Drive, One Drive, etc.). Além disso, se os clientes quiserem
isso apenas para contratos, devemos explorar o fornecimento de
um contrato de mudanças padrão que pode ser criado no painel e
assinado no aplicativo, sem necessidade de anexos.
Modelos
Nenhum ainda! 213
Problemas Pendentes
• É preciso descobrir o objetivo exato da métrica de sucesso
• É preciso descobrir as mensagens exatas do produto, especialmente
para os clientes existentes que poderiam se beneficiar do sistema
de mensagens agora
Perguntas e Respostas
Nenhuma ainda!
Outras Considerações
Nenhuma ainda!
CAPÍTULO SEIS
TRABALHANDO COM DESIGN
214 Até agora, você é responsável por cada etapa do ciclo de vida do design
do produto. Você encontrou e validou uma oportunidade, comunicou-a
THE PRODUCT BOOK
às partes interessadas e colocou todos a bordo. Agora, passaremos para

a fase de execução, que começa por descobrir a experiência de usuário
do produto com a equipe de design. Deve-se pensar muito nesta fase
para estarmos seguros de que produzimos um ótimo produto! Dito de
outra forma, agora que descobrimos que estamos construindo uma casa,
precisamos elaborar esquemas e esboços, para descobrir tudo, desde
onde os banheiros ficarão, até que espessura uma parede precisa ser para
sustentar o teto, e como queremos decorar.
O QUE SERIA O DESIGN DE EXPERIÊNCIA DO USUÁRIO?

Simplificando, o design de experiência do usuário (UX) é sobre como
interagimos e engajamos com o produto. Porque construir produtos
é fundamentalmente tornar uma experiência nova ou melhorar a
experiência existente, uma boa experiência do usuário é essencial para
um ótimo produto. Isso inclui tudo, desde a caixa - se houver - para o
produto, até como um cliente alcança seus objetivos dentro do produto,
até o toque e a aparência do produto.
Existem duas abordagens principais para o design. A primeira é que
6. Trabalhando com Design

o cliente deve se adaptar ao produto, e a segunda é que o produto deve
funcionar de maneira que o usuário espera/ entenda. Por muito tempo,
UX ficou em segundo plano na engenharia. Como os engenheiros que
construíram o produto também eram responsáveis pelo projeto, o UX
representava diretamente como o produto funcionava internamente.
Nesses casos, se houvesse uma equipe de design, ela seria relegada a criar
ícones legais para a interface criada pela equipe de engenharia. É por isso
que muitas pessoas pensam que design é apenas fazer algo parecer bonito.
As pessoas são adaptáveis e essa abordagem funcionou - e continua 215

a funcionar - muito bem para muitos produtos, mas o resultado é um
produto que a maioria das pessoas não quer usar. A Figura 6-1 mostra um
aplicativo no qual o UX corresponde à engenharia. Cada campo e opção
no UX mapeia diretamente para os componentes internos do software, e
o resultado é uma confusão total. Com algum tempo e esforço (e listas de
macetes), todos nós poderíamos descobrir como usar este produto, mas
muito poucos de nós iriam realmente querer usá-lo.
Nos últimos anos, o segundo tipo de design, chamado de design

centrado no usuário, se tornou muito mais popular, e é nisso que vamos
nos concentrar. Nesse tipo de design, o UX do produto é uma solução
bem pensada para ajudar o usuário final a alcançar efetivamente seu
objetivo usando o produto. Compare o design do iPhone original para o
Blackberry e outros smartphones da época, por exemplo.
Figura 6-1. O UX deste app é uma representação visual de seu interior e os resultados não
são bonitos!
216
De muitas maneiras, o iPod e o iPhone da Apple são responsáveis pela
THE PRODUCT BOOK
alteração da prioridade de design. O Mac OS colocou o design à frente

e no centro por anos, sempre tentando criar uma ótima experiência,
construindo assim uma base de clientes fiéis. Mas sua participação de
mercado era tão pequena que a maioria das pessoas nunca teve a chance
de apreciar a diferença que uma boa experiência de usuário fazia - o design
de software no Windows tendia a refletir como as coisas funcionavam
internamente. Quando o iPod foi lançado, sua funcionalidade era a
mesma de muitos outros tocadores de MP3, mas sua experiência geral,
desde colocar música nele até encontrar e tocar a música que você
queria, foi tão grande que esmagou a concorrência (A Figura 6-2 mostra
a concorrência original do iPod.). O iPhone deu um grande impulso
quanto a uma experiência de toque incrivelmente intuitiva. Até mesmo
crianças podem usar o iOS. Os relatórios de ganhos da Apple mostram o
resultado desse foco no design centrado no usuário.
Figura 6-2. O Nomad Jukebox da Creative tinha um disco rígido de 6 GB comparado aos 5 217
GB do iPod, mas você consegue adivinhar como selecionaria uma música? A experiência do
usuário é importante!
À medida que as pessoas usavam o iPod, o iPhone e outros produtos

com um excelente design centrado no usuário, eles perceberam o quanto
os produtos eram mais fáceis de usar, permitindo que atingissem seus
objetivos - desde ouvir música até verificar o correio de voz - mais
rapidamente. As pessoas começaram a querer grandes experiências em
todos os seus produtos, seja software de RH ou um termostato. Quando se
deparam com dois produtos que resolvem um problema, eles geralmente
escolhem o que foi melhor projetado. O Slack, por exemplo, tem visto um
crescimento exponencial, pegando um produto que existe há anos - bate-
papo em grupo - e criando uma UX muito melhor em torno dele. Essa
tendência levou a equipes de design muito maiores e tornou o design
uma parte integral do ciclo de vida de desenvolvimento de produtos, em
vez de uma reflexão tardia.
No Capítulo 2, quando discutimos software de empresa versus
software de consumidor, mencionamos que por muito tempo o design
de UX importava muito pouco, especialmente em produtos corporativos.
Enquanto o produto resolvesse um problema, os clientes se adaptariam
e aprenderiam como usá-lo. Mas, à medida que as pessoas começaram a
experimentar uma experiência de usuário bem projetada nos produtos
de consumo que usavam em casa, queriam experiências melhores
no trabalho. Isso levou a uma interrupção significativa no software
corporativo recentemente, com ferramentas novas e bem projetadas,
como o Basecamp, substituindo ferramentas tradicionais e de grande
porte, como o Microsoft SharePoint.
Então, o que acontece com uma ótima experiência centrada no usuário?

Em um alto nível, os designers de UX precisam entender os clientes,
ter ideias sobre como atender às necessidades deles, ajudar a definir
218 os requisitos da solução e criar uma especificação que eles trabalhem
diretamente com a Engenharia para criar. Isso deve soar semelhante ao
THE PRODUCT BOOK
papel de um Product Manager, e é absolutamente semelhante. Na verdade,

é por isso que algumas empresas recém-criadas não contratam um PM -
acham que um designer de UX pode fazer tudo isso - ou, inversamente,
uma empresa recém criada deseja que um PM lide com tarefas de design.
No entanto, a diferença está nos detalhes e, embora os papéis sejam
complementares, eles realmente precisam de habilidades diferentes!
Product Managers vs. Designers

Para usar uma analogia, um PM é como o típico presidente dos Estados
Unidos e o designer principal é como o típico secretário de Estado. Isso se
encaixa muito bem com a afirmação de Guy Kawasaki de que um Product
Manager tem “toda a responsabilidade e nenhum poder”. O presidente
definirá metas políticas e fornecerá razões pelas quais ele escolheu essas
metas, mas cabe ao secretário de Estado elaborar os detalhes de alcançar
os objetivos. A secretária de Estado também fará recomendações ao
presidente para ajudá-lo a tomar boas decisões e elaborar objetivos úteis.
Essencialmente, o presidente se concentra na estratégia e não na tática,

e a secretária de Estado é tática. O presidente trabalha com pessoas além

da secretária de Estado, seja ele o secretário de educação ou o Congresso -
ele precisa manter uma visão ampla todos os dias! E, embora a secretária
de Estado não seja responsável pela educação, ela ainda deve ter algum
conhecimento das metas do presidente para a secretaria de educação - ela
não pode simplesmente trabalhar paralelamente.
O Product Manager possui e grava os requisitos e metas do produto.

Ele vai liderar o documento de requisitos do produto (PRD), roteiro,
comunicação entre equipes e, às vezes, até mesmo o orçamento para
ajudar a construir o produto. O chefe de designer será o proprietário da 219
estratégia de experiência do usuário: qual UX queremos criar, a curto e a
longo prazo, para ajudar a oferecer a melhor experiência geral do produto?
No entanto, o chefe de designer provavelmente também fará pesquisas
com usuários e apresentará requisitos. Sua pesquisa pode ajudar o PM a
descobrir quais são os requisitos finais do produto, e o design também será
tático e determinará como atender a esses requisitos. Como o presidente
típico, o gerente de projetos trabalha com frequência com cada equipe,
não apenas com o chefe de designer, para conduzir o produto, para que
o gerente de projetos tenha que equilibrar as necessidades de todos. E
um bom chefe de designer terá uma compreensão básica do contexto
de negócios do produto para que ele não trabalhe em um vácuo e possa
ajudar o Product Manager a entender as compensações para decisões de
design diferentes.
O PROCESSO DE DESIGN E AS HABILIDADES CHAVE DE
DESIGN
O processo de design geralmente se divide em seis fases primárias:
1. Pesquisa de usuário
2. Arquitetura de Informação
3. Design de interação
4. Prototipagem
5. Design Visual
6. Estratégia de Conteúdo
Cada fase requer uma habilidade dominante diferente. Embora algumas

dessas habilidades sejam complementares, você raramente encontra
uma pessoa excelente em todas as etapas do processo de design. Isso
significa que você geralmente tem uma equipe de projeto com pessoas
220
diferentes especializadas em cada elemento tático ou alguma combinação
de elementos.
THE PRODUCT BOOK
Durante cada fase, você avaliará o trabalho que a equipe de projeto

criar, responderá perguntas sobre os requisitos do projeto e necessidades
de clientes/ negócios para a equipe de projeto, facilitará a comunicação
necessária com o chefe de engenharia e outras partes interessadas. Uma
maneira de ajudar a manter as coisas em movimento é ter uma reunião
de design / engenharia / produto recorrente a cada semana para o projeto,
mas deixar claro que você está sempre disponível para responder a
perguntas que a equipe de design tem além dessas reuniões.
Vejamos mais o típico processo de design e os tipos de designers que

você encontrará. O processo de design começa antes de você escrever
o PRD, enquanto trabalha com o designer-chefe e um pesquisador de
usuários, se não for a mesma pessoa, para descobrir a estratégia e o
escopo certos de sua oportunidade. Assim como um Product Manager,
um pesquisador de usuário está focado em entender o cliente, quais são
suas necessidades e objetivos, o que ele está usando agora para atender
a essas necessidades e o que podemos fazer para melhorar sua vida. O
designer-chefe e um pesquisador de usuários geralmente o acompanham

a entrevistas com clientes, e você trabalhará em conjunto para descobrir
o valor do usuário que deseja entregar, os objetivos de negócios a serem
focados e os recursos/ funcionalidades necessários para atingir essas
metas e entregar o valor. Eles provavelmente terão uma contribuição
valiosa para o seu PRD e, como mencionamos no Capítulo 5, usam essa
entrada de forma construtiva.
Pesquisadores de usuários também ajudam nos testes de usuários.

Isto é, mais tarde, no processo de design, uma vez que você construiu
um protótipo, o teste do usuário irá ajudá-lo a aprender como o cliente 221
realiza as principais tarefas usando seu protótipo.
THE PRODUCT BOOK
222
HOMEPAGE
PERFIL SOLICITAÇOES PROPOSTAS MENSAGENS CONFIGURAÇÕES
Informações da
Localização Oferta Todos Editar perfil
Conta
Informação de Mensagens
Data Detalhes Modificar senha
Pagamento não lidas
Informação de Dimensão do
Resenhas Marcados Contato
Contato agregado familiar
Requisitos Adicionais Contato Enviados Relatório
Selecionar
Figura 6-3. É assim que um diagrama IA para mensagens da Moover pode ser.
Depois de descobrir o que construir com a ajuda de um pesquisador
de usuários, um designer de arquitetura da informação (AI) descobrirá
como modelar e organizar os dados com os quais estamos trabalhando.
AI é muito mais uma etapa de estrutura, perguntando quais informações
um usuário deve ver primeiro, segundo e assim por diante. O AI pode
criar um modelo de dados, explicando como o produto subjacente será

conceitualmente apresentado ao cliente, juntamente com diagramas
de bloco que expressam em que ordem apresentar as informações. A
Figura 6-3 mostra um diagrama de AI como exemplo para o recurso de
mensagens da Moover.
Os designers de interação, então, pegam a arquitetura da informação
e descobrem como apresentá-la no produto. São eles que se concentram
em como um cliente navega pelo produto, que controles de interface do
usuário você usa (por exemplo, você deve usar um controle deslizante
ou um campo de texto?), Quantos passos são necessários para realizar
tarefas comuns e muito mais. Como a habilidade implica, eles são 223
realmente focados em como você usa o produto. É muito comum
encontrar designers especializados em AI e design de interação. Esta é
também a etapa em que o chefe de engenharia começará a se envolver,
fornecendo à equipe de projeto uma avaliação sobre a viabilidade técnica
de seus projetos.
A entrega mais comum desta fase é um conjunto de wireframes. Esses
são diagramas de blocos aproximados que mostram como um usuário
interagirá com seu produto, como vemos na Figura 6-4 para a Moover.
Estamos mostrando apenas um modelo de wireframe, mas normalmente
você tem uma série que representa várias visualizações e interações
importantes. Os wireframes ajudam a visualizar onde seus clientes
encontrarão várias informações, como navegarão pelo seu produto e
muito mais. Os wireframes não são interativos e podem até ser esboços
no papel, e não serem recursos digitais.
224
THE PRODUCT BOOK
Figura 6-4. Exemplo de wireframe para o recurso de mensagens da Moover, mostrando uma
das etapas do fluxo de trabalho após passar a revelar as opções disponíveis para uma empresa.
As equipes de projeto costumam ter especialistas em prototipagem

que transformam esses wireframes estáticos em protótipos interativos
usando qualquer coisa de HTML para ferramentas especializadas como
Balsamiq e InVision. Protótipos são incrivelmente úteis por três razões.
Primeiro, eles ajudam a todos que trabalham no produto internamente a
entender o que você está construindo, seja pessoas na equipe direta, seu
chefe ou além. Ter algo visual é mais facilmente compreensível do que
um PRD escrito, e ter algo interativo é ainda melhor. Em segundo lugar,
o protótipo ajuda a equipe de Engenharia a fornecer estimativas mais
precisas de como as peças duras do produto serão construídas. O uso de
um controle de interface do usuário padrão pode levar alguns minutos
para ser implementado, enquanto um controle personalizado da equipe
de design pode levar dias, por exemplo, e todas as equipes terão que
discutir se o controle personalizado vale a pena a compensação de tempo.

225
Figura 6-5. Modelo de exemplo para o recurso de mensagens da Moover, indicando como
uma visualização deve ficar quando terminar
Essa decisão afetará o protótipo. Os protótipos ajudam nos testes de

usabilidade. Após a criação de protótipos, você terá uma ótima ideia
de como o produto fluirá/funcionará, mas não saberá como ele será. O
design visual é o foco em como o produto ficará. Os designers visuais da
sua equipe costumam trabalhar em paralelo com as pessoas que criam
wireframes, estabelecendo a aparência geral do seu produto. Eles criarão
maquetes, como na Figura 6-5, geralmente com base nos wireframes, que
parecem perfeitos em pixels, mas não são funcionais. Essas maquetes são
projetadas para ajudar a equipe geral do produto a avaliar como tudo se
encaixará, e o produto final terá uma aparência semelhante à do modelo.
O design visual é mais do que apenas tornar o aplicativo bonito. Os

designers visuais precisam considerar a usabilidade (por exemplo, a fonte
é grande o suficiente para ler e os botões são grandes o suficiente para
tocar com precisão em um telefone?), emoções (transmitidas através de
cores e ícones) e mensagens de marca consistentes. Os designers visuais
geralmente trabalham com marketing para criar um guia de estilo da
empresa que influencia tudo, desde e-mails de anúncios do cliente até o
site de marketing e o produto real. Às vezes, designers visuais e protótipos
criam um protótipo de alta fidelidade usando a maquete e os wireframes,
226 dando ao protótipo uma aparência mais acabada para ajudá-lo a julgar o
produto com mais eficiência.
THE PRODUCT BOOK
Depois de criar seus wireframes e modelos de exemplo para a

engenharia implementar, um estrategista de conteúdo ajudará a garantir
que seu produto esteja usando a mídia e o texto corretos, por exemplo,
como redigir um alerta. Como o design visual, a estratégia de conteúdo
também se aplica ao marketing e você deseja usar palavras consistentes e
manter um tom consistente, pois estes poderiam diminuir a experiência
geral e confundir seus clientes devido a expectativas desalinhadas se
o aplicativo for muito formal e o site for muito extravagante. Algumas
empresas terão um gerente de cópia responsável por todo o texto, seja no
produto ou em um anúncio.
O principal processo de design é feito quando seus protótipos e
maquetes são validados como uma solução e a equipe de Engenharia
concordou com sua viabilidade. À medida que você entrega os projetos
à Engenharia, provavelmente descobrirá questões sobre como deve se
comportar parte do produto, casos inesperados de bordas que precisam
ser projetadas, novos alertas para os quais você precisa da formulação
adequada e partes do projeto que são de implementações problemáticas.
Sua função principal em todo esse processo será a de facilitador, mas

você também desejará garantir que os primeiros clientes de teste estejam
satisfeitos com os projetos e sejam capazes de alcançar a meta do produto
satisfatoriamente. É provável que você deseje continuar a realizar uma
reunião com as equipes de design e engenharia durante o projeto para
garantir que todos estejam na mesma página e abordem a avaliação
antecipada do usuário e as necessidades adicionais de engenharia. Por
exemplo, se você tiver um prazo para a data de envio, talvez seja necessário
cortar um recurso e alterar parte do design do produto para que o recurso
não pareça estar ausente. Todo o processo de design não está realmente
completo até que o produto seja lançado. 227
Teste de Usabilidade com Protótipos

À medida que sua equipe de projeto constrói um projeto, é útil testar
vários aspectos dele com os clientes, quando possível, para ver se o
projeto é fácil e agradável de usar e garantir que o cliente possa concluir
as tarefas que o teste oferece.
Pesquisadores e protótipos de usuários trabalharão juntos para realizar

este teste. Ferramentas como UserTesting (que permite obter vídeos de
pessoas aleatórias que atendem a critérios específicos executando tarefas
com seu site, aplicativos móveis ou protótipo) e UsabilityHub (que fornece
dados, incluindo mapas de calor, sobre como as pessoas executam tarefas
com seu simulador em diferentes categorias) ajudam a simplificar a tarefa.
O teste de usabilidade é essencial para criar um design centrado
no usuário bem-sucedido, mas não é perfeito. Ele não testa perguntas
como "Este produto é de grande valor para um cliente?" A validação de
hipótese que você fez no Capítulo 4 deve ter respondido a esse tipo de
pergunta. Se você estiver testando isoladamente um novo recurso do
produto principal com um protótipo, o teste de usabilidade não testará
se os clientes existentes conseguem encontrar e usar esse novo recurso.
Também não pode explicar coisas como gosto. Um teste pode revelar
que os clientes são mais bem-sucedidos quando você usa um esquema de
cores laranja e verde para o recurso, mas, a menos que você esteja criando
um produto com tema de abóbora, poderá optar por trocar algum valor
de usabilidade por uma estética melhor.
De vez em quando, até mesmo uma equipe de projeto centrado no

usuário precisa fazer escolhas que pareçam mais como forçar o cliente a
228 se adaptar ao produto, em vez de ser centrado no usuário. Às vezes, isso
ocorre devido a uma limitação interna, como recursos de engenharia ou
THE PRODUCT BOOK
design. Outras vezes, é porque essa escolha está de acordo com a visão
geral e a atitude da empresa, como a Apple não fornecer armazenamento
removível no iPhone.
Uma ótima equipe de design também pensará no futuro e no roteiro,
e isso pode levar a escolhas no produto atual que pareçam estranhas, mas
que serão melhores futuramente, como remover a unidade de disquete e
as portas de série do iMac original.
Embora o teste seja importante, o design é mais uma arte do que uma
ciência. No entanto, isso não significa que você deva enviar um design
inutilizável porque está alinhado com a visão da sua empresa. Se um
cliente não puder usar seu produto para resolver o problema dele ou se
for muito difícil usar seu produto, ele procurará uma solução diferente.
Seu produto deve ser utilizável além de fornecer utilidade!
Assim como você criou uma hipótese de oportunidade e depois
trabalhou para validá-la, o design criará várias possibilidades de UX e, em
seguida, trabalhará para convergir estas no design principal. Assim como
sua hipótese de oportunidade, ideias maiores precisarão de mais trabalho
para validar. Alguns projetos pequenos podem não exigir nenhuma
iteração de design. Se você é responsável pela programação, certifique-se

de incorporar o tempo apropriado para o design ser repetido.
TRABALHANDO COM DESIGN

Embora o produto e o design tenham um relacionamento fantástico,
muitas vezes, eles têm um relacionamento frustrante. Vamos ver por que
isso acontece e ver algumas dicas para ajudá-lo a trabalhar bem com sua
equipe de projeto.
Julgando e Avaliando o Design

Como um PM, você deverá avaliar os projetos e ter opiniões informadas. 229
Embora seja altamente recomendável que você reserve um tempo para
aprender sobre design, ler livros como o seminário de Donald Norman,
O Design do Dia a Dia, é possível ter uma opinião instruída sobre design
sem ser um especialista. Podemos formar essa opinião usando uma
estrutura com critérios específicos e, em seguida, observando como o
design atende a esses elementos.
O critério mais importante que vamos definir é: "Será que esse design
permite que o cliente atinja seu objetivo com o menor atrito possível"?
Quando você olha para um wireframe e imagina o uso do produto passo a
passo ou quando testa um protótipo, você é capaz de realizar as principais
tarefas prometidas pelo produto? O design pede informações irrelevantes
ou exige ações complexas que impeçam você de atingir seus objetivos?
Faça a si mesmo essas perguntas para cada caso de utilização e você
ficará surpreso com o que descobrirá. Em algumas câmeras, por exemplo,
é fácil colocar a bateria ao contrário porque a bateria é um retângulo
sem ranhuras especiais. A única indicação de que você colocou errado é
quando a câmera não liga. Uma mudança de design poderia ter poupado
os usuários do incômodo de colocar as baterias no lugar errado!
Com o software, as informações que os usuários precisam facilmente
estão disponíveis ou estão constantemente tendo que alternar entre
partes do aplicativo para obter os dados necessários? E o processo de
inscrição? Você tem um aplicativo simples que permite aos usuários
interagir imediatamente com o aplicativo ou você faz muitas perguntas
irrelevantes antes de começar a usá-lo?
Para darmos um passo adiante em nossos critérios, vamos recomendar

o uso dos 10 princípios do “bom design” de Dieter Rams. Rams é um
designer bem conhecido, tendo trabalhado principalmente na Braun
ao longo de sua carreira. Seus projetos são altamente considerados, ele
230 influenciou inúmeros designers, incluindo Jony Ive, e seus 10 princípios
são fáceis de entender.
THE PRODUCT BOOK
Um bom design é inovador. A inovação tecnológica está

constantemente criando oportunidades para projetos novos e
inovadores. Isso não significa que você precise reinventar a roda
em todos os projetos. Muitas vezes, existem elementos de design
padrão que farão sentido para o seu produto, como um botão. Mas,
especialmente quando você estiver criando um produto inovador,
vale a pena perguntar se você está inovando com o design ou
aplicando ideias antigas de design a algo novo.
Um bom design torna um produto útil. Queremos que nossos

produtos sejam usados e amados, o que significa que eles precisam
ser úteis. O design tem que tornar o produto funcional, mas também
psicologicamente agradável. O aparelho freio de burro é um ótimo
exemplo de um produto funcional que não agrada psicologicamente,
o que significa que um cliente não vai querer usá-lo.
Um bom design é estético. Citando Rams, “A qualidade estética de

um produto é essencial para sua utilidade, porque os produtos são

usados todos os dias e têm efeito sobre as pessoas e seu bem-estar.
Apenas objetos bem executados podem ser lindos”.
Um bom design torna um produto compreensível. O design

pode ajudar a tornar clara a função pretendida de um produto
e um excelente design torna o produto utilizável sem nenhum
treinamento. Quando não se consegue tornar o produto
compreensível, o cliente, muitas vezes, fica frustrado ao tentar usar
o produto ou lembrar-se de como usá-lo.
231
Um bom design é discreto. Os produtos existem para ajudar
um cliente a ser incrível e atingir um objetivo, e não para serem
reverenciados por si só. Se um design é neutro e restrito, ele
permite que o foco esteja no cliente, em vez de chamar a atenção
para o produto.
Um bom design é honesto. Um produto bem projetado não faz

com que o cliente acredite que ele faz algo que realmente não faz
ou que é algo mais valioso do que realmente é. Pintar o produto na
cor de ouro não o torna tão valioso quanto se ele fosse realmente
feito de ouro.
Um bom design é duradouro. Embora possa ser tentador fazer

algo moderno e na moda, um bom design vai durar, de modo que,
mesmo quando os estilos mudam, o seu produto não vá para o
beleléu.
Um bom design é detalhado até o último detalhe. Você quer

pensar em todos os aspectos para garantir que, independentemente
de como os clientes interajam com o produto, eles tenham uma
ótima experiência.
Um bom design é ecológico. O design pode nos ajudar a preservar

o nosso planeta para as gerações futuras, minimizando os recursos
de que ele precisa, independentemente de estarmos falando de
ciclos de computação que exigem energia ou projeto físico que
precisam de matérias-primas.
Um bom design é o menor design possível. Como diz Rams:

232 “menos, mas melhor”. Ao avaliar um projeto, pergunte-se se é
possível eliminar elementos. Concentre-se em reduzir o design
THE PRODUCT BOOK
ao essencial, já que a pureza e a simplicidade ajudarão a tornar

seus produtos estéticos, compreensíveis, discretos e honestos.
Nem todos os princípios se aplicam a todos os projetos com igual
peso. Ao criar um aplicativo, você provavelmente não se preocupa
tanto com sua natureza duradoura ou ecologicamente correta. Mas
quando um designer lhe dá um wireframe, protótipo ou mock-up
e pergunta o que você pensa, esses critérios oferecem uma maneira
de fornecer feedback preciso e cuidadoso.
Habilidades de Relacionamento com o Design

A maior fonte de conflito é que tanto o produto quanto o design parecem
representar o cliente. Ambos os grupos representam o cliente, apenas
de maneiras diferentes. Como dissemos anteriormente, os PMs têm que
pensar sobre o quadro geral e as necessidades das diferentes equipes,
enquanto o chefe de design será mais tático e focado principalmente em
um ótimo design. Uma maneira útil de pensar sobre a diferença é que os
Product Managers se concentram no cliente ideal, enquanto os designers-
chefes geralmente se concentram no usuário ideal.
Vamos ver um exemplo para entender a diferença. Se você estivesse

projetando um teclado, seu objetivo seria ajudar os usuários a digitar
com rapidez e precisão. A equipe de design criaria uma configuração de
teclado fantástica, e quase certamente não seria a configuração de teclado
mais comum, o QWERTY. O QWERTY provou não ser o design ideal
para digitação rápida ou precisa.
Mas os teclados QWERTY já existem há muito tempo. Eles estão em
todos os lugares, do seu computador ao smartphone, a alguns controles
remotos da TV. Os clientes sabem usá-los para escrever de forma
relativamente rápida e precisa. Um teclado que não seja QWERTY terá
uma curva de aprendizagem potencialmente íngreme, o que significa que 233
os clientes não digitariam com rapidez ou precisão enquanto estivessem
aprendendo a nova configuração.
Embora nossa equipe de design pudesse criar uma nova configuração
de teclado para o usuário ideal cuja meta é digitar com rapidez e precisão,
o cliente ideal provavelmente não o compraria por causa do compromisso
de curto prazo.
Para entender os clientes de maneira abrangente, é útil se concentrar
em suas personas. Além de seus objetivos, que outros fatores estão em
jogo que afetarão o comportamento dos clientes? Em nosso exemplo
de teclado, embora a meta fosse digitar com rapidez e precisão, sua
familiaridade anterior com o QWERTY é um grande fator que afeta
nossas escolhas de produtos.
Às vezes, especialmente com produtos de consumo, é fácil para os
PMs acreditarem que representam a persona-alvo com precisão, mesmo
quando não o fazem.
Esses PMs frequentemente ignoram os detalhes da persona, usando
seu próprio gosto, e não detalhes de personas, para tomar decisões sobre
produtos. Isso pode ser frustrante para os designers, pois pode fazer com
que as decisões do PM pareçam arbitrárias.
Microgerenciar cada projeto de decisão pode causar atrito entre a

equipe de design e o PM também. Os PMs são responsáveis pelo sucesso
ou fracasso do produto, e essa responsabilidade pode fazer com que eles
tentem dizer à equipe de design como projetar o produto. Mencionamos
anteriormente que wireframes, maquetes e protótipos são ótimos porque
são muito mais compreensíveis de imediato que o PRD. Por outro lado,
como o design é tão visível, é fácil ter uma opinião desinformada. Confie
na sua equipe de projeto para tomar decisões inteligentes e use critérios
como os princípios de design de Rams para avaliar se são boas decisões e
para dar opiniões informadas.
234 Então, como você constrói um relacionamento construtivo com a
equipe de design? Um passo simples, mas importante, é conhecer a
THE PRODUCT BOOK
equipe. Construir relacionamentos individuais com as pessoas com quem

você trabalha ajudará a se respeitarem como pessoas e a lidarem com o
conflito de maneira mais produtiva.
Além disso, em nenhuma ordem específica, há uma variedade de coisas

que você pode fazer para ter um ótimo relacionamento com sua equipe
de design. Recomendamos que você aprenda um pouco sobre design, se
você ainda não souber. Você não precisa ser um especialista, mas deve
saber por que acha que um produto é bem projetado ou não. Para software,
aprenda padrões de design comuns e configurações aceitas para funções
como pesquisa, definições e muito mais, especialmente para diferentes
plataformas. Isso o ajudará a aprender a não forçar um aplicativo Android
a se parecer com um aplicativo iOS ou vice-versa, por exemplo.
À medida que você aprende sobre design, concentre-se em desenvolver
uma apreciação do que vai para o design, de modo que, ao ver um
wireframe, você possa fazer boas perguntas sobre por que os designers
fizeram determinadas escolhas e entender a implicação dessas escolhas,
em vez de certas coisas. Palavras como "espaço em branco" e "hierarquia"
devem, eventualmente, fazer parte do seu vocabulário.

Da mesma forma, não ultrapasse seus limites. No PRD, não especifique
o design. Sua tarefa é fornecer requisitos e restrições, além de como você
considerará o problema e permitir que as equipes de design e engenharia
encontrem a solução. Por exemplo, em vez de incorporar as maquetes de
um novo processo de integração, especifique quais dados são necessários
e o que é opcional para um usuário inserir, então deixe o design criar
um wireframe mostrando como inserir esses dados. Mesmo se você
costumava ser um designer incrível, seu trabalho principal como PM é se
concentrar em dar personas, requisitos e objetivos claros. 235
Sua equipe de design vai adorá-lo se você estiver claro sobre esses três
elementos. Essa clareza fará parte de um PRD bem escrito e verdadeiro no
mais alto nível - o objetivo geral do projeto - e com histórias de usuários
individuais.
Em vez de apenas dizer: “Precisamos melhorar o processo de
integração”, diga explicitamente quem são os clientes-alvo, o que você
precisa para o processo de integração e como medir seu sucesso.
Além disso, nunca, nunca diga vagamente que um produto é para
“todo mundo”. Não existe tal pessoa, e nenhum produto é perfeito para
cada pessoa. Em vez disso, certifique-se de que seu mercado-alvo seja uma
parte clara dos requisitos do PRD e que uma persona seja definida para
que o design possa fazer as escolhas certas para atender às necessidades
desta persona.
De vez em quando, você descobrirá que realmente quer esboçar
uma experiência do usuário, pois essa será a maneira mais rápida de
compartilhar seus pensamentos, seja nas conversas iniciais sobre o
produto ou até mesmo em um PRD. Quando se unir a uma nova equipe
pela primeira vez, você precisará trabalhar com outras partes interessadas
e ganhar o respeito delas. Recomendamos que você organize uma sessão
de quadro branco com o chefe de design (e talvez o chefe de engenharia)
para discutir ideias iniciais e aproximadas. Juntos, vocês podem desenhar
em um quadro branco e depois tirar fotos do quadro para incorporar ao
seu PRD ou compartilhar com outras pessoas.
Depois de trabalhar com uma equipe, você geralmente descobrirá que

é bom esboçar um conceito de UX sozinho, em vez de incluir apenas
fotos de quadros brancos, mas é preciso reconhecer e deixar claro para os
outros que esse esboço é apenas para transmitir o que você quer dizer, e
236 não para implicar respostas de design.
A melhor maneira de fazer isso é através de um esboço de guardanapo.
THE PRODUCT BOOK
Um esboço de guardanapo é um desenho de baixa qualidade e criado

rapidamente, como se você desenhasse nas costas de um guardanapo
com uma caneta. Recomendamos o uso de uma ferramenta como o
FiftyThree’s Paper para iPad, em vez de uma ferramenta de prototipagem,
como InVision ou Balsamiq, para todos os esboços UX que você criar.
Isso fará com que seu desenho seja claramente desenhado à mão e forçá-
lo a criar algo não polido, mas oferecerá um desenho digital com uma
boa qualidade de traçado.
À medida que a equipe de design começar a criar ideias usando seu

PRD, trabalhe com eles e outras partes interessadas para discutir os prós e
contras de cada ideia, além de se é um bom design ou não, especialmente
pensando no usuário ideal versus cliente. Além disso, pergunte se a equipe
pensou em todas as implicações do design. Se você estiver projetando
uma rede social e a equipe de design tem um botão de "denúncia" no
design para marcar conteúdo impróprio, o que acontece quando um
cliente pressiona esse botão? Esse botão significa que alguém da equipe
de suporte terá que examinar manualmente o conteúdo e possivelmente
removê-lo? Essa equipe tem recursos para isso?

Todos esses conselhos se acumulam em um ponto-chave: sua tarefa é
fornecer uma comunicação clara entre todas as partes interessadas e, ao
mesmo tempo, manter a meta final - tornar o cliente incrível - na mente
de todos. Você não está aqui para fazer o trabalho das partes interessadas
- você deixou Design / Engenharia / Suporte / etc. para trás para passar
para o Product Management. Você precisa manter todos se movendo em
direção ao seu objetivo.
Há uma ótima história sobre quando o Presidente Kennedy visitou a 237

NASA em 1962. O presidente perguntou a um zelador o que ele estava
fazendo, e o zelador respondeu: “Bem, Sr. Presidente, estou ajudando a
colocar um homem na Lua”. A NASA fez um ótimo trabalho certificando-
se de que todos soubessem para o que estavam trabalhando, e isso ajudou
cada indivíduo a pensar sobre como suas ações afetariam essa meta.
Você pode se sentir como um disco quebrado às vezes, mas se você se
concentrar em manter a meta do seu produto na mente de todos, você
ficará surpreso com a forma como toda a equipe se posiciona para atingir
essa meta.
DICA DO CAPÍTULO SEIS
Conrad Albrecht-Buehler, um designer incrível que também

trabalhou como Product Manager, nos fornece a dica deste capítulo.
Conrad projetou uma interface vencedora de prêmios para a BMW,
projetou alguns dos primeiros aplicativos móveis da VMware e
trabalhou em vários produtos da Apple. Além de designer, ele
trabalhou como engenheiro de software, Product Manager e
pesquisador de usuários. Ele mora em Munique e na Bay Area com
sua esposa, tem dois filhos e um Shiba Inu.
ESTEJA ABERTO E FLEXÍVEL

Aaron Sorkin, que escreveu alguns dos meus programas favoritos de
238 televisão e filmes, disse recentemente que, para muitos episódios do The
West Wing, ele começaria com apenas uma ideia por um momento, e depois
THE PRODUCT BOOK
deixaria a história se desenvolver à medida que a escrevesse. Parafraseando:

ele nem sempre sabia exatamente o que estava escrevendo até o momento
em que o escreveu. Em entrevistas, muitos dos meus autores favoritos e,
sim, até mesmo designers, disseram a mesma coisa. Não é porque eles não
tinham disciplina ou não eram metódicos em seu trabalho, mas as histórias e
os produtos são complexos e, até você se aprofundar na criação de um deles,
grande parte dessa complexidade não é revelada. Por causa disso, como um
PM trabalhando com um designer - seja ele um designer de experiência de
usuário, um pesquisador de usuário ou um designer industrial ou visual -
meu conselho é este: esteja aberto e flexível.
Como um designer trabalha para acomodar os requisitos do produto e da

engenharia (e várias outras fontes descritas nos capítulos anteriores), os
compromissos devem ser feitos em um aspecto ou outro. Seja flexível, ao
invés de autoritário. Não tente forçar uma agenda singular a chamá-la de
"visão". Esteja aberto a compromissos à medida que as complexidades mais
profundas do produto se revelarem. Os melhores designers aprendem
como fazer os melhores compromissos. Mas apenas com a sua ajuda e
com a ajuda de todas as partes interessadas e colaboradores. No entanto,
como o Primeiro Ministro, você pode ter que arbitrar o debate em torno
desses compromissos, e isso é sempre difícil, porque você nunca será um

observador neutro nesses debates.
Os vários lados do debate serão enquadrados em termos de custo versus

benefício. A maioria das partes interessadas verá os custos em termos de
custos financeiros ou custos de tempo - coisas que afetam a empresa e
os funcionários. Os designers verão os custos em termos de impacto
para o usuário. É aí que as coisas saem dos trilhos com mais frequência.
Outra parte interessada afirma: "Sou usuário, e eu gostaria disso". Talvez o
cliente também gostaria, mas é responsabilidade do designer saber como
as pessoas, que não são como o designer, perceberão e interpretarão o
239
produto. Mesmo que todos os participantes do debate afirmem que eles,
como usuários, também estariam de acordo com um compromisso, não os
tratem como a maioria de uma amostra e imagine que o designer que esteja
argumentando por algo mais esteja obviamente equivocado. Esteja aberto
à experiência deles e valorize o tempo que eles passaram tentando entrar
na mente de personas diferentes de si mesmas para ajudá-lo a prever como
um cliente verá, usará e valorizará seu produto. Isto pode ajudá-lo a fazer
o seu melhor, se não sempre o mais oportuno, compromisso ao abordar as
complexidades de um produto.
GOOGLE PROJETA SPRINTS
A Google Ventures criou uma ótima maneira de usar o pensamento de
design para resolver questões críticas de negócios. Ela usou esse processo
com as empresas do seu portfólio para resolver problemas que variam
de "Nosso novo negócio é viável?" a "Como desenvolvemos esse novo
recurso para produtos existentes com milhões de usuários?"
Gostamos de sprints de design porque são colaborativos (envolvendo

os principais interessados de cada departamento), maneiras focadas,
eficazes e centradas no usuário para resolver grandes problemas. Além
disso, como acabamos de passar muito tempo explicando, os PMs, de fato,
precisam manter suas mãos longe do trabalho de design propriamente
dito, mas em um sprint de design você consegue colocar a mão na massa.
Isso pode ser divertido, porque permite que você use sua criatividade, e
isso o ajudará a obter uma apreciação do que sua equipe de design faz no
240
dia a dia.
THE PRODUCT BOOK
Esses sprints normalmente duram uma semana. Você começa a

semana com um desafio específico para resolver e termina a semana
com um design que a equipe concordou e que você validou com clientes
reais. É claro que, de vez em quando, você acaba invalidando o design
e/ ou levantando novas questões, mas depois pode executar outro sprint
usando o que aprendeu. Vamos mergulhar a fundo em como executar um
sprint de design!
Preparação do Sprint
Comece escolhendo um mestre de sprint. Essa pessoa definirá o contexto
para o sprint de design e facilitará cada estágio do sprint. Geralmente é
alguém que está familiarizado com o projeto de pesquisa e interação da
UX, mas essa pessoa também deve ser capaz de liderar uma reunião de
maneira produtiva e fazer com que todos os participantes contribuam.
O mestre de sprint fará um bom planejamento em relação ao conteúdo
e logística antes do sprint para garantir que ele corra bem. O Google
recomenda cerca de um dia de preparação para cada dia do sprint.
Para o planejamento de conteúdo, o mestre de sprint escreverá um

resumo de projeto que define claramente o desafio (o PRD pode ser
uma ótima referência aqui), o produto final e a linha do tempo para o
lançamento. Ele também pode fazer uma auditoria de projeto de antemão,
reunindo os projetos atuais, a pesquisa de usuários e muito mais, para
fornecer contexto à equipe de sprint. Isto é especialmente crítico se a
equipe já tiver trabalhado nesse problema, pois haverá aprendizado
existente a partir do qual você poderá construir.
Quanto a logística do sprint, ela começará determinando a equipe certa
para o sprint. As melhores equipes são de cinco a oito pessoas e incluem o
PM, designers, engenheiros e outros especialistas ou partes interessadas. 241
Às vezes, especialmente em empresas recém-criadas, o CEO fará parte
da equipe de sprint. Também é possível ter várias equipes trabalhando
em paralelo no mesmo desafio. O mestre de sprint até mesmo agendará a
sala e garantirá que ela tenha todos os suprimentos necessários, incluindo
papel, fita adesiva, adesivos, adesivos de votação, cronômetro e canetas.
Entendimento
A primeira parte do sprint é dedicada a entender o problema que você
está tentando resolver, por que você está tentando resolvê-lo, quem são os
clientes, as necessidades e os recursos desses clientes e muito mais. Como
discutimos no Capítulo 2, entender o contexto geral para seus clientes e
empresa/produto é sempre o primeiro passo para criar novas soluções. O
mestre de sprint pode organizar palestras curtas, entrevistas com usuários,
visitas aos clientes, visões gerais competitivas, ou até mais, para facilitar essa
etapa. Se você já fez uma pesquisa anterior ou trabalhou com esse desafio
de sprint, essa etapa é quando você apresentará esse trabalho anterior.
Você, como Product Manager, provavelmente terá um papel
fundamental aqui, ajudando o restante da equipe a entender suas metas
e estratégias.
Durante o primeiro dia do sprint, você também agendará as entrevistas
de teste do cliente para o último dia. Isso colocará pressão na sua equipe,
forçando a criarem algo para mostrar aos clientes, já que pessoas reais
estarão vindo para ver seu trabalho. Afinal, a melhor criatividade acontece
quando você tem exigências!
Definição
Depois que a equipe entender o espaço do problema, crie uma definição
clara do problema. É quando você reduz o problema e apresenta os
principais princípios e metas para ajudá-lo a avaliar sua solução. Você
242 pode definir seus objetivos de design, como criar um produto “divertido
de usar” ou pensar na mensagem e na frase da sua solução, como “mil
THE PRODUCT BOOK
músicas no seu bolso”.
Divergência
Depois que você souber claramente o problema e o que você quer que sua
solução atinja, você e a equipe de sprint farão o debate de ideias com o
maior número possível de ideias sobre como resolver o desafio do sprint.
Você pode fazer com que todos trabalhem individualmente para gerar
ideias tendo como inspiração o “Oito Maluco”, onde você dobra um pedaço
de papel pela metade três vezes, para criar uma página com oito segmentos
e leva cinco minutos para desenhar oito ideias, uma por segmento.
Ou talvez você trabalhe em conjunto para debater idéias. Não rejeite
as ideias de ninguém durante essa fase. Seu objetivo é gerar o máximo
de ideias possíveis, até mesmo as ruins. Na verdade, às vezes, trabalhar
juntos para criar a pior solução possível pode ajudá-lo a pensar em novas
ideias para a melhor solução.
Você não precisa saber desenhar bem para participar da fase de
Divergência. Mas você deve se certificar de que qualquer coisa que você
desenhe ou crie seja compreensível por si só, sem uma explicação do
criador. Não há problema em colocar um texto nos seus desenhos ou usar

vários desenhos para mostrar um fluxo. Dê os títulos dos conceitos para
ajudá-lo a se referir a eles. No entanto, não coloque o nome do criador
em cada um deles. Você não quer que nenhuma política da empresa
influencie quais ideias você escolhe.
Seja louco, seja criativo e não se filtre. Crie ideias, crie ideias, e crie
mais ideias.
Decisão
Quando você tiver várias ideias, você escolherá as melhores, até o
momento, através de votação. 243
Para a primeira rodada de votação, todos recebem um número

ilimitado de adesivos de votação, e você vota em quais idéias, ou partes
de idéias, você gosta mais. Você pode usar muitos adesivos se você
simplesmente adorar algo.
Embora cada ideia deva ser autoexplicativa, passe algum tempo
discutindo cada uma delas. Por exemplo, reserve três minutos para
analisar cada ideia e discuta sobre o que você gosta, o que não gosta, o que
pode dar errado e muito mais. Não deixe que o criador explique a ideia
primeiro, pois ela deve se sustentar sozinha, mas se os outros perderem
um aspecto da ideia, o criador poderá indicá-lo.
Não se preocupe em alcançar consenso durante a primeira rodada

- fale sobre o que você gosta em várias ideias. Depois de discutir cada
ideia, você super-votará. Este é o voto decisório. Cada membro da equipe
receberá um número limitado de adesivos de votação, e o CEO e o PM
receberão adesivos de votação extras. Novamente coloque esses adesivos
ao lado do que você acredita ser a melhor ideia ou parte de uma ideia.
Este processo de votação irá ajudá-lo a descobrir as melhores ideias,
independentemente de quem as criou.
Protótipo
Depois de escolher uma ideia-chave ou duas, crie um protótipo. Construir
este protótipo levará o maior tempo possível, mas você surgirá com uma
maquete, demonstração, protótipo físico ou outra maneira de demonstrar
a ideia que você possa usar para mostrar para pessoas reais.
Você pode acabar tendo vários protótipos para testar o utilitário geral
da solução separadamente da usabilidade ou para testar a usabilidade de
diferentes ideias. A dica nesta etapa é criar algum artefato que o ajude a
244 validar sua solução. Afinal, você mostrará para os clientes em breve!
THE PRODUCT BOOK
Teste de usuário
A etapa final do sprint é mostrar seu protótipo para clientes reais e obter
avaliações. Tente descobrir o que eles gostam e não gostam, se a solução
atenderá às suas necessidades e se há fatores ocultos que poderiam
impedi-los de usar essa solução.
Você também pode pedir avaliação para medir o quão bem você
alcançou as metas estabelecidas na etapa de Definição. Por exemplo, peça
a cada usuário que avalie o quanto foi divertido usar seu produto e o que
o tornou menos divertido.
Certifique-se de validar esta solução com as principais partes interessadas,
incluindo a equipe de engenharia, também, para confirmar que esta é a
solução que todos estão envolvidos e que pode ser implementada.
Quando o teste do usuário terminar e o sprint terminar, reserve um
tempo para revisar o processo e analisar como ele foi. Esses clientes
gostaram da solução ou o design não funcionou? Você precisa fazer outro
sprint? O ideal é que você tenha um design básico que você saiba que
é promissor, e que pode ser feito, desenvolvido e transformado em um
produto real.

Se você gosta dessa abordagem e quer executar seus próprios sprints,
recomendamos muito a leitura do livro do Google Ventures, chamado
Sprint: Como Resolver Grandes Problemas e Testar Novas Ideias em
Apenas Cinco Dias (Sprint: How to Solve Big Problems and Test New
Ideas in Just Five Days). Este livro contém muitas dicas da experiência
do Google Ventures na execução de sprints para ajudá-lo a executar o
melhor sprint possível.
Neste ponto, você deve ter uma ideia do que o design envolve e ver que 245
é mais do que simplesmente deixar algo bonito. Você também deve ter
uma ideia sobre como trabalhar em colaboração com a equipe de design.
Lembre-se, dizemos que o design está feito quando nossos protótipos e
modelos são validados como uma solução para o problema que estamos
tentando resolver, e a Engenharia concordou com a viabilidade dos
projetos. Agora que elaboramos os modelos do nosso produto, vamos
voltar nossa atenção para como trabalharemos com a Engenharia para
desenvolver nosso produto.
CAPÍTULO SETE
TRABALHANDO COM A ENGENHARIA
246 Agora que você definiu os requisitos de seu produto e criou um design,
e com certeza testou, é hora de realmente criar seu produto! Na prática,
THE PRODUCT BOOK
essa fase do ciclo de vida de desenvolvimento de produtos é onde você

passará a maior parte do tempo como Product Manager. Você trabalhará
em estreita colaboração com a equipe de Engenharia no dia a dia para
ajudar a supervisionar o produto que está sendo construído, garantindo
que ele atenda aos requisitos do produto, fazendo alterações no escopo
se os principais recursos estiverem demorando mais do que o esperado,
priorizando o mais importante e eliminando os obstáculos pode para a
equipe de engenharia.
Você vai querer dar o seu melhor ao estabelecer um forte relacionamento

com a equipe de engenharia, pois, embora um ótimo relacionamento não
garanta o sucesso, um relacionamento ruim garante um fracasso.
Embora essa fase possa ser muito divertida à medida que o produto
ganha vida, pode ser muito difícil para os Product Managers por dois
motivos. O primeiro é que, se você começou sua carreira como engenheiro,
pode, sem intenção, frustrar a equipe de engenharia ou sugerir que sabe
7. Trabalhando Com a Engenharia

melhor do que eles. Como alternativa, se você não tiver formação em
engenharia, talvez não entenda como os engenheiros trabalham ou como
trabalhar com eles, fazendo com que eles não o respeitem. Felizmente,
esses problemas são evitáveis! Vamos começar examinando habilidades
sociais e habilidades de relacionamento interpessoal que o ajudarão
a trabalhar com a equipe de engenharia. Em seguida, analisaremos as
formas comuns pelas quais as equipes de engenharia trabalham e veremos
como você, como PM, entra nesses fluxos de trabalho.
RELAÇÕES DE PRODUTOS/ ENGENHARIA

Assim como o design é mais do que apenas criar pixels, a engenharia é
mais do que apenas digitar o código. A programação é muito parecida com 247
uma forma de arte: você está construindo algo do nada e todas as peças
devem funcionar perfeitamente ou todo o produto não funcionará. Essa
complexidade artística leva a alguns traços comuns em engenheiros que
vale a pena conhecer, pois a compreensão dessas características ajudará
sua comunicação interpessoal e seu relacionamento com os engenheiros.
Em geral, os engenheiros são pessoas altamente inteligentes, motivadas
por trabalhar em problemas difíceis e por apoiar algo novo. Eles
costumam ser muito independentes e se preocupam mais em criar uma
solução elegante para um problema complexo do que com necessidades
comerciais específicas. A engenharia é difícil e todo produto precisa de
engenheiros. Dito isto, suas habilidades são incrivelmente procuradas e
engenheiros talentosos valem seu peso em ouro!
No entanto, como suas habilidades são realmente necessárias, se
os engenheiros acharem que não estão sendo respeitados ou que estão
sendo desafiados intelectualmente, ou se não acreditarem no produto
e na direção geral, provavelmente procurarão uma nova oportunidade.
Substituir um engenheiro é muito dispendioso, tanto em termos de custos
reais quanto de produtividade. Os PMs podem ajudar os engenheiros e
a toda a empresa, garantindo que os engenheiros se sintam respeitados,
reconhecidos e tenham confiança no produto.
Então, como você mantém um ótimo relacionamento com a
Engenharia? Você deverá começar do jeito certo, reconhecendo que é
preciso trabalhar! A coisa mais importante que você deve ter em mente
é que a codificação é difícil e você deve confiar que seus engenheiros
conhecem seus ofícios - ao contrário do que alguns projetistas e PMs
pensam, os engenheiros não são apenas macacos adestrados digitando em
teclados. Especialmente se você tem formação em engenharia, uma das
piores coisas a se dizer a um engenheiro é "você não pode simplesmente
...". Essas três palavras indicam que tudo o que o engenheiro está fazendo
248 é fácil e você sabe mais do que ele.
Recomendamos que você visualize o trabalho com a Engenharia
THE PRODUCT BOOK
como uma experiência educacional, tanto para você quanto para eles.
Por exemplo, peça a eles que ajudem a estimar o nível de dificuldade de
uma tarefa. E se a estimativa for maior do que a esperada, pergunte se eles
poderiam explicar o que acontece nessa estimativa e onde estão as partes
complicadas. Isso ajudará você a entender todo o escopo da tarefa e, se
o engenheiro estiver fazendo suposições porque você não considerou
algo, talvez possa decidir limitar o escopo da tarefa e facilitar a vida do
engenheiro. Como um exemplo simples, se você estiver criando um
reprodutor de vídeo, será preciso muito mais trabalho para criar um fluxo
de vídeo 4K de maneira eficiente do que um HD normal. Se fizer sentido,
você pode optar por não oferecer suporte ao reprodutor de conteúdo 4K,
reduzindo assim a carga de trabalho da Engenharia.
Outro grande erro que os PMs cometem com a Engenharia é que
eles não dedicam tempo em conhecer os engenheiros e a melhor forma
de trabalhar com cada pessoa. Alguns engenheiros trabalham melhor
quando têm uma lista de tarefas e não se importam com a imagem mais
ampla ou por que você está fazendo determinadas escolhas. Mas outros

engenheiros ficam frustrados quando você não explica claramente por que
fez determinadas escolhas. Para esses engenheiros, isso faz com que você
pareça um ditador, não um colaborador. Um documento de requisitos
do produto (PRD) bem escrito, como descrevemos no Capítulo 5, pode
ajudar nessas duas situações, pois disponibiliza as informações para os
engenheiros, caso decidam lê-las.
À medida que você continua durante todo o ciclo de desenvolvimento
e tem que tomar decisões difíceis, cortar recursos, etc., certifique-se de
trabalhar com o líder de engenharia e talvez com engenheiros individuais
para entender o lado técnico dessas decisões. Eles são as únicas pessoas
que podem dizer o quão tecnicamente viável é algo e fornecer uma
estimativa de quão difícil será construir. Isso nem sempre significa que 249
a Engenharia só tem más notícias para os PMs. Às vezes, eles até dizem
que algo que você achava impossível é realmente viável! Certifique-se de
anotar as principais decisões, como no PRD ou nas principais histórias
do usuário, ou em requisitos épicos, se você estiver usando de pressão,
para que não haja confusão sobre qual é o estado dessa decisão. Além
disso, mudanças e trocas acontecem em todos os produtos. Os projetos
geralmente atrasam porque muitas coisas pequenas se acumulam, como
quando alguém fica doente por algum tempo, emergências familiares,
dever de júri e muito mais. Se você trabalha em estreita colaboração
com a Engenharia para observar o equilíbrio entre tempo (Quando
estamos planejando fazer isso/ entregar?), qualidade (Podemos assumir
alguma dívida técnica agora?) e dinheiro (Mais pessoas ou horas extras
nos ajudariam a conseguir que o projeto esteja pronto?), você manterá
o processo colaborativo e entregará o produto da mais alta qualidade
possível no melhor horário possível.
Trabalhar em projetos que têm muita dívida técnica também pode
ser muito frustrante para os engenheiros, pois a dívida acumulada pode
tornar o polimento e as correções de erros penosas. Já falamos sobre
como é importante para o ímpeto geral do projeto pagar periodicamente
qualquer dívida técnica. Também é importante fazê-lo periodicamente
para a sanidade de seus engenheiros e seu relacionamento com eles.
Muito do que acontece em um escritório conspira inerentemente
contra os engenheiros. Especificamente, resolver problemas difíceis
requer concentração profunda.
Interrupções, seja para reuniões ou para responder a mensagens de alta
prioridade via e-mail, Slack, HipChat, etc., podem ser muito frustrantes
e difíceis de recuperar mentalmente. Os planos pendentes do escritório
tornam as coisas ainda piores, pois há tantas distrações e tanto barulho
que os desenvolvedores costumam usar fones de ouvido grandes e com
cancelamento de ruído, para que possam se concentrar em seu trabalho.
250 Embora parte disso esteja além do seu controle, como as plantas de
pisos, há algumas coisas que você pode controlar, especialmente em torno
THE PRODUCT BOOK
da comunicação. Faça o que puder para dar tempo à equipe de engenharia

para se concentrar em fazer seu trabalho, mesmo que isso signifique
esperar por uma resposta a uma pergunta. Nem todas as perguntas que
você tem são urgentes, e interromper o fluxo de codificação de alguém
para uma pergunta que não seja crítica nunca é apreciado.
À medida que a Engenharia concluir cada tarefa, certifique-se de
fornecer avaliação, quer seja por eles terem feito um excelente trabalho e
excedido suas expectativas ou se você tiver encontrado um erro ou algo
não está correto. E quando o projeto terminar, certifique-se de que os
engenheiros - e todos os envolvidos - recebam sua parte do crédito para
que o projeto seja concluído. Não roube o crédito - seja humilde!
Para deixar claro, a equipe de engenharia não está acima do PM- você
não precisa da aprovação dos engenheiros em tudo, e eles não são as
pessoas mais importantes da empresa. Mas são eles que estão construindo
o produto e com os quais você gastará muito do seu tempo. Se você fizer
um esforço extra em dar seu melhor para eles e ajudá-los a se sentirem
parte da equipe geral do projeto e não apenas macacos adestrados em

codificar, eles se sentirão mais felizes e respeitados, e o trabalho que eles
fizerem será de melhor qualidade.
Finalmente, não há duas equipes de engenharia iguais. Embora você
deva manter nossos conselhos em mente, às vezes, com as equipes júnior,
você precisa dar um passo a mais e ter certeza de que eles estejam seguindo
as práticas recomendadas. Por exemplo, talvez seja necessário incentivá-
los explicitamente a adicionar mais cobertura de teste automatizada e
reservar um tempo para fazer revisões completas de código.
METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE

Uma metodologia de desenvolvimento é simplesmente um quadro de
trabalho que você usa para estruturar o trabalho para construir o produto. 251
Essas metodologias são realmente mais sobre gerenciamento de projetos,
não apenas como os desenvolvedores escrevem código. Já mencionamos
duas dessas metodologias - cascata e enxuta/ ágil - mas elas têm um
impacto muito profundo na forma como sua equipe de engenharia
trabalha. Vamos abordá-las em detalhes aqui. Vamos nos concentrar em
várias metodologias de desenvolvimento de software, mas muitos dos
mesmos princípios se aplicam ao desenvolvimento de hardware.
Em um extremo do espectro, você tem fluxos de trabalho em que
você, o gerente de projeto, cria uma especificação detalhada e a equipe
de engenharia desaparece por meses - provavelmente mais do que o
previsto - ressurgindo com o produto construído exatamente conforme
especificado. No outro extremo, a equipe de engenharia divide o projeto
nas menores tarefas possíveis, os programadores trabalham em pares no
mesmo computador para concluir uma tarefa e, em seguida, voltam para
ver qual tarefa devem executar em seguida. As tarefas seguintes podem
mudar enquanto os programadores estão trabalhando em sua tarefa atual
e isso não importa para os programadores. Vamos comparar as duas
abordagens mais comuns ao longo deste espectro, cascata e enxuta.
Desenvolvimento "Cascata"
O método cascata é o estilo mais antigo de desenvolvimento de software.
Os primeiros engenheiros de software simplesmente adotaram estágios
do mundo do hardware (fabricação) e, com o tempo, essa abordagem se
tornou cada vez mais refinada. Em 1985, o Departamento de Defesa dos
Estados Unidos formalizou o processo em cascata em seu documento
DOD-STD-2167A, que especificava que seus contratados usariam essa
abordagem para escrever software, além de descrições detalhadas de
como usá-lo e dos resultados dos produtos que eles criariam.
252 Como você pode imaginar, o método cascata é muito estruturado, com
estágios explícitos e formais. Ele é chamado de "cascata", porque você não
THE PRODUCT BOOK
pode passar para o próximo estágio até que o estágio atual seja concluído
- tudo vai de um estágio para o próximo em um grande depósito, como
a água em uma cascata. O desenvolvimento em cascata começa na fase
de requisitos, onde o PM tem mais a fazer, encontrando a oportunidade
certa e escrevendo um PRD muito detalhado. Ao contrário dos PRDs que
discutimos no Capítulo 5, os PRDs em cascata precisam ser detalhados
e completos, especificando o máximo possível do projeto. Eles não são
documentos vivos, mas sim Bíblias grandes e detalhadas para o produto.
Após a fase de requisitos, a equipe de Engenharia e de Design assumem,

começando com uma fase de projeto, uma fase de codificação, e uma fase
de teste e integração. Os produtos geralmente são lançados com erros
conhecidos, já que eles nunca seriam lançados se você corrigisse todos
os erros. Os PMs geralmente estão envolvidos na priorização de erros
para garantir que os que afetam mais os clientes sejam corrigidos antes
do lançamento.

O método cascata tem alguns benefícios. Por um lado, todo mundo
vai ter uma ótima idéia de como será o produto final desde que você crie
uma especificação detalhada. Além disso, como você trabalhará bastante
criando os requisitos, talvez encontre e corrija um problema nessa fase.
É significativamente mais barato solucionar um problema desde o início.
Como o escopo é fixo desde o início, a Engenharia pode tomar decisões
de projeto próximas do ideal em vez de projetar para possíveis incógnitas.
As empresas de desenvolvimento terceirizadas costumam gostar de
trabalhar com a cascata com clientes porque podem orçar um projeto
com base no trabalho que concordaram em fazer.
Os clientes (e os PMs) gostam disso porque não precisam estar 253

envolvidos no dia a dia na administração do projeto. O gerenciamento
também costuma gostar de marcos claros e facilmente compreensíveis
em um projeto, e você pode medir o progresso em qual porcentagem
da especificação é implementada. Mas também há desvantagens
significativas no modelo de cascata que fizeram com que muitas equipes
de software se afastassem dele. Esses problemas incluem o seguinte:
Os clientes podem não conhecer seus requisitos exatos

antecipadamente. Como o método cascata concentra-se em
especificar e construir algo completo em vez de em iterações rápidas,
o que você cria inicialmente pode não atender às necessidades dos
clientes. E quando você tiver uma nova versão que atenda às suas
necessidades, poderá descobrir que os clientes há muito tempo
pararam de usar seu produto e procuraram outra resposta.
Não há uma boa maneira de lidar com as alterações. Após o
estágio de requisitos, você pode encontrar novos dados que afetam
o produto, e o método cascata não permite que você volte contra a
corrente para alterar as decisões nos estágios anteriores.
Não há uma estimativa de tempo fixa em cada etapa, e o

lançamento frequentemente atrasa. Um dos problemas mais
comuns é que havia incógnitas tecnológicas e a codificação da
solução levou muito mais tempo do que o planejado, de modo que
uma estimativa de projeto de três meses levou, na verdade, seis
meses para ser concluída. Você tinha que investir esses três meses
extras porque, caso contrário, você não teria um produto.
Pode levar tanto tempo para passar pelos estágios que uma boa
decisão que você tomou inicialmente pode se tornar a decisão
254 errada ao lançar o produto. Por exemplo, talvez você tenha
pensado que os clientes queriam um determinado produto, mas
THE PRODUCT BOOK
depois de construí-lo, você descobriu que as condições do mercado

mudaram e eles não o queriam mais.
Se você estiver trabalhando em um produto em que os requisitos e a

tecnologia são bem conhecidos, o método cascata é uma abordagem
razoável. Se a sua empresa estiver usando um sistema em cascata, a
melhor coisa que você pode fazer como PM é validar o PRD o máximo
possível inicialmente para evitar alterações mais tarde e tentar aprender
rapidamente se o mercado gosta da sua ideia.
Na maioria dos casos, as deficiências do método cascata superam seus

benefícios. Muitas equipes de software - incluindo a do Departamento de
Defesa - mudaram para abordagens de desenvolvimento mais iterativas.
Existem inúmeros tipos com vários nomes, e alguns ainda são parecidos
demais com o método cascata, mas eventualmente você encontrará a
segunda principal metodologia de desenvolvimento, o desenvolvimento
ágil ou enxuto.

Desenvolvimento Ágil
O desenvolvimento ágil ou enxuto é fundamentalmente flexível,
interagindo rapidamente e adotando mudanças. Infelizmente, “ágil”
tornou-se um termo um pouco genérico e vago, muito parecido com
“grandes arquivos de dados”. Muitas empresas afirmam seguir práticas
ágeis ou usar palavras de metodologias ágeis para descrever seu processo,
quando na verdade seus fluxos de trabalho não são ágeis. Vejamos o que
o método ágil realmente significa e, em seguida, em implementações
específicas.
O Manifesto para o Desenvolvimento Ágil de Software define os 255

princípios-chave, incluindo:
• Indivíduos e interações em vez de processos e ferramentas

• Trabalhar no software em vez de uma documentação abrangente
• Colaboração do cliente em vez de negociação de contrato
• Respondendo a mudanças em vez de seguir um plano
Em vez de totalmente concretizado, abordagem encenada, o método

ágil segue uma abordagem gradual. Com o método ágil, você planeja
uma unidade de trabalho relativamente pequena, constrói o que precisa
e avalia o que você construiu. Então, você usa esse conhecimento para
planejar o próximo trabalho a ser feito. Essas pequenas unidades de
trabalho podem ser organizadas em torno do tempo, em cujo caso elas
são chamadas de sprint, ou em torno do número de tarefas em que uma
equipe pode trabalhar de uma só vez, chamada de ciclo.
Existem várias implementações de metodologia de desenvolvimento
ágil que você pode usar como ponto de partida para o fluxo de trabalho ágil
da sua equipe e pode adaptar uma abordagem à dinâmica da sua equipe. O
que importa é que você esteja aberto a fazer alterações, iterar rapidamente
e criar softwares de trabalho, sem se concentrar em como chegar lá.
Para que o método ágil seja realmente eficaz, você precisa adotar os
princípios enxutos ou lean que defendemos ao longo deste livro, como
criar um produto viável mínimo (MVP) em vez do produto completo. Em
outras palavras, construa algo pequeno o mais rápido possível, aprenda
com ele e depois repita no próximo sprint/ciclo.
Sprints curtos - uma ou duas semanas - ou implantação contínua são
ideais com o método ágil, pois permitem que você se mova rapidamente
e obtenha avaliação. Se você tentasse executar um processo ágil com um
sprint de seis meses, encontraria muitas das desvantagens que listamos
para o método de cascata, como as necessidades do cliente podem mudar
256 enquanto você ainda estiver construindo o produto e você não terá nenhum
mecanismo para obtenha avaliação ou fazer alterações durante um sprint.
THE PRODUCT BOOK
O método ágil ou enxuto também conduzem a uma abordagem básica

em que cada sprint ou ciclo produzirá - de preferência - uma peça de
software utilizável que possa ser usada para obter avaliação de clientes
ou compradores. No método cascata, é muito mais provável que você
programe marcos para que parte do produto seja considerada completa
antes de passar para outra parte, programando a sua abrangência. Com o
método ágil, os sprints/ciclos geralmente se concentram em chegar a um
aplicativo mínimo, mas funcional, inicialmente e, em seguida, adicionar
recursos a cada seção, conforme necessário, agendando o intervalo.
Além disso, a equipe fará testes graduais no código durante cada
sprint/ ciclo, o que leva a um produto de maior qualidade com menos
erros. Estudos mostraram que é até 20 vezes mais barato encontrar
e consertar erros à medida que você cria um produto, em vez de fazer
etapas separadas de desenvolvimento e teste, como no método cascata.
Infelizmente, existem algumas desvantagens para o método ágil,
especialmente para os PMs. Fluxos ágeis de trabalho, frequentemente,
colocam muito mais demandas em você, às vezes até fazendo com que
você lide com controle de qualidade/ teste de erros, além de todo o resto

que você estará fazendo.
Ter mais marcos com mais frequência também impõe exigências
adicionais a você para validar as construções com os clientes, mas é
necessário trabalhar para encontrar o equilíbrio certo entre querer
avaliações e decidir quais criações validar. Certificar-se de que um cliente
quer algo antes de gastar muito tempo construindo é realmente uma
grande vitória em si. Afinal, se você perceber que está construindo a
coisa errada, pode descartá-la antes de perder mais tempo nela. Mas isso
levaria todo o seu tempo e nem sempre produziria informações úteis se
você tentasse validar cada compilação.
Da mesma forma, em um modelo de agência, os clientes às vezes não
gostam do método ágil porque precisam estar mais envolvidos no projeto, 257
agendando e priorizando consistentemente.
Uma das maiores críticas do método ágil, no entanto, vem dos
desenvolvedores. Se você estiver construindo algo novo/ tentando
resolver um problema difícil, o foco pesado do método ágil em fornecer
algo utilizável em um sprint (e as várias práticas associadas) é contrário
ao pensamento profundo e à solução de um problema. Frequentemente,
os desenvolvedores descobrem que a melhor maneira de encontrar uma
solução criativa para um problema difícil é isolar-se, concentrar-se
profundamente, experimentar e ressurgir quando tiverem uma solução.
Existem maneiras de evitar essa falha, como alavancar picos de pressão
- uma história de usuário para investigar algo - ou ter sprints explícitos
de pesquisa e desenvolvimento em que a única tarefa do desenvolvedor
é tentar resolver um problema. O fato de você estar ciente de que isso
é uma frustração para os desenvolvedores ajudará a tomar decisões de
planejamento que levem isso em consideração.
O método ágil também pode ser difícil de expandir para grandes
equipes. Consulte a seção "Leitura adicional" para obter informações
sobre Sucessões de Lançamentos Ágeis para ajudar quanto a expansão.
Também há uma curva de aumento antes que você atinja a produtividade
total ao implementar um fluxo de trabalho ágil.
Críticos do método ágil dizem que isso leva a um desenvolvimento
reacionário, já que você está respondendo ao que os clientes querem
agora, em vez de planejar um roteiro e manter uma visão de produto.
Acreditamos que é possível ter um roteiro temático geral com projetos
definidos e comunicados por PRDs, criados com metodologias ágeis/
enxutas, em que os detalhes exatos mudam à medida que você descobre
como os clientes usam seu produto.
Apesar das várias críticas, o Standish Group, um centro de consultoria
de TI, acompanhou 50.000 projetos de 2011 a 2015 e constatou que a
taxa de sucesso (envio de um produto em funcionamento) de produtos
258 ágeis foi de 39% vs. 11% para os produtos de método cascata. Essa é uma
grande diferença, mas observe que mesmo com o método ágil 61% dos
THE PRODUCT BOOK
projetos não têm um produto em funcionamento até o final.

Vejamos duas das formas mais populares de implementação da
metodologia ágil: scrum e kanban.
Scrum
O desenvolvimento do scrum é baseado em uma ideia do rúgbi,
especificamente que o funcionamento de uma equipe como uma equipe,
e não como um grupo de indivíduos, é a chave para o sucesso, e as
melhores equipes recebem orientação, mas podem elaborar suas próprias
táticas para alcançar seus objetivos. O scrum surgiu no início dos anos 90,
enquanto o método ágil foi formalizado no início dos anos 2000, mas os
arquitetos do scrum fizeram parte do grupo que criou a Agile Alliance.
Em alto nível, com o desenvolvimento de software, o uso de scrum
significa que a equipe se reúne para priorizar o que fazer a seguir e definir
metas de curto prazo para o trabalho a ser concluído. Você, como PM,
terá uma contribuição muito forte nessa parte do processo. Então a
equipe sai e descobre a melhor forma de fazer esse trabalho. Você fará

a verificação com os membros da equipe no início de cada dia enquanto
eles trabalham, respondendo a todas as perguntas e validará o trabalho
quando eles disserem que está pronto. Mas você não os gerencia ou altera
suas metas antes que eles terminem o conjunto atual.
O scrum é uma das abordagens mais comuns para o método ágil
porque tem uma estrutura de projeto claramente definida com funções de
equipe claras. Isso facilita a migração de uma empresa do método cascata
para a adoção do scrum. E mesmo que as empresas não implementem
totalmente o scrum, muitas vezes usam idéias emprestadas, como
reuniões diárias de levantamento ou verificação.
O scrum usa sprints de tempo, mais comumente de uma ou duas
semanas. A cada semana, você se encontra com a equipe de engenharia 259
para realizar a preparação do acúmulo. O acúmulo de um produto é a
coleção de todos os erros e sugestões, geralmente escritos como histórias
do usuário, para o produto.
A preparação simplesmente significa que você precisa se certificar de
que os erros e sugestões estejam organizados e claros o suficiente para
serem abordados. Por exemplo, todos nós já vimos - e talvez já tenhamos
lançado- erros de software mal escritos que apenas dizem "encontramos
um erro". Isso não ajuda. Na preparação, você faria o que pudesse para
adicionar etapas para reproduzir a falha e anexar um registro de falha
ao problema para que a equipe pudesse, eventualmente, corrigir o erro.
Além de adicionar clareza, durante a preparação, você garantirá que cada
novo item do acúmulo tenha critérios de aceitação: Como você sabe que
o item foi feito corretamente? Além disso, gostamos de escrever tarefas do
acúmulo como histórias do usuário, porque esse formato ajuda a explicar
por que algo é um problema para que o Design e a Engenharia possam
determinar a melhor abordagem para resolver o problema.
Além disso, durante a reunião de preparação, a equipe de engenharia
avaliará a complexidade das histórias novas ou atualizadas, dividindo-as
em sub-tarefas, se necessário. É difícil saber exatamente o quão difícil é
uma tarefa ou quantas horas ela demorará, por isso, muitas vezes você
verá a complexidade medida usando pontos de história relativamente
ponderados. As equipes podem atribuir um ponto a uma tarefa fácil,
dois pontos a uma tarefa média, quatro pontos a uma tarefa difícil e oito
pontos a uma tarefa muito difícil. A ideia é que você não sabe exatamente
o quão difícil é algo, mas pode dizer que uma coisa deve ser duas vezes
mais difícil que outra.
Depois de avaliar a complexidade, sua função como proprietário do
produto será fornecer prioridades precisas para todos os novos itens,
juntamente com os itens existentes na lista de pendências, com base nas
260 necessidades do cliente, no valor comercial e nos objetivos / necessidades
de longo prazo. Seu objetivo com essa priorização é ter a tarefa mais
THE PRODUCT BOOK
importante a se trabalhar em seguida na parte superior da lista de acúmulo.

Os acúmulos crescem bastante, e geralmente há uma grande
quantidade de coisas que você não conseguirá alcançar, além de coisas
legais, mas não relevantes no futuro imediato. As equipes geralmente
criam uma segunda lista, chamada de "congelador", para essas histórias
menos relevantes de imediato, mas que você não quer esquecer.
As histórias no congelador podem ser "descongeladas" e movidas para
o acúmulo, mas você não trabalhará ativamente em itens do congelador.
Como discutimos nos capítulos anteriores, haverá muitos recursos e
ideias em potencial para tornar o produto melhor. Você vai dizer "não"
muitas vezes para garantir que o projeto não saia do controle! Colocar
algo no congelador em vez de explicitamente dizer “não” é uma boa
maneira de fazer as pessoas sentirem que sua contribuição é valorizada,
evitando problemas com recursos. Posteriormente, você terá outra
reunião de planejamento na qual você determinará o acúmulo do sprint.
O acúmulo do sprint é simplesmente a lista de histórias de usuários
que a equipe pretende completar durante o sprint. Você escolherá

as principais coisas com as quais deseja trabalhar com base no valor
prioritário/comercial, e a equipe de engenharia concordará se pode se
comprometer com isso durante o sprint.
Uma pergunta comum é: como você sabe quantos itens de acúmulo
devem ser escolhidos para um sprint? Com o tempo, você descobrirá que
a equipe tende a completar n pontos de história por sprint. Esse número
é chamado de velocidade do sprint.
Durante essa reunião de planejamento, se você somar os pontos da
história nas tarefas que todos concordam em fazer, deve chegar a essa
velocidade.
Se você estiver lutando para priorizar o que fazer, tente calcular uma
pontuação de prioridade adicionando um campo de Valor de Negócios a 261
cada história, como sugerimos na seção Seguindo em Frente no final do
Capítulo 4. Fatores que influenciam o valor de negócios podem incluir
o quanto você acredita que isso o ajudará a atingir uma meta, quantos
clientes estão solicitando isso, se há uma importante razão técnica para
isso e assim por diante.
Em seguida, calcule uma pontuação de prioridade dividindo o
valor de negócios pela complexidade. Histórias de alto valor e baixa
complexidade terão uma pontuação alta. Histórias de alto valor e alta
complexidade terão uma pontuação intermediária. Histórias de baixo
valor e alta complexidade terão uma pontuação baixa. Essa abordagem
é especialmente útil quando sua equipe estiver responsável por vários
produtos e você precisar equilibrar as necessidades de cada produto
durante o planejamento do sprint.
Observe que você não alterará o acúmulo do sprint durante o próprio
sprint, pois isso interrompe a equipe e pode interromper a velocidade do
sprint, o que afeta o planejamento.
Essa falta de mudança vai encorajá-lo a ter sprints mais curtos,
especialmente quando as prioridades estiverem mudando, de modo
que você possa equilibrar a reação à mudança, permitindo que a equipe
funcione de maneira eficaz.
Você também verá que o scrum requer mais atenção para o equilíbrio
entre construir a coisa certa (o que os PMs querem), construir a coisa
certa (o que os engenheiros querem) e construí-la rapidamente (o que os
mestres de scrum querem para obter avaliação rapidamente) . É muito
provável que você acumule dívida técnica, ou seja, o código terá alguns
problemas que a Engenharia precisou criar para entregar algo a tempo.
Não há problema algum em ter uma pequena dívida técnica para
obter valor para o cliente a curto prazo, mas muitas dívidas técnicas
podem reduzir a velocidade da sua equipe. Durante os sprints, você
262 precisará aceitar periodicamente o trabalho que paga essa dívida técnica,
mesmo que não exista um valor visível para o cliente. Por exemplo, se
THE PRODUCT BOOK
reescrevermos a Moover de Objective-C para Swift, não haveria nenhum

valor imediato para o cliente, mas isso poderia facilitar a adição de novos
recursos daqui para frente, melhorando a velocidade da equipe.
Durante o sprint, você terá reuniões curtas de 15 minutos chamadas
de apresentações no início de cada dia de trabalho, onde cada membro
da equipe declara o que fez durante o dia anterior, o que pretende realizar
hoje e se tem algum problema de bloqueio.
No final do sprint, você terá uma reunião de demonstração com os
principais interessados/ o cliente para mostrar o que você criou e analisar
as avaliações deles, além de uma retrospectiva de sprint interna para
avaliar como foi o sprint.
Quando bem feito, ao combinar metodologias scrum e enxuta, o
scrum tende a fornecer um equilíbrio muito bom de planejar com
antecedência e tolerar mudanças, o que acreditamos ser valioso. Como
cada sprint idealmente produz algo útil, você pode dividir um plano
maior especificado em um PRD em marcos menores e validar o que você
está criando em pontos-chave com clientes e partes interessadas para

garantir que você esteja no caminho certo. Se você não estiver, pare em
vez de construir mais.
Quando você inicia um novo projeto, o scrum é especialmente útil. No
início de um projeto, há muito risco (comercial, técnico e muito mais).
Ao se concentrar em sprints e tarefas que diminuam o risco do projeto,
você poderá ter um valor inicial baixo para o cliente, mas isto permitirá
um progresso rápido depois.
Por exemplo, ao planejar o novo recurso de mensagens do cliente da
Moover, podemos nos concentrar em fazer as mensagens entre os clientes
e as empresas de mudança funcionarem inicialmente, sem prestar atenção
a uma boa experiência do usuário. Isso nos permitirá testar e garantir que
essa peça central funcione. Se a equipe de desenvolvimento descobrir que 263
sua abordagem inicial tem uma grande limitação (por exemplo, talvez ela
seja constantemente bloqueada por um firewall), a equipe pode encontrar
uma solução melhor.
E se a peça central não for capaz, você pode reavaliar o que está
construindo sem perder o tempo da equipe em peças não essenciais.
O Scrum também facilita o gerenciamento de projetos, já que você
pode usar os pontos da história e o total de pontos da história para itens
pendentes no acúmulo do produto para criar linhas de tendência. Essas
linhas de tendência permitem estimar quando o projeto será executado
com um conjunto de recursos, além de quanto trabalho será feito em uma
determinada data.
Se você tiver que fazer uma alteração no cronograma, recomendamos
reduzir o escopo do projeto, em vez de estender o cronograma. Dessa
forma, você se certificará de ter feito algo dentro do prazo e, se terminar
cedo, poderá aumentar os escopos.
Infelizmente, o scrum possui alguns problemas. Alguns desses
problemas até poderão fazer com que você grite “o método ágil está fora
de questão”. O cerne desse argumento é que o movimento ágil deveria
ser sobre indivíduos e interações, e responder à mudança. O scrum se
tornou sinônimo de ágil, mas implementar o scrum geralmente é mais
sobre o processo em relação aos indivíduos, e a mudança foi limitada
para permitir um melhor planejamento. Em outras palavras, o método
“ágil” foi banalizado ao ponto de se tornar algo tão rígido quanto o
método de cascata.
As reuniões de apresentações são um ótimo exemplo dessa rigidez.
O objetivo é manter a equipe informada sobre o que está acontecendo e
ajudar a desbloquear qualquer problema no início de cada dia. Mas se sua
equipe começar o dia em momentos diferentes ou trabalhar em diferentes
fusos horários, as reuniões de apresentações em pé não serão eficazes
porque acontecerão no início do dia para uma pessoa, mas na metade
264 do dia para outra. Além disso, estas verificações, muitas vezes, se tornam
uma maneira fácil de os gerentes administrarem microgerenciamentos,
THE PRODUCT BOOK
alegando que isso faz parte do scrum. Apesar destas deficiências, as

equipes ainda mantêm suas apresentações porque é isso que o scrum diz
para fazerem. Uma abordagem melhor seria criar novas maneiras de se
comunicar, como incentivos ágeis, como postar uma atualização de status
no Slack no final do dia, em vez de fazer apresentações.
O scrum também pode criar dores de cabeça para você. Geralmente,
cabe ao Product Manager realizar testes de aceitação, garantindo que cada
história de usuário seja concluída corretamente e sem erros. Isso pode
exigir muito do seu tempo e, quando você combina tudo o que precisa
fazer, é fácil ficar desleixado e deixar passar despercebidos os erros que
uma equipe dedicada de controle de qualidade teria captado.
Uma desvantagem final para o scrum é que, mesmo que você esteja
vendo o progresso com mais frequência do que com o modelo cascata,
no melhor cenário, ainda precisa aguardar um sprint inteiro para ver
o há de melhor e mais recente. Enquanto isso pode ser bom para um
novo recurso, pode ser muito frustrante para correções de erros! Dada
a facilidade de lançamento de um software no mundo atual, como em

aplicativos da rede, há abordagens ágeis alternativas que valem a pena,
como o Kanban.
Kanban
O desenvolvimento Kanban vem da Toyota, que surgiu com
essa metodologia, analisando como as prateleiras de estoque dos
supermercados. Especificamente, os supermercados pretendem estar
sempre “dentro do prazo” para que as prateleiras não fiquem vazias
nem sobrecarregadas com alimentos vencidos e desperdiçados. Embora
a Toyota tenha usado essa técnica para construir carros de maneira
eficiente, ela também é aplicada ao software.
265
O objetivo do Kanban é combinar a capacidade da equipe de
trabalhar com a quantidade de trabalho que está realmente acontecendo.
Além disso, deve haver algumas tarefas prontas para serem executadas,
de modo que, se uma equipe concluir n pontos de trabalho de história,
ela poderá começar imediatamente a trabalhar em uma tarefa que exija
outros n pontos para concluir. Isso é bom porque suas prioridades futuras
podem mudar com muito pouco impacto no trabalho atual da equipe.
No Kanban, você normalmente criará um quadro de tarefas mostrando

o que está por vir (pendente), em andamento, pronto para ser testado/
verificado e concluído. As tarefas passarão de uma coluna para outra e
você saberá quanto trabalho a equipe pode lidar de uma só vez, além de
quantas coisas ela poderá verificar de uma só vez.
Embora muitas metodologias ágeis sejam baseadas em tempo, o
Kanban não é. Em vez disso, o gerente de desenvolvimento trabalhará
com a equipe de desenvolvimento para redefinir a prioridade do acúmulo
e garantir que os itens mais importantes estejam sempre a seguir e que
suas estimativas de dificuldade sejam precisas. Isso leva as equipes de
Kanban a se concentrarem no tempo do ciclo: quanto tempo leva desde o
momento em que você inicia uma unidade de trabalho até ela ser lançada.
Muitas pequenas coisas podem prejudicar o tempo do ciclo, como

uma pessoa com conhecimento especializado e necessário para a tarefa,
além de múltiplas tarefas. Portanto, o Kanban incentiva as equipes a
aprenderem habilidades fora de seus domínios - para que todos possam
testar, por exemplo, se há trabalho se acumulando na fila “pronto para
ser verificado” e segurando a próxima fase - e manter o foco ao manter a
quantidade de trabalho em andamento pequena.
266
Um dos maiores benefícios do Kanban é que ele permite a implantação
THE PRODUCT BOOK
contínua. Quando uma mudança se move pelo ciclo, ela está pronta para
ser liberada. Especialmente para aplicativos da rede, isso é muito bom e
permite uma avaliação imediata do cliente.
O Kanban também é bom porque pode ser implementado sobre

outras metodologias. É realmente apenas um foco na melhoria contínua
e gradual do produto. Em geral, se sua equipe já estiver usando um
fluxo de trabalho e o executando bem, o Kanban pode ajudar a equipe a
passar para o próximo nível. Mas se sua equipe precisa de ajuda para se
tornar mais eficiente em geral, acelerando as coisas, concentrando-se na
implementação de outro processo ágil, o Kanban pode não ser o lugar
certo para começar. Isto porque o Kanban é um método muito menos
formalizado do que o scrum, e pode ser mais difícil entender como
implementá-lo inicialmente.
Às vezes, você verá o Kanban combinado com o scrum - chamado
"scrumban") - que originalmente era uma forma de transição do scrum
para o Kanban, mas se tornou uma metodologia própria. Aqui, a equipe
fará uma reunião de planejamento, executará um sprint muito curto e,

em seguida, realizará outra reunião de planejamento quando o trabalho
em andamento ficar abaixo de um certo número de pontos da história.
Não há funções pré-definidas ou programações fixas, e as iterações são
focadas em pontos entregues em vez do tempo.
No entanto, ao mesmo tempo que o Kanban é ótimo para as equipes
de desenvolvimento, pode ser muito difícil para os PMs. Os PMs são
frequentemente bastante ocupados, trabalhando com clientes, orientando
produtos, trabalhando com marketing e muito mais. O Kanban exige que
também permaneçamos disponíveis continuamente para verificar se cada
tarefa está concluída (teste de aceitação) e para garantir que o próximo
conjunto de tarefas seja priorizado e esteja pronto para ser executado
(preparação de acúmulo). Se você não fizer essas tarefas continuamente, 267
poderá se tornar um ponto de estrangulamento para toda a equipe!
Em geral, lembre-se de que, com o método ágil, os indivíduos e as

interações são o elemento mais importante - mais importante do que
processos e ferramentas. Isso significa que você não deve se preocupar
em seguir uma implementação palavra por palavra de uma metodologia
específica. Comece em algum lugar e descubra o que funciona melhor
para sua equipe. E não tenha medo de tentar uma nova abordagem.
DICA DO CAPÍTULO 7
Mohammad Musa, um instrutor da Product School, fornece a dica deste

capítulo. Mohammad é cofundador de uma empresa recém-criada em
tecnologia furtiva focada na realidade virtual para empresas. Ele costumava
trabalhar no Google em todos os esforços da empresa para permitir que
as equipes construíssem produtos com mais eficiência. Ele trabalhou
especificamente em produtos de infraestrutura para rastrear métricas
centradas no usuário, gerenciamento de erros e avaliações contínuas do
usuário. Antes disso, ele foi chefe de Lançamentos & Disponibilidades nos
aplicativos Google para Trabalho, onde liderou uma equipe multifuncional
gerenciando lançamentos de produtos, roteiro de produtos, teste de
confiabilidade e lançamento de comunicações. Antes de entrar para o Google,
268 Mohammad trabalhou em engenharia de software e em cargos técnicos de
vendas nas indústrias de videogames e semicondutores, principalmente em
THE PRODUCT BOOK
pequenas empresas iniciantes.
TRABALHANDO COM EQUIPES DE DESENVOLVIMENTO

JÚNIOR
Se você é um PM de software, precisará trabalhar lado a lado com o gerente
de engenharia de software (geralmente chamado de gerente de tecnologia
principal ou TLM em empresas como Google, Facebook e Twitter). O
TLM gerencia vários engenheiros de software com níveis de senioridade
variáveis. Os engenheiros mais experientes são geralmente chamados de
líderes de tecnologia (LTs). Os LTs podem ou não ter responsabilidade de
gerenciamento sobre os outros membros da equipe.
O LT se reporta ao TLM e lida com a maior parte do trabalho diário e
ajuda a equipe a desbloquear os desafios técnicos de um projeto específico.
Se você tiver sorte, estará trabalhando com um TLM e/ ou LT experiente
que já orientou e gerenciou muitos engenheiros no passado. O TLM ou LT
cuidará do treinamento e aconselhará os desenvolvedores júnior da equipe
sem exigir ciclos extras de você como um PM.

No entanto, na realidade, você nem sempre consegue trabalhar com um
TL ou TLM experiente. Ou, às vezes, você pode trabalhar com um TLM ótimo,
mas ocupado, que tem mais de 15 engenheiros se reportando a ele/ ela.
Nesses casos, sua função como o PM precisará ser expandida para melhor
ajudar a equipe a obter êxito. Na minha experiência, descobri que trabalhar
com desenvolvedores júnior requer que o PM trabalhe mais em torno do
gerenciamento de scrum, qualidade e definição de produto ou recurso.
Em primeiro lugar, no que diz respeito ao scrum, os desenvolvedores

júnior não estão acostumados a estimar a história do usuário. Suas
estimativas são geralmente erradas e, muitas vezes, eles pensam que uma
história está completa, enquanto ainda há muito trabalho a ser feito. Essas
269
histórias prematuras podem causar constrangimento na frente das partes
interessadas, se não houver garantia de qualidade o suficiente. Em segundo
lugar, e intimamente relacionado ao primeiro ponto, você realmente
precisa fazer muito mais garantia de qualidade em torno do trabalho que
os desenvolvedores júnior concluíram. Você pode não ter uma equipe de
controle de qualidade e mesmo se você tiver, os testes com roteiros podem
não detectar todos os erros que foram introduzidos por alguém que não
conhece o sistema muito bem. Isso é exacerbado em sistemas de software
complexos que já estão sofrendo com problemas de cobertura e qualidade.
Finalmente, em torno de requisitos e definição: Como o PM, você

precisa assumir que os membros da equipe júnior são como novos
usuários que usaram apenas casualmente seu produto. Você não pode
contar com conversas rápidas no corredor ou bate-papo para concordar
sobre pequenos detalhes e seguir em frente. Você realmente tem que
documentar e certificar-se de que os membros da equipe júnior tenham
realmente absorvido o que você está pedindo que eles façam. Isso incluirá
descrições mais detalhadas da história do usuário, simulações detalhadas
e jornadas/ cenários do usuário, além de critérios detalhados de aceitação.
De seis a oito sprints, os membros mais novos entenderão melhor as

complexidades e os requisitos do produto. Para acelerar a compreensão e
encurtar a curva de aprendizado, seria ideal para sua equipe desenvolver
mais empatia pelo usuário. Incentive sua equipe de engenharia a monitorar
as sessões de pesquisa do usuário ou conduzir conversas informais com
os usuários diretamente (se possível). Mais conhecimento da persona do
usuário e seus pontos problemáticos ajudam toda a equipe a se tornar
mais experiente e ajuda os desenvolvedores júnior a assumirem mais
responsabilidades e se orgulharem de seus trabalhos.
270
THE PRODUCT BOOK
TRABALHANDO COM EQUIPES REMOTAS
Um desafio comum que os PMs enfrentam é como trabalhar com
equipes de desenvolvimento que não estão no mesmo espaço físico ou
no mesmo fuso horário que eles. Embora não exista apenas uma resposta

certa, o segredo está em uma comunicação clara. Isso não significa uma
expectativa de comunicação ininterrupta e disponibilidade constante, mas
sim fazer verificações regulares e usar ferramentas como o Hangouts do
Google para ver uns aos outros e se lembrarem de que estão trabalhando
com uma pessoa de verdade.
Você pode desempenhar um papel importante ajudando as equipes

remotas a serem bem-sucedidas ao comunicar excesso de requisitos,
metas, decisões e a definição de “feito” para o projeto, de modo que todos
sintam que estão na mesma equipe e tenham um claro entendimento de
o que eles estão trabalhando, independentemente de onde suas mesas
271
estejam localizadas. Às vezes, decisões importantes ou esclarecimentos
acontecem em uma conversa no corredor, e, a menos que você preste
atenção, um desenvolvedor remoto pode não ouvir sobre essa decisão, ou
pode se sentir excluído do processo de tomada de decisão.
Criar uma cultura em que as pessoas não pensem duas vezes em ter
um bate-papo por vídeo rápido pode ajudar a replicar a interação face
a face que acontece naturalmente em um único local. Muitas vezes,
ainda pensamos em uma videoconferência como um horário formal e
agendado - não precisa ser assim.
Além disso, esteja ciente de quando as pessoas estão começando ou

terminando seus expedientes. Existe algo que a equipe A pode fazer no
final do dia que você precisa para o início do dia? Ou há algo que você
pode fazer até o final do dia para que, quando a equipe B começar a
trabalhar, ela não fique bloqueada?
Pode até ser útil estabelecer reuniões de transferência em “horários
comuns” para que essas necessidades sejam comunicadas claramente no
início e no final do dia de trabalho de cada equipe.
O método ágil ajuda muito com as equipes remotas porque obriga você
a pensar sobre a natureza adaptável da agilidade para descobrir fluxos de
trabalho que funcionam bem para você. Por exemplo, o scrum funciona
bem com equipes remotas, porque você pode planejar o que fazer,
permitir que as pessoas trabalhem de forma independente e ainda realizar
apresentações diárias. Dependendo do horário em que as pessoas estarão
disponíveis, você pode ter que fazer levantamentos diários de forma
assíncrona por e-mail ou mensagens instantâneas durante o dia, em vez
de ter todos juntos ao mesmo tempo. Além disso, na reunião de revisão,
em vez de tentar acomodar a programação de todos e possivelmente
tornar a reunião inconveniente para as partes interessadas, tente que
o proprietário do produto, em vez de desenvolvedores individuais,
272 apresente o trabalho geral da equipe às partes interessadas.
THE PRODUCT BOOK
A coisa mais importante que as equipes remotas perdem é a formação

natural de equipes que acontece quando as pessoas passam seus dias
juntas. É importante reunir sua equipe no mesmo lugar periodicamente,
mesmo que seja apenas para exercícios de formação de equipes. Os
Product Managers devem ter empatia por suas equipes, não apenas por
seus clientes. Passar tempo juntos é uma boa maneira de desenvolver
relacionamentos sólidos.
TRABALHANDO COM EQUIPES DE DESENVOLVIMENTO

TERCEIRIZADAS
Se você for um PM de software, há uma boa chance de que, em
algum momento, você trabalhe em um projeto com uma equipe de
desenvolvimento terceirizada. Isso significa que os desenvolvedores
do projeto não são funcionários da empresa, mas funcionários de uma
agência de desenvolvimento que você contratou. As empresas costumam
envolver uma equipe de desenvolvimento terceirizada quando estão
com recursos restritos - uma empresa iniciante pode não ter tido tempo

ou recursos para construir uma equipe de desenvolvimento em tempo
integral ou, em uma empresa de maior porte, pode querer assumir um
projeto que sua equipe interna não tem tempo para fazer. Às vezes, você
também pode contratar uma equipe de terceiros porque eles têm uma
habilidade específica que você precisa em curto prazo, como experiência
em uma API específica.
Como Product Manager, você lidará com muita interação entre sua
empresa e a equipe terceirizada e poderá fazer algumas coisas para ga-
rantir o sucesso. A mais importante delas é certificar-se de que você este-
ja comunicando os requisitos, metas e prazos para a equipe terceirizada
com clareza. Aproveite o tempo para abordar quaisquer elementos po- 273
tencialmente confusos à medida que surgirem. Escrever tudo em um re-
curso compartilhado de gerenciamento de projetos, como o Basecamp,
ajudará a garantir que todos tenham acesso às mesmas informações e de-
cisões-chave. Coordene os cronogramas e avance com as partes interes-
sadas internamente para garantir que tudo esteja conforme o planejado.
Muitas vezes, é melhor comunicar demais, principalmente no começo.
Também é muito útil se você estabelecer marcos frequentes com a

equipe externa. Se essa equipe estiver usando internamente um processo
ágil, isso deverá ser fácil. O benefício é que você poderá ver o que eles
estiverem construindo, e se algo não estiver indo na direção certa - seja
por causa de uma falta de comunicação ou porque você cometeu um erro
no que você precisava construir - você poderá resolver isso logo no início.
Assim como com uma equipe de desenvolvimento interna, se você der a
uma equipe terceirizada uma grande especificação e só fizer verificações
três meses depois, o que ela criou pode, involuntariamente, não ser o que
você queria ou o que você precisa.
Ter um plano sólido de curto prazo também é muito útil, pois permite
que as agências programem seus desenvolvedores de maneira eficiente
em seu projeto. Na verdade, algumas agências preferem deixar o trabalho
em filas de espera até que elas tenham um valor de sprint no projeto antes
de priorizá-lo. Alterar com frequência o que você está pedindo é frus-
trante para as agências de desenvolvimento, pois dificulta que a agência
planeje o projeto a longo prazo e avalie quando ela terminará seu proje-
to e quando ela poderá assumir novos trabalhos. Acima de tudo, assim
como você faria com uma equipe interna, procure uma agência de desen-
volvimento externa como parceira. Seja respeitoso com as habilidades, o
tempo e as necessidades da agência, e ela provavelmente fará um ótimo
274 trabalho para você.
No entanto, embora existam muitas excelentes equipes de
THE PRODUCT BOOK
desenvolvimento externas, existem algumas suspeitas também, então você

deve conhecer alguns sinais de alerta. Como quando você está comprando
um carro usado, e seu contato continua repetidamente dizendo o valor
que você estará recebendo, provavelmente ele está tentando superfaturar
com a sua compra. Se o seu contato nunca fizer perguntas para esclarecer
cada história do usuário ou fizer um esforço para esclarecer e fornecer os
critérios de aceitação, você deve ser cauteloso. Se o seu contato ignorar
as perguntas que você faz, exceto em suas chamadas de verificação, você
também deve ficar alerta.
Fique atento a como agências de métodos ágeis atribuem pontos de

história a histórias de usuários para as quais elas usam uma estrutura
interna pré-construída. Inclusive, muitas agências criam bibliotecas de
funções comuns, como o código do servidor para gerenciamento de
contas. Uma boa agência que esteja usando sua biblioteca para concluir
as histórias de usuários estimará essas histórias de usuário como "fáceis".
Isso é honesto e permite calcular a velocidade do sprint de maneira

eficaz. Uma agência não tão honesta listará uma estimativa difícil para
as histórias do usuário, reivindicando todo o trabalho original necessário
para desenvolver a biblioteca como parte de sua história, mesmo que
seja trivial para a agência implementar. Em seguida, a agência lhe dirá o
quanto ela deu de pontapé inicial no sprint porque sua equipe realizou
centenas de pontos de história, mesmo que ela realmente tenha apenas
10 pontos de história de trabalho. Essa afirmação atrapalha os cálculos de
velocidade e planejamento do sprint, e é um sinal claro de que você deve
encontrar uma nova agência.
Não importa onde os membros da sua equipe estejam localizados,

sejam internos ou externos, e se usam o método Kanban ou cascata, 275
dizemos que a fase de desenvolvimento do ciclo de vida do produto é
feita quando o software testado está funcionando e atende aos requisitos
do produto e está pronto para lançamento. Sua função durante a fase
de desenvolvimento se resume a fornecer requisitos claros para os
membros da equipe de engenharia, trabalhando com eles para priorizar
e redefinir prioridades, conforme necessário, e confiando que eles
criarão um ótimo código. Agora que criamos nosso produto, vamos ver
como o lançamos e comercializamos.
CAPÍTULO OITO
COLOCANDO SEU PRODUTO NO
MERCADO
276 Mas, para um Product Manager, ainda há mais trabalho a ser feito para
colocar seu produto no mercado de forma bem-sucedida. Como diz a
THE PRODUCT BOOK
equipe da Pragmatic Marketing, uma agência focada em marketing de

produto: “O lançamento não é o fim do desenvolvimento, mas sim o começo
da venda”. Por mais que gostaríamos de acreditar que, se construíssemos
o produto perfeito que se venderá sozinho, a dura realidade é que não. Se
nenhum dos seus clientes-alvo conhecerem, encontrarem ou comprarem
seu produto, ele será um fracasso. Se as pessoas erradas comprarem seu
produto, elas não ficarão felizes e seu produto também será um fracasso.
A menos que você tenha um plano sólido para levar seu produto ao
mercado, ele provavelmente irá fracassar. Felizmente, existem equipes
de marketing e vendas para garantir que os clientes certos aprendam,
encontrem e comprem seu produto!
Para garantir um lançamento bem-sucedido, você trabalhará de perto
com a equipe de marketing. Algumas empresas até têm um segundo papel
no marketing relacionado ao Product Management, o gerente de marketing
8. Colocando seu Produto no Mercado

do produto (GMP). Simplificando, o GMP é focado externamente e é um
especialista no cliente - e o comprador, se não for a mesma pessoa, como
no software corporativo - enquanto o PM se concentrará internamente na
criação do produto. As empresas que possuem um PM e um GMP chamam
o PM de "entrada" e um GMP de "saída" para refletir esse foco diferente.
Em termos de fluxo de trabalho, o GMP geralmente lidará com o

desenvolvimento e o alcance do cliente, o PM receberá essa avaliação e
pesquisa e obterá o produto certo, e o GMP voltará sua atenção para o
lançamento. Durante o lançamento, o GMP é responsável por descobrir
como explicar o produto aos clientes, elaborar o plano de entrada no
mercado (GTM) correto para levar o produto ao mercado com sucesso e
ajudar a equipe de vendas. 277
Passaremos por este capítulo como se o PM e o GMP fossem a
mesma pessoa para dar a você a melhor compreensão de como produto e
marketing se reúnem durante o lançamento.
Ao representar o cliente, a equipe de marketing e vendas sempre

pedirá a entrada do PM ao formar estratégias. Por exemplo, se o seu
produto for destinado a adolescentes, o PM saberá que os adolescentes
usam atualmente o Snapchat e o Instagram mais do que o Facebook.
A equipe de marketing usará essa informação como ponto de partida
para determinar onde comprar anúncios gráficos. Embora você não seja
responsável pelos detalhes da compra de anúncios gráficos, sua opinião
afetará onde esses anúncios estarão localizados e suas mensagens.
Ao longo deste capítulo, veremos a preparação do lançamento, o
lançamento em si e um pouco sobre as atividades pós-lançamento.
A preparação do lançamento começa muito antes do lançamento do
produto, com o entendimento de seus clientes e as mensagens do produto.
Apesar de estarmos cobrindo este material depois que o produto foi
criado, você implementará esse conselho enquanto estiver criando este
produto. Se você está lançando uma nova versão de um produto existente
com pequenas correções ou lançando um grande produto completamente
novo, o conselho neste capítulo vai ajudá-lo. Você ajustará a escala
adequadamente. Uma versão de correção de erros não precisa de um tour
de imprensa, por exemplo.
ENTENDENDO OS CLIENTES
Para comercializar seu produto com sucesso, você precisa saber como
seus clientes tomam decisões. Pensar no marketing desde o início,
278 mesmo quando você estiver fazendo o desenvolvimento inicial do cliente,
ajudará seu produto a entrar no mercado com sucesso. Por exemplo, seus
THE PRODUCT BOOK
clientes podem esperar comprar seu produto no Mercado Livre. Pode

levar meses para que sua equipe de vendas estabeleça o relacionamento
para que seu produto fique disponível na loja, o que significa que você
não pode esperar até o lançamento para iniciar o processo.
No Capítulo 3, apresentamos o Quadro de Modelo de Negócios e

o Quadro de Proposta de Valor. Na época, nós os usamos para ajudar
a procurar uma oportunidade de produto. Podemos usar as mesmas
ferramentas para entender como comercializar melhor nosso produto
para os clientes certos, observando diferentes partes do quadro. Para
referência, a Figura 8-1 mostra o Quadro do Modelo de Negócios
(também mostrado no Capítulo 3 na Figura 3-5).
QUADRO DE MODELO DE NEGÓCIOS
Principais Atividades Propostas Relacionamento Segmentos de
Parceiros Principais de Valor com os Clientes

Recursos Canais
principais
Custo da Estrutura Fluxos de Renda
Figura 8-1: O Quadro de Modelo de Negócios, do http://strategyzer.com, fornece

informações sobre como comercializar seu produto.
279
Estas são as áreas-chave para se focar do ponto de vista do marketing:
• Segmentos de clientes: Quem são as pessoas-chave?

• Propostas de valor: Qual é o benefício / valor que cada pessoa
obterá com seu produto?
• Canais: Como a empresa alcança cada pessoa?
• Relacionamentos com clientes: Qual nível e tipo de comunicação
cada pessoa espera?
• Fluxos de renda: Quanto e com que frequência o cliente pagará?
Ao fazer sua pesquisa com clientes, você precisará preencher esses

blocos e expandir sua persona para incluir a parte do marketing. Aqui
estão algumas coisas específicas para se certificar de que suas personas
abordem:
• Como a persona consideraria seu produto um sucesso
• Como a persona percebe seu produto / empresa (se você tiver um
produto existente)
• Quais critérios de compra a persona possui
• Como a persona avalia os produtos (por exemplo, ela espera uma
avaliação gratuita? )
• Como a persona percebe sua concorrência
• Que influência essa persona tem no processo de compra
Ao desenvolver o lado do marketing de uma persona, você ajudará a

equipe de marketing a tomar decisões bem-sucedidas. Por exemplo, sua
persona pode se concentrar em novos pais que buscam orientação on-
line. Em seguida, a equipe de marketing fará pesquisas adicionais para
determinar quais sites e blogs para pais os clientes reais leem, além de onde
compram fraldas e outros suprimentos. Em outras palavras, quando você
280 sabe quais são as suas personas, você e a equipe podem descobrir quais
canais os clientes que eles representam usam para aprender e comprar
THE PRODUCT BOOK
novos produtos. Isso permite que sua equipe faça escolhas, como onde
comprar publicidade, para que as pessoas certas encontrem seu produto.
O bloco de Relacionamento com Cliente ajudará sua equipe a determinar

como alcançar esses clientes também. Com um produto corporativo e um
cliente de alto valor que compra muitas licenças, o cliente provavelmente
espera que seu gerente de contas fale com ele pessoalmente e, talvez, até
venha ao escritório para fazer uma demonstração. Novamente, certifique-
se de que as escolhas que você faça para os relacionamentos com os clientes
correspondam às expectativas de seus clientes.
Às vezes, especialmente se você estiver lançando uma versão

completamente nova de um produto, convém informar todos os
segmentos de clientes de que o produto ainda não está pronto.
Por exemplo, quando a Apple lançou o Final Cut Pro X, que era uma
versão completamente reescrita do Final Cut, ela deixou de fora alguns
recursos avançados e esperou que a avaliação dos clientes determinasse

qual recurso adicionar novamente. Isso também significava que a Apple
não comercializava explicitamente o produto para os clientes que eles
sabiam que precisavam desses recursos avançados, pois esses clientes não
teriam ficado satisfeitos com essa nova versão.
Mensagens do Produto
Uma das coisas mais importantes que o Quadro de Modelo de Negócios
e o Quadro de Proposta de Valor podem ajudar você e sua equipe a
determinar é a mensagem certa do produto. Especificamente, como
você comunica o valor de seu produto aos clientes e explica por que eles
devem se importar e quais problemas seu produto resolve? Esses quadros
podem ajudar, porque eles pedem especificamente que você pense nas
necessidades, problemas e metas de seus clientes, além dos problemas 281
que seu produto resolve e de quais benefícios ele oferece aos clientes-alvo.
Enquadrar seu produto dessa maneira - por que o cliente deve

se preocupar? - ajuda com tudo, desde como você venderá o produto
até quais recursos realmente importam. É muito importante que, no
Capítulo 5, tenhamos recomendado incluir pelo menos uma primeira
etapa na mensagem principal do seu produto no PRD. Se você não pensa
nos clientes que está tentando alcançar e porque eles devem se preocupar,
será muito mais difícil encontrar clientes. Por exemplo, se você estiver
trabalhando em uma nova versão de um produto de empréstimo para
estudantes, seu foco será fazer os alunos e recém-formados se interessarem
e comprarem seu produto.
Antes de começar a criar a mensagem do seu produto, certifique-se de

que realmente entenda as personas dos clientes que você está segmentan-
do e como o produto se encaixa na vida delas. O Quadro de Proposta de
Valor, especialmente, o ajudará a ver essas conexões. Em um mundo ideal,
criamos uma mensagem universal que aborda todas as suas personas, mas
provavelmente precisaremos de mensagens diferentes para cada persona.
Usar a mesma mensagem para cada pessoa é como começar cada

carta que você envia com “Caro senhor”, mesmo que o destinatário seja
uma mulher. E da mesma forma que você não cumprimentaria alguém
pessoalmente com "Caro senhor", provavelmente terá mensagens
diferentes para diferentes mídias, de site a e-mail até anúncios em
vídeos. Em outras palavras, não será apenas o idioma da mensagem que
muda. Diferentes personas vão querer propostas de valores diferentes e
se preocuparão com diferentes características/ casos de utilização. Um
pai que fique em casa para cuidar do filho provavelmente se preocupará
282 mais com a classificação de segurança de um carro do que com sua
potência, enquanto um pai que esteja passando pela crise de meia-idade
THE PRODUCT BOOK
se preocupará mais com a potência.
Os PMs são frequentemente responsáveis pela primeira passagem

nas mensagens de um produto e contribuirão nas várias formas que
essas mensagens terão. Vamos mergulhar em como criar uma ótima
mensagem. Criaremos uma mensagem juntando algumas notas em torno
dos elementos colocados em uma mensagem e depois juntaremos essas
notas em uma mensagem.
Principais Elementos de Mensagem do seu Produto

Começaremos nossas anotações pensando nos temas do produto, sobre
os quais falamos no Capítulo 2. Há três perguntas principais que o nosso
tema deve responder: Por que esse produto/ empresa é importante? Por
que você está fazendo isso? O que há de especial na missão de sua empresa
que fará com que um cliente deseje seu produto no lugar do produto de
um concorrente? Idealmente, haverá um tema fundamental que responda

a essas três perguntas. Pegue uma folha de papel em branco e comece
a escrever o que você acredita que seja o tema central da sua empresa.
Revise o que você escrever conforme necessário para se certificar de que
o tema se aplique a todas as três perguntas.
Vamos anotar o tema da Moover. Os fundadores da Moover criaram

a empresa porque descobriram que planejar uma mudança seria
extremamente estressante, especialmente quando se trabalha em período
integral. O tema central deles é fazer com que o processo de mudança
seja o mais tranquilo possível, para que seja fácil chegar onde você deseja
morar. Embora possamos nunca dizer explicitamente essas palavras aos
clientes, esse tema guiará nossas mensagens de produto.
283
Outro elemento a ser observado é o que há de inovador e novo no
produto: Para que estamos construindo uma mensagem? Na sua folha de
papel, crie uma nova seção na qual você listará o que há de novo. No caso
da Moover, é o recurso de bate-papo.
Observe que a parte "novo" pode ser diferente para clientes novos versus
clientes existentes. Com a Moover, podemos informar especificamente os
clientes existentes sobre o recurso de mensagens. Mas quando tentamos
alcançar novos clientes, provavelmente temos que, primeiramente,
educá-los sobre a Moover no geral, e o recurso de bate-papo será um
ponto de destaque abaixo da mensagem principal. Esse é um problema
comum que as empresas enfrentam e é apenas mais um motivo pelo qual
você precisará de mensagens diferentes para diferentes clientes.
Em vez de contar às pessoas sobre esses mais novos recursos, no entan-
to, queremos falar sobre os benefícios que eles proporcionam ao cliente,
usando o tema subjacente e os problemas/ necessidades do cliente para afe-
tar nossa fluência. Ao lado de cada novo recurso listado, escreva por que
o cliente deve se importar e como esse recurso está relacionado ao tema.
O recurso de bate-papo da Moover permite que os clientes se

comuniquem com empresas de mudanças de forma conveniente para
os clientes, não apenas das 9h às 17h. Poderíamos reformular isso para
explicar por que um cliente deveria se importar em escrever: "Nunca
se preocupe em perder um telefonema dos atendentes: fale com eles de
acordo com sua agenda".
Continuando com a elaboração de sua mensagem, como o seu produto

é diferente e melhor do que o que o cliente está fazendo agora? Isso é
284 especialmente relevante no envio de mensagens para novos clientes. Em
outra seção do seu artigo, crie colunas "Agora" e "Futuro" e escreva o que
THE PRODUCT BOOK
o cliente está fazendo agora e por que seu produto, especialmente com
esse novo recurso, é melhor.
Neste momento, os clientes existentes e potenciais da Moover precisam

se preocupar em atender chamadas telefônicas e não perder e-mails de
empresas de mudanças, mesmo quando estão realmente ocupados lidando
com seus cotidianos. Poderíamos refinar ainda mais a nossa mensagem
dizendo: "Estamos eliminando o incômodo de falar com as empresas de
mudanças". Isso é ótimo porque engloba rapidamente todos os tipos de
comunicação: "falar" pode significar via telefone ou e-mail. E estamos
dizendo por que a Moover é melhor: é livre de problemas. Essa versão de
nossa mensagem também é forte porque é positiva (a mensagem anterior
começou com o negativo "nunca") e está na fluência do cliente ("falar" em
vez de "comunicar" e "incômodo" em vez de "estresse").
Outro aspecto da sua mensagem é abordar a primeira impressão que
alguém pode ter sobre seu produto e se você precisa influenciar essa
impressão. Nossas primeiras impressões têm um grande efeito em nossas

atitudes. Por exemplo, na primeira vez que você vir um software 3D como a
Unity, ele parecerá impressionante e complexo. A Unity aborda isso em seu
site, afirmando especificamente: “Você pode criar qualquer jogo 2D ou 3D
com a Unity. Você pode fazer isso com facilidade”. Como outro exemplo,
o CleverPet é um console de jogos para cães e, à primeira vista, parece que
é apenas o jogo de memória Simon, apesar de custar US$ 299. O site da
CleverPet deixa bem claro que é "Uma plataforma. Jogos ilimitados ”. Esse
texto influencia sua primeira impressão ao saber que é mais do que apenas
o jogo Simon, e isso ajuda a justificar o preço de US$ 299.
Em suas anotações para o seu produto, anote também o que você

acredita que será a primeira impressão de cada pessoa sobre o seu
produto. Se você precisa causar uma certa impressão, escreva como você 285
pretende mudar a percepção.
Como Encontrar a Voz da sua Empresa

Depois de reunir suas anotações, pense em sua voz. Esta refere-se à fluência
e tom que você usará em seus materiais de marketing e propaganda,
possivelmente até mesmo dentro do produto, como em mensagens de
alerta. Basicamente, você quer ter um tom muito formal com seus clientes,
um tom casual, um tom “moderninho” ou um meio termo?
Tradicionalmente, os produtos empresariais assumiram um tom

formal para criar um sentimento de “negócios” e os produtos de
consumo adotaram um tom casual para criar um sentimento amigável e
acessível. A tendência predominante agora para os produtos corporativos
e de consumo é ter um tom mais casual e autêntico. No entanto, alguns
produtos B2B em campos altamente regulamentados como medicina e
finanças ainda precisam usar vozes muito formais e específicas, porque a
linguagem errada pode causar problemas legais.
Algumas empresas criarão diretrizes de estilo formais para a voz

de sua marca e exigirão que tudo, desde painéis de alerta no produto
até cada anúncio, estejam em conformidade com essas diretrizes. Isso
pode dificultar a adaptação da sua mensagem para diferentes clientes.
Em vez disso, recomendamos ter um senso geral da voz que você deseja
que sua marca tenha, mas use-a como ponto de partida e não como uma
abordagem obrigatória. Apenas se certifique de ficar consistente dentro
de cada meio/ mensagem! Será confuso se você começar uma carta com
"Caro senhor" e depois mudar para "E aí, rapaz" no próximo parágrafo.
Usar uma dicção semelhante para seus clientes pode ajudá-los a

286 entender rapidamente sua proposta de valor. Com produtos de consumo,
isso significa não usar o jargão da indústria. É provável que você precise
THE PRODUCT BOOK
riscar e reescrever algumas de suas descrições "por que o cliente deve

se importar?". Por exemplo, a Microsoft descreve seus dispositivos
Surface como "os dispositivos mais produtivos do planeta" e continua
descrevendo o Surface Book como "o laptop definitivo". De imediato,
você sabe que se está procurando um laptop de última geração, este é
o produto certo para você. Se você quer algo apenas para navegar na
internet, também sabe que esse não é o produto certo. Se a Microsoft
tivesse listado as especificações de CPU de cada dispositivo, a maioria dos
clientes não saberia qual produto analisar.
Com software corporativo ou produtos específicos e direcionados,

muitas vezes, você deve optar por usar certas palavras-chave que um
cliente esteja procurando. Por exemplo, se um chefe de TI de um hospital
estiver procurando comprar um sistema de registros médicos, ele
provavelmente se preocupa com a conformidade com as regulamentações
governamentais. Chamar a atenção para um nível específico de

conformidade como parte da mensagem ajudará o cliente a saber
rapidamente que esse produto atende exatamente às suas necessidades.
Uma maneira simples de se certificar de que você esteja usando

a dicção correta é perguntar como um cliente diria a um amigo sobre
seu produto. Se a dicção deles for parecida com a sua, excelente! Se for
muito diferente, reconsidere sua escolha de palavras. Você quer que sua
mensagem corresponda ao modo como seus clientes veem o mundo. Sua
mensagem ganha pontos de bônus se realmente criar imagens e evocar
emoções na mente de um cliente.
Juntando as Partes da Mensagem

Se você estivesse acompanhando, agora você tem algumas páginas de 287
anotações e ideias de como você poderia contar a um cliente sobre seu
produto. Isso é excelente porque, novamente, não há uma mensagem
que funcione para todas as pessoas em todas as mídias. Por exemplo, o
que você escreve em um comunicado de imprensa será diferente do que
está na página da rede do produto, e isso será diferente de como você
anuncia o produto na TV. Como outro exemplo, quantos sites você já
acessou que pediram para que você escolhesse uma persona escolhendo
entre textos “Para desenvolvedores” ou “Para designers”? As mensagens
serão diferentes em cada página, concentrando-se nas coisas com que
cada uma dessas pessoas se preocupa.
Embora você não seja responsável pela criação de anúncios, vale a pena
analisar os anúncios para entender como outras empresas expressam suas
mensagens. Passe algum tempo olhando sites e anúncios de produtos que
você usa ou conhece. O que a empresa está dizendo sobre cada produto? A
mensagem é explícita ou implícita? Que dicção ou imagem a empresa usa?
A publicidade em vídeo é realmente interessante de analisar porque a

mensagem é frequentemente implícita, e você terá que pensar sobre o que a
empresa estava tentando dizer. Então, observe como ela escolheu transmiti-
la: Para quais personas ela apelou? Como deixou claro as personas-alvo? Que
emoções o anúncio criou? Veja o anúncio clássico de 1984 da Apple ou o
anúncio Amor Parisiano (Parisian Love) do Google para ver dois exemplos
fantásticos. O 1984 enfoca como o Macintosh permite que você se destaque
e se liberte de suas restrições, já o Amor Parisiano examina como a pesquisa
muda sua vida, fornecendo as respostas de que você precisa. Também vale
a pena observar explicitamente que esses anúncios não se concentram no
produto. Eles se concentram em sua vida, na experiência que você deseja e
em como o produto pode ajudá-lo a ter essa experiência.
288
Em geral, é bom descobrir a mensagem mais curta possível que atrai
THE PRODUCT BOOK
mais pessoas. Você provavelmente usará muito essa mensagem, seja

como uma frase de efeito durante uma reunião com a imprensa ou como
o título na página do produto. Em seguida, crie mensagens diferentes,
mais específicas e mais segmentadas, conforme necessário, usando suas
anotações para orientá-lo.
É altamente recomendável tentar determinar essa breve mensagem

no início do ciclo de vida do desenvolvimento do produto e revisá-
la conforme necessário. Isso ajudará a manter as decisões de produto
focadas (elas adicionam/ subtraem à mensagem?) e fornecer um ponto
de partida para discussões sobre como colocar o produto no mercado.
Assim como escrever cenários de usuários para as partes interessadas
é o segredo para bons PRDs, escrever sua mensagem como uma história
pode ajudar a torná-la clara e repercutir mais nos clientes. Você pode até

usá-la para dar mais valor a algo novo que pode não parecer empolgante.
Por exemplo, se o seu novo recurso for uma seção de tutorial no site,
conte uma história sobre como o cliente pode usar esses tutoriais simples
para se tornar um especialista no produto muito rapidamente, deixando
seus colegas a comer poeira.
Por fim, lembre-se de que sua mensagem não é sobre o que o produto
faz, mas sobre o que o produto permite que o cliente faça. Os clientes
compram seu produto para melhorar suas vidas. Certifique-se de que sua
mensagem destaca claramente como seu produto ajudará seus clientes a
melhorar suas vidas.
289
DICA DO CAPÍTULO OITO
Essa dica vem de um incrível líder de produtos, Kirk Paulsen, vice-

presidente sênior de marketing da DxO. Por mais de uma década, Kirk
dirigiu o marketing mundial de produtos para todos os softwares de
fotos e serviços baseados em nuvem da sede da Apple em Cupertino.
Como executivo das empresas recém-criadas, Sonic e Spruce, ele
ajudou a lançar os primeiros sistemas de codificação e criação de
DVD disponíveis comercialmente no mundo. Kirk também foi um dos
primeiros especialistas em tecnologia a introduzir o próprio conceito de
sistemas de edição de áudio e vídeo baseados em computador para as
indústrias de música e cinema.
290
PEÇA AO DRI PARA EXPLICAR O RECURSO NO QUADRO
THE PRODUCT BOOK
BRANCO
Na minha experiência em uma determinada empresa com nome de fruta,
cada uma das nossas versões de aplicativos de software normalmente
envolvia dezenas de novos recursos e aprimoramentos. Para cada
lançamento, era tarefa do PM selecionar a lista completa até meia dúzia
de recursos de nível superior (TLF), que representavam a história desse
lançamento específico. Era da responsabilidade do PM apresentar o
TLF à equipe de marketing mais ampla, que incluía diretores de criação,
redatores, designers gráficos, etc. Era absolutamente essencial que a
mensagem fosse clara, concisa e apresentada com entusiasmo. Conte a
história corretamente, com clareza e paixão, e toda a equipe criativa se
envolverá para fazer o melhor trabalho possível para ajudá-lo a exibir o
produto. Se a mensagem carecesse de coesão ou viesse sem inspiração, a
equipe criativa poderia facilmente se desvencilhar, realizando um trabalho
medíocre, na melhor das hipóteses, o que invariavelmente resultaria na
indústria respondendo com um grande bocejo coletivo. A maneira mais
rápida para um PM perder o respeito da engenharia é tornar o produto

chato ou obscuro. Por outro lado, uma das melhores maneiras de um PM
ganhar reconhecimento de outras equipes é contar a história de maneira
articulada, envolvente e perspicaz.
Então, como exatamente você descobre como comunicar de forma

sucinta e eficaz a solução que tornará o cliente incrível?
Simples: para cada TLF, peça ao engenheiro ou cientista mais
diretamente responsável por essa parte específica para explicá-la em
detalhes, em termos leigos. O processo exige que você procure o indivíduo
diretamente responsável (DRI) para esse recurso ou tecnologia exata. Em
alguns casos, particularmente com pequenas empresas recém-criadas,
pode ser o fundador. Muitas vezes, é o arquiteto-chefe do produto quem
dirige a equipe de engenharia. Em uma empresa listada na Fortune 100,
pode muito bem ser um cientista tímido, mas brilhante, que trabalha
291
dentro de uma pequena equipe entre uma vasta organização de Pesquisa e
Desenvolvimento. O que posso garantir é que não será alguém um pouco
próximo do recurso, mas não diretamente envolvido. Em vez disso, deve
ser o DRI, a pessoa que codificou, projetou, criou ou dirigiu o trabalho que
levou a esse recurso específico. Na Sonic Solutions, foi o Dr. Andy Moorer,
na Apple, geralmente era Randy Ubillos, e no DxO, o Dr. Frédéric Guichard.
Quando você dedicar um tempo para identificar o DRI preciso para esse
recurso ou tecnologia específica, descobrirá que essa pessoa, e somente
essa pessoa, é capaz de explicar isso a você com mais profundidade e
clareza do que você poderia imaginar. O mais importante é que você terá
a oportunidade de sentir em primeira mão a paixão pessoal pelo produto
e obter uma melhor compreensão do verdadeiro benefício da solução
como ela originalmente concebeu. Na minha experiência, esse processo
normalmente envolvia uma sessão privada individual ou uma reunião
muito seleta, mas nunca um grupo grande. E, na minha experiência, sempre,
sempre envolvia um quadro branco, porque nunca conheci um engenheiro
ou cientista que não quisesse se expressar com um marcador apagável.
Depois de ouvir atentamente a descrição do recurso ou da tecnologia,

é essencial que você tente canalizar imediatamente a voz deles e repita o
que acabou de aprender, como em “Então, estaria correto em descrever
isso como…?”. O processo, que envolve audição focalizada e anotações
detalhadas, pode requerer várias interações antes que você esteja em
completa harmonia com o DRI e seja capaz de articular perfeitamente,
em termos leigos, a solução. Siga esta dica e você, como PM, estará
devidamente equipado para contar uma ótima história para a equipe de
marketing criativo, e que o ajudará a compartilhar sua mensagem com a
indústria, a mídia, os parceiros de canal e seus futuros clientes incríveis.
292
THE PRODUCT BOOK
RUMO AO MERCADO
É tentador pensar que, uma vez concluído o desenvolvimento e você tiver
reunido uma mensagem inicial do produto no PRD, basta dar o produto

para a equipe de marketing/ vendas e deixá-los fazer o que bem quiserem.
Mas o que acontece se, durante o lançamento, seu servidor falhar e sua
equipe de engenharia estiver fora do escritório comemorando? Ou pior, e
se a equipe de marketing não entender completamente os novos recursos
do produto, segmentar os PR/ pontos de publicidade errados e ninguém
aparecer para o lançamento?
Muitas empresas criam listas de verificação de lançamento, modelos

pré-definidos das informações que a equipe de marketing precisa para
lançar um produto. Mas o problema é que nem todo lançamento de
produto é da mesma forma, seja em termos do produto que você está
lançando ou de como as pessoas recebem informações. Por exemplo, o
293
lançamento de um grande produto pode justificar um evento que você
transmite ao vivo. Cinco anos atrás, a transmissão ao vivo não era uma
opção fácil. Em alguns anos, a transmissão ao vivo em realidade virtual
ou outra forma que não podemos imaginar agora pode se tornar padrão.
E se você estiver lançando uma nova versão de um pequeno recurso,
provavelmente não precisará de uma transmissão ao vivo.
Uma ótima maneira de lançar um produto é identificar o proprietário

do lançamento desde o início, formar uma equipe com representantes de
cada grupo-chave (Design, Engenharia, Produto, Suporte e Marketing)
e estabelecer objetivos e responsabilidades de lançamento claros para o
mercado (GTM). Às vezes, o proprietário do lançamento é o PM, mas os
PMs estão sempre ocupados o suficiente para que outra pessoa da equipe
de marketing assuma essa função. Embora o proprietário do lançamento
organize e gerencie o plano do GTM, cada departamento contribuirá
para isso. A cada semana, a equipe se reunirá para garantir que tudo
esteja a caminho para garantir um lançamento bem-sucedido, além de
comunicar quaisquer atrasos ou problemas e discutir soluções.
Para essas reuniões, é útil criar um rastreador de lançamento para

organizar o lançamento. Três folhas em uma planilha são suficientes.
A primeira folha conterá os itens de ação. Essas são tarefas específi-
cas, designadas a uma pessoa/ equipe em particular, juntamente com
detalhes de quando cada tarefa foi atribuída, seus prazos de entrega e
quaisquer atualizações de comentários/ status apropriadas para a tare-
fa. A segunda planilha conterá itens de precaução. Estes são possíveis
problemas, juntamente com quem os criou, quando criaram, quando
cada problema foi resolvido e quaisquer comentários. A última folha
terá as principais decisões, incluindo quem tomou as decisões, quando
e quaisquer comentários.
294 Da mesma forma que o PRD é um documento vivo que atua como
o principal recurso do produto enquanto você constrói o produto, este
THE PRODUCT BOOK
rastreador de lançamento será sua referência de lançamento.
Muito do trabalho que você fez até agora, desde identificar seus
clientes-alvo até analisar a concorrência e desenvolver mensagens de
produtos para cada persona, informará sua estratégia geral e influenciará
as decisões tomadas dentro do plano do GTM. Tenha isso em mente
enquanto lê esta seção!
Em um nível elevado, o plano do GTM é subdividido em três seções:

pré-lançamento, lançamento e pós-lançamento. Vamos dar uma olhada
em cada uma.
Planejamento de Pré-lançamento
As principais decisões a serem tomadas durante o pré-lançamento são
as principais metas de lançamento, como você garantirá que o produto

esteja pronto para o lançamento, quando e como você lançará o produto
e quais recursos serão necessários para o lançamento.
Objetivos do Lançamento
Lançamentos têm finalidades diferentes. Para alguns produtos, como
o smartphone do Google Pixel mais recente, é provável que o objetivo
seja o maior número possível de clientes atuais comprarem a nova
versão do smartphone ou novos clientes comprarem o smartphone.
Para softwares corporativos como o Salesforce, a meta pode estar em
receber um subconjunto de clientes envolvidos com um novo recurso.
Às vezes, o objetivo é simplesmente a conscientização de um novo
recurso, de modo que, quando o cliente for inserido no ciclo de compra,
295
seu produto estará em sua mente.
Identificar seus principais objetivos antecipadamente permitirá que
você tome outras decisões de lançamento, como quando tentar lançar
o seu produto.
Data do Lançamento
Após o objetivo de lançamento, a maioria das equipes de lançamento
identifica quando deseja lançar o produto. Às vezes, essa será uma data
específica, mas geralmente será um período. Por exemplo, os lançamentos
de produtos de consumo tendem a acontecer no início do ano, no final de
abril/ início de maio para a janela de “pais e formandos” (Dia dos Pais e
graduação), ou após o verão, mas antes da Black Friday.
É importante escolher essa janela de lançamento o mais cedo possível,
pois isso pode afetar o desenvolvimento de seu produto. Se você estiver
vendendo um produto de consumo e a equipe de desenvolvimento achar
que ele estará pronto para o lançamento em 26 de dezembro, você perderá
a janela inteira desde a Black Friday até o Natal, quando os produtos
de consumo vendem muito bem. Se você deseja que o produto esteja
disponível para compras no Natal, reduza o escopo do produto para que
ele fique pronto a tempo.
Às vezes, as empresas também têm períodos de compra que você pode
precisar para agendar o lançamento. As escolas, muitas vezes, compram
produtos na primavera e no verão, antes do início do próximo ano letivo.
Às vezes, as empresas têm um orçamento extra que precisam gastar
antes do final do ano, então compram mais em dezembro. Entender seus
clientes e seus hábitos de compra ajudará a identificar a melhor janela de
lançamento para seu produto.
Para lançamentos de recursos para produtos existentes, o tempo de
lançamento depende do tipo e meta do lançamento. Se é uma grande
atualização que incentiva novos clientes a comprar seu produto, você
296 provavelmente o trata como um novo produto e alinha o lançamento com
os hábitos de compra de seus clientes. A data dos lançamentos menores
THE PRODUCT BOOK
varia muito. A única regra prática para esses lançamentos menores é

lançar no início da semana para que, caso surjam problemas de suporte,
sua equipe não precise trabalhar no fim de semana para solucioná-los.
Se o recurso for uma correção de erro para um problema de segurança
crítico, sua meta de lançamento é disponibilizar isso para o maior
número possível de clientes, o mais rápido possível. Se for uma pequena
atualização criada para melhorar o produto para clientes existentes, sua
meta também será a de atualizar o maior número possível de clientes
existentes, mas não será tão urgente. Se o cliente tiver de tomar uma ação
inconveniente para fazer a atualização explicitamente, como reiniciar
um computador, agende seu lançamento para equilibrar o valor do
lançamento com a inconveniência de fazer uma atualização.
Felizmente, novas ferramentas, como a Mac App Store e a Windows
Store, facilitam as atualizações para seus clientes, manipulando
automaticamente as ações inconvenientes, como reiniciar quando os

clientes estiverem longe de seus computadores.
Uma pergunta comum é: o que significa o lançamento e como você
escolhe uma data quando tem uma equipe ágil, produzindo produtos
utilizáveis no final de cada sprint ou ciclo? Depende! Para recursos pequenos
e correções de erros no sistema, muitas empresas nem se importam com um
plano de lançamento e apenas implantam o recurso quando ele está pronto
(contanto que não seja em uma sexta-feira). Para versões maiores, como
um novo recurso importante, a empresa pode optar por implantar o código
internamente, mas não liberá-lo publicamente até uma determinada data.
O scrum torna isso fácil porque você escolherá um sprint cuja
data esteja alinhada com sua janela de lançamento para ser o sprint
de lançamento. Os cálculos de velocidade e as estimativas de ponto
de história proporcionam uma boa ideia sobre o trabalho que estará 297
disponível nesta data. É sempre bom que o sprint de pré-lançamento seja
dedicado a qualquer tarefa de última hora relacionada ao lançamento, e
durante a fase de pré-lançamento você terá a certeza de que cada sprint
esteja dentro do prazo para o lançamento.
Durante cada reunião da equipe de lançamento, um ponto de
discussão será: tudo ainda está no caminho certo quanto ao produto? Se
você perceber que a velocidade está caindo, talvez seja necessário ajustar
seus planos de lançamento.
Depois de escolher uma possível data de lançamento, você estabelecerá
uma programação de trabalho para determinar quais tarefas você precisa
fazer quando estiver se preparando para o lançamento - ou seja, na semana
anterior ao lançamento, você fará coletivas de imprensa - duas semanas
antes, os recursos de vídeo precisam estar prontos - e assim por diante.
Testando
Como parte da preparação para o lançamento de seu produto, é importante
criar um plano para testá-lo com clientes reais, para que você possa
garantir que o produto forneça suas métricas de sucesso. Geralmente,
as empresas fazem um lançamento interno de um produto. O objetivo é
garantir que tudo funcione como esperado e detectar os principais erros
antes de exibir o produto a qualquer cliente externo.
Em seguida, as empresas fazem um beta mais amplo, onde mostram o
produto para um pequeno grupo de clientes externos. Isso pode ser feito
por meio de um convite exclusivo para os principais colaboradores de seu
fórum de suporte ou por meio de um sistema de inclusão automático. O
primeiro é uma abordagem melhor para lançamentos maiores, em que
você tem novos recursos específicos que você deseja que os clientes testem.
Criar um grupo seleto de clientes para fornecer acesso antecipado é útil,
pois oferece a você um grupo de pessoas que usam seu produto ativamente,
298
e é mais provável que usem os novos recursos e tenham avaliações valiosas
a fazer. O acesso antecipado também faz com que esses clientes se sintam
THE PRODUCT BOOK
especiais e, com frequência, desejem compartilhar esse status com o mundo

quando o produto for lançado. Além disso, esse grupo muitas vezes se
torna especialista em produtos, fornecendo dicas e suporte a outros clientes
e defendendo seu produto entre seus colegas.
A inclusão automática é mais comum em aplicativos da rede com um
grande número de usuários, onde você pode ativar o recurso por um curto
período de tempo para 1% de seus clientes e obter avaliações importantes.
A opção de inclusão automático é fantástico, pois oferece dados reais de
clientes reais, provavelmente expondo o produto a muito mais clientes do
que os que optariam manualmente por um teste beta. Mas isso torna difícil
manter o novo produto em segredo, basta observar com que frequência
as pessoas relatam ter visto novos recursos do Facebook antes de um
anúncio oficial. A ativação automática também pode gerar reclamações
ou uma queda temporária em suas métricas de sucesso, mas esses dados
o ajudarão a melhorar o produto para que ele tenha um lançamento bem-
sucedido. Muitas empresas criaram ferramentas internas para permitir

o lançamento/ teste de recursos seletivos, e o LaunchDarkly criou uma
ferramenta de uso geral que qualquer pessoa pode usar.
O segredo para planejar uma versão beta é pensar em como o seu
lançamento precisa ser perfeito. Se o seu produto for um aplicativo
para dispositivos móveis e novos clientes o encontrarem com erros, eles
o excluirão e provavelmente nunca o reinstalarão. O hardware é ainda
menos tolerante, porque um cliente devolverá seu produto e isso lhe
custará caro.
Os aplicativos da rede tendem a ser muito tolerantes, pois você
pode atualizá-los várias vezes por hora sem que o cliente precise fazer
nada. É claro que, se você aderir estritamente à metodologia enxuta,
fará testes mínimos, se houver algum, e continuará lançando-os o mais
rápido possível. Mas, como mencionamos anteriormente, a maioria das 299
empresas adotam uma abordagem híbrida, o que significa que você terá
algum tipo de beta. Você será proprietário ou estará envolvido em testes
de produtos.
Algumas coisas importantes que o ajudarão a executar um teste beta

bem-sucedido:
• Certifique-se de que seu grupo beta corresponda à sua(s)

persona(s) alvo. Isso garantirá que as pessoas que estão testando
sejam as pessoas que você realmente deseja alcançar
• Teste suas mensagens do produto com qualquer alcance que

puder. Se você enviar um e-mail a alguns clientes clientes para
convidá-los para a versão beta, inclua as mensagens do produto
que você acha que farão com que eles queiram usar o produto.
Também é possível enviar mensagens de teste A/ B para a mesma
persona, para que você possa testar qual mensagem recebida faz
com que mais pessoas queiram se inscrever na versão beta.
• Assegure-se de ter a integração apropriada. A integração é a

primeira experiência que um cliente tem com seu produto ou
versão atualizada. No produto de envio e nos betas posteriores,
normalmente é onde você destaca os principais recursos e explica
por que eles são úteis e relevantes. Em um contexto beta, a
integração é muito importante, pois inclui instruções específicas
de teste, como qual parte do produto é especificamente testada
ou quais partes você sabe que ainda não funcionam. Às vezes,
uma experiência de integração é tão simples quanto um e-mail de
notas de lançamento com instruções para instalar a versão beta.
300
• Tenha mecanismos de avaliação em vigor. Certifique-se de ter
THE PRODUCT BOOK
ferramentas de análise quantitativas para medir suas métricas

de sucesso e capturar qualquer histórico de falhas, fornecer um,
mecanismo de avaliação qualitativa, como Qualaroo ou UserVoice,
para que os clientes possam dizer o que pensam e contactá-lo
com problemas, e fazer acompanhamento com os clientes para
ver o que eles pensam. Fóruns beta especiais podem fornecer
uma ótespeciais são uma excelente maneira dos testadores beta
interagirem, fornecerem avaliação e ajudarem uns aos outros. As
peças-chave de avaliação a serem pesquisadas são a capacidade
de descoberta, o envolvimento, a repetição do produto (se as
pessoas voltam a usá-lo), os casos de utilização reais e as barreiras
à adoção do mesmo.
• Analise suas avaliações e use-as para informar as decisões de
lançamento. Os testes Beta permitem que você veja se seu produto
atende às necessidades dos clientes com êxito e ajuda a atingir

suas métricas de sucesso com um pequeno grupo. Isso fornece
dados úteis sobre as coisas que você desejará abordar antes do
lançamento, como erros ou outras barreiras à adoção que muitos
clientes enfrentaram. Às vezes, você pode descobrir que um recurso
não pode ser encontrado e precisa adicionar especificamente um
texto explicativo ou uma experiência de integração para orientar
os clientes sobre o uso. Às vezes, você descobrirá que algo não
funciona como esperado no mundo real e você decidirá remover o
recurso. Ocasionalmente, você descobrirá que todo o produto não
é bom e os clientes não o utilizam, e você cancelará o lançamento.
O resultado mais comum de um teste beta é que você use os
resultados para fazer algumas pequenas alterações e correções de
erros, e depois faça outro teste beta. Depois de algumas iterações 301
com amostras maiores em cada, o produto estará pronto para ser
pproduto estará pronto para ser lançado.
Ao criar um plano de GTM, estabeleça quando você deseja executar

cada fase de teste, o que você deseja obter em cada fase e quem será o
proprietário - geralmente, o suporte ou o PM será o proprietário dos
testes. Certifique-se de planejar o tempo para reagir à avaliação dos betas
antes do lançamento.
Para alguns produtos, você também desejará executar testes de
estresse com a Engenharia durante a fase de pré-lançamento para
garantir que suas capacidades técnicas possam atender a qualquer
demanda. Por exemplo, alguns produtos muito populares geram tanto
interesse que seus servidores da rede falham devido ao pico súbito de
visitantes. É muito comum adicionar uma tarefa de inicialização para que
a Engenharia amplie a capacidade do seu servidor virtual durante uma
janela de ativação, até que o tráfego tenha nivelado a um nível previsível.
Qual Tipo de Lançamento?

Pense em lançamentos de produtos que você já viu antes. Às vezes, você
apenas nota um novo botão na UX com uma dica pop-up dizendo para
você verificar algo novo. Outras vezes, você não faz nada por algumas
horas porque está assistindo a uma apresentação da Apple ou do Google,
grandes eventos que chamamos de "grandes lançamentos".
É importante alinhar o tipo de lançamento que você faz com o escopo
do produto e sua capacidade. Se você não fizer isso, seu produto pode
acabar ou até se transformar na piada da vez. Em 2011, uma empresa
recém-criada de compartilhamento de fotos de aplicativos móveis
chamada Color focou em anúncios de dimensões enormes. Recebeu US$
41 milhões em financiamento logo de cara, o que foi bastante também.
302 Em seguida, lançou seu aplicativo com grande alarde, mas houve um
problema: a Color focou em compartilhar com usuários próximos, mas
THE PRODUCT BOOK
a maioria das pessoas que baixou a Color descobriu que eram os únicos
que usavam o aplicativo nas proximidades e pararam de usá-lo. O pré-
lançamento de teste ruim da Color falhou em descobrir esse problema.
Nos próximos meses, a empresa fez mudanças para resolver esses
problemas, mas perdeu seu ímpeto e a empresa fechou em 2012.
Resumindo, o produto não estava pronto, a empresa fez um grande
lançamento, as pessoas deram uma chance ao produto e ficaram
desapontados, e a Color nunca teve uma segunda chance.
Como alternativa, veja produtos como o Gmail. O Google testou
internamente e lançou-o como uma versão beta somente para convidados.
Além de dar ao Google a chance de descobrir e corrigir problemas antes
que o Gmail se tornasse popular, criou um sentimento de exclusividade e
demanda pelo produto. Agora imagine que o novo recurso pelo qual você
é responsável seja adicionar um botão de "assistir offline" ao aplicativo
para celular do YouTube. Embora isso possa ser um ótimo recurso, é
provável que você não precise de um grande evento para lançá-lo. Em

vez disso, trabalhar com a imprensa para obter artigos sobre vários sites
de notícias sobre tecnologia e mídia e permitir que usuários existentes
saibam sobre o recurso, seja no aplicativo ou via comunicação direta,
pode ser suficiente para atingir suas metas de lançamento.
Pequenos eventos podem ser outra ótima maneira de efetivamente
lançar e alcançar os principais influenciadores. Por exemplo, se a Sonos
estivesse lançando uma nova linha de alto-falantes, poderia fazer o seguinte:
alugar uma mansão, instalar o sistema de alto-falantes da Sonos, convidar
os principais clientes, parceiros e membros da imprensa especializados
em tecnologia e audiófilos, e esperar que esses influenciadores escrevam
para as mídias em que os clientes da Sonos leem.
Às vezes, você trabalha com um produto que o cliente realmente
precisa experimentar para entender, especialmente se for um produto 303
caro. Você compraria um carro apenas com base em uma resenha, ou
você gostaria de testá-lo primeiro? Para esses produtos, você precisará de
uma estratégia de lançamento que seja muito voltada para o usuário, tanto
para o lançamento inicial quanto para os eventos de acompanhamento
que permitem que os clientes experimentem o produto. O espaço VR/
AR (realidade virtual/realidade aumentada) é um ótimo exemplo. A
melhor maneira de as pessoas entenderem por que o VR/ AR é atraente
seria elas experimentarem por si mesmas. Quando a HTC lançou seu
sistema de alto-acabamento Vive VR, ela tinha uma exposição itinerante
onde os clientes podiam experimentar a Vive em trailers especialmente
construídos para isto.
Esses são os principais pontos a se pensar quanto ao seu tipo de
lançamento:
• Quais personas se preocupam com esse recurso e com quais
clientes eles mapeiam?
• Como você alcançará novos clientes?
• Como você alcança clientes existentes?
• Qual é o seu objetivo de lançamento, além de alcançar os clientes
certos com eficiência?
Se você tiver um novo produto ou uma nova versão significativa de

um produto existente, convém alcançar novos clientes e clientes
existentes, e um grande evento pode ser apropriado. Se você tem um
grande novo recurso, um evento pequeno ou uma série de coletivas
de imprensa focadas em alcançar os clientes existentes e alguns novos
clientes provavelmente são mais apropriados. Se trata-se de um novo
recurso pequeno, atingir os clientes existentes é mais importante do que
garantir a cobertura da imprensa.
304 Para uma pequena empresa que luta por atenção, lançamentos de
sucesso podem ser difíceis. Você pode fazer tudo perfeitamente, mas se
THE PRODUCT BOOK
os clientes não aparecerem, nada importará. Uma abordagem simples

é criar uma lista de e-mail de pré-lançamento de clientes interessados.
Uma página de destino "conte-me mais" para seu produto é uma maneira
simples de capturar endereços de e-mail. Isso garante que você alcance
pessoas que estejam explicitamente interessadas em seu produto.
Você deve garantir que seus métodos de divulgação correspondam à
sua capacidade. Se você tem um vendedor que envia e-mails manualmente
e faz chamadas, ele será capaz de lidar com o volume se quiser que ele
alcance milhares de clientes no dia em que o produto for lançado?
Muitas empresas menores optam por trabalhar com uma agência de
relações públicas que tenha conexões em vários meios de comunicação
para ajudar a obter cobertura nos lugares certos que sua persona-alvo
procurar. Essa é outra razão pela qual saber como seus clientes-alvo
encontram informações - parte do Quadro do Modelo de Negócios - é
importante: permite que você seja eficiente!
Depois de escolher como você deseja iniciar, você alinhará seu

planejamento de lançamento para fornecer o que precisa para tornar esse
método bem-sucedido.
Planejamento de Recursos de Lançamento

Não importa o quão pequeno seja o evento de lançamento que você es-
teja planejando, a equipe de lançamento sempre acabará criando vários
recursos para acompanhar o lançamento do produto. Como Product Ma-
nager, muitas vezes você participa da criação desses recursos de lança-
mento, mesmo que outras pessoas lidem com os detalhes. Recursos de
lançamento específicos a serem considerados incluem o seguinte:
• Atualizações do site. Como a página do produto será atualizada

em seu site? 305
• Documentação de suporte. O que precisa ser atualizado na

página de suporte do seu produto para a nova versão? Existe novo
material de treinamento a ser criado antecipadamente?
• Amostra de vídeo/ imagens. Você precisa criar novas capturas de

tela para a App Store ou onde quer que você distribua o produto?
• Postagens no blog e outros materiais de mídia social. Qual material

você deseja criar para o lançamento do produto nos canais de mídia
social/ blog da sua empresa? Esses pontos de venda são chamados
de mídia própria porque você os controla e deseja garantir que eles
suportem suas metas de lançamento/ empresa.
• Anúncios. Você pretende ter algum material publicitário para o
lançamento do seu produto? Nesse caso, você precisará criar a
mídia com antecedência.
• Plano de demonstração. Quando os representantes da empresa

estiverem mostrando o produto, como eles demonstrarão o novo
produto? Ou, se você estiver lançando uma nova versão/ recurso,
como isso afeta os planos de demonstração existentes?
• Necessidades de revisão de distribuição. As lojas de aplicativos,

como a App Store, geralmente exigem logins de revisores especiais
ou demonstrações de vídeo para que eles possam garantir que seu
aplicativo funcione conforme planejado. Você tem que criar algo
para esse processo?
306 • Perguntas e Respostas internas do produto. Se você planeja

participar de conferências de imprensa como parte do lançamento,
THE PRODUCT BOOK
também é útil criar uma FAQ interna do produto com as perguntas

que você espera obter sobre o produto por parte dos repórteres. Ter
respostas claras e voltadas à mensagem para perguntas comuns,
incluindo perguntas difíceis que possam perguntar, ajuda quem
estiver responsável por passar as instruções para a imprensa a se
preparar de maneira eficaz.
• Materiais de treinamento da equipe de suporte. Embora as

equipes de design, engenharia e produto provavelmente estejam
familiarizadas com o produto quando o lançamento chegar,
as equipes de suporte podem não estar tão familiarizadas.
Crie materiais para eles com os problemas mais comuns que
os clientes enfrentarão e as soluções. Use o que você aprendeu
durante os períodos de teste para avaliar os problemas mais
prováveis. Durante e após o lançamento, atualize estes materiais
de treinamento com quaisquer novas perguntas que surgirem.

• Materiais de treinamento da equipe de vendas. Como no suporte,
é importante criar materiais para a equipe de vendas para que os
representantes entendam claramente o valor do produto.
Esses materiais devem se concentrar em entender as principais personas

compradoras e o que o produto oferece para elas. Para clientes existentes,
forneça informações de migração para que a equipe de vendas possa
ajudar a garantir migrações sem problemas.
Embora não seja um recurso explícito, lembre-se de trabalhar

adequadamente com qualquer parceiro externo para que ele não seja pego
de surpresa no lançamento. Por exemplo, com a Moover, queremos garantir 307
que as empresas de mudanças foram notificadas e ajudaram a testar nosso
recurso de mensagens. Podemos até optar por lançar o painel de rede
atualizado com a ajuda deles, discretamente, antes de iniciar o aplicativo
para dar suporte a um teste beta.
Uma Estrutura Útil de Marketing de Pré-lançamento

Existe uma estrutura de marketing que é muito útil para a equipe de
lançamento ter em mente ao determinar como lançar um produto. Essa
estrutura, chamada de quadros de trabalho 4Ps, é um guia para tomar
decisões de marketing e um lembrete das principais decisões que você
precisa tomar ao lançar um produto. Os P representam produto, preço,
promoção e ponto. Vamos verificar a fundo cada um.
Produto inclui as partes óbvias do produto (o que é, para quem, qual
é o benefício?) junto com o não óbvio. Elementos não óbvios incluem a
política de embalagem, acessórios, suporte, garantia e devolução. Uma
maneira útil de lembrar esses elementos não óbvios é que eles são coisas
que o cliente encontra depois de comprar o produto. Por exemplo, depois
de comprá-lo, você retira o mesmo de sua caixa. Ou você compra um
acessório. Ou você tem um problema e entra em contato com o suporte.
Preço refere-se ao que você cobra - tanto transações normais quanto
diárias e com possíveis descontos por volume e venda.
Determinar o preço certo pode ser bastante complexo e é influenciado
pelos objetivos do produto e pelo modelo de negócios desejado. Jogos
sociais são gratuitos para jogar, justamente para que o maior número
possível de pessoas baixe os jogos, o que permite um jogo social melhor. Por
vezes, os anúncios ajudam a fornecer uma pequena renda para cada cliente,
e as compras no aplicativo ajudam a gerar renda de clientes engajados e,
ao mesmo tempo, tornam o jogo melhor para eles. O preço do hardware
é comumente baseado no preço do componente, mas às vezes as empresas
308 usam um modelo de lâmina e vendem o hardware do núcleo com prejuízo,
ganhando dinheiro com software e acessórios. Como Product Manager,
THE PRODUCT BOOK
muitas vezes, você tem informações sobre a estratégia de fixação de preços,

pois o preço é influenciado pelos objetivos do produto e tem um impacto
nas métricas de sucesso e no planejamento do produto.
O próximo P é para promoção. É nisso que pensamos tradicionalmente
com o marketing: como será o seu comunicado de imprensa? Quais
anúncios você criará? Como a equipe de vendas alcançará os clientes?
Finalmente, chegamos ao ponto. Onde seus clientes encontram seu
produto para venda? É só no seu site? Está em pontos de lojas específicas,
virtuais ou físicas? A chave aqui é garantir que o ponto esteja alinhado com
o local em que seus clientes-alvo vão para encontrar os produtos. Alguns
clientes não se sentem seguros comprando de um site de uma empresa
que não possui nome, por exemplo. Eles podem estar interessados em
seu produto, mas eles vão comprá-lo apenas quando estiver disponível
na Amazon. Ou talvez os clientes esperem que seu aplicativo esteja
na Google Play Store, e eles o procurarão por lá em vez de na loja de
aplicativos da Amazon. Se você não estiver vendendo onde seus clientes

estiverem procurando, você perderá.
Lançamento
O bom do planejamento antes do lançamento é que, durante o lançamento,
você está basicamente apenas executando seu plano, o que é relativamente
relaxante e até divertido!
Os Product Managers geralmente são porta-vozes da empresa e
recomendamos que você trabalhe com sua equipe de comunicação para se
certificar de que fale bem e conheça as principais mensagens do produto.
E, claro, se você estiver falando para um público, tenha o cuidado de ter
a melhor aparência, lavar as mãos, aparar as unhas e apresentar uma
imagem profissional.
De volta ao escritório, as equipes de engenharia e suporte devem querer 309
observar para garantir que tudo esteja funcionando corretamente e que
os clientes estejam recebendo o auxílio de que precisam. Você, como PM,
também vai querer trabalhar com eles para procurar por quaisquer erros
críticos que você possa ter perdido durante a fase de testes. Tenha um
plano em andamento com a Engenharia antecipadamente para avaliar,
reparar e atualizar esses erros, conforme necessário. Mas além disso, você
pode respirar e observar como seus clientes reagem ao seu trabalho duro.
Chamamos de mídia conquistada as postagens de mídia social que seus
clientes escrevem, as avaliações que seu produto recebe e os artigos que a
imprensa escreve sobre sua mídia de produto, porque você não a controla
e muito menos pagou por ela. A mídia conquistada é muito valiosa
porque significa que as pessoas acham seu produto digno de ser relatado.
Claro que corre o risco deles não gostarem e a mídia conquistada não ser
positiva. Felizmente, a maioria das pessoas, especialmente os profissionais,
geralmente preferem não escrever um comentário em vez de escrever algo
negativo.
Pós-lançamento
No Capítulo 9, entraremos em mais detalhes sobre o que você, o PM,
fará após o lançamento. A maior parte do seu trabalho será focada
internamente, avaliando resultados e métricas iniciais e planejando o que
virá a seguir. As equipes de marketing e vendas se concentrarão em como
promover e vender a nova versão atual. Definiremos brevemente alguns
termos que você poderá ouvir ao trabalhar com essas equipes.
O Ciclo de Vida do Cliente

Assim como pensamos em funis de produtos com análises (abordados
no Capítulo 3), o marketing também pensa em funis. Mais ou menos. O
marketing de produto tornou-se complexo o suficiente para que muitas
310 pessoas pensem em se envolver com os clientes como um ciclo chamado
ciclo de vida do cliente.
THE PRODUCT BOOK
Os clientes, muitas vezes, iniciam sua jornada com as fases de

conscientização, interesse e engajamento. Isso significa simplesmente que
as pessoas conhecem seu produto e procuram aprender mais. As equipes
de marketing geralmente pagam por anúncios gráficos e sociais para
atrair mais clientes nessa parte do funil. Um anúncio gráfico é o anúncio
visual típico em que pensamos, como um anúncio em uma revista ou um
anúncio em banner. Um anúncio social é um anúncio que você paga em
uma rede social, seja um anúncio de texto no Twitter ou uma imagem no
Instagram. O que os profissionais de marketing adoram no marketing
on-line é que ele pode ser muito segmentado. Ao contrário de um
anúncio de jornal que muitas pessoas veem, os anúncios on-line podem
ser exibidos apenas para mulheres de 31 anos que estejam interessadas
em videogames casuais. Isso ajuda a garantir que sua publicidade chegue
às pessoas certas!
A próxima fase do ciclo de vida é fazer com que as pessoas confiem que
seu produto cumprirá sua promessa e a comprá-lo - oferecer garantias de
devolução do dinheiro é uma técnica comum aqui. Geralmente, inclui a

busca de opiniões de colegas e a realização de pesquisas sobre o produto,
como a busca de resenhas.
O marketing de afiliados pode ajudar a mover os clientes por essas
etapas. O marketing de afiliados é quando uma fonte confiável recebe um
pequeno pagamento para incentivar seu público a comprar seu produto.
Os clientes estão felizes porque agora sentem que podem confiar em seu
produto, os afiliados estão satisfeitos porque receberam um pagamento
por seu aconselhamento especializado e a sua empresa está feliz porque
tem um novo cliente. Às vezes, as empresas fornecem ofertas especiais
para seus parceiros afiliados, como códigos de desconto, o que incentiva
ainda mais os clientes a comprarem seu produto.
As últimas fases do ciclo de vida do cliente são sobre a satisfação e
defesa do cliente. O objetivo final do ciclo de vida do cliente é ter clientes 311
defendendo você. O boca-a-boca é um dos fatores mais importantes para
as pessoas comprarem certos produtos, e traz novos clientes para o ciclo
de vida do cliente, tornando-os cientes do seu produto. Embora a equipe
de suporte desempenhe o papel mais importante nessa fase, garantindo
que os clientes tenham uma experiência positiva, a equipe de marketing
também ajudará com a retenção e a fidelidade do cliente para que, por sua
vez, recomendem o produto novamente. Eles podem fazer isso enviando
roupas como camisetas aos clientes ou enviando ofertas especiais para
fazer com que o cliente faça outra transação. Se você já tentou cancelar
seu serviço a cabo, por telefone ou pela Internet, provavelmente se
encontrou falando com uma pessoa cujo trabalho é fazer de tudo para
mantê-lo como cliente, como oferecer um bom negócio.
À medida que um cliente passa por cada fase, você precisa verificar se
ele vê as mensagens e os materiais apropriados. Você não precisa mostrar
uma garantia de devolução do dinheiro, o que ajuda na fase de confiança,
quando estiver tentando conscientizar as pessoas sobre seu produto.
Mensagens diferentes são importantes quando se trabalha com
otimização de mecanismos de busca e marketing (SEO / SEM). Esse é
um domínio inteiro, e não vamos aprofundá-lo, mas SEO refere-se a
como você otimiza seu site para que, quando as pessoas pesquisarem
por palavras-chave, você seja o resultado relevante. O SEM é quando
você paga para que um anúncio do seu site seja exibido com base em
determinadas palavras-chave.
Termos de Medição de Custo de Marketing

Com todas essas abordagens, há alguns termos-chave dos quais você deve
estar ciente, pois, às vezes, surgem durante reuniões estratégicas entre a
equipe de produto e de marketing:

312 • Pagar por impressão (PPI): Você paga pelo anúncio sempre que
ele é exibido. Impressão significa "alguém que viu o anúncio".
THE PRODUCT BOOK
• Pagar por clique (PPC): Você paga pelo anúncio apenas quando
alguém clica nele.
• Pagar por ação (PPA): Você paga apenas quando o usuário realiza
alguma ação final, como baixar o seu aplicativo.
• Taxa de cliques (CTR): A porcentagem de pessoas que clicam no

seu anúncio.
• Custo por impressão (CPI) / custo por mil impressões (CPM):
é quanto você paga para exibir seu anúncio uma vez (CPI), mais
comumente listado em comparação ao custo para exibi-lo 1.000
vezes (CPM). Isso pode ser usado para avaliar a eficácia de uma
campanha. É simplesmente o custo de publicidade dividido pelo
número de impressões.

• Custo por clique (CPC): Esse é o preço real que você paga por cada
clique em sua publicidade PPC. Em sistemas baseados em lances,
como no Google e no Bing, isso pode ser menor do que o preço
inserido. Por exemplo, se você colocasse o lance mais alto em $2 /
clique, o que significa que você pagaria no máximo $2 por clique,
o valor real que você pagará dependerá de vários fatores, como o
lance do concorrente mais próximo e a qualidade do seu anúncio.
O CPC é usado com frequência quando há um orçamento diário
para exibir anúncios gráficos e de pesquisa. Quando você atinge
seu orçamento, você para de veicular o anúncio do dia. Como é de
se esperar, o CPC é geralmente o CPI dividido pelo CTR.
• Valor da vida útil do cliente (CLV / LTV): Quanto dinheiro 313

você espera fazer desse cliente durante a vida útil do produto?
Isso é útil para determinar quanto gastar com publicidade para
esse cliente. O CLV deve ser maior do que o que você gasta para
adquirir o cliente. Se você tiver que gastar US$100 em promoções
de exibição e de afiliação para adquirir um cliente, mas só espera
ganhar US$ 20 com esse cliente, terá perdido dinheiro.
O PLANO DE GTM DA MOOVER

Aqui está um primeiro passo no plano GTM da Moover. A equipe de
lançamento dividirá essas tarefas em itens de ação explícita e atribuirá cada
uma delas, e elas poderão levantar preocupações durante o lançamento
de problemas não listados aqui. Mas isso deve lhe dar uma compreensão
de como começar a pensar em lançar e comercializar um produto.
Mensagem-chave: Moover elima o incômodo de planejar uma
mudança.
Mensagem com novos recursos: o novo recurso de bate-papo da Moover

elimina o incômodo de falar com as empresas de mudança.
Pré-lançamento
• Como vamos testar isso internamente? Pediremos a voluntários de

várias equipes que ajudem a testar o aplicativo móvel e o painel
da rede por dez minutos todos os dias ao longo de duas semanas.
Usando ambos os aspectos, eles podem garantir que tudo ocorra
conforme esperado. Usar o produto por alguns minutos todos os
dias é provavelmente o caso de utilização mais comum. Também
designaremos uma pessoa na equipe de garantia de qualidade para
314 lidar com uma empresa falsa diferente no banco de dados para
que ela possa testar o sistema de "muitos clientes/ uma fonte de
THE PRODUCT BOOK
resposta".
• Como vamos testar isso externamente? Vamos disponibilizar

e ligar para um pequeno grupo de clientes sem anúncio especial
e ver como o uso muda, se os clientes encontrarão problemas
e muito mais. É difícil criar um grupo beta para mudanças de
clientes porque as pessoas se mudam e não fazem isso novamente
por um bom tempo. Permitir que os clientes experimentem esse
recurso também significa que teremos de implantar o portal da
rede para nossas empresas de mudanças antecipadamente, pois elas
precisarão ser capazes de responder a mensagens. Precisamos criar
material de treinamento para essas empresas e fornecer suporte.
• Como vamos lançar isso? Este não é um recurso muito grande,
por isso não precisa de muito alarde. No entanto, como muitas

pessoas não ouviram falar na Moover, queremos usá-lo para
ajudar a gerar novos artigos sobre nosso produto. Trabalharemos
com nosso PRF para fazer uma pequena digressão de imprensa
e nos certificaremos de que o foco esteja na mensagem principal
do produto, mais do que no novo recurso específico. Precisamos
apresentar um exemplo de demonstração para essas reuniões.
Talvez possamos criar uma falsa empresa de mudanças que envie
automaticamente uma série de respostas na infra-estrutura para
que pareça que você está tendo uma conversa real com a empresa
durante a coletiva de imprensa.
• Quais ativos precisamos criar? Precisamos de materiais de

treinamento e suporte para os clientes da empresa de mudanças, 315
capturas de tela e documentação atualizadas para o site e as lojas
de aplicativos, além de uma postagem no blog descrevendo o que
está nesta atualização.
• Como chegaremos aos clientes? Não temos clientes recorrentes

com frequência, portanto, alcançar clientes existentes não é uma
grande preocupação. Podemos continuar a promover a Moover
em geral em quadros de empregos como o LinkedIn (dado
que depois que as pessoas conseguem um novo emprego, elas
geralmente se mudam).
Lançamento
Deve haver muito pouco a fazer durante o lançamento, além de atualizar o
site com novas informações sobre o produto e liberar o aplicativo atualizado.
Queremos garantir que nosso site aguente uma carga maior de
visitantes, mas, devido à frequência com que as pessoas se mudam, não
esperamos um grande aumento nos usuários ativos simultâneos no
aplicativo. Como vemos uma média de 1.000 usuários por dia, podemos
começar presumindo que cada usuário envia dois bate-papos por dia
para todas as empresas de mudanças das quais ele recebeu uma cotação.
Há uma média de cinco cotações por usuário. Isso significa que devemos
estar preparados para lidar com 1000 * 2 * 5 ou 10.000 bate-papos por dia,
o que não é um grande número. Podemos ajustar a capacidade conforme
necessário após o nível se manter.
Pós-lançamento
Continuaremos promovendo a Moover normalmente, com foco especial
em anúncios de exibição segmentados e de pesquisa. A mensagem geral
ainda é a mensagem principal a ser promovida, já que nossa percepção
316 do aplicativo ainda não está em um ponto em que vale a pena anunciar
inicialmente recursos específicos.
THE PRODUCT BOOK
Queremos ver com que frequência as pessoas usam o recurso de bate-

papo para garantir que ele seja suficientemente detectável e intuitivo. Para
muitos em sua empresa, especialmente as equipes de vendas, marketing
e suporte, o pós-lançamento é quando eles realmente vão trabalhar. Para
você, este é o último grande passo no ciclo de vida do desenvolvimento
de produtos. Continue lendo para aprender a finalizar o ciclo de vida.
9. Finalizando o ciclo de vida de
desenvolvimento de produto
CAPÍTULO NOVE
FINALIZANDO O CICLO DE VIDA DE
DESENVOLVIMENTO DE PRODUTO

Parabéns! Você lançou seu produto com sucesso! Tudo está feito, certo? 317
Bem, você precisa fazer mais três coisas durante este ciclo: FESTEJAR,
auto-avaliar o ciclo e criar uma recomendação para a próxima iteração.
Vamos ver esses três em detalhes.
COMEMORE!
É muito importante para o moral da equipe e da empresa celebrar até
mesmo pequenas vitórias. Por exemplo, você pode comemorar o reparo
de um erro difícil comendo bolinhos (certifique-se de levar em conta os
requisitos dietéticos, como glúten/ sem açúcar). Quando você lança uma
versão principal de seu produto, você pode levar a equipe principal para
um belo jantar. E quando você lançar algo grande, você pode ajudar a
organizar uma comemoração em toda a empresa.
Estas comemorações proporcionam uma forma de os colaboradores
individuais serem reconhecidos pelo seu trabalho. Os Product Managers
costumam ser os representantes mais visíveis de seus produtos, mesmo
que não sejam eles a projetar ou a criar a codificação. É importante dar
crédito à equipe por fazer um ótimo trabalho para que cada pessoa se
sinta importante e como parte de algo maior. Também é uma ótima
maneira de criar respeito entre você e a equipe - enquanto uma das
maneiras mais fáceis de perder o respeito de sua equipe é levar o crédito
pelo trabalho da equipe.
Se você estiver organizando uma comemoração em toda a empresa,

como um PM, provavelmente fará um discurso rápido. Esta é uma ótima
oportunidade para reconhecer a equipe principal, outras pessoas específicas
que foram além para ajudar no lançamento do produto e quaisquer grupos
que contribuíram para isso além da equipe principal do produto.
Também é muito bom ter avaliação positiva de pessoas internas (o
que o CEO acha?) e de pessoas externas (citações de imprensa, e-mails de
318 clientes) para compartilhar. Essa avaliação é uma validação extra de que
o trabalho da equipe está sendo bem recebido. Se um lançamento não
THE PRODUCT BOOK
foi bem recebido, você ainda deve reconhecer o esforço que foi aplicado,
pois você deseja que a equipe tenha uma atitude positiva ao trabalhar na
próxima iteração do produto.
Organizar pequenas atividades e celebrações durante a construção

do produto também pode ser muito útil para o moral da equipe.
Quando a equipe atinge um marco importante, você pode sair para
jogar mini-golfe. É provável que você se encarregue de organizar essas
comemorações - embora o seu gerente de RH/ equipe de RH possa ajudar
com as comemorações de toda a empresa. Certifique-se de estar ciente da
importância dessas comemorações, pois é fácil esquecê-las com todas as
outras tarefas na lista do Product Manager.
AVALIE COMO AS COISAS CORRERAM
Em última análise, o que mais importa para a empresa é o que seus

clientes pensam do produto e se você atingiu suas métricas de sucesso,
mas é importante analisar como você chegou ao lançamento. Se você
alienou a todos ou tornou o produto extremamente difícil de criar, as
pessoas da sua equipe provavelmente não querem trabalhar na próxima
versão e podem até procurar novos empregos. Avaliar como as coisas
correram garante que você obtenha avaliação, permitindo que as
pessoas sintam que suas preocupações são ouvidas e pensem em como
fazer melhor no próximo ciclo.
Para algumas pessoas, avaliar como as coisas correram durante o
ciclo de desenvolvimento é muito difícil, pessoalmente. É quando você

explicitamente se coloca lá fora e pede avaliação, e você receberá avaliação
positiva e negativa.
319
Debate com seu Chefe
A primeira parte de obter avaliação é ver o que seu chefe pensou do seu
trabalho. Ele estava feliz com a forma como você abordou tudo ou havia
coisas que ele gostaria que você tentasse fazer diferente? Ele obteve uma
avaliação positiva de outras equipes sobre você, ou outras pessoas sempre
se queixaram de você? É muito útil agendar uma reunião individual
com a liderança, se você não tiver reuniões agendadas regularmente,
fazer uma verificação e garantir que tudo esteja bem. Uma maneira de
começar a conversa é perguntando: “Você poderia me dar uma avaliação
sobre como você se sente nesse ciclo? Eu quero ter certeza de que estou
fazendo o melhor trabalho possível”. Afinal, nós crescemos trabalhando
em nossos pontos fracos.
Autópsia da Equipe
A outra parte de avaliar como as coisas correram é obter avaliação da
equipe, e uma maneira eficaz de fazer isso é com uma reunião de autópsia.
Existem algumas maneiras diferentes de executar essas reuniões. Vamos
orientá-lo sobre como administrar uma com a sua equipe principal. Se
você acha que teve problemas em trabalhar com a equipe, você pode
pedir a alguém para executar a autópsia para que você possa se ausentar
da sala para que a equipe se sinta confortável ao falar abertamente.
Algumas empresas têm autópsias de porta aberta, onde qualquer pessoa
na empresa pode entrar para ouvir sobre o processo. Você só precisa
escolher o que é mais adequado para sua situação.
Veja como gostamos de executar autópsias. Encontre um horário

em que a equipe principal do produto e as principais partes interessadas
estejam disponíveis e agende uma reunião por uma hora ou mais. Você vai
querer tentar criar um ambiente descontraído e aberto, que pode significar
qualquer coisa, desde reservar a sala de reunião com as cadeiras mais
320 confortáveis até fornecer alimentos e bebidas alcoólicas/ não-alcoólicas
para a equipe - isso varia de empresa para empresa. Apenas certifique-se de
THE PRODUCT BOOK
ter um quadro branco ou algo para escrever e que todos possam ver.
Como essa reunião é para avaliação, todas as opiniões são válidas.

Certifique-se de não colocar juízos de valor sobre o que as pessoas dizem,
especialmente se elas derem uma avaliação negativa. Divida o quadro em
duas colunas: as coisas que você fez bem e as coisas que você desejaria
que fossem mais fáceis. Comece pedindo a todos que digam o que acham
que correu bem. Depois de um tempo, mude para a outra lista e peça que
as pessoas citem o que gostariam que tivesse sido melhor. Pule para frente
e para trás entre as listas até sentir que todos tenham sido ouvidos.
Por último, reserve um tempo para discutir o que você gostaria de fazer
de maneira diferente e o que deseja manter durante o próximo ciclo. Você
deve fazer anotações da autópsia em algum lugar, como na página wiki do
produto, incluindo as principais coisas que você esteja se comprometendo a
fazer de forma diferente durante o próximo ciclo. Consulte periodicamente

essa lista para se certificar de que você alivie o máximo possível da dor do
processo enquanto mantém as coisas fluindo bem.
RECOMENDANDO O QUE VEM A SEGUIR

Após o lançamento, é hora de iniciar outra iteração do ciclo de vida do
desenvolvimento do produto. No entanto, há um desafio. Em um mundo
ideal, você teria dados úteis sobre como o que você fez durante essa
iteração afetou suas métricas e metas de sucesso. Infelizmente, geralmente
leva tempo coletar dados úteis suficientes para ver se suas alterações
funcionaram. Sua próxima iteração imediata será orientada pelo roteiro

de seu produto (Capítulo 2) e outras abordagens tratadas no Capítulo
3. Então, depois de passar um tempo suficiente para coletar dados úteis
dessa iteração, você colocará esse produto de um a três recipientes de alto
nível. De forma mais específica, você recomendará a mudança para outro 321
produto, pois esse produto/ recurso é bom o suficiente, iterando mais esse
produto ou desativando o produto.
Se você alcançou ou superou suas metas de métricas de sucesso, sua

recomendação provavelmente será mudar para outra coisa. Os relatórios
automáticos de falhas podem ser muito úteis aqui para aplicativos
móveis e de computador, já que você pode descobrir erros que afetem
muitos clientes e que você desejará reparar antes de prosseguir, mesmo
que você já tenha atingido suas metas de sucesso de métricas.
Se você não tiver atingido suas metas, precisa ir mais fundo para
pensar em onde e como deseja interagir. Executar testes A/ B simples com
ferramentas como o Optimizely é uma ótima maneira de ver rapidamente
se você pode fazer pequenas alterações para ajudá-lo a atingir suas
metas. Às vezes, alterações de produtos não essenciais, como a redação
em um site, podem fazer uma grande diferença. A equipe de marketing
provavelmente realizará muitos testes A/ B no site de marketing para ver
o que leva a maioria dos clientes a comprar / usar seu produto.
Observar o que seus clientes pensam também é importante. Talvez

você atinja suas metas de renda mudando para um modelo de pagamento
por assinatura, mas se seus clientes detestarem e estiverem procurando
alternativas, seu sucesso a longo prazo estará em questão. O que há de
bom em lançar um produto em destaque é que você verá resenhas de
produtos, postagens em mídias sociais e tíquetes de suporte sobre o novo
produto. Analise estes, além de analisar suas métricas, para ver o que os
clientes pensam.
Recomendamos reler os Capítulos 3 e 4, pensando em como apresentar

sua próxima hipótese de oportunidade para um produto/ recurso
322 existente que não esteja atingindo suas metas. A Moover, por exemplo,
pode descobrir que os clientes adoram e usam o recurso de bate-papo,
THE PRODUCT BOOK
mas a empresa ainda não está atingindo suas metas. Aproveitando o

conselho do Capítulo 3, perguntando por quê, podemos concluir que
temos um problema de crescimento de plataforma para abordar a seguir.
Você pode concluir que nenhum esforço razoável fará com que o
produto atinja suas metas de sucesso de métrica. Ou talvez as prioridades da
sua empresa tenham mudado, e este produto não esteja mais na estratégia
geral. Ou talvez um desenvolvimento tecnológico tenha tornado algo
muito melhor para seus clientes, mas criar esse “algo melhor” significará
um produto completamente diferente e não uma atualização. Neste caso,
sua recomendação deve ser ao final da vida ou "aposentaria" do produto.
Aposentar um produto simplesmente significa que você deixará de
desenvolver ativamente o produto e os clientes deverão mudar para

outra coisa. Nós não vamos entrar nisso em profundidade, mas você
geralmente não deixa de vender um produto. É importante ter uma
janela em que o suporte ao cliente ainda esteja disponível para o produto,
tempo em que os dados do cliente ainda estejam disponíveis para que
os clientes possam recuperá-los para produtos on-line e, idealmente, um
caminho de migração para ajudar os clientes a migrar para um produto
alternativo. Embora possa ser frustrante para os clientes fiéis, os produtos
em desativação não são uma coisa ruim, e as empresas fazem isso o tempo
todo. O truque é apenas ter certeza de que você tenha um plano razoável.

Em março de 2013, o Google anunciou que descontinuaria seu
agregador de feeds RSS do Reader, pois cada vez menos pessoas o usavam
e a empresa queria se concentrar em outros produtos. O Google deu aos
clientes quatro meses para recuperar e mover seus dados e mostrou aos 323
clientes como usar o Google Takeout para recuperar esses dados.
Em outro exemplo, a Apple aposentou sua ferramenta profissional

de gerenciamento de fotos, a Aperture, em meados de 2014. A empresa
forneceu uma atualização para garantir que a Aperture funcionasse na
próxima versão do OS X, para que os clientes pudessem continuar a
usá-la por pelo menos mais um ano. A Apple também trabalhou com
seu principal concorrente, a Adobe, para garantir que a ferramenta
profissional de gerenciamento de fotos da Adobe, o Lightroom, tivesse
um comando "Importar partir da Aperture" para ajudar os clientes a
migrarem seus dados.
Em última análise, seja qual for a sua recomendação, essa etapa

final do ciclo de vida do desenvolvimento de produtos se encaixa
perfeitamente no primeiro passo que abordamos no Capítulo 3: decidir o
que fazer em seguida. A principal diferença é que você começa avaliando
se está satisfeito com o que acabou de fazer, se precisa trabalhar mais ou
se precisa deixar o produto de lado para se concentrar em outra coisa. E
então você repete e repete e repete.
324
THE PRODUCT BOOK
DICA DO CAPÍTULO NOVE

Nossa dica final vem de Carlos González de Villaumbrosia, fundador e
CEO da Product School. Ele dedicou toda a sua carreira para preencher
a lacuna entre educação e emprego em tecnologia. Carlos se inspirou
para criar a Product School com base em sua própria experiência,
quando teve que aprender como entrar no Product Management da
maneira mais difícil. Como um bom e ágil empreendedor, o Carlos
focou em resolver esse problema específico e construiu um MVP muito
básico para validar sua solução. A Product School começou como uma
reunião recorrente casual entre Carlos e sete aspirantes a Product

Managers da Starbucks no Distrito Financeiro de São Francisco.
Nessas reuniões, Carlos compartilhava sua experiência e até convidava
outros PMs como palestrantes convidados para compartilhar suas
325
opiniões. A reação foi tão positiva que Carlos alugou um quarto em
um espaço de trabalho em grupo, criou a primeira versão do currículo
de Product Management, ensinou as primeiras 10 coortes para refinar
cada detalhe relacionado para encantar seus alunos e a garantir que
eles estivessem equipados com as ferramentas certas e o conhecimento
para construir produtos, e conseguirem empregos como PM.
Em apenas dois anos, a Product School se tornou a primeira escola
de negócios de tecnologia do mundo. Atualmente oferece cursos de
Product Management em São Francisco, Vale do Silício, Los Angeles
e Nova Iorque. Todos os seus instrutores são PMs de nível sênior em
empresas importantes como Google, Facebook, Snapchat, Airbnb,
PayPal, American Express e Netflix. Este conselho vem dos dados e da
experiência obtida ao trabalhar com os alunos de Product Management
da Product School todos os dias.
COMO FAZER SUCESSO EM PRODUCT MANAGEMENT
Migrei para o Product Management a partir da engenharia de software oito
anos atrás, e fundei a Product School para ensinar a outros aspirantes a
Product Managers a fazer o mesmo. A principal razão pela qual as pessoas
mudam de carreira para o Product Management é porque estão interessadas
em ter mais poder de decisão na estratégia de produto da empresa. Eu não
as culpo; Esse é um grande dilema que impactará sua vantagem de longo
prazo, já que você deixará de ser especialista em uma parte do processo
para se tornar um generalista em todas as partes envolvidas no processo,
aproveitando os talentos de outras pessoas. Esta abordagem irá atendê-lo
bem profissionalmente e pessoalmente.
Ao longo da minha carreira, conheci dezenas de Product Managers

atuais e empreendedores e investidores que trabalharam como Product
Managers no passado. Todos compartilharam exatamente o mesmo
326 problema sobre como eles não tinham treinamento adequado quando
iniciaram suas carreiras de gerenciamento em tecnologia. Sim, é verdade
THE PRODUCT BOOK
que muitos deles obtiveram MBAs ou diplomas semelhantes relacionados

a negócios nas principais universidades que forneceram diferentes
habilidades e acesso a redes que ajudaram à longo prazo. Mas esses
níveis de negócios nem sempre são aplicáveis ao Product Management,
nem ensinam como se tornar um Product Manager. Na verdade, a maioria
dos Product Managers de hoje, tenham MBAs ou cursos de ciência da
computação, tiveram que aprender seu ofício em movimento porque não
havia nenhuma escola de Product Management que tivesse uma visão
holística, incorporando negócios, engenharia e design. Felizmente, a
Product School preenche essa lacuna.
Aqui estão alguns exemplos de diferentes planos de carreira para entrar

no Product Management. Tenha em mente que esta lista não está completa:
Engenheiro → Engenheiro sênior → Gerente de projetos técnico ou
Gerente de programação/gerente de engenharia → Product Manager

Fundador de uma empresa recém-criada ↔ Product Manager
Consultor de gerenciamento/banqueiro de investimento
→ Product Manager
Suporte ao cliente → Analista de Negócios/Gerente de projetos ou

Gerente de programação → Product Manager
Marketing → Marketing do produto → Product Manager

Design → Design do produto → Product Manager

A única coisa que todas essas carreiras têm em comum é que os PMs não
começam como PMs. Eles passam pelo menos alguns anos em um cargo
diferente, desenvolvem algumas habilidades-chave e depois fazem a
transição para o Product Management. As três habilidades críticas que eu
327
acredito que você deva desenvolver para conseguir um emprego como
Product Manager são especialização técnica, conhecimento de domínio e
especialização em comunicação. Vamos dar uma olhada nestes três quesitos.
Como você aprendeu nos capítulos anteriores, mesmo que você não
saiba codificar, é essencial que os Product Managers compreendam parte
da engenharia por trás dos produtos que gerenciam. Esse conhecimento o
ajudará a se comunicar com designers e engenheiros, avaliar a viabilidade
técnica e entender o lado técnico da implementação de um projeto.
Em seguida, especialmente para o seu primeiro trabalho em Product
Management, é importante entender o domínio em que você estiver
trabalhando. Como discutimos no Capítulo 1, descobrimos que, quando
você conseguir seu primeiro trabalho de PM, se você tiver conhecimento
sobre o campo em que estiver trabalhando, poderá dedicar seu tempo a
se concentrar em como ser um Product Manager, em vez de aprender as
nuances, os desafios, o cenário competitivo e muito mais do seu domínio.
Finalmente, algo que não abordamos em detalhes neste livro é o quão
crítico grandes habilidades de comunicação são para os PMs.
Os PMs precisam se comunicar o tempo todo, seja por email ou

apresentação. Nos nossos campos de treinamento da Product School,
passamos várias horas ensinando os alunos a serem ótimos oradores
públicos através de muita prática. Se você não consegue se comunicar, não
importa quão excelente você seja, porque ninguém conseguirá entendê-lo.
Além da Product School, existem algumas coisas específicas que
ajudarão na sua transição para o Product Management:
Construa algo. Na sala de aula, nossos alunos trabalham para um

projeto final onde escolhem uma empresa para a qual estão qualificados,
determinam qual característica a empresa deve construir em seguida e
criam uma apresentação explicando por que a empresa deve construí-la
e os principais requisitos . Tente fazer isso sozinho! Se você sabe codificar,
328 faça um projeto do início ao fim para experimentar o lançamento de um
produto e obter avaliação dos clientes.
THE PRODUCT BOOK
Participe de hackathons. Confira as maratonas de desenvolvimento

tecnológico de produtos, como o ProtoHack ou o Startup Weekend,
para obter experiência prática na criação de um produto em ambientes
de alta pressão.
Encontre um mentor. Estenda a mão para PMs que você respeite e que
você sinta que poderiam ser bons mentores para você. A Product School
tem uma comunidade ativa no Slack, product-school, que é um ótimo lugar
para encontrar um mentor. Um mentor pode lhe contar histórias de guerra
e ajudá-lo a entender as práticas recomendadas.
Rede. Confira eventos de produtos em sua cidade. Sites como Meetup
e Eventbrite costumam apresentar eventos. Esses eventos podem ser um
ótimo lugar para encontrar um mentor também.
Leia. A lista de Leituras Adicionais no final deste livro tem ótimos recursos
para ajudá-lo a aprender mais sobre como ser um PM. Recomendamos
que você confira o artigo Cracking the PM Interview de Gayle Laakmann
McDowell ou Decode and Conquer, de Lewis C. Lin, para entender mais

sobre as entrevistas de PM.
Inscreva-se em programas do gerenciador de produtos (APM). Algumas
grandes empresas de tecnologia, como Google, Yahoo e Facebook, têm
funções de APM de nível básico para recém-formados, onde ensinam como
ser um PM no trabalho. Talvez você preencha os requisitos para se candidatar.
Um dos erros mais comuns em conseguir seu primeiro emprego de PM é

definir expectativas muito altas, seja em termos de seu título ou de sua
empresa. Só porque você é um engenheiro de software sênior agora não
significa que seu primeiro trabalho de PM será como gerente sênior de
produto. Da mesma forma, sua empresa atual pode não ser sua empresa de

sonhos, mas se houver uma oportunidade para um MP, você provavelmente
terá uma chance maior de conseguir isso como seu primeiro emprego de
PM do que conseguir um emprego em outro lugar.
Seja realista! Avalie sua experiência atual e trace trajetórias de carreira
329
realistas dentro ou fora de sua empresa atual. O seu trabalho ideal para
PM provavelmente não será seu primeiro trabalho de PM, mas tudo bem.
Desde que o seu primeiro emprego de PM seja relevante para os seus
objetivos de carreira e você esteja rodeado por pessoas mais experientes
com quem você possa aprender, este ainda será um excelente trabalho
para você.
AGORA, VÁ CONSTRUIR
PRODUTOS INCRÍVEIS!
LEITURAS ADICIONAIS
Capítulo 1
Product Manager, Você É… Um Zelador, Essencialmente.

(Product Manager You Are…A Janitor, Essentially), por Mat
Balez (14 de abril de 2014). https://medium.com/@matbalez/
product-manager-youare-664d83ee702e#.ae25xz72r.
O Trabalho do Product Manager (A Product Manager’s Job),

por Josh Elman (19 de julho de 2013). https://medium.com/@
joshelman/a-product-managers-job-63c09a43d0ec#. h6re9qq6r.
Encontre, Examine e Feche Negócio, os Melhores Product

332 Managers (Find, Vet, and Close the Best Product Managers), da
Resenha tirada do First Round. http://firstround.com/review/ find-
vet-and-close-the-best-product-managers-heres-how/.
Bom Gerente de Produto, Mau Gerente de Produto

(Good Product Manager Bad Product Manager), por Ben
Horowitz e David Weiden. http://www.khoslaventures.com/
wp-content/uploads/Good_Product_Manager_Bad_Product_
Manager_KV.pdf.
Impressionando na Entrevista para PM: Como Conseguir um

Emprego como Product Manager em Tecnologia (Cracking
the PM Interview: How to Land a Product Manager Job in
Technology) por Gayle Laakmann McDowell e Jackie Bavaro, em
CareerCup, 2013.
Seja um Grande Líder de Produtos (Be a Great Product Leader),
por Adam Nash (16 de dezembro de 2011). http:// blog.adamnash.
com/2011/12/16/be-a-great-product-leader/.
Capítulo 2
Inspired: Como Criar Produtos que os Clientes Amam (Inspired:

How to Create Products Customers Love), por Marty Cagan,
Imprensa SVPG, em 2008.
O Dilema do Inovador: Quando as Novas Tecnologias Levam

Empresas ao Fracasso - (The Innovator’s Dilemma: When
New Technologies Cause Great Firms to Fail (Management
of Innovation and Change)), por Clayton Christensen, ed. da
Harvard Business Review Press, 2016.
333
Strategize: Estratégia do Produto e Práticas de Roteiro do Produto
para a Era Digital (Strategize: Product Strategy and Product
Roadmap Practices for the Digital Age), por Roman Pichler,
Pichler Consulting, 2016.
O Único Número Que Você Precisa Crescer (The One Number

You Need to Grow), por Frederick F. Reichheld (dezembro de
2003). https://hbr.org/2003/12/ the-one-number-you-need-to-grow.
Por Quê: Como Grandes Líderes Inspiram Ação (Start with Why:
How Great Leaders Inspire Everyone to Take Action), por Simon
Sinek, Penguin Group, 2009.
Equilibrando Compensações Entre Diferentes Clientes (Balancing
Tradeoffs Across Different Customers), por Steven Sinofsky (28
de janeiro de 2013).
https://blog.learningbyshipping. com/2013/01/28/balancing-
tradeoffs-across-different-customers/.
A Hierarquia do Engajamento (The Hierarchy of Engagement),

por Sarah Tavel (23 de março de 2016).
https:// www.linkedin.com/pulse/hierarchy-engagement-sarah-
tavel.
Capítulo 3
Os Quatro Passos para a Epifania: Estratégias Bem Sucedidas para

334 Produtos Vencedores (The Four Steps to the Epiphany: Successful
Strategies for Products that Win), por Steve Blank, Cafepress.
com, 2013.
Hooked: Como Construir Produtos Formadores de Hábitos

(Hooked: How to Build Habit-Forming Products), por Nir Eyal,
Portfolio Penguin, 2014.
O Manual do Produto Lean: Como Inovar com Produtos

Mínimos Viáveis e Avaliação Rápida do Cliente (The Lean
Product Playbook: How to Innovate with Minimum Viable
Products and Rapid Customer Feedback), por Dan Olsen.
Geração do Modelo de Negócio: Um Manual para Visionários,

Inovadores e Desafiadores (Business Model Generation: A
Handbook for Visionaries, Game Changers, and Challengers),
por Alexander Osterwalder e Yves Pigneur, Wiley, 2010.
Design de Proposta de Valor: Como Criar os Produtos e Serviços

Que os Clientes Querem (Value Proposition Design: How to
Create Products and Services Customers Want (Strategyzer)), por
Alexander Osterwalder, Yves Pigneur e Gregory Bernarda; Wiley,
2014.
A Startup Enxuta: Como Empreendedores Atuais Utilizam a

Inovação Contínua para Criar Empresas Extremamente Bem-
sucedidas (The Lean Startup: How Today’s Entrepreneurs
Use Continuous Innovation to Create Radically Successful
Businesses), por Eric Ries, ed. Viking, 2011.
Incrivelmente Simples - A obsessão que levou a Apple ao sucesso 335

(Insanely Simple: The Obsession That Drives Apple’s Success), por
Ken Segall, ed. Penguin Group, 2012.
Priorizando Recursos: Quem Usará e Com Que Frequência?

(Prioritising Features: Who’ll Use It & How Often?), por Des
Traynor. Retirado de https://blog.intercom.io/ prioritising-features-
wholl-use-it-how-often/.
Capítulo 4
Desenvolvimento de Clientes Lean: Construindo Produtos

Que Seus Clientes Comprarão (Lean Customer Development:
Building Products Your Customers Will Buy), por Cindy Alvarez,
ed. O’Reilly, 2014.
Conversando com Humanos: O Sucesso Começa Conhecendo o
Cliente (Talking to Humans: Success Starts with Understanding
Your Customers), por Giff Constable, Frank Rimalovski e Tom
Fishburne.
Realidade UX: 14 Duras Verdades Sobre os Usuários (UX

Reality Check: 14 Hard Truths About Users), por Giff Constable
(2014) e Robert Jr. Hoekman (17 de Maio de 2016). http://www.
fastcodesign.com/3059921/ ux-reality-check-14-hard-truths-about-
users.
A Intercomunicação com o Product Management (Intercom on

Product Management), por Intercom. https://www.intercom.io/
books/product-management.
336 Quais são as melhores maneiras de priorizar uma lista de recursos

do produto? (What are the best ways to prioritize a list of product
features?), por Adam Nash. Retirado de https://www.quora.com/
What-are-the-best-ways-to-prioritize-a-list-of-product-features.
Estratégia de Produto Significa Dizer Não (Product Strategy

Means Saying No), por Des Traynor. https://blog.intercom.io/
product-strategy-means-saying-no/.
Capítulo 5
Como Escrever um Bom PRD (How to Write a Good PRD), por

Martin Cagan. http://www.svpg.com/assets/Files/goodprd.pdf.
Qual é a abordagem da Amazon no desenvolvimento de produto
e de Product Management? (What is Amazon’s approach to
product development and product management?), escrito por
Ian McAllister. Retirado de https://www.quora.com/Amazon-
company-What-is-Amazons-approach-to-productdevelopment-
and-product-management.
Story: Estilo, Estrutura, Substância, e os Princípios de Roteiros

(Story: Style, Structure, Substance, and the Principles of
Screenwriting), por Robert McKee, ed. HarperCollins, 2010.
A Especificação Está Morta: Viva a Especificação (The

Specification Is Dead; Long Live the Specification), por Ben
Yoskovitz (14 de novembro de 2011).
http://www.instigatorblog.com/ the-specification-is-dead-long-live-
the-specification/2011/11/14/. 337
Capítulo 6
Meça Duas Vezes, Corte Uma: Introduzindo o Teste de

Usabilidade em Nosso Processo de Design (Measure Twice, Cut
Once: Introducing Usability Testing into Our Design Process),
por Cole Derochie (17 de junho de 2014) http://inside.unbounce.
com/product-dev/introducing-usability-testing/.
Sprint: Como Resolver Grandes Problemas e Testar Novas Ideias

em Apenas Cinco Dias (Sprint: How to Solve Big Problems and
Test New Ideas in Just Five Days), por Jake Knapp, John Zeratsky
e Braden Kowitz.
Não Me Faça Pensar: Uma Abordagem de Bom Senso À
Usabilidade na Web (Don’t Make Me Think, Revisited: A
Common Sense Approach to Web Usability), por Simon &
Schuster (2016) e Steve Krug; ed. New Riders, 2014.
Cirurgia de Foguetes Facilitada: O Guia Faça-Você-Mesmo para

Encontrar e Corrigir Problemas de Usabilidade (Rocket Surgery
Made Easy: The Do-It-Yourself Guide to Finding and Fixing
Usability Problems), por Steve Krug, ed. New Riders, 2009.
O Design do Dia a Dia: Edição Revisada e Expandida (The

Design of Everyday Things: Revised and Expanded Edition), por
Don Norman, ed. Basic Books, 2013.
Como Trabalhar com Designers (How to Work with Designers),

338 por Julie Zhuo (15 de agosto de 2013).
https://medium.com/the-year-of-the-looking-glass/how-to-work-
with-designers-6c975dede146#.kib1vjbd5.
Capítulo 7
O Mítico Homem-Mês: Ensaios sobre Engenharia de Software

(The Mythical Man-Month: Essays on Software Engineering), por
Frederick P. Jr Brooks, ed. Addison-Wesley Professional, 1995.
Engenheiros: E Daí Que Seu PM Seja Ruim? Veja Como

Consertar Isso. (Engineers: So Your PM Sucks? Here’s How to Fix
It), Ellen Chisa. http://blog.ellenchisa.com/2014/07/20/engineers-
pm-sucks-heres-fx/.
Dívida Técnica (Technical Debt), por Martin Fowler (1 de
outubro de 2003). http://martinfowler.com/bliki/TechnicalDebt.
html.
Liderando o Lançamento Ágil (Leading the Agile Release Train),

por Drew Jemilo (8 de agosto de 2011).
https://www.agilealliance.org/wp-content/uploads/2016/01/
Leading-the-Agile-Release-Train-Agile2011.pdf.
Cascata vs Ágil: Qual é a Metodologia Certa Para Seu

Projeto? (Waterfall vs. Agile: Which is the Right Development
Methodology for Your Project?), por Mary Lotz (5 de julho de
2013). Retirado de http://www.seguetech.com/blog/2013/07/05/
waterfall-vs-agile-right-development-methodology.
Gestão de Produtos com Scrum: Criando Produtos Que os 339

Clientes Amam (Agile Product Management with Scrum:
Creating Products That Customers Love), por Roman Pichler, ed.
Addison-Wesley Professional, 2010.
Codificadores no Trabalho: Reflexões sobre o Ofício da

Programação (Coders at Work: Reflections on the Craft of
Programming), por Peter Seibel, ed. Apress, 2009.
Joel sobre Software, por Joel Spolsky.

http://joelonsoftware.com.
Como Trabalhar com Engenheiros (How to Work with

Engineers), por Julie Zhou (28 de agosto de 2013).
https://medium.com/the-year-of-the-looking-glass/how-to-work-
with-engineers-a3163f1eced#.h2lk3tr6v.
Capítulo 8
Meaningful: A História das Ideias que Voam (Meaningful: The

Story of Ideas that Fly), Bernadette Jiwa, Perceptive Press, 2015.
Marketing do Produto é o Mesmo que Marketing? (Eu Digo Que

Não) (Is Product Marketing the Same as Marketing? (I Say No)),
por Steve Johnson (23 de janeiro de 2014).
http://onproductmanagement.net/2014/01/23/is-product-
marketing-the-same-as-marketing-i-say-no/.
Lançamento de Produto de Alta Tecnologia (High Tech Product

Launch), por Catherine Kitcho, ed. Pele Publications, 2005.
Posicionamento: A Batalha por Sua Mente (Positioning: The

340
Battle for Your Mind), escrito por Al Ries, Jack Trout e Philip
Kotler; ed. McGraw-Hill Education, 2000.
Contribuição do Marketing de Produto (Product Marketing

Contribution), por Martina Lauchengco (28 de abril de 2012).
http://www.svpg.com/product-marketing-contribution/.
Incrivelmente Simples (Insanely Simple), por Ken Segall, ed.

Penguin Publishing Group, 2012.
Capítulo 9
Quora. https://www.quora.com/profile/Carlos-Gonzalez-de-
Villaumbrosia.
Então você quer ser um Product Manager? Torne-se um produto!

(So you want to be a product manager? Make yourself the
product), por Mixpanel (10 de fevereiro de 2016). https://blog.
mixpanel.com/2016/02/10/ so-you-want-to-be-a-product-manager-
make-yourself-the-product/.
3 Erros Comuns por Engenheiros em Transição para Product

Management (3 Common Mistakes by Engineers Transitioning to
Product Management), Blog da Product School.
https://www.productschool.com/blog/get-job/3-common-mistakes-
341
for-engineers-transitioning-to-product-management-2/.
RECONHECIMENTOS
Muitas pessoas imaginam que escrever um livro significa simplesmente

sentar, escrever muito e apertar um botão mágico de “Publicar”. Isso não
poderia estar mais longe da verdade. É preciso uma equipe para criar um
livro, não apenas um autor, e temos a sorte de ter trabalhado com uma
grande equipe para esse livro.
Para a equipe da Product School, tanto do passado quanto do presente,
quero deixar meus agradecimentos pela estrutura e o suporte que vocês
trouxeram para este livro. Agradecimentos especiais a Aaron Filous,
Jasmin Lopez e Stany Yeh por seus esforços para este projeto.
Devemos muitos agradecimentos a Jason Alt por ser nosso primeiro
leitor e editor técnico. Suas anotações tornaram este um livro da maior
magnitude! Jason, estamos felizes em te chamar de amigo. Outros leitores
ajudaram a refinar esse material, pelo qual somos gratos. Esses leitores
incluíram Richard Fleming e Max Kornblith.
Diversas pessoas excelentes contribuíram com dicas para este livro,
também, para fornecer perspectivas e conselhos adicionais. Agradecemos
ao Kirk Paulsen, Jeremy Toeman, Beatriz Datangel, Conrad Albrecht-
Buehler, Nik Laufer-Edel e Mohammad Musa por sua sabedoria.
Além do texto, agradeço à talentosa Candace Cunningham por mais
uma vez ser uma grande editora de texto e fazer o mundo pensar que
sabemos mais sobre gramática do que realmente fazemos. Também
estamos muito contentes por ter trabalhado com a equipe de acabamento
no The Frontispiece pela primeira vez, e estamos ansiosos em trabalhar
com eles novamente.
RECONHECIMENTOS DO JOSH
Para a equipe da Product School, obrigado por me dar a oportunidade de
escrever este livro! Eu devo ao CEO da Product School, Carlos González
de Villaumbrosia, uma dívida de gratidão por me incluir na Product
School e me dar esta oportunidade.
Eu realmente aprecio o apoio moral que recebi da minha família e dos
amigos, incluindo Ellen Anon, Jack Anon, Seth Anon, Eliot Peper e Kellie
Hudson. Obrigado à equipe de produtos da Magic Leap, incluindo Jeff
Gattis, Sakina Groth e Cole Shelton, por me ajudarem a ser um Product
Manager melhor.
Finalmente, devo mais uma vez agradecer à minha professora de
inglês Claudia Skerlong. No entanto, uma vez a ouvi dizer que ela achava
que Donald Trump ganharia um segundo mandato antes de eu escrever
um nono livro.
SOBRE OS AUTORES
Josh Anon é diretor de Product Management da Magic Leap e instrutor

de Product Management na Product School. Depois de se formar na
Universidade Northwestern com um diploma em ciência da computação,
ele passou os primeiros 10 anos de sua carreira na Pixar Animation
Studios. Ali, ele desempenhou vários papéis. Ele começou no grupo de
desenvolvimento de software, ajudando a criar ferramentas de fluxo de
trabalho e passou para o grupo de produção, trabalhando como câmera e
artistas de encenação, diretor técnico de simulação de multidões, diretor
técnico de otimização de renderização e mais, em vários filmes.
Da Pixar, ele se mudou para a Lytro, Inc. como gerente sênior de
produtos, onde ganhou experiência no desenvolvimento e comercialização
de um produto disruptivo. Josh liderou equipes interdisciplinares em
toda a empresa como proprietária de produtos para o aplicativo Lytro
Mobile, Lytro Illum e muito mais. Depois de Lytro, enquanto tentava
começar seu próprio estúdio de cinema, Josh trabalhou como consultor
de produtos para uma variedade de empresas e começou a trabalhar com
a Product School, projetando seus currículos. Ele também construiu e
enviou vários aplicativos de forma independente, incluindo o popular
programa de animação FlipBook para iOS. Fora do trabalho, Josh é um
fotógrafo profissional de meio período e também pode ser encontrado
em um kitesurf na praia.
Carlos González de Villaumbrosia é o fundador e CEO da Product
School. Ele tem oito anos de experiência na construção de equipes e
produtos digitais na Europa, América Latina e nos EUA.
Antes da Product School, Carlos era o co-fundador e CEO da Floqq,
cujos investidores incluíam 500 Startups. A Floqq era o maior mercado
de educação on-line da América Latina na época. Carlos supervisionou
todos os esforços de engenharia, design, produto e marketing, incluindo
a captação de recursos e expansão internacional.
Antes da Floqq, Carlos trabalhou como gerente de marketing de
produto na Involver (adquirida pela Oracle), a maior plataforma de
marketing social do mundo na época. Antes disso, ocupou cargos de
engenheiro de software e gerente de projetos de várias marcas de pequeno
e médio porte na Espanha.
Carlos é bacharel em ciência da computação pela Universidad
Complutense de Madrid, bacharel em engenharia de gestão pela
Universidade Pontifícia de Salamanca e certificado em gestão de negócios
globais e marketing pela Universidade da Califórnia, Berkeley.
Ao longo de toda a sua carreira, Carlos participou como palestrante
em mais de 1.000 eventos e aulas em todo o mundo. Fora do trabalho,
Carlos é um apaixonado jogador de futebol, esquiador e surfista.

The Product Book PT

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Product Book PT

Uploaded by

Copyright:

Available Formats

THE

CA R LOS G O NZÁL E Z D E VI LLAUM B RO S IA

Nenhuma parte desta publicação pode ser reproduzida, armazenada ou

ISBNS 978-0-9989738-8-3 IMPRESSÃO

DESIGN DO LIVRO POR The Frontispiece

PUBLICADO POR Product School

1 O Que é o Product Management 9

2 Estrategicamente Entendendo uma Empresa 36

3 Criando Oportunidades Hipotéticas 74

4 Validando suas Hipóteses 125

5 Colocando Ideias em Ação 170

6 Trabalhando com Design 214

7 Trabalhando com a Engenharia 246

8 Colocando seu Produto no Mercado 276

9 Finalizando o Ciclo de Desenvolvimento do Produto 317

Sobre os Autores 344

“Ninguém pediu para que você aparecesse”. Todo Product Manager 9

Essas simples perguntas são o que causam não apenas essa

O QUE UM PRODUCT MANAGER FAZ?

1. O Que é o Product Management

Os gerentes de projetos são mais frequentemente confundidos com

gerentes de projeto são mestres de cronogramas e gráficos de Gantt, não

1. O Que é o Product Management

onde o Product Management (idealmente) se situa em relação a outros

1. O Que é o Product Management

Figura 1-1. O Triângulo do Produto, mostrando o Product Management na interseção de três

Uma pergunta comum sobre como se tornar um PM é: quão técnico 15

facilita a transição porque, provavelmente, você saberá as respostas para

1. O Que é o Product Management

COMO OS PRODUCT MANAGERS CRIAM SEUS PRODUTOS

Na realidade, os produtos passam continuamente por um ciclo de

Embora as etapas estejam bem definidas, existem várias abordagens

1. O Que é o Product Management

A abordagem mais comum que você encontrará é um híbrido de

O desenvolvimento de produtos de hardware exige uma abordagem

1. Encontrar e planejar a oportunidade certa

Em outras palavras, esse processo envolve descobrir qual problema trabalhar

Conceitualmente, é! O mal está nos detalhes. Para ajudá-lo a ver como

Encontrando e Planejando a Oportunidade Certa

1. O Que é o Product Management

inteligente voltado para notícias ou outro produto de hardware.

A identificação clara dos objetivos da empresa, outro elemento

Além dessas, existem outras questões estratégicas do contexto da

comum de novas oportunidades, permitindo que você encontre maneiras

1. O Que é o Product Management

Depois de validar sua ideia, você precisará desenvolvê-la em algo

a oportunidade e os clientes que você deseja segmentar, juntamente com

Ao trabalhar em ambientes lean ou híbridos, muitas vezes, você ouvirá

Identificar o MVP é uma parte fundamental do escopo de um

Compare isso com abordagens não baseadas em MVP para o

1. O Que é o Product Management

Gastar muito tempo interagindo internamente e construindo recursos

poderíamos usar as métricas do site para priorizar esses recursos, mas

A maioria das empresas que usa um modelo híbrido nunca constrói

Às vezes, como discutiremos no Capítulo 4, seu primeiro MVP será

Tão importante quanto definir o escopo do problema é definir suas

Voltando à CNN.com, seu objetivo final pode ser se tornar o local de

1. O Que é o Product Management

Um dos maiores motivos pelos quais outras partes interessadas, como

Os PRDs ganharam uma má reputação através do desenvolvimento

Aqui, os PMs trabalharão principalmente com a equipe de projeto,

última hora tenham um vídeo de 360° transmitido ao vivo para colocar os

Embora o próprio PM não consiga a solução sozinho, ele continuará

1. O Que é o Product Management